Single-step Kinematics-only Collision Detection


What I’m trying to do:
I’m trying to create a JME-based server that allows clients to independently register their own geometries and find out if they are colliding with other objects. The geometries and positions/orientations of these clients will be determined by physical hardware and the aim of the library is to predict and avoid real-world physical collisions. I am not interested in simulating physics in time steps, only collision detection. I am still very keen on using JME’s abstractions and graphical abilities in SimpleApplication for debugging/visualization.

My problem:
I have my own synchronous (i.e. non-threaded) implementation of JmeContext which calls update() on its SystemListener when manually stepped after each Spatial is added or moved. This works fine at the moment except I have to call call update() about 10000 times to realiably trigger the collision event in my PhysicsCollisionListener. I’ve tried experimenting with bulletAppState.getPhysicsSpace().setMaxSubSteps() and bulletAppState.setSpeed() but to no avail.

To rule out timing/framerate issues I’ve tried using my own Timer implementation that always returns 60fps or 1/60tpf to JME. Accurate time-scales shouldn’t matter since all my objects are kinematic. This does not seem to affect collision detection reliability.

Why do I have to call SystemListener.update() so many times to actually trigger collision events in native bullet?


The next thing to check, I think, is how often PhysicsSpace.update() is being called, and with what values of time, maxSteps, and accuracy.


Good tip, thank you. This helped me figure out that LegacyApplication does not assign the JmeContext's timer because it is set to new NanoTimer() in timer's field declaration. Probably a bug, judging from LegacyApplication.setTimer()'s JavaDoc.

Now that I actually am using my own Timer implementation I am able to lower the number of calls to SystemListener.update() to 2! Any clues on why I still need a second update call?


I think you’re using Bullet in ways the authors never intended.

I haven’t yet dug into Bullet’s btDiscreteDynamicsWorld::stepSimulation() code in detail, so I can only speculate. Perhaps collision detection takes place before new collision objects are effectively added to the world.