[Bf-gamedev] New loop normals/tspace needs testing

[Bastien Montagne]

Hey guys,

Further tweaked the code, patch is available here (for review as well). 
Still more a draft than final, trunk-ready code, but I would avoid 
spending more time on it before having it reviewed and global design 
validated.

https://codereview.appspot.com/20790043/

 From that point, we can have two different goals:
I) Simply add import of normals (from FBX and co) as a "frozen" loop 
normal layer, which just stays as-is even if you edit the mesh (probably 
on a vertex- or loop-based flag, so that someone can choose to go back 
to auto-computed ones for some parts of the mesh), and add some 
modifiers to get procedural loop normals editing (e.g. to use other 
geometry's normals, the "trees" example).
II) Aim to a full support of custom normals.

I) is relatively easy to do, could be mostly finished and working in a 
few weeks. However, it is not fully featured and powerful (you can't say 
"I want this normal to point this way"), and support for geometry 
deformations and editing would be *very* poor (in other words, normals 
computation should happen as late as possible in the modifier stack).

II) would allow to do virtually everything with normals. However, it is 
much more involved (most likely months of work):
* Have to add loop normals handling in BMesh.
* Will need some UI new stuff (maybe a new Loop select mode, similar to 
current vertex/edge/face ones in Edit mode, perhaps even new editing 
widgets in viewport, etc.).
* Implies to store custom normals as some kind of diff (in tspace-like 
coordinates) format, relative to auto-computed ones. This would allow to 
keep meaningful (to some extend!) custom normals even in heavy geometry 
changes.

So I'd really like to get feedback from expert gamedevs, ideally with 
example of workflow involving custom normals (the only real one I found 
so far is the "tree" one, which is very easy to implement as a 
modifier). I need to know whether solution II) (which covers 100% of the 
editing needs in this area) is worth the work involved, or if solution 
I) (covering maybe 90% of needs) could be enough?

PS: Don't think I'll make builds, this has proved to be rather painful 
and time consuming in the past (Blender uses many libs, hard to 
static-link all that together), and building Blender is now very easy on 
every OS!

On 24/10/2013 08:59, Simon Broggi wrote:
> cool.
> any chance to get a test build?
> cheers, simon
>
>
> On Wed, Oct 23, 2013 at 1:42 AM, Jacob Merrill 
> <blueprintrandom1 at gmail.com <mailto:blueprintrandom1 at gmail.com>> wrote:
>
>     So this is like a automatic smooth unsmooth setting?
>
>     ( you can use edit - Smooth - and -Flat- on individual faces) or
>     is that different? (having the option to set a edge as flat or
>     smooth would be cool....
>
>     does this work with object.hitNormal? etc?
>
>
>     On Tue, Oct 22, 2013 at 11:57 AM, Bastien Montagne
>     <montagne29 at wanadoo.fr <mailto:montagne29 at wanadoo.fr>> wrote:
>
>         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
>
>         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)…
>
>         Cheers,
>         Bastien
>         _______________________________________________
>         Bf-gamedev mailing list
>         Bf-gamedev at blender.org <mailto:Bf-gamedev at blender.org>
>         http://lists.blender.org/mailman/listinfo/bf-gamedev
>
>
>
>     _______________________________________________
>     Bf-gamedev mailing list
>     Bf-gamedev at blender.org <mailto:Bf-gamedev at blender.org>
>     http://lists.blender.org/mailman/listinfo/bf-gamedev
>
>
>
>
> _______________________________________________
> Bf-gamedev mailing list
> Bf-gamedev at blender.org
> http://lists.blender.org/mailman/listinfo/bf-gamedev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-gamedev/attachments/20131101/32066c2d/attachment-0001.htm