[ODE] Avatar navigation with ODE

Bren Lynne blynne at telus.net
Sat May 14 15:27:29 MST 2005


Hi,

I have a bunch of question pertaining to character/avatar navigation in
an ODE simulation.  Surprisingly, there is very little on the topic on
forums or in my archives of this list.  This is a long message, so I
hope you'll take the time to read and respond with your thoughts and
suggestions.

This is the solution I'm considering/trying at the moment, though I do
forsee some problems.

The player navigates by rolling a relatively small sphere around the
level.  This sphere's diameter is the width of the player's bounding
box.  The player controlled object maintains a "navigation orientation"
which is the direction the player is facing.  Translation is
accomplished with dBodySetLinearVel, rotation by setting the orientation
of the sphere directly.  Determining the "Y = ground normal" forward
orientation of the player based on the rolling orientation of the sphere
just seemed too difficult, hence the decoupled "navigation orientation".
The sphere's orientation can be seen to "jitter" a bit, which is a
concern, but as I can use the navigation orientation, this jitter will
not be seen in the player model's orientation.  Nor does the linear
velocity appear to be significantly affected.

After stepping, I translate the player's actual model to the sphere's
new position and check for collisions, to ensure the sphere hasn't
rolled under something (like a table or overhang) that the height of the
player model should prohibit.  It if has, just restore the "last known
good position".  This is less than satisfactoy as it prevents the player
from "sliding" along a table edge.

If the player "goes dynamic" (jumps, walks off a cliff, is thrown by an
explosion) disable the sphere completely and use the player model for
dynamics, until such time that the player has come "to rest" and is
ready to start navigating again.  This is particularly important for
ragdolling, as you wouldn't want your characters rolling around like
spheres.

Rolling up stairs will be a problem if the sphere's diameter is too
small.  If it's too big, the player may have trouble fitting through
doors.  (Insert mother-in-law joke here.)  If you cover the stairs with
an invisible ramp (as many games do) you'll have to deal with the sphere
rolling down the stairs when there is no input.  (This is a problem on
hills in almost any case anyway).  In all these cases, the "set player
model to sphere position" solution is very likely to get penetration
collisions between the player's "box" and the stairs/ramp/hill geometry.

A possible solution would be to attach a capsule or something on top of
the sphere, that more accurately represents the full bounding box, and
dynamic orientation, of the player.  I just can't imagine how to keep
this capsule upright when the player is navigating.

Other problems include the fact that during the step, only the
navigation spheres will be interacting, so it's easy to imagine players
jumping through each other (as the smaller spheres jump over each
other).  The "attached capsule" solution could do sphere<>capsule
collisions, disabling sphere<>sphere collisions completely.  This would
also alleviate the ragdolling issue as well.

Any suggestions, or even better, links/samples on how to best do player
navigation in a physics sim would be very much appreciated.  I haven't
been able to find anything really good yet myself.

As a side question, I am very curious what peoples' opinions on
networking ragdolls are.  I might have assumed ragdolls were entirely
client side, but I have seen HL2 simulate a guy falling down the stairs,
or players moving dead bodies around by shooting them, so I figure the
ragdoll must be synchronized somehow.  Are they actually propagating all
those joints?  Or is the simulation really that reliably deterministic
once forces have been transmitted?

Once all the above is dealt with, I'll have a good way of allowing a
player to "drive" an avatar around.  For reasons of re-usability,
networking and consistency, I would like AI-controlled avatars to use
the a similar control mechanism.

I'm planning to implement an "edge tracing" obstacle avoidance steering
solution similar to that used in OpenSteer, using ODE rays, and I have a
few question I thought I'd post before I start experimenting. 

The basic idea is that objects cast three rays in front of them, one
straight forward, and two at a slight angle to either side (say 20
degrees). While moving forward, if the "right" ray hits something, they
turn left, if the "left" ray hits something they turn right. The
advantage of using this in addition to a graph-based A* pathfinding
solution is that objects will "edge trace" obstacles, avoid other
dynamic objects, find their way out of concave "U" shaped enclosures,
etc. 

Once my three rays are created, how would I attach them to the objects
so that the will translate/orient with that object? Can I create/attach
the rays in an object's "local" coords? Or would I create the rays in
"world" coords, and then attach them? (Does ODE have a concept of
local/world coords?) 

Can I set up my rays so that they will collide with other objects, but
other objects will not collide with them, using collisions
categories/bits or something?  That is, I want the rays to hit other
objects, but I do not want other objects to hit the rays, if you know
what I mean.

If the object "gets dynamic" (say falls of a cliff or something) I
wouldn't want the rays to collide for the object. I'm using
autodisabling, so just manually enabling/disabling the rays would not be
trustworthy. I would guess in my callback, I can simply decide whether
to generate a contact joint based on if the geom is a collision
avoidance ray or not, correct? 

In that last situation, I would be concerned that even if the collisions
are not generating contacts, there would be some overheard just doing
collision detection for those rays. In that case, should I
create/destroy the rays each time the the object starts/stops
navigating? Would that be more efficient? 

Is it possible to just do a one-off "ray query" for contacts, as opposed
to creating a ray object that will be part of the physics space?

Thanks!

Bren

-- 
I am using the free version of SPAMfighter for private users.
It has removed 36087 spam emails to date.
Paying users do not have this message in their emails.
Try www.SPAMfighter.com for free now!



More information about the ODE mailing list