Page MenuHome

FBX exporting and importing again in default settings breaks armatures with animations and meshes totally for me
Closed, ResolvedPublic

Description

System Information
Windows 10, Geforce GTX 745 (driver version 359.06)

Blender Version
Broken: 2.77a abf6f08

Short description of error
When exporting the attached blend file to FBX and importing it again, things get really weirdly broken (see attached screenshots)

Exact steps for others to reproduce the error
Open attached blend file (in example.zip) and export to FBX in default settings. Now remove everything and import from FBX again in default settings. Compare the animation / scene / camera view, i.e. at frame 10.

Additional information
The scene was created by importing an "short" AGR file (basically captures a share of the entity_state information from the Counter-Strike: Global Offensive engine to disk, made with HLAE 2.14.1) using Blender Source Tools 2.7.1 ( http://steamreview.org/BlenderSourceTools/ - the assets were retrieved using Crowbar ( http://steamcommunity.com/groups/CrowbarTool ) and GCFScape of course)) + afx-blender-scripts v0.0.1 ( https://github.com/ripieces/afx-blender-scripts/releases/tag/v0.0.1 ). I then removed the other players / models and removed a huge part of the animation data to strip down the example.
I cannot guarantee 100% that the usage of those tools did not create a problem with the setup in the blend file, but I hope it has not.
I understand that the hide_render option probably cannot be preserved when using FBX.
(I am to blame for the afx-blender-scripts plugin.)

If we just wanted to use AGR in Blender things would be fine, but several CS:GO movie makers want to use Blender as a bridge to export to other programs like Cinema 4D or 3DS Max (which I don't have and probably also cannot afford), and they seem to prefer the FBX format.

Please let me know if I can assist with anything.

Attachments


Event Timeline

Actually I am not sure if this is the way to go, because movie makers and me have this problem:

For bigger projects we cannot use FBX 7.4 binary export, because it takes longer than an hour (I gave up then and terminated Blender, so did other people - it didn't even start writing the file by then) to export

s.th. that takes 3 minutes to import from the AGR into Blender (resulting in a 627 MB .blend file)

and takes 15 minutes to export as FBX 6.1 ASCII (resulting in a 1.3 GB .fbx file)

The problem is that the even if FBX 7.4 would take shorter, FBX 6.1 ASCII and FBX 7.4 binary are broken when importing i.e. into Cinema 4D for example, because some ankles are twisted, as you can see on the screenshots that some movie maker gave me:


(Feet twisted)


(Head twisted)

TL; DR:

  1. We cannot use binary FBX, because it's way too slow upon exporting for larger projects.
  2. FBX 7.4 Binary and FBX 6.1 ASCII have the same problem when i.e. importing into Cinema 4D (twisted ankles, see screenshot).
Bastien Montagne (mont29) lowered the priority of this task from 90 to 50.

Erf… OK, so, first of all, did find a bug thanks to that report - animated rigged meshes (the mesh objects, not the armatures ones) are not well supported - and cannot be well supported in fact, due to how FBX works (afaik). Further more, did quick check and it looks that their animation is not required nor used (at least, not by Unreal engine). So for now, will disable exporting/importing those animations, assuming people are sane enough not to actually animate their mesh in addition to their rigging… Of course, not talking about shape keys animation here.

  1. Export time: this is due to animation exporting, we have to bake all animation for each frame and store resulting transformations, if you have several complex armatures with long animation it will take time. First of all, when you are exporting a whole scene and not a single asset, you should disable All Actions and NLA Strips options. You can also try to reduce processing time by setting Simplify to 0.0 (will then export one keyframe per frame [with default sample rate], giving bigger files).
  1. As for Cinema4D, really cannot help, already had a hell of a time to get our FBX working (more or less) OK with maya/3dsmax/unity/unreal… FBX is just not the “common export format” some want to sell it as, it’s interpreted in various different ways by various different applications. Maybe could change if we get public specifications of that format one day, but for time being trying to understand that format is reverse-engineering a messy black box, so cannot cope with all its weirdnesses and variations. :(

Thank you for your reply.

I just wanted to point out, that the only animation data on the mesh is for the hide_render property of the mesh and nothing else.
Removing that data won't make export + import work :(

We will probably use Blender to get the models into FBX format without animations and do the animation of the models with a C4D plugin then.

You do not understand how animation works in blender->FBX: it *bakes* object transformation (and then decide whether there is animation on it or not).
Using mere actions to detect whether an object is animated or not is not enough - by far, there are way too much 'implicit' animations possibilities (constraints, drivers, etc.).

But again, with latest fix in FBX addon, no animation from rigged mesh will ever be exported, which will fix your reported issue, as well as a nice share of the long export time. And you can reduce animation export time even more as explained in previous comment.