[Bf-committers] Normalise patch
Brecht Van Lommel
brechtvanlommel at pandora.be
Fri Feb 10 01:37:03 CET 2006
Michael Reimpell wrote:
>> It was setting
>> super-small vectors to <0,0,0>, which really isn't a good behavior for
>> something that's supposed to return vectors of length 1.
> The normalise function is _not_ supposed to return a vector of unit length for
> the zero element of the vector space! Mapping 0 to 0 is the most reasonable
> mapping. Translation, e.g., 0 -> (0,0,1), has nothing to do with
> normalisation! Of course this applies to all floating point representations
> of the zero element, i.e., all vectors of length below a certain threshold.
My main concern about this patch is what influence it will have on the _300_
different places in the code Normalise is used. How do you know that there is
no dependency on Normalise returning a (0,0,0) vector?
For example, in blenkernel/intern/mesh.c, mesh_calc_normals. There the
normals from faces are interpolated to get a vertex normals. With the new
code, normals of faces without a proper normal (e.g. with zero area), will
add (0, 0, 1) to the vertex normal. If the normal computation code shouldn't
also use the face angle or area is debatable of course, but you get the point.
I can imagine there being more places with a (possibly indirect) dependency
on this behavior.
More information about the Bf-committers