Jump to content

  • Log In with Google      Sign In   
  • Create Account

how to implement stable timestep for systems (Bullet Physics and SFML for time) when they are processed through a list.


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 Gasimzada   Members   -  Reputation: 206

Like
0Likes
Like

Posted 03 December 2013 - 12:05 PM

I have integrated Bullet physics to my engine and I am having trouble with the timestep. I have read the "Fix your timestep" and other articles regarding this issue, but none of them help me with my design. This is my update function:

int SFMLWindow::run() {
        bool bRunning = true;
        sf::Clock clock;
        sf::Time oldTime = clock.getElapsedTime();
        sf::Time deltaTime;
        while(bRunning) {
            
            sf::Time currentTime = clock.getElapsedTime();
            deltaTime = currentTime - oldTime;
            currentTime = oldTime;
            
            mRenderWindow.clear();
            mRenderWindow.pushGLStates();
            mCurrentState->update(deltaTime.asSeconds());
            mRenderWindow.popGLStates();
            
            mRenderWindow.display();
        }
        return 0;
    }

The state holds all the systems and passed the "deltaTime.asSeconds()" parameter to the update function of these systems. And here is the bullet physics update function:

   void BulletPhysicsSystem::update(double dt) {
        mWorld->stepSimulation(dt,10.0);
    }

The problem is, the sphere I have in my scene goes with a speed of light to the ground. What should I add or do?


Edited by Gasimzada, 03 December 2013 - 12:13 PM.


Sponsor:

#2 Álvaro   Crossbones+   -  Reputation: 13934

Like
1Likes
Like

Posted 03 December 2013 - 01:17 PM

currentTime = oldTime;

 

Are you sure you don't want to do the opposite?



#3 Gasimzada   Members   -  Reputation: 206

Like
0Likes
Like

Posted 03 December 2013 - 01:23 PM

I cannot believe I missed that! Thank you!



#4 ferrous   Members   -  Reputation: 2146

Like
0Likes
Like

Posted 03 December 2013 - 05:02 PM

It looks like Alvaro already spotted your problem, but I figured I'd add to the conversation anyway:

 

How 'smart' is the bullet physics update call, does it automatically break up the update if the delta passed in is too large?  I'm assuming that is what the 'fix your timestep' articles you mention are talking about?



#5 Gasimzada   Members   -  Reputation: 206

Like
1Likes
Like

Posted 03 December 2013 - 05:16 PM

Yes thats what it does. Here is the wiki from Bullet Physics:

 

 

 

It's important that timeStep is always less than maxSubSteps*fixedTimeStep, otherwise you are losing time. Mathematically,

timeStep < maxSubSteps * fixedTimeStep

When you are calculating what figures you need for your game, start by picking the maximum and minimum framerates you expect to see. For example, I cap my game framerate at 120fps, I guess it might conceivably go as low as 12fps.

 

After you asked the question, I couldn't stop myself from digging into the source code of Bullet:

if (maxSubSteps)
	{
		//fixed timestep with interpolation
		m_fixedTimeStep = fixedTimeStep;
		m_localTime += timeStep;
		if (m_localTime >= fixedTimeStep)
		{
			numSimulationSubSteps = int( m_localTime / fixedTimeStep);
			m_localTime -= numSimulationSubSteps * fixedTimeStep;
		}
	} 

So it looks like the "semi-fixed timestep" from the article I was referring to.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS