Jump to content
  • Advertisement
Sign in to follow this  
Kest

ODE - Iterations / Quickstep

This topic is 5096 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've heard some people suggest using a maximum time check for time stepping in ODE. The version I downloaded has a quickstep function which allows specifying a number of iterations. So is it safe to constantly change the number of iterations according to how much time has passed in one frame? For example, 2 iterations for every 1 millisecond. If this were supposed to fix the problem, then slow-down should not have any effect on the simulation, correct? I'm giving ODE the correct number of iterations to laps the time value. But I seem to still be having issues when the frame rate drops. Anyone know why? Or is it obvious that I'm not doing it correctly? Perhaps I'm not understanding what quickstep iterations are doing? Help is much appreciated :) edit: Typo spelling [Edited by - Kest on November 30, 2005 9:43:59 AM]

Share this post


Link to post
Share on other sites
Advertisement
If you're working with a fixed framerate, I find 1 / TargetFPS to be quite smooth.... Although, that's working with the normal Step function, not QuickStep.

Share this post


Link to post
Share on other sites
Err, I've never heard of dynamically changing the number of iterations based on the framerate. What I have heard of (and I recommend) is using a fixed timestep size (0.01 seconds, so you get ODE running at 100 Hz, is what I use), and then vary the number of times you call dQuickStep() based on framerate.

Share this post


Link to post
Share on other sites
Quote:
Original post by BradDaBug
Err, I've never heard of dynamically changing the number of iterations based on the framerate. What I have heard of (and I recommend) is using a fixed timestep size (0.01 seconds, so you get ODE running at 100 Hz, is what I use), and then vary the number of times you call dQuickStep() based on framerate.

If the number of iterations are not based on time, what is their purpose?

If you vary the number of calls to dQuickStep() based on the current frame rate, doesn't that result in your simulation running slower when the host machine is already having trouble keeping up to begin with? The player completely misses these lapses of time, and the game would be unplayable on slower machines (or just when a scene becomes complex).

Thanks for the help :)

Share this post


Link to post
Share on other sites
I've had some issues with ODE when I've called the stepping functions numerous times without some time actually being passed, so the solution I used was to use the normal time, but don't let it exceed some preset value (0.02 worked fairly well).

Example:

float stepSize = timer.getSecondsPassed();
#define MAX_STEP_SIZE 0.02f
if (stepSize > MAX_STEP_SIZE) stepSize = MAX_STEP_SIZE;
...//update joints, call the collision functions, etc.
dWorldQuickStep(...,stepSize);
...//release the contact joints



Share this post


Link to post
Share on other sites
Quote:
Original post by Kest
If you vary the number of calls to dQuickStep() based on the current frame rate, doesn't that result in your simulation running slower when the host machine is already having trouble keeping up to begin with? The player completely misses these lapses of time, and the game would be unplayable on slower machines (or just when a scene becomes complex).

It's definitely possible. The way I handle that is limit the number of times that dQuickStep() can execute per frame. Worst case senario is that the rate of the game begins to scale down (goes slow-motion, in other words) since the simulation is running at a slower rate. But the simulation stays stable. Plus when the framerate begins to drop due to other reasons (complicated graphics or something) the simulation stays stable. If you just sent 1/FPS to dQuickStep() as the timestep size you could be taking huge timesteps and who knows what could happen.

Share this post


Link to post
Share on other sites
I've noted that ODE's dQuickStep is less stable than the traditional StepFast.
It means on collisions with dQuickStep: suddenly, objects stack have popping behavior and do not rest very well. But with StepFast they mantain their positions when resting. And with StepFast, 5 Iterations is enough for good simulations, but with dQuickStep you'd need more than 10. do you have the same feeling?

Share this post


Link to post
Share on other sites
I haven't noticed that, but I haven't really used StepFast much. By the time I really started using ODE StepFast had already been depreciated in favor of dQuickStep. I guess it's possible.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!