Archive 17/01/2023.

Bullet stepSimulation() question

TheComet

I was tracking down a bug when I came across this section of code in btDescreteDynamicsWorld.cpp:454:

for (int i=0;i<clampedSimulationSteps;i++) { // Urho3D: apply gravity and clear forces on each substep applyGravity(); internalSingleStepSimulation(fixedTimeStep); synchronizeMotionStates(); clearForces(); } } else { synchronizeMotionStates(); }

When comparing this to bullet’s official repository, we see something different:

[code] applyGravity();

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

clearForces();[/code]

applyGravity() and clearForces() are outside of the for loop. I’m interested why there is a discrepancy here.

Enhex

Are you comparing Urho’s Bullet to Bullet’s HEAD version?
AFAIK Urho’s Bullet is older version.

TheComet

That doesn’t matter because the code I speak of was modified explicitly by an Urho3D developer. I’m wondering what the exact reasoning behind this change was.

Enhex

Tried to log the git repo but it only goes back to a version which already had the change (Commit: 02512cecf928c89863d1c5ec6874e5f4abcfaeb6).

weitjong

Use the git log with “–follow” option.

Enhex

Commit: ee668a791f5842180d139f60fe4fd8f8c47c2456 [ee668a7]
Clear forces after each physics substep so that rendering framerate doesn’t affect code which calls ApplyForce() / ApplyTorque().

Commit: 20c63654e374f8dbc00ef13ddd0b6f717555d42c [20c6365]
Fixed gravity being incorrectly applied if framerate is low.