[JOODE] Bug in RealPointer

Game Mechanics
#1

I think, I found the reason, why JOODE isn’t reacting on any “bounce” setting. I simply didn’t set the appropriate mode bit. But after I set it, I got this exception:


Exception in thread "Thread-1" java.lang.ArrayIndexOutOfBoundsException: 12
	at net.java.dev.joode.util.RealPointer.getValue(RealPointer.java:141)
	at net.java.dev.joode.util.Real.dot(Real.java:114)
	at net.java.dev.joode.joint.JointContact.getInfo2(JointContact.java:146)
	at net.java.dev.joode.stepper.EulerStepper.step(EulerStepper.java:314)
	at net.java.dev.joode.stepper.StepUtils.dxProcessIslands(StepUtils.java:108)
	at net.java.dev.joode.World.stepEuler(World.java:242)
	at net.java.dev.joode.World.step(World.java:208)
	at org.xith3d.physics.simulation.joode.JoodeSimulationWorld.stepImpl(JoodeSimulationWorld.java:134)
	at org.xith3d.physics.simulation.SimulationWorld.step(SimulationWorld.java:253)
	at org.xith3d.physics.simulation.SimulationEngine.step(SimulationEngine.java:148)
	at org.xith3d.physics.simulation.SimulationEngine.update(SimulationEngine.java:175)
	at org.xith3d.physics.PhysicsEngine.update(PhysicsEngine.java:152)
	at org.xith3d.loop.UpdaterImpl.update(UpdaterImpl.java:73)
	at org.xith3d.loop.RenderLoop.prepareNextFrame(RenderLoop.java:675)
	at org.xith3d.loop.RenderLoop.loopIteration(RenderLoop.java:712)
	at org.xith3d.loop.RenderLoop.update(RenderLoop.java:772)
	at org.xith3d.loop.UpdatingThread.nextIteration(UpdatingThread.java:471)
	at org.xith3d.loop.RenderLoop.loop(RenderLoop.java:836)
	at org.xith3d.loop.UpdatingThread.run(UpdatingThread.java:519)
	at org.xith3d.loop.RenderLoop.run(RenderLoop.java:859)
	at java.lang.Thread.run(Thread.java:595)

could this be fixed quickly? Or even better: When could we port JOODE to vecmath2? @Arne: Where are you, man ???.

Marvin

#2

I checked out this bug a little deeper. And ALL cases of this exception are caused by accessing the "data.length"th element. Could it be, that there is a zero-based/one-based bug somewhere in RealPointer?

Marvin

#3

The bug always occurs when “mu” is zero. If “mu” is non-zero, everything is fine. Does this help?

What is “mu” good for, btw.?

Marvin

#4

In real physics, I was heard mu was the greek symbol used for the friction coefficient between two options. Not sure if that’s at all related to RealPointer or where it’s being used for your bug, though.

#5

Fixed.
The bug was that when the dot product is taken, the Vector3 size is incorrectly declared as size 4, not three. So during the process of dot producting the code attempts to reference data in the RealPointer matrix that is not there. Its all to do with the stupid size four packing. sigh I wish I was brave enough (and had enough time) to get all the data in the size format. Its a common cause of problems.
The reason why this bug does not normally show up is because a Vector3 dotted to another Vector3 does not overflow, only when dotted with a pointer to a real.

Anyway, it works now, there is a BounceTest case in the library as well now.

PS and it doesn’t show up when mu is >0 becuase an extra set of constraints are present to represent the friction. Thus when the dot product overflows, it does so into the constraint equations of the mu coeffecients. If we had a true submatrix formulation the error would be caught and assigned to the bounce code no matter what the mu setting was.

#6

Thanks a lot. Well, all these problems would be gone after we ported the lib to OpenMaLi’s vecmath2 :).

Thanks.

vecmath2 has that.

Marvin