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.

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,

EDIT We are now using GIT and Phabricator, so this work is now hosted in a Differential revision instead of a branch:…

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: Many thanks to him! 😀

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.

Export Sharp Edges as Vertex Normals – Day 8

Great news ‑ core code and RNA API are in trunk (commits r60005, r60014 and r60015)! Many thanks to Campbell, who helped a lot optimizing and cleaning up the core code, and to Brecht, who reviewed the API code. 😀

Note that for now, there is no preview in 3D View, and no storing of those split normals in .blend file, as this is only temp data currently.

Very soon (probably tomorrow), I will commit the OBJ update. FBX will have to wait a bit more, as it first needs some deeper changes! Anyway, hard work is done, py scripting is easy… 😛

Export Sharp Edges as Vertex Normals – Day 6 & 7

So, ping-pong with Master Yoda, King of Optimization (aka Campbell 😛 ) kept going…

I must say I’m rather amazed and happy with the results! In latest patch, we have another 50% or so gain in performance, and we now only use 8 bytes per edge and 4 bytes per loop!

Btw, found out FBX export currently exports tessellated faces, which is bad and will need to be fixed before adding split normals export to this format. Will try to tackle this in the next days (if optimizations suggestions stop filling up my available time! 😉 ).

Export Sharp Edges as Vertex Normals – Day 5

So, API is validated! However, Campbell gave me some hints to improve core code, which now only uses 24 bytes per edge (plus 4 bytes per loop), and runs twice as fast as previous version. Compared to first patch, current one is about four times faster and eats about three times less memory… that was worth a few more hours of work! 😉

Export Sharp Edges as Vertex Normals – Day 4

Spent a few hours on polishing the core code – removed some unused elements, gaining a few CPU cycles and over all, reducing temp edge data from 80 bytes to 48 bytes per edge (on 64 systems)! Also made some more tests, everything still successful. 🙂

Also reworked the API… Still very basic, but less nasty than first version imho. Now waiting feedback from Cambpell about it (issue here is that we have too much ways to do it, need some advices about the best one!).

Current patches: core and obj exporter.

So I’d say the core goal of the project is now done (remaining bits – FBX export & adding split angle threshold – are trivial). If current API is validated, will try to get that reviewed asap, and then will see about adding 3D View visualization…