So, I’m trying to fix some issues regarding Blender’s FBX export towards UE4, and investigating that bug report, I found out UE4 (v4.4.2) seems to apply bones’ animations without taking ‘rest pose’ (i.e. binding pose, as defined in Clusters deformers) into account.
Here is a capture of the [.blend file][1] in Blender:
So, I do not know what is the expected behavior here, since I do not know any specification for FBX. At least, with this same file, Unity plays expected animation.
On my side (Blender exporter), I could add an option to export animations with ‘rest pose’ offset, but would not really consider this a good thing (adds needless complexity, and imho we should not have such big differences in behavior here, does not make sense).
But I’d rather have your point of view on this issue, since you also may know better about FBX expected data here.
Can you take a screenshot of your .fbx in blender and in the editor so I can see the difference? Other than having no animation to see what you mean I am not seeing anything on my end that is as you have described.
Hi, I opened your file with Autodesk’s FBX Review, which also shows a messed up animation (because of the lost bone offset). Taking this as an ‘official’ program from the developers of this file format … isn’t this problem only related to Blender’s messy binary FBX export in 2.71?
I’m no more confident in FBX Preview than any other app using the FBX SDK, tbh. Personnaly, I even doubt Autodesk itself has a clear specifications of this format, or at least I doubt they fully follow it in all their product…
Anyway, it could obviously very well be an issue on Blender exporter side, I just do not know! The fact that Unity plays it correctly does not help, since there is no way to know which way of interpreting bone anim is “right”…
I see what happened now! Both Maya and Blender are set so that the Y axis is your up axis. In UE4, the Z axis is up. All you should have to do is rotate to allow the Z axis to be your up axis and it should fix this error.
Eeeeh… Not sure if you are refering to global orientation, or bones alignement?
In Blender, global Up axis is Z (-Y is forward), but we convert to Y Up by default when exporting to FBX, since most target apps use that. In any case, this should not be an issue, FBX stores this orientation data, and iirc the FBXSDK provides helpers to make conversions between global orientations.
Anyway, I tried exporting with global Z Up (-Y Forward), no change at all: Z up, -Y Forward
As for bones, Blender indeed use Y as ‘main’ axis, not so sure this is important for FBX since afaik it uses a ‘joint’ model, not a ‘bone’ one. Anyway, tried with the exprimental exporter to change bones’ main axis to Z, no luck here either… Y Up, -Z Forward, Bones aligned to Z
Hi everyone! I’m the Blender/UE4 user who Bug Reported this issue to Mont at Blender Foundation after encountering this issue inside UE4 with a Spaceship & Canopy exported from Blender 2.71.6 using the 7.4 FBX Exporter. I also constructed the Car and Sun Roof Blender file to demonstrate this issue. I’m just a 3D artist and know nothing about programming, but if there’s anything I can do to help please let me know. Thanks so much to all of you for trying to fix this issue and make the Blender → UE4 Pipeline better for everyone. Cheers!
For example if you want me to construct a Blend file featuring Skeletal Mesh’s with varying Bone Rotations to demonstrate the differing results of different bone rotations., I could do that. I’ll have a think about it and let ya know if I come with anything. Thx!
That would be immensely helpful! The more obvious the effect the better so I can understand whether this is primarily on our end or theirs that the error occurs. We want to make sure you have a good experience exporting from blender!
It’s not clear where this goes wrong from this. We do consider bind pose but from my experience with blender was that scene information is wrong - including unit or coordinate. Still that shouldn’t mess up animation.
You can see bind pose from “show reference pose”. Also note that we only look for bind pose - in FBX term, bind pose and rest pose are different.
Also try to import by disabling convert scene. I doubt that would help for this but it may be worth to try.
Either way, I’ll ask this to be added to our database.
Okay, so I have done a bit more testing with this error, trying to replicate the problem in a few different ways. Here’s what I discovered.
First I tried to replicate the error with a slightly different skeletal mesh, that theoretically should have had the same problem: That any bone off set from its parent with translation data would have an incorrect position in UE4. But the problem was not replicated. Here are screens of that Skeletal Mesh in Blender and UE4.
All the bones are in the correct position and the animation works fine. “That’s Strange!!” I said to myself. This Skeletal Mesh has essentially the same set up as The Car Sun Roof file. “Maybe I had made a mistake in the Car Sun Roof file?” I thought to myself. So I reconstructed The Car Sun Roof test file again from scratch this afternoon, but indeed I got the same error. “What was the only difference between The Car Sun Roof Test and new simple Skeletal Mesh test I had built today?” I asked myself.
The only fundamental difference is that in the Car Sun Roof Test one of the Bones that has translation data is offset vertically from its parent, and so the error occurs, as we have seen.
In the first simple Skeletal Mesh test I made today none of the Bones with translation data are offset in space vertically from their parent and so, amazingly, no error occurs.
So I decided to make another version of this simple Skeletal Mesh test but with one of its Bones that has translation data offset vertically from its parent. And voila!! The Error is there again. See the screens here:
Conclusion: Only bones with vertical offset from the parent AND translation data lose their correct world position - being incorrectly snapped to their parent On the right hand side of the SimpleSkeletalMesh you can see the shoulder that does not have translation data, only rotation data, and its child has translation data, but that does not return an error.
I understand that this may not be conclusive evidence of the cause of the bug, but I hope it points us closer to it.
Just checking to see if there is any update on this issue. I’m a Blender user facing the same issue described here, would be great to know if anything new was discovered on this issue.
I did try 2.73 as well, no luck. From OP’s explanation (mont29 is from Blender foundation I believe) I understand the fix possibly resides in Epic’s importer rather than in Blender.
I’ve created a forum thread for other Blender users to pitch in on which version of the exporter they’re using so that we can get more focus on this issue if many people are found to be using the older version of the exporter simply to work around this issue.
Yes, I’m ‘from’ Blender foundation - have been fighting with FBX IO since over one year now…
And again, I’m not sure at all the issue is on UE4 side - I really do not know, which is always the problem with FBX, since there are so few serious informations about that format. The only thing that makes me believe this is that Unity imports (afaik) those files without any issue.
Technically speeking, I’m currently wondering if it could be that Blender exporter does not generates bindposes at all (those contain redundant binding matrices, that are already available in deformers, so…), and that UE4 still relies on those bindposes to get binding matrices, not taking into account those from deformers?
Hi mont29, just checking whether you can comment on 's question.
I wanted to keep this thread alive as it’s been a while since this issue has been lingering. My thanks to everyone from both Blender and Epic for looking into this issue.
