Non-physics avatar in ODE environment

Scripting Issues
1

Some of you may remember me posting about keeping my runtime-created avatar upright in an ODE environment.

I never solved that, so I switched to a normal 3D model.
Problem is, how do I get that model to behave nicely (i.e, not run through things, react to gravity, etc…) in my ODE sandbox?

Right now, I have something like:

if avatar_z is > other_model_z: pass

else:
   if avatar_x < other_model_x: move_backward

   else: move_forward

   if avatar_z > other_model_z: move_down

This somewhat works, but my avatar occasionally slides through other models, or, when it touches a model on its left or right side, moves forward by itself until it no longer touches the other model.

Any algorithms or code snippets would be appreciated!

2

[ODE Middleware)

This is my code which, among other things, contains a Kinematic Character Controller implementation. It initially contained only that, but grew a tiny bit with time :stuck_out_tongue:.

As for Dynamic Controllers (which is, AFAIU what you’ve tried to do first), I’ve attempted to get that working too at first, but it’s nearly impossible to get it right. Only Havok managed that.

3

This looks cool (in fact, I’ve looked at your middleware before), but I have to use Panda 1.7.0, and your middleware topic says your code causes Panda to leak memory with 1.7.0 and lower.

Also, do you have the algorithms you used on hand? That would be much easier to study! (No offense to your code or anything, but algorithms are easier to understand to me).

4

None taken. Even with all the comments code is generally much easier to write than it is to read. Especially code written by someone else.

Yeah, there is a leak. Why can’t you use the buildbot version? I haven’t noticed it being any less reliable than the stable version.

Unfortunately, I’m not sure my designs can be implemented without 1.7.1. The problem is that they rely heavily on them having full control over the way collisions are handled. That in turn relies on the odeSpace.collide() method (exactly the one that leaks in 1.7.0), because AutoCollide and CollisionEvents just won’t give you that control. They first handle the collisions and just then inform you of them, which behavior is completely incompatible with the way I do stuff…

I’ve initially tried to use AutoCollide and CollisionEvents, but just couldn’t get it to work the way I needed. That’s why I chose to do all the collision handling myself.

5

I just saw 1.7.1 was released. I’ll try it, and see if it works.

6

Okay, 1.7.1 works with my existing code, so I’ll take a look at your middleware.

Thanks!