[Bf-committers] Normalise patch

[Campbell Barton]

Brecht Van Lommel wrote:
> Hi,
>
> 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.
>
> Brecht.
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

URL:    http://www.metavr.com
e-mail: cbarton at metavr.com
phone: AU (03) 5229 0241