Bug with /fp:fast floating point model

[marcimatz]

Hello,

I tested the Bullet library on a few test scenes, and I am really happy and impressed by the engine.
However I noticed that in some rare cases the engine generated NaN numbers in the body quaternion. That error however only occurs in my case when I compile the whole application (my application with the embedded Bullet engine) with the /fp: fast floating point model (Visual Studio 2005). Using the default /fp:precise switch, the error never occurs. So I am wondering where the error is generated. Is it possible that there is a bug in the integrator? (with the precise floating point model, the error might also occur, but much more rarely?)

My scene set-up is following:

One box is a kinematic body which moves horizontally, then later on slowly rotates around an arc trajectory. A second box is dynamic and makes a small drop onto the kinematic box, then follows the first box's trajectory (it is at this point sitting on the first box). When the first box is about to follow the arc trajectory (i.e. change orientation), the error occurs. The error occurs only rarely but this is the simplest set-up where I could reproduce the error systematically.
(the above set-up is similar to a conveyor belt where a box is moved forward)

EDIT: following topic http://bulletphysics.com/Bullet/phpBB3/ ... f=9&t=4135 sounded similar to my problem, but the proposed workaround has no effect in my case: the NaN is still generated

[Erwin Coumans]

Are you sure the suggested fix in the other topic doesn't fix it (complete rebuild-all etc)?

Is there any way you can share a reproduction case, possibly modifying one of the Bullet demos?
Perhaps more information, callstack etc?
Thanks a lot,
Erwin

[sparkprime]

I quite often get NaNs out of bullet if I spawn two things in exactly the same place (btDiscreteDynamicsWorld). This can happen if I am firing spheres faster than the frame rate and thus the camera doesn't update. It's not really a serious problem for me though so I haven't debugged it properly. I haven't seen any in 'normal' operation.

[marcimatz]

> Are you sure the suggested fix in the other topic doesn't fix it (complete rebuild-all etc)?

Yes, I tried again and it didn't help.

I tried to locate the problem in debug mode, using the same code generation settings (and also the same floating point model), but in debug mode I unfortunately can't reproduce the bug somehow. That's annoying.

[marcimatz]

Well, the bug doesn't appear anymore after adding following lines in the btAcos and btAsin functions:

if (x<-1.0f)
x=-1.0f;
if (x>+1.0f)
x=+1.0f;

[ola]

There seems to be 3 different issues active on the forum now that to me seem to be very similar.

It's my issue with btQuaternion/btVector angles, this one (with a similar, but more general fix), and then this one using btMatrix3x3::getEulerYPR (pitch angle).

btMatrix3x3::getEulerYPR uses btAsin to calculate the angle, and this will return nan with values outside [-1, +1].
btMatrix3x3::getEulerZYX also does this, and to me it seems there isn't any test to see if the arguent is smaller than -1 (only > +1).

There isn't much other code actually using the acos or asin functions.

btAcos is called in btQuaternion (twice), btVector, then once in btSoftBody and BulletMultiThreaded/vectormath/scalar/cpp/quat_aos.h.
btAsin is called in btMatrix3x3 (twice), as mentioned above.

btGeneric6DofConstraint also uses btAsin, but there the input value is actually checked for the valid range before being used (it has it's own version of calculating angles instead of using btMatrix3x3).

marcimatz, are you using any of the getEuler-functions in btMatrix3x3?

[marcimatz]

Ola,

Yes I immediately noticed similarities with your topic. But your proposed fix didn't work for me.
I am not using anything fancy yet, just creating bodies, and stepping the simulation. So I am not explicitely calling any getEuler functions.
In my own application, I am always using robust versions of those functions to avoid rounding/precision issues leading to NaNs.

[Erwin Coumans]

Well, the bug doesn't appear anymore after adding following lines in the btAcos and btAsin functions:

if (x<-1.0f)
x=-1.0f;
if (x>+1.0f)
x=+1.0f;

Unless someone objects, we'll just apply this fix in the btAcos and btAsin function, the overhead is likely very small.

There seems to be 3 different issues active on the forum now that to me seem to be very similar.

All 3 should be solved by above fix, right?

Thanks,
Erwin

[marcimatz]

Thank you Erwin.

Since I applied above changes, the problem disapeared... but I anyway reset the floating point model to precise.
Since then I however noticed just one time a similar error, but unfortunately could not reproduce it. I'll keep you informed should the problem appear again in a reproducible case.

[Erwin Coumans]

The fix has been applied in the latest trunk, please double-check if all is ok now.

Thanks,
Erwin