[ODE] ODE as a complete FPS solution..

[Pierre Terdiman]

> As for collision, if you want to collide the player against the
> environment, the big problem is the large list of primitives in the
> environment, so you need some very efficient way of finding only the ones
> close to the player.  A bsp does that, and I don't think Opcode does that,
> it would just test every triangle against the player.  (A BSP uses the
> fact that the level geometry is stationary, and precomputes a structure to
> help search for the triangles near any point.  Without doing any
> precomputing, it will take at least O(n) to collide the level geometry
> against the player, which I assume is too slow for you.)

Of course Opcode "does that". Actually that's the only thing it does. The
structure is an AABB-tree, speed is O(log n) or ~O(1) using temporal
coherence.

Player-world interaction in your typical FPS has two parts :
1) find triangles close to the player
2) perform collision response on them

Opcode is perfect for 1), however it doesn't do 2).

ODE does 2) but not using "FPS physics". FPS physics are limited to a
canonical collision response where the player's volume slides along collided
triangles. This is so different from rigid-body simulation you'd better
implement it directly in your camera control - that's about a dozen lines of
code. Implementing FPS-syle physics using ODE will give you inaccurate
controls, different from the typical FPS look-and-feel. For example ODE
doesn't use sweep-tests, whereas this is almost mandatory for player
control.

Now, all bets are off when you want the player's volume to physically
interact with rigid-bodies....

I tried both ways (physically-driven player or FPS-style player applying
artificial forces on other bodies), without much success. Pros & cons in
both cases. There's a Gamasutra article describing some of the issues using
a physically-driven player.

Pierre