Crazy 3.1 behavior (Location = NaN)

Hey Guys,
I just started to work on my 3.1 branch and after updating a few libs it somewhat works :stuck_out_tongue:

The Problem is the following: My code works in 3.0 but not under 3.1
When I don’t attach my Player (Spatial) to the BulletAppState everything is as expected (well, except for gravity :stuck_out_tongue: )

This is how my Spatials PhysicsLocation looks like when attached to the PhysicsSpace:

(0.0, 1.1851496, 0.0)
(0.0, 0.98077464, 0.0)
(0.0, 0.65377474, 0.0)
(0.0, 0.53932476, 0.0)
(0.0, 0.53932476, 0.0)
(0.0, 0.42214978, 0.0)
(0.0, -0.0738001, 0.0)
(0.0, -0.20460007, 0.0)
(0.0, -0.474375, 0.0)
(NaN, NaN, NaN)

Now the question is: What happens when I collide with the ground, so that I get the NaN-Vector?
From the PhysicsDebug View I can see that everything has a collision shape etc so it should work.

Thanks in Advance

I remember (roughly) somthing with inertia and behavior differently between Linux and windows in a division / 0 case. Is a Meshcollision shape somewhere in there? Are you on windows?

I am currently comparing Mac OS X versions.
I also found a post (I guess by you), where someone said stuff about x * 0 whereas x = NaN and so based on compiler magic it’s: NaN * 0 = NaN or NaN * 0 = 0.

Anyhow that was targeted to zero-masses which I don’t use so it’s really wierd.
I also noticed another change: In 3.0 a wrong gravity doesn’t affect anything. Here it atleast turned the world upside-down. (though the NaN Bug occured anyway)

I don’t know much about the bullet physics integration and I don’t know anything at all about your app… but stuff to look for:
-invalid rotations
-anywhere a divide by 0 could occur (time step = 0, mass = 0, etc.)

…essentially, check every input you send to bullet for strange values.

Else, see if you can narrow it down to a simple test case so others might spot the issue.

Mhh I tried the test case even with the same .j3o’s but I can’t reproduce it there :confused:
I don’t really play around with rotations or any stuff, I only use .setViewDirection() and setWalkDirection on a BetterCharacterControl.

Even after Bruteforcing (random values between -1 and 1) a few minutes the bug didn’t occur.
I do get some Quaternions but I don’t really change them.

If I knew what changed between 3.0 and 3.1 then I could look closer.
Else I need to increase my testcase :confused:

Could I maybe use the debugger on prePhysicsTick or anything like that? (I guess I’d need jBullet because else I wouldn’t see anything)

And what values are you sending to these? Log those. setViewDirection() especially.

Okay, it really seems to be an OS-dependant case as @Empire_Phoenix guessed.

It runs fine on Windows with native-bullet, it runs fine on Mac with JBullet, but it doesn’t run on Mac with Native-Bullet.

It’s not the first problem I encounter on the native-bullet: Native bullet crash when using ragdoll without bones · Issue #367 · jMonkeyEngine/jmonkeyengine · GitHub

Either something is wrong with my computer or nobody really tested the new bullet on mac or the newer version is somewhat broken.

Back to the test case: I tried to fire random values on the Directions() and also the “-0” which caused some problems in BCC (Or say at least an error message, since it checks for equality with Vector3f.ZERO), but I will investigate on what I actually send.

I am linking @Dokthar and @normen since you are the bullet guys, maybe you know something? (BTW Its Mac OS X 10.9.5)

And the last thing: On my Windows-Box the 3.1 only renders the GUI and the Bullet Debug Output. It looks like an “endless recursion” or say the Viewport doesn’t get cleaned before a new render.
Any Ideas on that?

i also encounter this issue running on linux ubuntu.

but for your issue could you give a simple test case as pspeed said :