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

[Piotr Adamowicz]

Custom normals are used mainly for two things. One of them is foliage
you already know about. The other is correcting shading errors on low
poly geometry when you want or need to avoid split edges. This other
use is actually much more common.

For example, with averaged normals, on a smooth-shaded cube with a
small single-segment bevel, there's very noticeable artefacting along
the surfaces of the large faces. You use custom normals to correct
this manually, to make the large faces' vertex normals point exactly
along the face normals. That way the large surfaces appear flat, but
the small beveled edges of the cube still appear rounded.

Other than that you might want to use custom normals for baking, to
point rays in a particular direction and, say, avoid waviness at the
edges of cylindrical shapes. This only applies if you're not using a
cage for baking, so assuming that cages are implemented at some point,
this usage isn't very important.

And one more use that is not usually game-related is importing,
rendering and baking from CAD models that have normals calculated
based on the underlying mathematical solid shapes. For this it's just
important to be able to keep the normals as is without wrecking them
with simple things like entering edit mode.

That's it I think, if there are other use cases I don't know about them.

I'd really like to see option II implemented, but I understand this is
a tall order. For correcting normals a modifier-based approach might
be ok. A modifier that calculates the vertex normals by taking the
relative surface areas of the adjoining faces into account
(face-weighted normals) would do most of the job. Such a modifier
should also have an optional threshold below which the larger face
'wins' and the vertex in question is pointed directly along the face
normal. This would probably cover 80% of cases. For the other 20%, the
trouble is that this threshold might be different for different parts
of the low poly mesh, so controlling it with a vertex group (this
would probably be very user-unfriendly), and/or a way to manually tag
faces 'flat' would be in order.


On Fri, Nov 1, 2013 at 7:06 PM, Bastien Montagne <montagne29 at wanadoo.fr> wrote:
> 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!



-- 
Piotr "MadMinstrel" Adamowicz
padamowicz at gmail.com