[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