Sharp edges

by

Custom Split Normals – Second Testbuild Available

EDIT: This tool is now in master, and will be part of Blender 2.74 release.

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

Since first of August, most noticeable changes are:

  • A fair amount of bugs were busted (most noticeable being wrong handling of (interpolation) weights, and crash with the modifier when switching target mesh to Edit mode).
  • Data structures were tweaked (WARNING: this means files saved with builds from 08/01 are not ‘compatible’ with those new builds, they will load, but all custom normals will be lost).
  • Some optimization work was done (especially in code computing final split normals, which is now multi-threaded).
  • Modifier UI was reworked, and a new ‘from split normals’ mode was added, which uses split normals of target, instead of its face normals.

As usual, please note that this remains “experimental” code, do not expect on stability of new features yet, nor of the file format (though this one should not change anymore, imho).

Also, if you are doing some nice tests with these builds, I would appreciate some nice screenshots (and even better, .blend files), those would be more than useful for final documentation! 🙂

Please report any bug you may (will!) find to our bug tracker, https://developer.blender.org.

by

Custom Split Normals – First Testbuild Available

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

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

Please report any bug you may (will!) find to our bug tracker, https://developer.blender.org.

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 http://wiki.polycount.com/VertexNormal ).
  • 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.
by

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

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

by

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

by

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!

by

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.

by

Export split normals in OBJ, work on FBX

Hi,

So today I committed the “split normals” in OBJ exporter, now when you check « Include Normals » you will get split normals.

I also kept working on FBX – one can get nice gain with optimizations here… Right now (only basic vertices, faces [now polygons] and edges export done), with a default cube subdivided nine times (i.e. over 1.5 millions of vertices and faces), here are the stats I get:

With edges:

New code:
New verts: done in 4.237405 secs...
New polys: done in 3.605981 secs...
New edges: done in 3.249940 secs...
export finished in 14.5939 sec.

Old code:
Old verts: done in 5.774732 secs...
Old faces: done in 5.692272 secs...
Old edges: done in 9.272664 secs...
export finished in 28.4587 sec.

Without edges:

New code:
New verts: done in 4.237738 secs...
New polys: done in 3.707349 secs...
New edges: done in 0.000003 secs...
export finished in 11.5021 sec.Old code:
Old verts: done in 5.733048 secs...
Old faces: done in 4.810387 secs...
Old edges: done in 0.000004 secs...
export finished in 16.1231 sec.

Still quite a bunch of work to do here (not to mention binary export 😉 )…

by

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… 😛

by

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

by

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