[ODE] Step Sizes
hplus-ode at mindcontrol.org
Wed Nov 3 10:13:23 MST 2004
It's likely that something's wrong in your program, or that
you're using some specific piece of code that's not well supported.
The only obvious one I can think of is the cylinder geom, although
trimesh to trimesh collisions aren't great, either (especially not
for concave trimeshes). Trimesh to anything else, and anything
else to anything else, has always worked well for me.
FWIW, I use 1/100 second step size, and it's very stable. There's
no popping, disapparance, or anything like that that I haven't
traced to issues with my own code. I use dWorldQuickStep().
Reduce your code to just a few items that reproduce the problem
you're seeing, and trace through it in the debugger, looking at
all the values involved. It helps greatly if you build ODE from
source for this, of course.
Yes, this probably means spending 20 minutes in the debugger on
a single world step of your test case. That's the fate of a
simulation developer. Just be glad you don't have to do it in a
distributed system :-)
From: ode-bounces at q12.org [mailto:ode-bounces at q12.org]On Behalf Of Donny
Sent: Wednesday, November 03, 2004 9:54 AM
To: ode at q12.org
Subject: [ODE] Step Sizes
Perhaps this is my own fault, but I didn't see anywhere a good step
size for dWorldStep. I'm using ODE in a fixed-frame game, running at 30
FPS, so originally I set the step size for 1/30. I recently tried
adjusting this to see if it would make my simulation more stable (you
know, the vanishing, jittering, and occasional popping that occurs.) I
adjusted it from 1/30 to 1/300. The simulation actually got MUCH WORSE
with more popping and vanishing.
What the hell? I'd have thought if ANY change were made by giving ODE
more granularity, it would be that the simulation would become MORE
WHAT IS GOING ON?
ODE mailing list
ODE at q12.org
More information about the ODE