[ODE] movement force conversion

[Piotr Obrzut]

Hi,

12 kwietnia 2005 (14:30:21) SJS wrote:

S> Piotr has his formulas right from what I see--

S> new_ang_vel = (new_angle - old_angle) / delta_time
S> (radians/sec) = (radians - radians) / sec == radians/sec

S> This is assuming constant velocity over the time step (or we're using an
S> appropriate Euler integrator, anyway).

S> So if we have an initial velocity v[0] and we want a final velocity v[1]
S> such that we get to the new angle within this time step:
S> v[1] = 'new_ang_vel' from above
v[0] = body->>get_angle_vel (); (as Piotr did)

S> assuming constant acceleration (or Euler integrator again),
S> v[1] = v[0] + aa[0]*dt -->  aa[0] = (v[1] - v[0])/delta_time

S> (there's the 2nd 'delta_time')
S> and units match--
S> (rad/sec) = (rad/sec) + (rad/sec^2)*sec == rad/sec

S> And just as F=m*a, T=I*aa (I := inertia tensor, and aa := angular
S> acceleration)

S> Your coordinate frame is important here-- including that of your inertia
S> tensor.  Since you're using ODE, all of these variables are probably in the
S> world frame, so you're OK.  If you're animating a hierarchical skeleton,
S> some of your animation will likely be local frames of the bones.  Just
S> remember (or look in to) coordinate frame transforms-- (R^-1)*M*(R) and
S> such.

all this is working fine I just have global and local transforms at
every time.

S> Now whether his plan will work or not-- hehe, that's harder to answer.  The
S> above equations use the instantaneous angular velocity, assume lots of
S> things, and will only be perfectly reversible if the integrator in ODE is
S> the appropriate kind of euler integrator (backwards, forwards, whatever).  I
S> say 'whatever' because I don't care much (not because I'm a jerk, but)
S> because I'm pretty sure the results won't be nearly perfect enough anyway,
S> so you'll need something to compensate for accumulated errors from your
S> animation and/or collisions, joints, etc.

so I was right at the begining : the only thing I could do to get
perfect visual effect is to cheat viewer and use ODE otputs only for
collisions and AI and ignore them for visual things?

S> You COULD figure out which integrator is used and match everything
S> perfectly, but you'll end up with something that only works for an ideal
S> case with no perturbations-- basically about as stable as an inverted
S> pendulum (maybe only good for a single body with no collisions or joints).

with ball and amotor (whith large stop ERP and CFM) joints it looks better
but still not idealy. I was thinking that it is the best I can get
from ODE but I am a bit confused by Jon, who is right? :)

S> Whew, long winded.  Anyway, summarizing, the delta_time in his equations are
S> right, but he'll need some serious tunable feedback to prevent his
S> animations from quickly straying from their intended orientations while
S> still allowing his character to interact via collisions and joints.

Either way I will have to use other delta time and connect it more
with physics not with animation, should I connect it with physics
steps?

When I will have to allow on some imperfection with physics I
will have to just do some bounding volume which will hold every body
part of my body within this volume (so viewer shouldn't notice errors)
 and other similar cheating things.

So here comes the last question : it is worthy to bother still with getting
physics more prefect or I should just drop it and rather accept
imperfection?

-- 
greetings,
 Piotr Obrzut