# Physics Simulation Forum

 All times are UTC

 Page 1 of 1 [ 1 post ]
 Print view Previous topic | Next topic
Author Message
 Post subject: Subtle determinism bug, and solutionPosted: Thu Jun 12, 2008 10:13 am

Joined: Fri Feb 01, 2008 9:44 am
Posts: 33
We came over this subtle determinism bug:

(From btDiscreteDynamicsWorld::stepSimulation)...
Code:
if (numSimulationSubSteps)
{

saveKinematicState(fixedTimeStep);

applyGravity();

//clamp the number of substeps, to prevent simulation grinding spiralling down to a halt
int clampedSimulationSteps = (numSimulationSubSteps > maxSubSteps)? maxSubSteps : numSimulationSubSteps;

for (int i=0;i<clampedSimulationSteps;i++)
{
internalSingleStepSimulation(fixedTimeStep);
synchronizeMotionStates();
}

}

synchronizeMotionStates();

clearForces();

As you can see, gravity is applied once per call to stepSimulation. Now, this is where it goes wrong...consider an object which is asleep when 'stepSimulation' is entered, and wakes up on one of the internal timesteps. It will have no gravity since it was asleep when 'applyGravity' was called which doesn't apply it to sleeping objects. This doesn't sound like a major issue, but it breaks determinism if you try to replay a sequence of physics events and during the playback, the program's frame rate is different (which is quite common, say, if you change the camera angle for the 'replay'). Although the fixed internal timestep means the framerate in theory doesn't matter, if the framerate is different then the batching of internal timesteps is different, and this bug can lead to gravity being missed for one or more internal timesteps when it was applied the first time around (or vice versa).

There are several solutions; the simplest is probably to apply gravity to all objects, sleeping or not. I think that is harmless because the force will never be integrated, and cleared at the end of 'stepSimulation'.

I think there is another bug lurking here too: I contest whether it is feasible to have a single accumulated force and torque vector. Since the addition of callbacks tied into the internal framerate, if you apply forces in one of these callbacks they will actually compound over internal timesteps which they should not do. My solution, in the end, is to have an 'internal' force and torque and an 'external' force and torque. Internal forces are cleared after each internal timestep, and external forces are cleared only after each 'stepSimultion'. If you apply forces at the 'game' framerate (i.e. between calls to 'stepSimulation' then you apply external forces, if you apply forces in a physics callback, you apply internal forces. It feels like a shame to have to bloat the data structures like this, but I couldn't see a better solution; I'm suprised nobody has noticed this problem since 'setInternalTickCallback' was added. Anyway, I moved gravity to be an internal force, which is an alternate fix for the problem.

Erwin, I'm afraid my changes are now so extensive I can't easily provide a patch for either of these issues, but I would be happy to prepare one if you let me know which solution you prefer, the changes are very simple to implement anyhow.

EDIT: thinking about it more, the cleanest solution is probably just to remove the 'isActive' clause from btRigidBody::applyGravity. Infact, it's probably faster overall, it's probably quicker to add gravity than to check and branch. I haven't tried this solution, it may have side-effects.

Many thanks,
Rob

Top

 Display posts from previous: All posts1 day7 days2 weeks1 month3 months6 months1 year Sort by AuthorPost timeSubject AscendingDescending
 Page 1 of 1 [ 1 post ]

 All times are UTC

#### Who is online

Users browsing this forum: No registered users and 8 guests

 You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum

Search for:
 Jump to:  Select a forum ------------------ BULLET PHYSICS LIBRARY USERS    General Bullet Physics Support and Feedback    Release Announcements    Applications, Games, Demos or Movies using Bullet PHYSICS AUTHORING TOOLS, SERIALIZATION AND STANDARDS    Physics authoring tools, serialization, standards and related topics RESEARCH AND DEVELOPMENT IN COLLISION DETECTION & PHYSICS. Don't post Bullet support questions here!    Research and development discussion about Collision Detection and Physics Simulation    Links, Papers, Libraries, Demos, Movies, Comparisons       Non-technical forum and license/patent discussion    Career Opportunities