Hi,
I've just updated my CVS (not done since 2 months) and now I got a new bug.
If i'm already centered on a body and I press the "c" key again : the camera jerks and finally returns to the center of the body...
But it should not move at all (like before) since it's already centered...
And in e more general way, the center command now moves the camera really strangly...
Center bug...
Are you using Capital C (shift-c) or lower-case c?
Capital C is new: it is supposed to keep the previously selected object in the same position on the screen while the newly selected object is centered. (e.g. it can be used to keep a spacecraft in view while turning the viewpoint toward the next flyby target.)
Lower-case c is supposed to work as it always has: it should just turn the viewpoint toward the currently selected object.
Is this what is happening or is it doing something different?
Capital C is new: it is supposed to keep the previously selected object in the same position on the screen while the newly selected object is centered. (e.g. it can be used to keep a spacecraft in view while turning the viewpoint toward the next flyby target.)
Lower-case c is supposed to work as it always has: it should just turn the viewpoint toward the currently selected object.
Is this what is happening or is it doing something different?
Selden
-
Topic authorKendrix
- Posts: 159
- Joined: 02.06.2002
- With us: 22 years 5 months
- Location: near Paris, France
- Contact:
I know the differences between the "C" and the "c" command.
Until now they worked very well !
But the simple "center" command is bugged since I've updated my CVS tree (today and not done since end of september)
Just read the exemple I gave in the first post to have a description of the bug.
Another example : I was centered on earth and I press "c" again : Suddenly I was seeing only black everywhere and I was at 18 million LY from the earth !!!
What a bug !
Until now they worked very well !
But the simple "center" command is bugged since I've updated my CVS tree (today and not done since end of september)
Just read the exemple I gave in the first post to have a description of the bug.
Another example : I was centered on earth and I press "c" again : Suddenly I was seeing only black everywhere and I was at 18 million LY from the earth !!!
What a bug !
-
chris
- Site Admin
- Posts: 4211
- Joined: 28.01.2002
- With us: 22 years 9 months
- Location: Seattle, Washington, USA
Kendrix wrote:Yes I forgot to tell you that now I'm compiling under .NET and not 6.0 anymore...
That's what I thought . . . I ran into an earlier divide by zero problem that only appeared when I compiled with .NET. This would be easy for me to debug except that the hard drive just died on my computer with Visual Studio .NET installed. I'm reluctant to update my only other Windows machine with .NET at the moment, but I should be getting a new drive very soon.
--Chris
chris wrote:That's what I thought . . . I ran into an earlier divide by zero problem that only appeared when I compiled with .NET.
Just saw the same (or at least a similar) problem on my system (Linux, gcc 3.2): Pressing "c" two times quickly in succession (i.e. while first still shows "travelling") leads to this:
Pressing "g" will decrease the displayed distance like with normal goto, but will reset to 3718 ly after travelling.
UPDATE:
This also happens with goto. Sometimes I can't trigger the bug, other times it happens the first time I press "c" (or "g") twice in rapid succession. The "follow" mode seems to be immune, but this could be luck & my imagination.
Chris, after the bug occurs, the rotation is w=x=y=z=NAN. Could this be the result of calling normalize on a all-zero quat?
Harald
Harry wrote:Chris, after the bug occurs, the rotation is w=x=y=z=NAN. Could this be the result of calling normalize on a all-zero quat?
It's not...
The problem lies in quaternion.h Quaternion::slerp() (l. 581):
Code: Select all
template<class T> Quaternion<T> Quaternion<T>::slerp(Quaternion<T> q0,
Quaternion<T> q1,
T t)
{
T c = dot(q0, q1);
T angle = (T) acos(c);
if (abs(angle) < (T) 1.0e-5)
return q0;
...
If q0 and q1 are nearly equal, c = dot(q0, q1) can become > 1
(in my case: the lsb of c is set, which it shouldn't be)! Don't know how this is happening, this may be a compiler thing or simply bad luck with rounding. Whatever, the result is:
angle will be NaN, then "s" and "is" will be NaN too and the result is all NaNs.
Chris, can we have a guard against this one? Like checking for "c > 1.0f", or making sure dot() never returns any result > 1 ? Or maybe inverting the "if (abs(angle) < (T) 1.0e-5)", AFAIR comparisons with NaN always fail...
I hope there aren't more arithmetic bugs like this one. They are hard to evade, as the code seems to be ok (it actually is, from a mathematical point of view).
Harald
-
chris
- Site Admin
- Posts: 4211
- Joined: 28.01.2002
- With us: 22 years 9 months
- Location: Seattle, Washington, USA
Harry wrote:The problem lies in quaternion.h Quaternion::slerp() (l. 581):Code: Select all
template<class T> Quaternion<T> Quaternion<T>::slerp(Quaternion<T> q0,
Quaternion<T> q1,
T t)
{
T c = dot(q0, q1);
T angle = (T) acos(c);
if (abs(angle) < (T) 1.0e-5)
return q0;
...
Yes, this looks like the problem . . . In cases like this, the input to acos needs to be clamped to [ -1, 1 ]
Chris, can we have a guard against this one? Like checking for "c > 1.0f", or making sure dot() never returns any result > 1 ? Or maybe inverting the "if (abs(angle) < (T) 1.0e-5)", AFAIR comparisons with NaN always fail...
The test should be:
Code: Select all
if (c > (T) 1.0)
c = (T) 1.0;
else if (c < (T) -1.0)
c = (T) -1.0;
It would be inappopriate to modify dot() to clamp its result, as there's no mathematical limit to the range of this function.
--Chris
I must have been thinking about normalized vectors...