[ODE] BSP And ODE?

[Pierre Terdiman]

> So you're basically saying that instead of feeding OpenDE (or OPDCODE)
with triangles made out of visible faces, you just create triangles out of
the Quake2/3 map brushes and give them to OPCODE at the start and it'll take
care of itself making an optimized collision tree or whatever..??

I'm not sure to have followed that thread correctly, but feeding OPCODE with
a list of *visible* faces seems dubious, since it sounds like you want to do
that each frame. This is a bad idea. Building the AABB-trees is not a fast
operation, you shouldn't do it each frame.

So, yes, send all faces to OPCODE at load time and let it deal with it.
That's not a real problem.... how many triangles are there in a Quake2/3 map
? 20000 ? 30000 ? Then colliding a sphere against the whole map will be very
cheap, I'd expect something like 50.000 cycles in the worst case. If it's
too much you can also enable OPCODE's temporal coherence, that reduces this
to ~2000 cycles for most frames (regardless of the actual number of faces in
the tree).

Now I'm not familiar with Q2/3's maps, but maybe the PVS data can be used.
If it provides a known set of groups of visible faces, you can create an
OPCODE tree for each group, and only collide the sphere against *visible
groups*. The difference with your initial approach beeing that all trees are
already built, you just select relevant ones according to visibility.

However, I suspect this won't be faster than the dumb single-tree approach.
Or more accurately, it might be "faster", but not faster enough to have any
influence over your framerate. As a smart professor of mine once put it,
"perception of time is not linear" : 1000 cycles instead of 10.000 is one
order of magnitude, still you'll never tell the difference without a
profiler. On the other hand, a user notices 1 second instead of 10 seconds
(yet it's still one order of magnitude). Aggressive optimization is needed
only in the second case.... :)

Cheers,

- Pierre
www.codercorner.com