Hi Guys,
I’ve done quite a bit of searching, but I can’t find how to set JMonkey or JBullet to run at faster than real speed. I.e. running at 2X speed, the tpf passed into everything would be double what it would normally be. I’d be using this to test out some quadcopter stabilization logic I’ve written in faster than normal time.
Sorry if it’s a simple question, but I couldn’t find the right search terms.
Thanks.
there is a speed instance variable in SimpleApplication you can change. It is set to 1 by default, so changing this to 2 would double the speed
DELETED!
AAAAhhhhh!! Sorry this is accuracy… this is not speed. Don’t look at my post above.
Why do you want to do this? If your physics “looks slow” make sure you have the right dimensions going on (1unit = 1 meter) or adapt your gravity and other forces and weights.
Thanks for the suggestion Normen, but I’m trying to test the effectiveness of different AI behaviors. These can be simulated without the need for player input, and instead of waiting for each to play out in real-time, I’d prefer to be able to run them as fast as I can without the physics getting jumpy. I realize I could increase gravity and scale my forces, but I was looking for a neater way to do it.
(Also, it could be a cool play with as a game mechanic…)
Awesome wezrule, you rule.
Still, debugging an application with physics is an headache. I managed hacking JME by setting the tpf manually, but I was not able to find the same hack for physics…
@yang71 said: Still, debugging an application with physics is an headache. I managed hacking JME by setting the tpf manually, but I was not able to find the same hack for physics...
LOL if you do things like manually “hacking” and setting tpf then you don’t need to wonder why everything is strange, doing that is very wrong ^^ The solution to change the speed was given here if you care to read. I think you just need to get a better grasp at what you’re doing, its not exactly hard.
Yes, I can understand that. But sometimes, I need several minutes figuring out what’s happening, since I’m working on some tricky multi-agent AI algorithms. Even at slow speed, this is simply too long.
Setting tpf manually makes each step the same length, whatever the time I need to check it. The idea was given to me by the Video-recording appstate, which makes the framerate a steady 30 frames per second, whatever the real time needed.
So I hope you “set the tpf” using a timer and not just change the var at some point.
Nope. If I did that, time would still run while I was debugging. I simply changed the tpf variable as the first action of the update method. It works only because all is done in a single method. This is why I was talking about ‘hack’. Not clean, but easy and efficient.
Of course, this is not scalable. If you have several application states, I think you cannot do that.
Is there a clean way to achieve this, “pausing” the simulation during debugging ? Without this, next tpf is several hundreds… And it becomes impossible to track the system evolution.