ODE - Iterations / Quickstep
Author
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]
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.
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.
Author
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 :)
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:
Example:
float stepSize = timer.getSecondsPassed();#define MAX_STEP_SIZE 0.02fif (stepSize > MAX_STEP_SIZE) stepSize = MAX_STEP_SIZE;...//update joints, call the collision functions, etc.dWorldQuickStep(...,stepSize);...//release the contact jointsQuote: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.
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?
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?
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
