[Fluxus] commits + recalc-normals bug

Glauber Alex Dias Prado smade4 at gmail.com
Sun Jan 17 15:20:49 PST 2010


Dave Griffiths <dave at pawfal.org> writes:

> On Sun, 2010-01-17 at 17:48 +0100, gabor papp wrote:
>> > I just 'fixed' this. The behaviour of sharp or smooth normals for
>> > indexed poly prims is implicitly determined by the indexing. 
>> great, thanks. on the other hand, it seems that obj files have sharp 
>> face normals instead of smoother vertex normals. so the new way how 
>> (recalc-normals 1) works with obj files, won't help.
>
> Well the initial sharp/smoothness of models from obj should be defined
> entirely by the modelling package.
>
> If you run recalc-normals on an model from obj - it should blend normals
> on shared vertices and generate separate normals for non-shared
> coincident vertices. So this is determined by how the modeller has
> exported the geometry I think.
>
> I'm guessing this index unification stuff that we've been talking about
> due to loading speed is also causing problems here though - eg. by
> creating extra normals or vertex positions....
if each index that you are talking about is each vertex(from a poligon
modeller perspective) then duplicated index(or rather indexes too much
close and connected with different indexes) will break geometry.
>
> cheers,
>
> dave



More information about the Fluxus mailing list