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

[Simon Broggi]

I totally agree with Piotr Adamowicz.
Here's a video of how I currently achieve smooth low poly models in blender.
http://vimeo.com/78378752
Biggest downside is that I have to apply the edge split modifier.

On Fri, Nov 1, 2013 at 8:09 PM, Piotr Adamowicz <padamowicz at gmail.com>wrote:

> 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
> _______________________________________________
> 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/ae841d5b/attachment-0001.htm