[ODE] Pushing through collisions
Jon Watte
hplus-ode at mindcontrol.org
Wed Apr 28 19:21:37 MST 2004
> I'm working on a pretty similar problem. Our avatar is moved by setting
> the velocities directly (which is the same way we did it when we were
> using Havok). I know this is "wrong", but it's the only way I've found
> to get the tight, animation synced movement we need.
What we do, both at work, and in my ODE playtime at home, is to
figure out how far the avatar moved each frame, and advance the
animation by that much, rather than the other way around. If you
have a groovy animation blending system that can deal with
melding cycles (like at work :-) you can have separate animations
for forward movement, lateral movement, etc. At that point, you
only need a bit of IK to make sure the foot doesn't penetrate the
ground, and you have slip-free walking.
> Anyway, what I'm trying right now is limiting the velocities I direct
> into static, unclimbable objects. Each frame I take all the collision
> normals from unclimbable static geometry and add them together, then
> normalize them. Then I get the vector in between that one, and the
> normalized velocity vector for the avatar. I use that resulting vector,
I don't think that's quite correct. You can imagine cases where
the player gets wedged badly enough that he's between opposing
faces. Adding perfectly opposing face normals together just gives
you zero. If he's between three faces, no matter what the normal
you end up with, it's going to point into one of the faces.
What I'm planning on testing is whether there is any direction
you can move in without moving counter to any face normal. To do
this, you just need three vectors to build a basis (and maybe a
bit per basis vector to know whether you have also seen a face
normal opposing the basis vector).
An alternate is to remove any component that will move into another
vector from any normal vector that you consider, and if there's
anything left at the end, that's a direction you can move in. Note
that just iterating over all the vectors, removing the dot product
projected amount, is not enough, as doing that will move the vector
WRT other vectors you've already visited -- going down this path,
you end up with either an LCP solver just for collision resolution,
or the basis-building approach above.
Anyway, my question still remains: how much force is supposed to
be exerted by the ODE contact constraints? Does ERP or CFM affect
this, and if so, how? And, has anyone used position displacement
in the case of contact only (i e, not for locomotion)?
Cheers,
/ h+
More information about the ODE
mailing list