[ODE] Angular-velocity autodisabling considered broken

[John Miles]

That could help, if you use the disable-time capability (my app doesn't).

Perhaps the best way to solve this is to let the app supply its own
autodisable evaluation function.  Right now we have a small function
(dInternalHandleAutoDisabling) that takes a whole bunch of parameters via a
whole bunch of ODE API calls, and uses them to manipulate public states
(body enable/disable status) without altering any internal state.  Those are
factors that suggest "move it into user-land" to me.

-- jm

> -----Original Message-----
> From: Jon Watte [mailto:hplus-ode at mindcontrol.org]
> Sent: Tuesday, September 14, 2004 3:49 PM
> To: John Miles; ode at q12.org
> Subject: RE: [ODE] Angular-velocity autodisabling considered broken
>
>
>
> An alternative (which uses less math) might be to subtract
> half the max timer if you get a value over the threshold.
> Thus, if you get get more than half the way to the timer
> before the spike, then at least some progress towards rest
> is made. (Or have a configurable "negative progress" value)
>
> I usually use conservative timer values (30-50 steps) but,
> as you, larger than ideal threshold values (and often, piles
> of stuff that "looks" at rest never goes to rest).
>
> Cheers,
>
> 			/ h+
>
>