FBX 7.4 Updates – III

Since last report, main missing feature was added to Export, and Import was greatly improved :

* Shapekeys export has been added, including animation (only for relative shapes, n o support for absolute ones’ animations currently).

* Armatures import was added (though there is a remaining unclear issue about bones’ orientation).

* Shapekeys import was added.

* Limited animation import was added, for loc/rot/scale of objects and bones, and values of shapekeys.

Last point needs some precisions – we currently always read FBX curves assuming linear interpolation. This means that if you FBX file has some fancy Bézier-like interpolated anim curves, results will be rather poor. In a word: bake your animations at export time! Note complete import support for FBX anim curves is a TODO, but not a top-priority one currently…

As usual, a bunch of more minor enhancements and bug fixes was done too.

And as usual, we need testing, testing and even more testing of the whole FBX io addon – complete feature should be in Blender nightly builds within a few hours. Just be kind, and if you find some failures, report them with a tiny FBX file illustrating the issue, not a whole multi-MB project one. 😉

Blender is NOT an API – let alone its addons!

So… The other day, a guy spent hours on IRC insulting everyone about “Blender always breaking its API for mere renames”. Today, I got this comment below:

Castano

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:
“io_scene_fbx.export_fbx.save”

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.

So, to that specific case first. I did not remove nor renamed io_scene_fbx.export_fbx.save, as everyone can see in that history page. So people could first stop talking about things they do not know about. Actually, I added new “bin” exporter in a new py file, with a new name.

Oh, and by the way, FBX export to Unity itself is not  broken at all, the only thing that is broken is a helper script in Unity itself that “hides” FBX exporting, making it looks as if Unity could directly open .blend files…

Nevertheless, it somehow broke that Unity’s script… What the heck? Seriously!

Let’s summarize:

• Blender is free and open source;
• Blender is an application, not a library;
• Blender features several extensions (“addons”);
• A third party society reuses an addon’s code (free and open source, if I may remind) to provide a feature in its own, closed and (at least for the full version) charged application;
• Some changes are made in the free, open source addon, which somehow break that third party society’s product;
• And some guys go reproaching the new, enhanced addon, yelling about breakings, raging over IRC (and, I guess, forums etc.), insulting, …

That does not make me happy. Not at all.

I’ve spent let’s say about three months of full-time work (probably more, actually) on the mess that’s called FBX. I would not wish that to my worst enemy. I’m already really sick of it, I’m pushing myself to complete the last pieces of needed features in new exporter (and importer) for 2.72… All those guys might gain is me dropping completely and definitively this task. They are free to take it over, since they are so wise ans full of knowledge and competent and super heroes and all that, I’d wish them good luck.

Now, back to the general case. Again, Blender is not a library. Let alone its addons!!!

We do have a few pieces of library inside Blender – some helper modules in python, PY RNA interface itself (how properties are defined, how operators are called, that kind of stuff). But! Operators themselves, data access themselves, RNA types themselves are not an API, in the sense they offer a direct acces to Blender’s internals, and Blender’s internals are not, were never meant to be, and will (probably) never be a library. Which means we do not have to twist and tweak to keep compatibility. We do try to do it, to some reasonable level, of course. We rarely do mere renames, and when we do, we keep old names (as deprecated) available at least for one or two releases. When we add a new parameter to a function, we try to make it optional as much as possible. But when we change how an operator works, or remove one, because it’s no more needed inside Blender or was doing bad work, we won’t keep it as a stupid “proxy” just for our py interface. Nor do we when we change data structures inside Blender.

As a side note, let me say you how much a mess can come from trying to keep compatibility – I had to experience it while working on (yes, again!) FBX format, and this does not give a nice result. At all.

So, as a final word: we do not need people which are just yelling, without actually doing anything, not even being constructive, which do not simply know how to talk with others! To those: STOP WAISTING OUR TIME!

GameDev Related Articles on code.blender.org

Hey, just a quick one, to share those two nice articles buy Dalai Felinto and Micthell Stokes, in case some of you did not saw them already. 😉

• A general status about close 2.71 Blender release concerning GameDev.
• An article about the new Cycles Baking feature.

And if I may spoil a bit about 2.72, it should have more FBX feature support (noticeably ShapeKeys in both export and import, and basic import support for armatures and animations)… and who knows, maybe even some custom split normals? 😉

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! 😀

FBX 7.4 Updates – I

So! After hours and hours of tries and failures, desperation and cursing at FBX format, since I could definitively not find any valuable difference between code generated by Blender and by FBXConverter regarding animation, I finally decided to dive into ugly hacking and have a look at binary files themselves…

Well, at least, it was rewarding: I found out some stupid FBX anim-related elements need a specific handling at binary level to be understood by the FBX SDK! I won’t hold forth on a format that needs such ugly tricks (the joys of vault development I presume…).

I’d rather summarize quickly current Blender’s FBX 7.4 binary exporter status:

Implemented and expected to be working!

• Objects, and simple parent relations between objects (not through constraints, though).
• Lamps.
• Cameras.
• Meshes, including:
  • UVs.
  • VCol.
  • Smooth groups (edges or faces).
  • Faces’ material indices.
• Materials (Phong or Lambert shading).
• Textures (only image/video type, embedding should work, needs ‘COPY’ path mode).
• Materials <-> Textures relations: textures can affect:
  • DiffuseFactor, DiffuseColor.
  • TransparencyFactor, TransparentColor.
  • EmissiveFactor, EmissiveColor.
  • AmbientFactor.
  • SpecularFactor, SpecularColor.
  • Shininess, ShininessExponent.
  • ReflectionFactor, ReflectionColor.
  • Normal/bump.

Implemented, but status unsure (needing testing!)

• Armature linked to mesh. Binding code itself seems to work OK, but bone’s orientations are usually completely wrong when I import back, still have to figure out what happens here. Although I got feedback from testers saying it imports OK under official FBX apps, so…
• Meshes’ (Split)Normals, tangents and bitangents (does not handle the 7.4-new “weights” for those, though). 7.4 seems to use 4D vectors, however I’m not quite sure about the compatibility of those with older apps, I might revert it to previous format (3D vectors) for now.

Implemented, but unfinished

• Animation: basic object baked animation (loc/rot/scale).

TODOs, mandatory

I.e TODOs that need to be addressed before we can consider the exporter finished.

• Add option to export other geometries (curves, texts, metaballs) as meshes.
• Finish animation.

 

New FBX 7.4 binary in Blender

Well, just a short note about the fact that since yesterday, I pushed new FBX 7.4 binary exporter in Blender’s FBX IO addon. So it should be available in this night’s builds of our buildbot!

Here is a short list of what’s working, implemented but buggy, and still TODO currently:

Implemented and expected to be working!

• Objects, and simple parent relations between objects (not through constraints, though).
• Lamps.
• Cameras.
• Meshes, including:
  • UVs.
  • VCol.
  • (Split)Normals, tangents and bitangents (does not handle the 7.4-new “weights” for those, though).
  • Smooth groups (edges or faces).
  • Faces’ material indices.
• Materials (Phong or Lambert shading).
• Textures (only image/video type, embedding should work, needs ‘COPY’ path mode).
• Materials <-> Textures relations: textures can affect:
  • DiffuseFactor, DiffuseColor.
  • TransparencyFactor, TransparentColor.
  • EmissiveFactor, EmissiveColor.
  • AmbientFactor.
  • SpecularFactor, SpecularColor.
  • Shininess, ShininessExponent.
  • ReflectionFactor, ReflectionColor.

Implemented, but buggy/needing testing!

• Armature linked to mesh. Binding code itself seems to work OK, but bone’s orientations are usually completely wrong when I import back, still have to figure out what happens here…

TODOs, mandatory

I.e TODOs that need to be addressed before we can consider the exporter finished.

• Normal/bump connections for Materials <-> Textures relations – includes handling more mapping types too.
• A few meshes layers (like e.g. edge crease).
• Add option to export other geometries (curves, texts, metaballs) as meshes.
• Add support for some basic objects constraints (trackto, limit loc/rot/scale, …).
• Animation!!!

TODOs, optional

I.e. things that we might want to add, if time allows.

• Shapekeys?
• Export Curves (FBX is supposed to support them)? Not sure it’s much portable though, so probably not worth waiting time on it?

New FBX Bin 7.3 Export – Stage I

So, we finally have a basic FBX bin 7.3 exporter, need testing!

To test it, just download this file and replace your current fbx addon by the one contained in this archive (io_scene_fbx). Note the old exporter (ASCII 6.1) is still available…

What to expect:

• Camera, lamps support.
• Mesh support (with loop normals, UVs, vertex colors, smoothing).
• Material and texture.

Do not expect any armature nor animation yet. Also please note all this is still big WIP, esp. the material/texture area… (this areas would also need some work on the importer side of the plugin).

Best way to report issues is to use this github’s page, just please try to feature small test cases (just saying “it does not work” without providing any file, or providing 10Mo files, won’t help much). Ideal case is to provide the Blender file, the FBX file as exported by Blender, and a similar scene exported as FBX from a ref app (like latest Maya or Max – 2013 or 2014). Also please be sure your tested app supports latest FBX (ones older than 2012/2013 probably do not).

That’s it for now, will update here as needs arise!

 

Loop normals: first step needs testing!

Hi guys,

I (hopefully) mostly finished first step in loop normals work. Now, all objects have the option to enable loop normals (with an optional angle threshold above which edges are always sharp). Once enabled, final derived meshes (structs representing objects to draw or render) gets a normal CD layer for their loops (and a tessellated version for its tfaces as well). Those loop normals allow to represent flat faces and sharp edges. As a temp UI, I added loop normals and angle options in the “Item” panel, “Properties” of the 3DView.

Code can be checked out from my svn branch, https://svn.blender.org/svnroot/bf-blender/branches/vgroup_modifiers

EDIT We are now using GIT and Phabricator, so this work is now hosted in a Differential revision instead of a branch: http://developer.blender.org/D11…

These data are used in OpenGL preview (only when “VBO” option is enabled, for now, I prefer to modify viewport code as few as possible currently!), and for tangent space compute as well (note that for this one, I assumed it is only used over final dm, this may not be always true, have to check this yet). These are also the same as exported in OBJ and FBX.

Only remaining TODO for this first step is to export TSpace in FBX (btw, if someone could provide me one or two simple ASCII FBX files with TSpace data, would be nice 😉 ) – and of course, to test!

I hope the core algo to compute loop (split) normals is now OK (I fixed two bugs here recently ), but esp. tspace/loopnormals combinations are to be checked carefully (baking)…

EDIT CoDEmanX just uploaded a Windows build of the WIP branch: http://www.graphicall.org/925 Many thanks to him! 😀

About Export Split Normals Status

Well, I guess I kinda forgot to announce this here…

So, 2.69 will have split normals export for both FBX and OBJ formats. I just fixed a (stupid, as always) bug in core code last week, think everything works OK now. You can still test latest Blender builds, obviously! 🙂

Also, as I’m now hired for six months on mid-time base by the Blender Foundation, especially to work over game-dev tools, I have chosen loop normals (i.e. split normals, i.e. normals per vertex per face) as main project, so expect more new features on this topic in upcoming releases. I’ll also try to keep this blog updated about it, this time!

6.1-ASCII FBX Export – Tests Needed!

Hi everyone,

So I finally got to the end of my first refactor of FBX export. Do not yet expect 7.3 support or binary export, but here are the news:

• Export polygons an no more tessellated quads/tris!
• Export split vertex normals.
• General cleanup of code (in mesh export only), much compact and somewhat better performances (about 20%, with size reduction of color/uv layers).

I did some quick tests with the only tool I found available for free under Linux (Beginner license of HoudiniFX), things seems to work OK, but I’d like to get some more tests from artists here who also have Maya/3DS Max available… Simply replace existing io_scene_fbx directory (in your addons path) with this one.