In the game that I am developing I implement flocks of pigeon using the famous Flocking Algorithm by Craig Reynolds. red3d.com/cwr/boids/
For such a purpose I manually zero all the forces and torques on every frame to manually set the linear velocity and the hpr as calculated by the flocking algorithm. This works relatively well and the collision detection usually works well with the flocking algorithm: the “bouncing” automatically adjusts the current linear velocity of the bird and this simple behaviour usually allows the flock to avoid objects!
However, there is still a issue: sometimes the birds don’t collide with other objects crossing them, sometimes even very thick ones! I wonder if it is caused by manually setting the linear velocity… I have tried to change the flocking algorithm to use forces instead of manipulating the linear velocity but it just doesn’t work well…
Does anyone have a hint on how to avoid this “wall crossing” in ODE? I have tried both ‘quickStep’ and ‘step’ without success --actually, I would say that quickStep even works more accurately than the other!
Thanks a lot!
I actually don’t think there’s a point to using bodies with such functionality. In most physics engines (the ones more modern-game-friendly than ODE) everything that requires a more “conscious” behavior than the typical environment stuff is done using kinematic objects, and I’d actually advice the same for ODE. It just gives you predictability that you can’t expect from dynamic bodies. It’s the same thing as with character controllers (well, it is a character control topic since you have AI controlling the pigeons).
You say that you zero out all the forces, velocities in every step and even set hpr by hand. My question - do you think there’s a point in having an ODE Body there, when you actually change it into a kinematic object using drastic constraints?
I’d advice using the kinematic approach in every case when you want to take the control away from the physics engine. Sure, the physics engine might seem to be doing some stuff for you, but - as you can see - you will always find unstable behavior, either caused by your interference with the engine’s way of doing things, or by the bodies simply doing what they’re supposed to be doing. As for the first, I’ve encountered similar problems when I’ve tried to make ODE body behave as a manually controlled object.
It’s really easier to just write the behavior you want than to force ODE to act against it’s nature.
What I found is that it’s best to keep the physics engine doing only the stuff that we want to be - let’s say - inert, and deal with the rest as kinematic (i.e. the more old school approach of just handling the collisions by hand).
That’s just my personal view on the subject.
Well, I still think that using a body has its advantages; for example, collision response.
I have happened to find that actually this wrong behaviour is caused only on a framerate drop when the pigeons start to collide with the laser fields that kill them (weird game, I know :p). Still, this framerate drop doesn’t seem to be too acute --around 20 fps, the game is still playable. I don’t know exactly the cause for this framerate drop, because it persists after the fire and smoke particles of the burning pigeon have been disabled… so I suspect that I am doing something wrong, that might influence ODE… I am going to cleanup the entity disposal code and see if this gets better.
I will post here back when I find more things.
I know, that’s what most people think 
. The thing is that the collision response that ODE gives you is usually appropriate only for inert physical objects. Most people expect that ODE will do some stuff for them, even the ODE wiki suggests that, but this is not always true. However, I’m not telling you to stop using ODE bodies, I don’t know your exact needs, but I’m just saying that in such cases kinematic approach usually works better so it’s worth a try.
Still, codding the collision response with ODE, even though it might seem intimidating, is not difficult at all. All you need to do is get the collision normal and depth and move object/s away accordingly to those values. That’s all. And it should be enough for AI simulation.
Anyway, more to the point. Do you use a constant time step value? Using a non-constant one for physical simulation usually causes instable behavior.
Also, if you use the time accumulator approach from the Panda (and ODE AFAIR) manual and still get unstability, you might try using doMethodLater with a small time value and with task.again as return value. I’ve been able to get far better results with that than with the time accumulator.