FBX 7.4 Updates – II

So, since last post:

* Armatures export has been finished.

* Export of baked animation (for both objects and bones loc/rot/scale) has been added, including current scene animation, strips from NLA and ‘All Actions’ compatible with exported objects.

* Export of curves/metas/text/etc. as meshes has been added.

* Export of dupli objects/groups has been added.

We are more and more close to a complete FBX 7.4 binary exporter for 2.71 release! Yet, more testing is always much welcomed. 😉

There was some work on the importer side too, fixing some issues, extending some existing features, like e.g. a new option to use FBX data for up/front axes and scale, instead of specifying those manually. And a first “armature import” feature was implemented as well (in a separated branch currently, fbx_io_development).

Note that in addition to Unity, which greatly supported FBX export work with their donation to the Blender Foundation, people from Unreal Engine also started showing some interest for Blender FBX support lately – gamedev community is very active on this topic! 😀


13 thoughts on “FBX 7.4 Updates – II

  1. Is there an option to export vertex alpha in the new FBX exporter?

    I know that Blender doesn’t support it, but maybe exporting through a vertex paint named “alpha” could be possible.

    • That would be an ugly hack… So no! 🙂

      It’s not the place of an export tool to hack around missing features in its app. So all vertex color are exported with an alpha of 1.0 (full opaque).

  2. That’s dissapointing:( Is it so much different from exporting sharp edges as split normals?

    Vertex alpha gives you that additional channel e.g for blending and most engines make use of it.

    Perhaps it could be set up in another way, like choosing a layer in the export toolbar.
    Blender has support for vertex paint layers, I really don’t see it as a huge hack.

    Obj exporter has a lot more checkboxes than fbx in it already, so it’s not that much of bloat either.

    • It is different, in that split normals are just another representation of existing Blender data, while using a selected vcol layer as alpha values for the other(s) would be hacking around something that *does not exists* in Blender…

      Will mumble a bit more the idea, but I’m still not convinced – and obj exporter has way too much options! 😉

  3. Hope you reconsider it at some point:)
    It’s not a big thing, but it’s one of those small things that are useful and are a standard in the commercial apps.

    On another note, the binary FBX exporter works very well for me, I mostly export static objects though.

  4. Hello again Bastien!

    I would like to request a change (or more likely added functionality) to the FBX exporter. As is, the exporter (well, the deprecated 2.70a release version of the exporter?) seems to add animation keyframes for every bone upon export. This mostly breaks non-additive animation blending in Unity (as far as I understand it, anyway).

    As per this link: http://answers.unity3d.com/questions/29802/playing-two-animations-from-one-armature.html

    If that is all it takes to remove the added keying, it seems like it wouldn’t be too much to have a toggle in the plugin’s settings? Please let me know if I am totally wrong here, or if the new version of the exporter solves this issue.

    Thanks as always!


    • Hi Casey,

      Did you try the new exporter (7.4 bin)? You can do it easily by downloading one of our nightly builds (http://builder.blender.org/download). IIrc, it should never output animation for *perfectly still* objects (or bones, relative to their parent).

      Needs testing, though, as exported animation is baked (so that thing like constraints etc. can also have effect), which may add some bias…

      But pretty sure in most common cases non-animated object/bone = no FBX animation in new exporter.

      • I’ve downloaded the latest nightly and given it a shot. I’m trying to use “direct blender import,” but Unity complains that I need 2.45-2.49 or 2.58+ in order for it to work (I assume this has to do with the nightly blender build being copy/pasted on top of an already installed 2.70a).

        Manual export of the FBX seems to work, though, so I assume the next released version of blender will allow direct importing with the desired effect. What are your thoughts on direct blender import? It certainly improves my workflow when it works. Thanks for your hard work!

      • Unfortunately, we have no responsability in the ‘direct import’ of Unity, this is a code managed by Unity team itself.

        Right now, as far as I know, it only uses old 6.1 (and is even probably completely broken with post-2.70, since adding 7.4 bin exporter changed the exporter’s parameters).

        But I agree it’s a nice feature for workflow, can only hope they’ll update it soon to handle and use new 7.4 code (should not be a great deal of work, imho).

        Until then, you should rather use manual export, imho, esp. since 6.1 is deprecated and no more maintained (only kept for 2.71, and prehaps 2.72, “just in case” it might still be useful in some rare cases).

      • I seem to have spoken to soon. A couple of problems:

        When saving out (.blend) or exporting (FBX), blender seems to save any currently active (but unkeyed!) loc/rot/scale (to the armature? not sure), which then seems to have a cascading/inheriting effect on animations which don’t have all bones keyed (essentially keyframes from animation 1 trickle down and fill in the gaps in animation 2, etcetera). I am new to animation, but this seems inherently bad. Just because I had an animation selected when I saved/exported, doesn’t mean I would want that animation’s current pose to impact animations that lack keyframes. Let me know if I am off-base, though!

        Additionally, upon importing the FBX (created using 7.4bin) into unity, unity still adds unnecessary/unkeyed frames? I am not sure if this is Unity’s fault or if your exporter is adding the unnecessary keys itself. I will be posting about this to Unity as well, since I don’t know whose bug it is.

        Thanks, as always!

  5. Eeeh… I would rather handle bug reports through our tracker (https://developer.blender.org/maniphest/task/create/?project=3&type=Bug), much simpler to keep all issues stacked in a single place.

    That said, current exporter bakes all animations (i.e. one keyframe each frame for all loc/rot/scale), and then performs a basic simplification (removing some keyframes when value does not change much, and removing curves where value does not change at all during whole anim). the later point needs more tweaking, though, since float precision creates havoc as usual…

    The key point here being that exporter does not use existing fcurves really, it just ‘plays’ the animation, keep track of loc/rot/pos of each object/element for each frame, and decide from that what moves and needs FBX AnimCurves. This is done so that all indirect animations (IK, other constraints, drivers, unusual parenting like hinge, etc.) can be correctly reproduced.

  6. By breaking the existing script interface and changing the way curves work you have done a tremendous disservice to the people that need FBX export the most.

    The fact that you got the funds to do this development in part from Unity Tech, but couldn’t be bothered to keep the old interface intact tells me you are not competent for this kind of work. You don’t understand the priorities, at all.

    All you would’ve needed to do is to keep this path to the ASCII code intact:

    You could’ve had named the new export “save_bin” or “save_new”, or something like that, instead of keeping the name but breaking the interface nonetheless. Instead, you expect Unity (and everyone else) to clean up after you. The idea that you couldn’t just easily support this is nonsense.

    Secondly, you don’t understand that people absolutely *need* the classic FCurve workflow. The new “baking” workflow is a nice feature, but only if it is optional. It can’t just replace the old workflow, and you shouldn’t be wasting everyone’s time by just changing this without being explicit about it.

    I sincerely hope you can be bothered to keep the old ASCII export around, as long as you have these regressions in the binary exporter.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s