applyGravity in stepSimulation causes determinism loss?

[efaj]

Excerpt from bullet's source (taken from http://bulletphysics.com/Bullet/BulletF ... ource.html which I have no idea which version is, but the code matches the behaviour 2.81 exhibits -and also it's source, after I went to check my copy-)

Code: Select all

 saveKinematicState(fixedTimeStep*clampedSimulationSteps);
00449 
00450                 applyGravity();
00451 
00452                 
00453 
00454                 for (int i=0;i<clampedSimulationSteps;i++)
00455                 {
00456                         internalSingleStepSimulation(fixedTimeStep);
00457                         synchronizeMotionStates();
00458                 }

As can be seen, applyGravity is executed outside the step execution loop. This causes the loss of determinism if forces are edited during mid-step, which is my current case: I'm running some game scripts at each preTick, this means that in high FPS environments, gravity quickly cancels this forces, while in low FPS, the script forces are able to stack for several physic ticks.

[xexuxjy]

applyGravity doesn't have any timestep component to it, all it does is update the total force so it has a standard 9.8m/s value , it's only when integrateTransforms is called during the rest of the simulation that the timestep comes into play . I believe thats why it's setup outside the number of steps sub loop.

I guess one option you could do is just have bullet have a gravity value of zero, and apply a gravity value in your scripts along with your other forces so they're guaranteed to be in step?

[efaj]

applyGravity doesn't have any timestep component to it, all it does is update the total force so it has a standard 9.8m/s value , it's only when integrateTransforms is called during the rest of the simulation that the timestep comes into play . I believe thats why it's setup outside the number of steps sub loop.

I guess one option you could do is just have bullet have a gravity value of zero, and apply a gravity value in your scripts along with your other forces so they're guaranteed to be in step?

That one seems like too much work heh...
What I ended up doing, and seems to work so far, is to make sure myself that each "stepSimulation" calls only one substep, like this:

Code: Select all

localTime+=((float)deltaMilliseconds)/1000.f;
	while( localTime > PhysicsMan::timeStepLength ){
		world->stepSimulation( PhysicsMan::timeStepLength, 2, PhysicsMan::timeStepLength );
		localTime-=PhysicsMan::timeStepLength;
	}

where localTime is a member float variable. I pass a maxSubSteps=2 just in case.