[Bf-committers] Normalise patch
cbarton at metavr.com
Fri Feb 10 03:38:56 CET 2006
Brecht Van Lommel wrote:
> 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
> 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),
> add (0, 0, 1) to the vertex normal. If the normal computation code
> 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)
> on this behavior.
Some of my python scripts rely on a zero length vector (0,0,0) to see if
a face is zero area.
....Cessen- its funny how somthing that can seem so logical at the time
can cause such a debate :) Maybe there can be an alternative normalize
func if its important for your needs.
Campbell J Barton
133 Hope Street
Geelong West, Victoria 3218 Australia
e-mail: cbarton at metavr.com
phone: AU (03) 5229 0241
More information about the Bf-committers