Custom Split Normals – First Testbuild Available

So, to change a bit from FBX, something funny this time! 😛

Here are three links on for testbuilds of current Custom Split Normals state of work:

Please report any bug you may (will!) find to our bug tracker,

EDIT: You can now found this project’s code in a WIP branch on our git repository: temp_custom_loop_normals (note the edits to FBX addons to enable custom normals import are not available this way).

Currently (but those features should not evolve much in near future), you can:

Import custom normals from FBX

Supports both vertex and ‘face corner’ normals. Note other addons can do it as well, but that’d be done once the work is merged in Blender’s master!

Write/read custom split normals into/from .blend files

Those custom  split normals are stored like e.g. vertex colors or any other custom data layer, which means that you can also edit your mesh (deforming should still give reasonably good custom normals, modifying the topology however (adding/removing faces, sharp edges, etc.) can quickly lead to nasty custom normals!).

Please note there is no guarantee about the final format of those data though, in other words, files created with those testbuilds might very well not be usable by later ones or final version (though this is rather unlikely, imho)!

View custom split normals in 3DView or renders, and re-export them

Custom split normals are fully integrated into the process to generate final split normals, so when you use the laters (exactly as in current official 2.71 release or master), you’ll get your custom normals instead of auto-generated ones, if available.

Note that when there are some custom split normals data, the ‘angle’ threshold of AutoSmooth is unused (as if it was at 180°), so you only can use sharp edges to define ‘smooth fans’ (i.e. a set of adjacent face corners sharing a same vertex, and a same split normal).

Add or Edit custom split normals with the SetSplitNormals modifier

It has two modes:

  • Ellipsoid assigns to each vertex the normal it would have at the surface of an ellipsoid (proportions of that ellipsoid are defined from bounding box of the modified object, and you can use another object to define the position of its center). Allows e.g. to realize a simple ‘tree shading’ effect (see ).
  • Object uses another object’s geometry to assign to each vertex the normal that target’s closest face. Allows e.g. to make the ‘fake smooth round corners’ effect – you take a cube, bevel its edges, and add a SetSplitNormals modifier to it using another cube as target.

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:


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.

So, to that specific case first. I did not remove nor renamed, 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

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. 😉

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