[ODE] Avatar navigation with ODE

[Megan Fox]

I would be inclined to say that you're going to create a great many
problems for yourself if you go with a rolling sphere representation. 
Off the top of my head, simply that for a sphere of sufficient height
to bound a bipedal entity, your sphere edges will protrude a GREAT
deal out from the sides of your player, resulting in strange, dirty
collision that just feels wrong.

I would advise creating a ccylinder bounding volume, locking it
upright (either by AMotor or just setting the orientation manually
every frame - the latter works surprisingly well), and then either
letting it drag on the ground or "hovering" it somewhat off the ground
via a combination of a height sensing ray and manually applied forces.

(and this method has been discussed multiple times in the archives, at
least twice by me, and I think more than a few times by Jon - there
are quite a few lengthy explanations of possible implementations, etc)

-Megan Fox

On 5/14/05, Bren Lynne <blynne at telus.net> wrote:
> 
> 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!
> 
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode
>