[ODE] Simple character control

[Adam Paul Coates]

Actually, on a side note:

Does anyone remember Thomas Jacobsen's GDC article (2002?) about cloth and
character animation (from Hitman I think...) using that odd Verlet
integrator?  On its own, it's wickedly easy to combine it with keyframe
animation, but it might be possible to link it up with ODE.  Since the
geometric bodies wouldn't have an ODE Body associated with them, I think
you'd have to do a bit of hacking to make the collision forces work out
for dynamic objects, but when colliding against a static environment you
should be able to take the output from ODEs collision code (contact point
and penetration depth) and dump it straight into the character and cloth
animation and have your characters, etc. behave pretty reasonably.

This doesn't solve the problem of "set position/orientation" issues in
ODE, but will give you decent physics-oriented character animation which
behaves nicely with solid objects.  I think the problem is less severe
since now you're not screwing up ODEs physical state (the dBody) and
instead managing it on your own.  Again, contact forces would probably
have to be a total kludge... not sure how easy or hard that is.

Just a thought.

Regards,
Adam C.


On Tue, 30 Mar 2004, Megan Fox wrote:

> > > And an addenum... what about animation?
> >
> > You're note setposition-ing anything in ODE; you're extracting
> > position to determine where to draw the mesh.
> >
> > Note that animation is totally different from simulation in most
> > games. You animate by using a high-resolution character skeleton,
> > but you usually don't simulate that entire skeleton. Instead, you
> > measure how far you've traveled across ground since last frame,
> > and advance the walk cycle by that much; this avoids foot sliding
> > on even ground; the IK takes care of the uneven ground case.
> >
> > The extreme end of realism would be to simulate the skeleton as a
> > rag doll, with forces applied to the joints to create the walk
> > cycle. However, that doesn't qualify as "simple" at all :-)
>
> If you separate animation data from collision data, you seemingly open
> yourself to any number of inconsistent interactions.  Player sphere is too
> big, so the player can't actually "touch" the wall, player sphere is too
> small, so the player's arm can clip through the wall if the animation is at
> the wrong point at the time, player's tall hat clips through a low archway
> because it isn't physically modelled, player's long staff weapon clips
> through a wall (and 3 cups on a table) during attack, etc.
>
>
> On the other hand, a ragdoll-modelled character mesh being keyframe animated
> seemingly gives you properly accurate collision regardless of animation
> frame, will always generate the contact data you need to adjust the
> animation (if an arm is hitting the wall, stop the animation or similar),
> assures proper physical response regardless of player's stance or animation
> (a character's pointing arm knocks the cup off the table in front of her),
> etc.  It even gives you "damage zones" - if an object collides with the
> player at high speed, you can decide what effect it has based on the body
> part it hits.
>
>
> I see that the docs suggest not using setposition and setorientation... but
> why?  It seems absolutely ideal for when you want the entity's movement
> assertive over the environment, and it should be fairly easy to handle the
> contact joints yourself to resolve collisions (and enable ragdoll if the
> forces get too high, or whatever).  Is the only reason that many won't pay
> attention to the contact joints, and the general instability you get from
> warping objects inside other objects (only a big problem if your step size
> is too large)?
>
>
> -Megan Fox
>
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode
>