Odd determinism problem

[rusty]

I have a very odd determinism issuet, and I'm trying to figure out if it's caused by my own code or Bullet.

I have a replay of a car on a track, that plays back on it's own just fine. But, when I have a race against the ghost, it goes screwy and the replay is no longer deterministic. The ghost cannot collide with the player car, and it does nothing different to the solo ghost replay.

I've disabled the random functionality in the solver mode, but this has not changed anything. Nor would I expect it to, as the cars do not collide.

Is there something in Bullet that has some incremental effect over a number of rigid bodies, such a random dampening term during integration which changes some current random number state? This is the only thing that I can think of that would wreck the determinism of the ghost during a race, but after looking trough the Bullet source, I just can't seem to figure where that might be.

Any ideas?

[ola]

not really an answer to your question, but why don't you just play back a recording of the car's position and orientation, updating it as a kinematic object (or just move it's graphics model, it's a ghost, after all), instead of simulating it during the replay?

In my experience, designing something to depend on the determinism of the physics engine isn't very robust, and should be avoided when possible.

Cheers,
Ola

[Erwin Coumans]

Indeed, Ole's suggestion of recording the transform for the vehicle might be best.

I have a replay of a car on a track, that plays back on it's own just fine. But, when I have a race against the ghost, it goes screwy and the replay is no longer deterministic. The ghost cannot collide with the player car, and it does nothing different to the solo ghost replay.

A simulation will not be deterministic once you add another object, such as a ghost object. The number of objects needs to be the same, the order in which the objects are added to the world etc, see Bullet/Demos/OpenGL/DemoApplication.cpp method void DemoApplication::clientResetScene() how to reset a simulation. Once you add a ghost object, the broadphase pairs might have a different order, compared to a simulation without that ghost object.

Can you try to re-run the simulation without adding that ghost object, and see if it is deterministic?
Thanks,
Erwin

[rusty]

I have actually recorded the position and orientation of the object at 5Hz which is enough to correct the error, which appears to be very small and resolves it all without popping.

But this tends to blow the size of the recorded data over the duration of a race, even when compressed. This is problematic as we need to transmit that data to a server, and store it in a database.

A simulation will not be deterministic once you add another object, such as a ghost object. The number of objects needs to be the same, the order in which the objects are added to the world etc, see Bullet/Demos/OpenGL/DemoApplication.cpp method void DemoApplication::clientResetScene() how to reset a simulation. Once you add a ghost object, the broadphase pairs might have a different order, compared to a simulation without that ghost object.

Can you try to re-run the simulation without adding that ghost object, and see if it is deterministic?

Is this true, even if the ghost object and player object cannot collide? Surely because no contact constraints are ever generated, the fact that there is one or two bodies should be irrelevant UNLESS there is some persistent state between resolving broad phase pairs (i.e. a racer car and the world collision) or integration of the body forces.

I have written my own rigid body sims with collisions in the past, and have been able to add ghost objects for replays without any issues, as the ghost object has no interaction with the game world beyond colliding with static objects. I'll admit that the sims I have written in the past may not have been as feature rich as Bullet, and less sophisticated in some parts of the implementation, but this does seem like an odd problem to me.

I actually destroy the simulation and then construct a new one during the game/replay reset which takes care of making sure that the simulation is set to known state. I still get the problem if I start the executable again, and start a race with the ghost.

[Erwin Coumans]

Is this true, even if the ghost object and player object cannot collide? Surely because no contact constraints are ever generated, the fact that there is one or two bodies should be irrelevant UNLESS there is some persistent state between resolving broad phase pairs (i.e. a racer car and the world collision) or integration of the body forces.

The overlapping pairs are persistent, and keep information, such as constraint solver warmstarting (lambda) values and cached collision information.

If you add/remove other objects, the order of overlapping pairs might change, which changes the constraint solver behaviour.

Why do you need to insert a new object (ghost) into the dynamics world during replay?
Thanks,
Erwin