[ quesa-Bugs-909213 ] SetRotateVectorToVector problem

[SourceForge.net <no...@so...>]

Bugs item #909213, was opened at 2004-03-03 17:56
Message generated for change (Comment added) made by grantd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=909213&group_id=45158

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Tom Sanham (tomsanham)
Assigned to: Nobody/Anonymous (nobody)
Summary: SetRotateVectorToVector problem

Initial Comment:
Some input values for 
Q3Quaternion_SetRotateVectorToVector produce duff 
quaternions.

Example:

start vector:
-0.2252647,-0.8941119,-182972.5

put through Q3Vector3D_Normalize gives
-1.231140e-6,-4.886592e-6,-1

Now do Q3Quaternion_SetRotateVectorToVector with 
the following parameters:
v1=-1.231140e-6,-4.886592e-6,-1
v2=0,0,1

the resulting quaternion is (0,-INF,INF,NAN)

This problem occurs on Mac OS X Quesa, I am unable to 
reproduce it on Windows.

To workaround this case, I just detect magnitudes <1e-
5 and set them to 0, and hence v1 becomes 0,0,-1, 
which then works correctly.

----------------------------------------------------------------------

>Comment By: Dair Grant (grantd)
Date: 2004-03-04 22:40

Message:
Logged In: YES 
user_id=439944

I've checked in a fix - the problem appears to be in the use of a macro 
which compares the vector length to a tolerance.

When done as a macro, this routine operates entirely in registers (which 
are double-precision on PowerPC, although the inputs to this routine are 
floats).

When implemented as a function, the inputs are passed through memory 
and truncated to single precision - which allows the existing tolerance 
test to pass.

Strictly speaking the example inputs should be allowed to fail (since v1 is 
not normalised), and one way to address this would be to have 
Q3Vector3D_Normalise double-check its outputs. However this would 
make normalising a vector quite expensive (6 additional compares, 12 if 
it should also have a tolerance) and since we need to handle tolerance in 
RotateVToV anyway we might as well do it once.

Would be interesting to know if the original code fails on x86 as well: I 
suspect it won't, even in macro form.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=909213&group_id=45158