Celestia Forums

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...

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?

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 !

I don't see this bug . . . Which compiler are you using? It's possible that there's a divide by zero error someplace that only appears when a particular compiler or library is used.

--Chris

Yes I forgot to tell you that now I'm compiling under .NET and not 6.0 anymore...

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

Perhaps you could tell me where to investigate these divisions so I can debug...

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):



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

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:



It would be inappopriate to modify dot() to clamp its result, as there's no mathematical limit to the range of this function.

--Chris

chris wrote:It would be inappopriate to modify dot() to clamp its result, as there's no mathematical limit to the range of this function.

Ups I must have been thinking about normalized vectors...

I've added the clamping and it does not change anything

By the way, If I compile in DEBUG there is no probleme at all with the center function.

So the problem comes from the RELEASE version only !

WFM - I can't trigger this bug anymore. But considering the type of bug there could be many places possibly affected. Maybe replacing calls to acos (and similar functions) by a safe wrapper could help, at least for debugging.

If I remove the "maximize speed" in the optimisation panel of the projects properties the bug is gone...

So it seems that .NET does some bad optimisations !