Bug? btDiscreteDynamicsWorld::stepSimulation()

[tentoo]

function btDiscreteDynamicsWorld::stepSimulation(), like this

Code: Select all

    :
if (maxSubSteps)
{
    //fixed timestep with interpolation
    m_localTime += timeStep;
    if (m_localTime >= fixedTimeStep)
    {
        numSimulationSubSteps = int( m_localTime / fixedTimeStep);
        m_localTime -= numSimulationSubSteps * fixedTimeStep;
    }
} else
{
    //variable timestep
    fixedTimeStep = timeStep;
    m_localTime = timeStep;          // <-- Here. I think that m_localTime = btScalar(0.);
    if (btFuzzyZero(timeStep))
    {
        numSimulationSubSteps = 0;
        maxSubSteps = 0;
    } else
    {
        numSimulationSubSteps = 1;
        maxSubSteps = 1;
    }
}
    :

When maxSubSteps is zero, m_localTime equals timeStep.
But I think that like this

Code: Select all

m_localTime = btScalar(0.);

[sparkprime]

As far as I can tell, bt_localTime is "the bit left over" after the real time has been simulated by an integer number of fixed time steps. It's only used to interpolate, and I presume it's the distance into the future (according to simulation time) that is interpolated over to bring the transforms up to real time.

Since we want no interpolation if there is no fixed time step then surely it makes sense to set this to 0.

[tentoo]

Thanks for your response.

I thought that following codes should get a same result.

Code: Select all

m_dynamicsWorld->stepSimulation(stepTime,1,stepTime);

Code: Select all

m_dynamicsWorld->stepSimulation(stepTime,0);

But not,
objects smooth moved, first code than second code.(I tried that stepTime = 1.0f/30.0f)
From now on, I use to first code.

[sparkprime]

Yes I believe if you call stepSimulation(x,1,x) you will get the behaviour that you are supposed to get from stepSimulation(x,0). Alternatively, you could modify bullet's source code, I have a number of changes in mine already (including this one, now).

Thinking about it, what's the point of stepSimulation(x,0) if it's equivalent to stepSimulation(x,*,x)?

[chunky]

maxsubsteps=0 is for variable timesteps.

What this means is that if your app calls stepSimulation(x,0), then yes, that's equivalent to stepSimulation(x,1,x). But the first x isn't always the same, while the second one is [or should be]; you're typically calling stepSimulation(time-since-last-stepsimulation-call, N, X).

maxsubsteps = 0 is not your friend. It leads to nondeterministic simulation, and large values of time passed as the first parameter lead to various woes including tunnelling [where objects don't collide with others].

Gary (-;

[cobolt_dink]

What is the proper way to use stepSimulation() if you use a high res timer so you have variable timestep between frames?

I tried this since I thought the physics were supposed to be a fixed timestep:

Code: Select all

#define PHYSICS_TIMESTEP = 1.0f/60.0f

m_accumulator += delta;

while (m_accumulator >= PHYSICS_TIMESTEP)
{
     m_dynamicsWorld->stepSimulation(PHYSICS_TIMESTEP);

     m_accumulator -= PHYSICS_TIMESTEP;
}

But that will make the physics run jerky at times. So I changed it to just this:

Code: Select all

m_dynamicsWorld->stepSimulation(delta);

Where delta is the time calculated between frames from the high res timer and the physics seem to be stable.

[chunky]

What is the proper way to use stepSimulation() if you use a high res timer so you have variable timestep between frames?

I assume you mean "variable time" and not "variable timestep", there.

Code: Select all

m_dynamicsWorld->stepSimulation(delta);

Where delta is the time calculated between frames from the high res timer and the physics seem to be stable.

Intuitively, this is likely to be the right one since it implies that the physics engine is doing the things that you'd expect the physics engine to do.

You may find this useful, that I wrote a while ago: http://chunkyks.com/bulletthings.pdf

Gary (-;

[cobolt_dink]

I ask because I was messing with Newton and it really needs to be run on a fixed timestep to be stable. I was having to run it at 200 FPS to get it to run right and still the block action is what I would like. But since Bullet is running at 60 FPS internally by default I don't need to try and fix the timestep?

But now I have a question about the number of substeps per physics tick. It seems that you shouldn't leave the number of substeps at one if you are planning on targetting older hardware that may not be able to keep a constant 60 FPS? From your article it just seems you should guess a low ball number for FPS and adjust the substeps to that.

[chunky]

But since Bullet is running at 60 FPS internally by default I don't need to try and fix the timestep?

Bullet does that stuff for you. By changing the third parameter, you can change that 60fps, but be sure to always pass the same value.

But now I have a question about the number of substeps per physics tick. It seems that you shouldn't leave the number of substeps at one if you are planning on targetting older hardware that may not be able to keep a constant 60 FPS? From your article it just seems you should guess a low ball number for FPS and adjust the substeps to that.

One is the default because, for want of a number, anything higher didn't make sense as a default, and zero is bad. So, yes, you'll probably want something higher in practice. And your last comment there seems like a pretty good precis

Gary (-;

[cobolt_dink]

Thanks, I have more of an idea what I'm trying to do now.

The demos are great for getting things up and running. I think all my actual physics code comes from the demos. But it would be nice to have some more "real world" example programs to learn from. I'd figure most of the problems I've had are because I've kind of guessed when integrating physics into a scene graph and the attached entities.