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?
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).
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…
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:
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!
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…
@param interpolationRatio how much “extra” time we have accumulated
*/
public abstract void stepPhysics(float delta, float interpolationRatio);
}
[/java]
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.
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.
@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.