New Physics

Troubleshooting physics
1

Hello,

I’m developing a new game in which the main character is driven by a set of complex equations. I need to get the behaviour computation with a time step which is not linked to the FPS so that the model is still convergent whatever the graphics performances. Even thought the objective is to simulate a flying object, I do not want to use the Rigid Body control but a mechanism based on second order system equations.

Could you tell me what is the best way to get the main character motion computed with a time step I can master?

2

create a new thread, have it step at a constant rate.

then attach controls to various spatials on the scene graph to copy transforms to the spatials from your game’s model

this is how bullet app state works btw. by default bullet app state runs at a constant 60 frames per second.

3

Bullet doesn’t have an update thread running at its framerate but it still uses a fixed framerate for computations. It deduces the timing from the input tpf and runs multiple updates / interpolation-only updates as necessary (which you should do as well, depending on a constant update rate is basically a design flaw).

4

Do not use a new thread unless you have to, it only complicates stuff.

A good read for you I think: http://gafferongames.com/game-physics/fix-your-timestep/
The final version of the game update loop in that post is essentially what bullet uses and what one should use when calculating physics.

1 Like
5

Thanks for your abswers,

I was rather thinking about using the BulletAppstate and instead of adding a RigidBodyControl to the PhysicSpace , I would have add a Custom Control… I would have reduced the coding time and allow me to get a code fully in line with the philosophy of the librairy… I wonder if I should manage this at PhysicSpace level or if I have to design also a custom space to do that…

6

Hello,

Finally I applied the method given by kwando (many thanks to him) and it’s quite easy.
I’ve just created a new class name HelicoSimulationState which derives from a Thread as here below:

[java]public class HelicoSimulationState extends Thread{
private boolean _blnExitGame;
private Helicopter _helico;

public HelicoSimulationState(Helicopter helico){
    _blnExitGame = false;
    _helico = helico;
}

public void stopGame(){
    _blnExitGame = true;
}
@Override
public void run(){
    long currentTime = System.currentTimeMillis();
    long accumulator = 0;
    long dt = 20;
    
    while(!_blnExitGame) {
        long newTime = System.currentTimeMillis();
        long frameTime = newTime - currentTime;
        if ( frameTime > 250 ) frameTime = 250;
        currentTime = newTime;

        accumulator += frameTime;

        while ( accumulator >= dt ){
            _doSomething(dt);
            accumulator -= dt;
        }
    }
}

private void _doSomething(long dtms){
    float dt = dtms*0.001f;
    _helico.updateMotion(dt);
}

}[/java]

In my helicopter Object, I compute the motion from a set of second order equation so that I can fine tune the overall helicopter response without any intensive work… I store all the motion parameters in a Vector…
Then I have a render method called from the update method of my AppState that is just updating the 3D model position and attitude according to what is computed in the simulation Thread…

It was very easy to implement and test! Now I have to make it clean!

7

You do not need that thread, it will only give you headaches unless you equations is really heavy. Use what jME gives you instead, I’m feeling generous today so I whipped up this…

[java]
import com.jme3.app.state.AbstractAppState;

/**

  • @author kwando
    */
    public abstract class FixedUpdateAppState extends AbstractAppState {

private final float dt;
private float accumulatedTime = 0;

public FixedUpdateAppState(float dt){
this.dt = dt;
}

@Override
public void update(float tpf) {
super.update(tpf);
accumulatedTime += tpf;

while (accumulatedTime > dt) {
  stepPhysics(dt, accumulatedTime / dt);
  accumulatedTime -= dt;
}

}

/**

  • Will be called 1/delta times per second
  • @param delta length of a timestep
  • @param interpolationRatio how much “extra” time we have accumulated
    */
    public abstract void stepPhysics(float delta, float interpolationRatio);
    }
    [/java]
8

In this case, shall I consider that tpf in the update method has nothing to do with the tpf we get in a simpleapplication update method which is more or less the frame rate? If so this method looks better.
The equations I’m using are basic second order equation to simulate an helicopter motion with all the couplings… It does not requires heavy computation resources, but I need to make sure that the time step remains constant or close to a constant value and that it does not exceed a critical value so that I won’t get any divergence.

Thanks for being so generous ;-)… It was basically the objective of my first question: use as much as possible what is given by Jmonkey.

9

Extend that class, update your helicopter state in stepPhysics().

The tpf value passed in is the same tpf the simpleUpdate gets.

[java]
class HelicopterSim extends FixedUpdateAppState{
public HelicopterSim(){
super(1f/37);
}

public void stepPhysics(float dt, float alpha){
// Update your chopper here
}
}
[/java]

Somewhere in simpleInit you should add this:

[java]
stateManager.attach(new HelicopterSim());
[/java]

10

The beauty of this is that it all happens on the same thread =) You do not have to call the appState methods yourself, jME will call them for you once you have attached it to the stateManager.
One can think of an AppState as a parallell game loop.

11
@kwando said: The beauty of this is that it all happens on the same thread =) You do not have to call the appState methods yourself, jME will call them for you once you have attached it to the stateManager. One can think of an AppState as a parallell game loop.

Being pedantic about the word parallel here: app states are run on the same thread as the rendering. Not really in “parallel” though I understand what you mean. Other readers might not understand.

AppStates are like extending application without having to extend application. You get to hook into its update and render methods. Composition versus inheritance.

12

Waow,

That’s sounds great… And not too expensive in coding!
Thanks a lot