<div dir="ltr">I totally agree with Piotr Adamowicz.<div>Here's a video of how I currently achieve smooth low poly models in blender.</div><div><a href="http://vimeo.com/78378752">http://vimeo.com/78378752</a><br></div>
<div>Biggest downside is that I have to apply the edge split modifier.</div><div><br></div><div><div class="gmail_extra"><div class="gmail_quote">On Fri, Nov 1, 2013 at 8:09 PM, Piotr Adamowicz <span dir="ltr"><<a href="mailto:padamowicz@gmail.com" target="_blank">padamowicz@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Custom normals are used mainly for two things. One of them is foliage<br>
you already know about. The other is correcting shading errors on low<br>
poly geometry when you want or need to avoid split edges. This other<br>
use is actually much more common.<br>
<br>
For example, with averaged normals, on a smooth-shaded cube with a<br>
small single-segment bevel, there's very noticeable artefacting along<br>
the surfaces of the large faces. You use custom normals to correct<br>
this manually, to make the large faces' vertex normals point exactly<br>
along the face normals. That way the large surfaces appear flat, but<br>
the small beveled edges of the cube still appear rounded.<br>
<br>
Other than that you might want to use custom normals for baking, to<br>
point rays in a particular direction and, say, avoid waviness at the<br>
edges of cylindrical shapes. This only applies if you're not using a<br>
cage for baking, so assuming that cages are implemented at some point,<br>
this usage isn't very important.<br>
<br>
And one more use that is not usually game-related is importing,<br>
rendering and baking from CAD models that have normals calculated<br>
based on the underlying mathematical solid shapes. For this it's just<br>
important to be able to keep the normals as is without wrecking them<br>
with simple things like entering edit mode.<br>
<br>
That's it I think, if there are other use cases I don't know about them.<br>
<br>
I'd really like to see option II implemented, but I understand this is<br>
a tall order. For correcting normals a modifier-based approach might<br>
be ok. A modifier that calculates the vertex normals by taking the<br>
relative surface areas of the adjoining faces into account<br>
(face-weighted normals) would do most of the job. Such a modifier<br>
should also have an optional threshold below which the larger face<br>
'wins' and the vertex in question is pointed directly along the face<br>
normal. This would probably cover 80% of cases. For the other 20%, the<br>
trouble is that this threshold might be different for different parts<br>
of the low poly mesh, so controlling it with a vertex group (this<br>
would probably be very user-unfriendly), and/or a way to manually tag<br>
faces 'flat' would be in order.<br>
<div><div><br>
<br>
On Fri, Nov 1, 2013 at 7:06 PM, Bastien Montagne <<a href="mailto:montagne29@wanadoo.fr" target="_blank">montagne29@wanadoo.fr</a>> wrote:<br>
> Hey guys,<br>
><br>
> Further tweaked the code, patch is available here (for review as well).<br>
> Still more a draft than final, trunk-ready code, but I would avoid spending<br>
> more time on it before having it reviewed and global design validated.<br>
><br>
> <a href="https://codereview.appspot.com/20790043/" target="_blank">https://codereview.appspot.com/20790043/</a><br>
><br>
> From that point, we can have two different goals:<br>
> I) Simply add import of normals (from FBX and co) as a "frozen" loop normal<br>
> layer, which just stays as-is even if you edit the mesh (probably on a<br>
> vertex- or loop-based flag, so that someone can choose to go back to<br>
> auto-computed ones for some parts of the mesh), and add some modifiers to<br>
> get procedural loop normals editing (e.g. to use other geometry's normals,<br>
> the "trees" example).<br>
> II) Aim to a full support of custom normals.<br>
><br>
> I) is relatively easy to do, could be mostly finished and working in a few<br>
> weeks. However, it is not fully featured and powerful (you can't say "I want<br>
> this normal to point this way"), and support for geometry deformations and<br>
> editing would be *very* poor (in other words, normals computation should<br>
> happen as late as possible in the modifier stack).<br>
><br>
> II) would allow to do virtually everything with normals. However, it is much<br>
> more involved (most likely months of work):<br>
> * Have to add loop normals handling in BMesh.<br>
> * Will need some UI new stuff (maybe a new Loop select mode, similar to<br>
> current vertex/edge/face ones in Edit mode, perhaps even new editing widgets<br>
> in viewport, etc.).<br>
> * Implies to store custom normals as some kind of diff (in tspace-like<br>
> coordinates) format, relative to auto-computed ones. This would allow to<br>
> keep meaningful (to some extend!) custom normals even in heavy geometry<br>
> changes.<br>
><br>
> So I'd really like to get feedback from expert gamedevs, ideally with<br>
> example of workflow involving custom normals (the only real one I found so<br>
> far is the "tree" one, which is very easy to implement as a modifier). I<br>
> need to know whether solution II) (which covers 100% of the editing needs in<br>
> this area) is worth the work involved, or if solution I) (covering maybe 90%<br>
> of needs) could be enough?<br>
><br>
> PS: Don't think I'll make builds, this has proved to be rather painful and<br>
> time consuming in the past (Blender uses many libs, hard to static-link all<br>
> that together), and building Blender is now very easy on every OS!<br>
<br>
<br>
<br>
</div></div><span><font color="#888888">--<br>
Piotr "MadMinstrel" Adamowicz<br>
<a href="mailto:padamowicz@gmail.com" target="_blank">padamowicz@gmail.com</a><br>
</font></span><div><div>_______________________________________________<br>
Bf-gamedev mailing list<br>
<a href="mailto:Bf-gamedev@blender.org" target="_blank">Bf-gamedev@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-gamedev" target="_blank">http://lists.blender.org/mailman/listinfo/bf-gamedev</a><br>
</div></div></blockquote></div><br></div></div></div>