FBX exporter applying incorrect rotation to some bones #41254

Closed
opened 2014-07-30 18:01:56 +02:00 by M. Lewis · 43 comments

Blender 2.71 / Linux

FBX exporter is applying incorrect rotations to some bones in the armature.

The error can be reproduced by selecting the armature in Blender and exporting using the fbx exporter. The export options are: Selected Objects, -Z forward/Y up, export Armature only, Apply Modifiers, Baked Anim, NLA Strips.

If you perform an export and then open the exported file in a 3rd party viewing, you will see that the jaw bone is rotated 90 degrees from where it should be. This is causing severe distortion in the attached mesh.

Screen shot of resulting error when viewed outside of Blender:
http://www8.zippyshare.com/v/51998258/file.html (jpeg file)

Closer examination of the exported skeleton shows that the Y and Z axis appear swapped. Any bones which have the errant bone as a parent are also out of position. I tried re-animating the jaw using both quaternion and euler rotations with no change. The jaw itself doesn't have any animation applied outside of a key set to the rest position.

I also noticed that one the bones used to move the eyes sometimes gets misplaced as well. But it doesn't show because there are no vertices assigned to it. Both these bones share the same parent bone (head). The parent bone appears to be correctly positioned and rotated. Re-parenting the jaw bone to another bone (neck) had no effect.

source: http://www.roboticgladiator.com/basic_male8.blend

Blender 2.71 / Linux FBX exporter is applying incorrect rotations to some bones in the armature. The error can be reproduced by selecting the armature in Blender and exporting using the fbx exporter. The export options are: Selected Objects, -Z forward/Y up, export Armature only, Apply Modifiers, Baked Anim, NLA Strips. If you perform an export and then open the exported file in a 3rd party viewing, you will see that the jaw bone is rotated 90 degrees from where it should be. This is causing severe distortion in the attached mesh. Screen shot of resulting error when viewed outside of Blender: http://www8.zippyshare.com/v/51998258/file.html (jpeg file) Closer examination of the exported skeleton shows that the Y and Z axis appear swapped. Any bones which have the errant bone as a parent are also out of position. I tried re-animating the jaw using both quaternion and euler rotations with no change. The jaw itself doesn't have any animation applied outside of a key set to the rest position. I also noticed that one the bones used to move the eyes sometimes gets misplaced as well. But it doesn't show because there are no vertices assigned to it. Both these bones share the same parent bone (head). The parent bone appears to be correctly positioned and rotated. Re-parenting the jaw bone to another bone (neck) had no effect. source: http://www.roboticgladiator.com/basic_male8.blend
Author

Changed status to: 'Open'

Changed status to: 'Open'
Author

Added subscriber: @Ryoko

Added subscriber: @Ryoko
Jens Restemeier was assigned by Bastien Montagne 2014-07-30 19:18:24 +02:00

Added subscriber: @mont29

Added subscriber: @mont29

basic_male8.blend

Jens, assigning to you, since it’s likely to be related to that bone orientation mess issue? Do not hesitate to reassign to me in case it would be different issue…

[basic_male8.blend](https://archive.blender.org/developer/F100297/basic_male8.blend) Jens, assigning to you, since it’s likely to be related to that bone orientation mess issue? Do not hesitate to reassign to me in case it would be different issue…

Ah, and for the records, files exported do re-import nicely in Blender with our own exporter, so it seems to be a 'global' issue in how all those matrices are handled…

Ah, and for the records, files exported do re-import nicely in Blender with our own exporter, so it seems to be a 'global' issue in how all those matrices are handled…

No problem. Ryoko, which application is used to view the FBX file?

Bastien, I think the problem is that other applications may have a different concept for bones. For example Maya stores "joints", and bones are just drawn as connection between joints. So where you would model one Blender bone you would model two Maya joints. Or if you have a skeleton, you would have one extra joint at the tip of each leaf bone. I have to finish some debugging before I can open my test scenes to see how that maps onto FBX.

No problem. Ryoko, which application is used to view the FBX file? Bastien, I think the problem is that other applications may have a different concept for bones. For example Maya stores "joints", and bones are just drawn as connection between joints. So where you would model one Blender bone you would model two Maya joints. Or if you have a skeleton, you would have one extra joint at the tip of each leaf bone. I have to finish some debugging before I can open my test scenes to see how that maps onto FBX.

Yep, those differences in bones concepts are really an pita, esp. since it looks like FBX does not really enforce any approach :/

Btw, think Ryoko tested with UE4 and FBXViewer (we talked earlier today on IRC)

Yep, those differences in bones concepts are really an pita, esp. since it looks like FBX does not really enforce any approach :/ Btw, think Ryoko tested with UE4 and FBXViewer (we talked earlier today on IRC)
Author

UE4 has it's own issues with fbx files. But the problem also appears in the Banzai viewer.

Also, I don't know if it's an indication of another problem or just FBXViewer being fussy. But FBX Viewer is reluctant to load the binary output from the exporter without converting it to ascii first. The converter has no problem reading the exported binaries however. Not sure what to think about that.

UE4 has it's own issues with fbx files. But the problem also appears in the Banzai viewer. Also, I don't know if it's an indication of another problem or just FBXViewer being fussy. But FBX Viewer is reluctant to load the binary output from the exporter without converting it to ascii first. The converter has no problem reading the exported binaries however. Not sure what to think about that.

Do you have a link for "Banzai viewer"? Is it this one: http://bonzaiengine.com/modelviewer.php ?

Do you have a link for "Banzai viewer"? Is it this one: http://bonzaiengine.com/modelviewer.php ?

Just a quick update: I was able to reproduce it in FBX Viewer (https://code.google.com/p/fbxviewer/ ) . I had to port it to the latest version of the FBX SDK because the API changed quite a bit...
The problem seems to be related to the FBX SDK (at least version 2013<= and 2015) and animations, but just the skeleton looks fine. Both work fine in Unity3D.
The data in the FBX file looks fine, so maybe the SDK just gets confused by something. You would expect this to break the whole model instead of a single bone, though.

Just a quick update: I was able to reproduce it in FBX Viewer (https://code.google.com/p/fbxviewer/ ) . I had to port it to the latest version of the FBX SDK because the API changed quite a bit... The problem seems to be related to the FBX SDK (at least version 2013<= and 2015) and animations, but just the skeleton looks fine. Both work fine in Unity3D. The data in the FBX file looks fine, so maybe the SDK just gets confused by something. You would expect this to break the whole model instead of a single bone, though.

See two explanations, then:

  • New SDK is buggy! (:P)
  • Tools start to really support FBX7.4, and something changed (again…) in it compared to 7.3, which reveals the breakage… Find this rather unlikely though, tbh.

And yes, the fact that only a tiny part of the rigging is affected is rather suspicious…

See two explanations, then: * New SDK is buggy! (:P) * Tools start to really support FBX7.4, and something changed (again…) in it compared to 7.3, which reveals the breakage… Find this rather unlikely though, tbh. And yes, the fact that only a tiny part of the rigging is affected is rather suspicious…
Author

FYI: UE4 is using the 2014.2.1 SDK which has the bug. It's really is odd this bone has been singled out, especially since it's a really simple bone with essentially no animation applied to it other than a rest position.

Is there a version of the SDK which works correctly?

FYI: UE4 is using the 2014.2.1 SDK which has the bug. It's really is odd this bone has been singled out, especially since it's a really simple bone with essentially no animation applied to it other than a rest position. Is there a version of the SDK which works correctly?

No idea... the version used for FBX Viewer originally shows the problem and the version I've got installed on my machine shows it.
I had an interesting observation with the old ascii exporter. If you switch to the FBX 6.1 ASCII exporter when writing the model the result doesn't show the jaw problem. Though I didn't have time to compare the output files, yet. (I've got to make some progress on my scheduled work...)

No idea... the version used for FBX Viewer originally shows the problem and the version I've got installed on my machine shows it. I had an interesting observation with the old ascii exporter. If you switch to the FBX 6.1 ASCII exporter when writing the model the result doesn't show the jaw problem. Though I didn't have time to compare the output files, yet. (I've got to make some progress on my scheduled work...)

Added subscriber: @S_Wilke

Added subscriber: @S_Wilke

Im also using UE4 and have the same issue. For now im using the 6.1 ASCII exporter but unfortunetly this does not support Normal-Tangent so in some cases normals have random seams but for now i can live with this problem.

As far a far as i can tell the problem looks like:

  • bone-rotation gets only messy if the bone is not animated in the animation (subtle animating the bone for 0.01 degree fixes it for me)
  • rotation errors seem to be handed to the the next animation/action (an inanimated bone could work fine for 3 animations but the 4th animation and forward breaks it, till the bone gets animated again)
  • If the same animation or model is exported multiple times, the results are always the same. I tested a newer version of the fbx-import/exporter from a nightly build and while it still has this problem, the bone rotation degrees of the errors are now a little bit different, the issues were again on the same bones.

I hope this observation can somehow help with the problem.

Im also using UE4 and have the same issue. For now im using the 6.1 ASCII exporter but unfortunetly this does not support Normal-Tangent so in some cases normals have random seams but for now i can live with this problem. As far a far as i can tell the problem looks like: - bone-rotation gets only messy if the bone is not animated in the animation (subtle animating the bone for 0.01 degree fixes it for me) - rotation errors seem to be handed to the the next animation/action (an inanimated bone could work fine for 3 animations but the 4th animation and forward breaks it, till the bone gets animated again) - If the same animation or model is exported multiple times, the results are always the same. I tested a newer version of the fbx-import/exporter from a nightly build and while it still has this problem, the bone rotation degrees of the errors are now a little bit different, the issues were again on the same bones. I hope this observation can somehow help with the problem.

Added subscriber: @Alphanumber

Added subscriber: @Alphanumber

Would like to chime in with my own experience with FBX export from Blender to UE4. Spent quite a bit of time trying to rig characters with Rigify and bring into UE4. The rigs would always break where child bones would take on transforms of the parent bones. I tried creating a simpler rig to isolate the problems into reproducible steps.

As Stefan has mentioned, if a bone doesn't have any delta transform, either translation or rotation, the bone may take on transforms of the parent. The child bone then needs to be animated to fix the issue. However, there were also times that I had to animate the parent bone to fix an issue with the child bone. Rather than play that game of whack-a-mole, I wrote a quick script to iterate through all the bones for one keyframe and key with some token delta (micrometers in length and a fraction of a degree). By ensuring that each bone has at least some animation somewhere in the export, the animations end up being fixed in UE4.

I also ran into an issue where after creating my fourth action, the third would break. I have no idea what's up with that.

I created a AnswerHub report here with my findings if useful.

Would like to chime in with my own experience with FBX export from Blender to UE4. Spent quite a bit of time trying to rig characters with Rigify and bring into UE4. The rigs would always break where child bones would take on transforms of the parent bones. I tried creating a simpler rig to isolate the problems into reproducible steps. As Stefan has mentioned, if a bone doesn't have any delta transform, either translation or rotation, the bone may take on transforms of the parent. The child bone then needs to be animated to fix the issue. However, there were also times that I had to animate the parent bone to fix an issue with the child bone. Rather than play that game of whack-a-mole, I wrote a quick script to iterate through all the bones for one keyframe and key with some token delta (micrometers in length and a fraction of a degree). By ensuring that each bone has at least some animation somewhere in the export, the animations end up being fixed in UE4. I also ran into an issue where after creating my fourth action, the third would break. I have no idea what's up with that. I created a AnswerHub report [here ](https://answers.unrealengine.com/questions/180277/blender-fbx-animation-bones-default-to-parent-tran.html) with my findings if useful.

Added subscriber: @PeteX-2

Added subscriber: @PeteX-2

I think I've encountered the same problem in a different guise, but if you'd rather I submitted this as a separate bug report, please let me know.

I downloaded the demo third person skeleton that comes with Unreal (https://cdn.unrealengine.com/marketplace_samples/Epic_Skeleton_Template.fbx). I imported this into Blender, then exported it as a binary FBX. I imported this binary FBX into Unreal and told it to use the standard third person skeleton rather than creating a new one.

The idea is that I would design my character around the Epic_Skeleton_Template. I would then import the character into Unreal and it would benefit from all the animations that already exist for that skeleton.

When I play one of the regular animations, say the walk cycle, all the body parts are rotated through 90 degrees. For example, the upper arm will stick out perpendicular to the arm bones. It will be detached from the lower arm, which will also be sticking out perpendicular, and so on.

If I design my own animation, everything works as expected. However, the problem then occurs if I attempt to use that animation with one of the models distributed by Epic.

What I'm guessing is that things are being exported with the wrong axes or something like that. The problem is consistent throughout the exporter, so if you export an animation, it has the wrong axes too and everything cancels out.

I hope this explanation is clear but if you'd like screenshots or sample files, just let me know. Thanks for all the work you're doing with Blender.

I think I've encountered the same problem in a different guise, but if you'd rather I submitted this as a separate bug report, please let me know. I downloaded the demo third person skeleton that comes with Unreal (https://cdn.unrealengine.com/marketplace_samples/Epic_Skeleton_Template.fbx). I imported this into Blender, then exported it as a binary FBX. I imported this binary FBX into Unreal and told it to use the standard third person skeleton rather than creating a new one. The idea is that I would design my character around the Epic_Skeleton_Template. I would then import the character into Unreal and it would benefit from all the animations that already exist for that skeleton. When I play one of the regular animations, say the walk cycle, all the body parts are rotated through 90 degrees. For example, the upper arm will stick out perpendicular to the arm bones. It will be detached from the lower arm, which will also be sticking out perpendicular, and so on. If I design my own animation, everything works as expected. However, the problem then occurs if I attempt to use that animation with one of the models distributed by Epic. What I'm guessing is that things are being exported with the wrong axes or something like that. The problem is consistent throughout the exporter, so if you export an animation, it has the wrong axes too and everything cancels out. I hope this explanation is clear but if you'd like screenshots or sample files, just let me know. Thanks for all the work you're doing with Blender.

Added subscriber: @Cancer-2

Added subscriber: @Cancer-2

That is the same thing I have found PeteX. If we make custom stuff from scratch and don't care about compatibility, we can do everything already. But like you said, you can't work with the standard "Epic_Skeleton_Template" which unfortunately, is the standard Epic is also using for buying/selling characters and accessories on the workshop.

It's not the worst limitation in the world, but unelss it's fixed, Blender will be behind other software that don't suffer said limitations.

I wanted to make a removable Jacket for the "Epic_Skeleton_Template" but I cannot and I've tried every which way, with every setting combination.

NOTE: the problem, might not even be with the exporter, it might just be that the IMPORT is bringing in wrong rotations and then of coarse, garbage in, garbage out..... It's a possibility anyways.

UE4 documents state that they are using FBX 2014.2.1 and that using any other import/export version of the FBX standard (newer or older) might likely lead to these sorts of incompatibilities.

Cheers

That is the same thing I have found PeteX. If we make custom stuff from scratch and don't care about compatibility, we can do everything already. But like you said, you can't work with the standard "Epic_Skeleton_Template" which unfortunately, is the standard Epic is also using for buying/selling characters and accessories on the workshop. It's not the worst limitation in the world, but unelss it's fixed, Blender will be behind other software that don't suffer said limitations. I wanted to make a removable Jacket for the "Epic_Skeleton_Template" but I cannot and I've tried every which way, with every setting combination. NOTE: the problem, might not even be with the exporter, it might just be that the IMPORT is bringing in wrong rotations and then of coarse, garbage in, garbage out..... It's a possibility anyways. UE4 documents state that they are using FBX 2014.2.1 and that using any other import/export version of the FBX standard (newer or older) might likely lead to these sorts of incompatibilities. Cheers

@Cancer-2—I've done some more work on this, and I've found a partial work-around. It does what I want: I can design characters in Blender, bring them into Unreal, then use them with the standard animations. I think it may not work for you, if you want to design clothes for the standard models.

In any case, I've put an explanation at https://forums.unrealengine.com/showthread.php?28882-Blender-to-UE4-using-UE4-animations. (It's currently the last post, but you'll probably find the whole thread informative, I know I did.)

I'm interested to know if you think I'm right. :-) I don't know Maya so it's hard to know if I understood the problem correctly.

@Cancer-2—I've done some more work on this, and I've found a partial work-around. It does what I want: I can design characters in Blender, bring them into Unreal, then use them with the standard animations. I think it may not work for you, if you want to design clothes for the standard models. In any case, I've put an explanation at https://forums.unrealengine.com/showthread.php?28882-Blender-to-UE4-using-UE4-animations. (It's currently the last post, but you'll probably find the whole thread informative, I know I did.) I'm interested to know if you think I'm right. :-) I don't know Maya so it's hard to know if I understood the problem correctly.
Jens Restemeier removed their assignment 2015-03-17 17:22:22 +01:00
Bastien Montagne was assigned by Jens Restemeier 2015-03-17 17:22:22 +01:00

TLDR: I think everything is fine as is, I'm just a bit of a perfectionist and would like to push the bar to utter perfection. Thank you.

@PeteX-2 - That may be a solution going forward (in which case no further work has to be done). That certainly works for creating a compatible (after the fact) skeleton for copying over animation. It doesn't however, allow the function "add body part" inside of the original mesh to work (that requires that all meshes are using the same skeleton inside of UE4, not just similar ones), however... I've looked a lot into that function "add body part" and I'm not sure how thoroughly used it is outside of doing ones own custom work (in which case compatibility is not needed and we have what we need to get going just fine). The reason I say this last part is because I purchased a standard man compatible mesh on the workshop store, and it's own "add body part" function only works with the two meshes it came with, it does not register to work with the default blue man. I think it is possible that I am just being a perfectionist, demanding the absolute best and most.

Basically what this all means is that if you were going to make custom, deformable armor for the default hero, that would follow along with the animation of your character, that you may have to take extra steps to make sure that the hero's animations properly trigger the copied animations on your armor skeleton (since they are not sharing a skeleton). This step would not be needed if we could import the armor onto the existing default skeleton, in which case it wouldn't have it's own similar but unique skeleton but would be sharing the UE4 Mans skeleton and many steps could be skipped.

I am happy with where we are now, I hope for more, but as I have looked around at other packages, this is mostly a problem with the .FBX format, as even packages like Houdini are having the same exact issues, word for word, step for step that Blender has mostly already solved.

TLDR: I think everything is fine as is, I'm just a bit of a perfectionist and would like to push the bar to utter perfection. Thank you. @PeteX-2 - That may be a solution going forward (in which case no further work has to be done). That certainly works for creating a compatible (after the fact) skeleton for copying over animation. It doesn't however, allow the function "add body part" inside of the original mesh to work (that requires that all meshes are using the same skeleton inside of UE4, not just similar ones), however... I've looked a lot into that function "add body part" and I'm not sure how thoroughly used it is outside of doing ones own custom work (in which case compatibility is not needed and we have what we need to get going just fine). The reason I say this last part is because I purchased a standard man compatible mesh on the workshop store, and it's own "add body part" function only works with the two meshes it came with, it does not register to work with the default blue man. I think it is possible that I am just being a perfectionist, demanding the absolute best and most. Basically what this all means is that if you were going to make custom, deformable armor for the default hero, that would follow along with the animation of your character, that you may have to take extra steps to make sure that the hero's animations properly trigger the copied animations on your armor skeleton (since they are not sharing a skeleton). This step would not be needed if we could import the armor onto the existing default skeleton, in which case it wouldn't have it's own similar but unique skeleton but would be sharing the UE4 Mans skeleton and many steps could be skipped. I am happy with where we are now, I hope for more, but as I have looked around at other packages, this is mostly a problem with the .FBX format, as even packages like Houdini are having the same exact issues, word for word, step for step that Blender has mostly already solved.

Added subscriber: @rimau

Added subscriber: @rimau

@rimau found a very nice piece of info in #41719:

I can confirm one thing: the bones that are causing problems are the bones with rotation values at 0, but they are transformed by the animation of parent bones. Like Positivity found out in some other thread, applying any rotation (even the slightest one) directly to the corrupted bone, solves the problem.He tested out my .blend file, I did test it again afterwards, and it works. So the problem is somehow connected to the transformations of the bones that are having zero values in themselfs, but are animated due to the parent bones transforation.

I could confirm that, and this behavior makes absolutely no sense to me… Would be nice though if you could check your problematic files and see whether, ensuring all your bones are slightly rotated compared to rest pose (even 0.1° is enough), issue get 'fixed' with UE4?

@rimau found a very nice piece of info in #41719: > I can confirm one thing: the bones that are causing problems are the bones with rotation values at 0, but they are transformed by the animation of parent bones. Like Positivity found out in some other thread, applying any rotation (even the slightest one) directly to the corrupted bone, solves the problem.He tested out my .blend file, I did test it again afterwards, and it works. So the problem is somehow connected to the transformations of the bones that are having zero values in themselfs, but are animated due to the parent bones transforation. I could confirm that, and this behavior makes **absolutely** no sense to me… Would be nice though if you could check your problematic files and see whether, ensuring all your bones are slightly rotated compared to rest pose (even 0.1° is enough), issue get 'fixed' with UE4?

I came across that post when I was first trying to solve this problem. Making the rotations non-zero didn't help me, but perhaps I was doing something subtly different to the author of that post.

Incidentally, there is a converter distributed by a third party that uses the Autodesk library (http://blenderfbx.render.jp/). Using this for import creates a skeleton with different rest bone rotations, but using it for export doesn't help with the twisted geometry issue we've been talking about. This is one of the things that makes me think the problem may be with the representation of the skeleton in Blender, rather than the exporter as such.

(I also had no luck exporting to Collada and converting to FBX using the Autodesk tool. Unfortunately I can't remember exactly what went wrong, so this probably isn't much help. :-) )

I came across that post when I was first trying to solve this problem. Making the rotations non-zero didn't help me, but perhaps I was doing something subtly different to the author of that post. Incidentally, there is a converter distributed by a third party that uses the Autodesk library (http://blenderfbx.render.jp/). Using this for import creates a skeleton with different rest bone rotations, but using it for export doesn't help with the twisted geometry issue we've been talking about. This is one of the things that makes me think the problem may be with the representation of the skeleton in Blender, rather than the exporter as such. (I also had no luck exporting to Collada and converting to FBX using the Autodesk tool. Unfortunately I can't remember exactly what went wrong, so this probably isn't much help. :-) )

Changing bones to have non-zero degree rotation values doesn't help if all other keys stay at the same non-zero value. What fixes the issue seems to be keying actual change, not just keying keyframes.

For example, I can change my animation so that the bones can be rotated at .1 degrees rather than 0 degrees throughout the animation, but the animation will still break and bones will still twist. If the bones are rotated 0 degrees at one keyframe and then the next keyframe is rotated to .1 degree, that tends to fix the animation. I think the absence of local change in the bones may be part of the problem.

Changing bones to have non-zero degree rotation values doesn't help if all other keys stay at the same non-zero value. What fixes the issue seems to be keying actual change, not just keying keyframes. For example, I can change my animation so that the bones can be rotated at .1 degrees rather than 0 degrees throughout the animation, but the animation will still break and bones will still twist. If the bones are rotated 0 degrees at one keyframe and then the next keyframe is rotated to .1 degree, that tends to fix the animation. I think the absence of local change in the bones may be part of the problem.

Hey guys, I forced a new build on our buildbot, which shall have the fix for #41719, please check your problematic files and report here the results (dreaming that it solves everything would be insane, but since FBX itself is insane…).

Hey guys, I forced a new build on [our buildbot](https://builder.blender.org/download), which shall have the fix for #41719, please check your problematic files and report here the results (dreaming that it solves everything would be insane, but since FBX itself is insane…).

I tried a few historically troubled rigs and the animations look good so far. I'll continue to keep testing to see if there are any other trouble cases, but I'm thinking this will fix a significant amount if not all of the animation issues.

I tried a few historically troubled rigs and the animations look good so far. I'll continue to keep testing to see if there are any other trouble cases, but I'm thinking this will fix a significant amount if not all of the animation issues.

Thanks, this sounds really encouraging! I'll check this as soon as I get some time. Presumably I want the official build (not gooseberry) without cmake?

Thanks, this sounds really encouraging! I'll check this as soon as I get some time. Presumably I want the official build (not gooseberry) without cmake?

Tested on my problematic rig, and it works just fine :) I will make a set of a few new animations tomorrow, and test them out in UE4, but right now the old animations that were corrupted are OK after just re-exporting them with the new build.
I did also re-exported them once again in 2.73 just to make sure that I didn't mess up anything and everything works like expected: 2.73 = corrupted rotations, 2.74 = correct rotations.
Will post additional info tomorrow.

Tested on my problematic rig, and it works just fine :) I will make a set of a few new animations tomorrow, and test them out in UE4, but right now the old animations that were corrupted are OK after just re-exporting them with the new build. I did also re-exported them once again in 2.73 just to make sure that I didn't mess up anything and everything works like expected: 2.73 = corrupted rotations, 2.74 = correct rotations. Will post additional info tomorrow.

I have a test if someone wouldn't mind trying it. I'm having difficulties.

  1. Make a UE4 3rd Person Blueprint Template and open it. (UE4 v4.73)
  2. Select "ThirdPersonSkelMesh" in the ThirdPersonBP/Character folder
  3. Right click it > asset actions > export .FBX

Now we have a test file straight out of the engine, nothing custom. Now comes the test...

A. Import it into Blender (I don't know what settings for Blender scene or what settings for the .FBX importer).
B. Export it from Blender (again I don't know what settings)
C. Import it back into the previous UE4 scene and when the import dialog pops up, under Mesh>Skeleton, pulldown and select Third Person Skeleton from the list. (aside from that requirement, I don't know what other settings might need to be adjusted)
D. Once it's imported without any complaints from the engine (a trick in and of itself), double click your newly imported skeletal mesh, go to the animation tab, and try to play one of the animations that in inherits.

Is there currently some combination of Scene, Import, Export, and Import settings, that will get us from step 1 to step D with the animations playing back properly. So far I have not found it but I am still trying.

I have a test if someone wouldn't mind trying it. I'm having difficulties. 1. Make a UE4 3rd Person Blueprint Template and open it. (UE4 v4.73) 2. Select "ThirdPersonSkelMesh" in the ThirdPersonBP/Character folder 3. Right click it > asset actions > export .FBX Now we have a test file straight out of the engine, nothing custom. Now comes the test... A. Import it into Blender (I don't know what settings for Blender scene or what settings for the .FBX importer). B. Export it from Blender (again I don't know what settings) C. Import it back into the previous UE4 scene and when the import dialog pops up, under Mesh>Skeleton, pulldown and select Third Person Skeleton from the list. (aside from that requirement, I don't know what other settings might need to be adjusted) D. Once it's imported without any complaints from the engine (a trick in and of itself), double click your newly imported skeletal mesh, go to the animation tab, and try to play one of the animations that in inherits. Is there currently some combination of Scene, Import, Export, and Import settings, that will get us from step 1 to step D with the animations playing back properly. So far I have not found it but I am still trying.

No noticeable change for me, I'm afraid. I still get the problems I reported before.

@Cancer-2, I'm seeing the same behaviour as you when I export and re-import the Epic third person character. I have noticed something that might help you with your project to design clothes for the Epic skeleton. (Just to be clear, this behaviour is the same with the test and released builds of Blender.) If you import the skeleton with automatic bone orientation turned off, you will end up with a weird skeleton where the bones all point in funny directions. However, if you export this back to Unreal, it will almost work. You just have to flip a couple of bones manually, and you can have a skeleton that exports back to Unreal successfully. It would be very hard to use this skeleton for animating because none of the bones are connected, and can't be connected because they are pointing in the wrong directions and so don't line up. However, it might just work for clothes. You might also be able to design with a different copy of the skeleton, then substitute this funny one before you export to Unreal. It will be a pain but it might just work.

@mont29, thanks for all your work with this bug, even though it didn't solve my specific problem.

No noticeable change for me, I'm afraid. I still get the problems I reported before. @Cancer-2, I'm seeing the same behaviour as you when I export and re-import the Epic third person character. I have noticed something that might help you with your project to design clothes for the Epic skeleton. (Just to be clear, this behaviour is the same with the test and released builds of Blender.) If you import the skeleton with automatic bone orientation turned off, you will end up with a weird skeleton where the bones all point in funny directions. However, if you export this back to Unreal, it will almost work. You just have to flip a couple of bones manually, and you can have a skeleton that exports back to Unreal successfully. It would be very hard to use this skeleton for animating because none of the bones are connected, and can't be connected because they are pointing in the wrong directions and so don't line up. However, it might just work for clothes. You might also be able to design with a different copy of the skeleton, then substitute this funny one before you export to Unreal. It will be a pain but it might just work. @mont29, thanks for all your work with this bug, even though it didn't solve my specific problem.

I'll try that PeteX, thank you so much.

And thank you Mont for your continued work on this, must be frustrating as hell.

I'll try that PeteX, thank you so much. And thank you Mont for your continued work on this, must be frustrating as hell.

Hi

I have just made a few new animations. Everything works perfect for me. I was able to put together all the animations that I needed for my character, using the exact same rig as before.

@PeteX-2, @Cancer-2 - your problems may be originating somehow form the fact that you are importing an FBX skeleton. As far as I understand you are both doing that? Or have you tried creating a rig from scratch in Blender?

Hi I have just made a few new animations. Everything works perfect for me. I was able to put together all the animations that I needed for my character, using the exact same rig as before. @PeteX-2, @Cancer-2 - your problems may be originating somehow form the fact that you are importing an FBX skeleton. As far as I understand you are both doing that? Or have you tried creating a rig from scratch in Blender?

@rimau, creating a rig from scratch in Blender, then exporting, works fine for me (with the released version of Blender too). I'd just like to be able to work with the standard Epic skeleton, so I can use the Epic animations without converting them.

@rimau, creating a rig from scratch in Blender, then exporting, works fine for me (with the released version of Blender too). I'd just like to be able to work with the standard Epic skeleton, so I can use the Epic animations without converting them.

That is correct rimau. I don't have ANY (serious) problems (that I know of yet) when I make things from scratch in Blender, and I often use the old 6.1 exporter combined with a bag of work-around tricks and for my current stage of development, it seems to fufill it's role quite nicely (thank you for that Mont!).

There are a lot of workflow benefits for UE4/Blender artists if Blender's .FBX import/export can be taken a few steps further. As a game developer, it's my number one feature wish for Blender. (more flexability with workflow, less work-arounds and tricks and steps to get everything working, easier to work with a team of artists who are using various software, etc., etc.)

That is correct rimau. I don't have ANY (serious) problems (that I know of yet) when I make things from scratch in Blender, and I often use the old 6.1 exporter combined with a bag of work-around tricks and for my current stage of development, it seems to fufill it's role quite nicely (thank you for that Mont!). There are a lot of workflow benefits for UE4/Blender artists if Blender's .FBX import/export can be taken a few steps further. As a game developer, it's my number one feature wish for Blender. (more flexability with workflow, less work-arounds and tricks and steps to get everything working, easier to work with a team of artists who are using various software, etc., etc.)
Author

There is an issue with importing an Epic skeleton. It's not fatal, but it is annoying. The problem is that FBX bones are aligned down the X-axis while blender bones are aligned down the Y-axis. The imported skeleton works, but it's distracting having the bones pointing in the wrong direction. If you use the auto align on the import, you get a more correct looking skeleton, but it won't import into Unreal 4 without corrupting the animations. I guess what needs to happen is for the bones axes to be swapped on import and back again on export.

There is an issue with importing an Epic skeleton. It's not fatal, but it is annoying. The problem is that FBX bones are aligned down the X-axis while blender bones are aligned down the Y-axis. The imported skeleton works, but it's distracting having the bones pointing in the wrong direction. If you use the auto align on the import, you get a more correct looking skeleton, but it won't import into Unreal 4 without corrupting the animations. I guess what needs to happen is for the bones axes to be swapped on import and back again on export.

Changed status from 'Open' to: 'Resolved'

Changed status from 'Open' to: 'Resolved'

Eeeeeh… Thanks for the feedback and checks, but please try to avoid using phab as a forum, it makes cases harder to follow. :)

Considering that report as fixed for now, if you have other kind of issues please consider opening new reports.

Eeeeeh… Thanks for the feedback and checks, but please try to avoid using phab as a forum, it makes cases harder to follow. :) Considering that report as fixed for now, if you have other kind of issues please consider opening new reports.

Added subscriber: @devbm

Added subscriber: @devbm

I'm experiencing the exact same issue (Blender 2.74 and UE 4.7.5)
Also in my case the problem is working with the Epic skeleton (exporting an Epic character, importing in Blender, exporting, importing in UE4)
The test pointed out by Cancer still fails, why has this report been considered fixed?

I'm experiencing the exact same issue (Blender 2.74 and UE 4.7.5) Also in my case the problem is working with the Epic skeleton (exporting an Epic character, importing in Blender, exporting, importing in UE4) The test pointed out by Cancer still fails, why has this report been considered fixed?

Opened a new task to keep track of the issue I'm experiencing (#44407 )

Opened a new task to keep track of the issue I'm experiencing ([#44407 ](https://developer.blender.org/T44407))
Sign in to join this conversation.
No Milestone
No project
No Assignees
9 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender-addons#41254
No description provided.