No subject

1)  player versus static world collisions
2)  whiskers
3)  player versus dynamic object collisions

1) In the space of player versus world collisions you have two more
sub-cases cases;

1a) cases where the player has physically collided due to un-expected
forces being applied to the player, and cases where the player needs to do
navigation.

1b) In the case of navigation (such as navigating stairs) you can probably
avoid requiring physics at all...  A simple strategy for example is to
assume that (as Martin points out and you agree) the collision geometry is
some vastly reduced subset of the visual geometry.  This can be often
abstracted such that walls, edges and suchlike are pulled in to prevent
visible player intersection of limbs against surfaces.  The walkable floor
tiles form a connectivity mesh of walkable spaces.  Often an a* algorithm
is applied to the walkable tile surfaces to create a connectivty graph for
robust pathfinding.  Given all this then basic navigation is simply a
traversal of your already pre-computed tiles with known elevation and
constraints per tile; all you are doing is a bresenham along the surface
of each tile...

2) Separately of course you may have collision information ordered in
such as way that efficient projectile or sighting calculations can be done
(I often call these whiskers).  BSP or PVS or AABB is fine for that of
course; but this is still not physics related).  In this case the geometry
for collision has to closely map to the real world.

3) So now you are left with unexpected or unpredictable cases.  These are
the cases where physics would be nice.

> ----- Original Message -----
> From: "Martin C. Martin" <martin at metahuman.org>
> > As far as dynamics, it seems you don't really need ODE for the player.
>
> Actually, I can't see how I could do without it. Even if I resign primary
> player collsion response/physics to our own code, the problem is then
> player/object interactions. That is, the player needs to interact with the
> dynamic objects in the world, including objects which could manipulate its
> position. I can't see how this could coexist with a custom system.

Overall using real dynamics is going to give you nicer behavior; if it is
something that fundamentally affects quality of game-play then it is worth
considering.

But given your design goals you may have to apply some fairly hefty
constraints to the player.  You can increase the players mass for example
so that they soak up impacts without repercussion; or you could apply
constraints to prevent the player from moving in certain directions.

If you know the players occupied volume is not going to be
inter-penetrated then you could have a low complexity hull for most
collision during say navigation, and then for more computationally
intensive subtle interactions such as falling down stairs you could switch
to a higher granularity group of jointed hulls for each of the limbs.

Jitter is not an issue either way; ideally you would solve it but you can
dampen it before it reaches the camera and/or you can detect if a system
is relatively at rest and simply turn it off. Ideally of course there
would be no jitter; you'd have to look at how many contact points are
being used to stabilize the contact between two surfaces - more contact
points == more stability usually.  But I have not tried OPCODE;
typically I'd probably use a BSP and a well behaved collection of polygons
first before going with a brute force solution.

Overall I suppose the best I can recommend is taking a shot at it; doing a
small thumbnail sketch.  It does sound like you have a lot of 'edge cases'
and probably discovering all of those requires some kind of coding
attempt.

 - a