[ODE] BSP And ODE?

[Marco Grubert]

> 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.

I assume the distinction here was visible tesselated faces as opposed to
generally invisible ones (forcefields, etc.). So you would send all faces
that could ever be seen in the level to Opcode once at startup.

> 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.

I would disagree with that; since your sphere will be contained inside some
rooms/corridors, etc. you would probably have to traverse the tree quite a
bit to get to it (contacts are on the inside, not on the outside, which
would lead to quick collision detection).

> 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.

That's the approach I am using, and it works fine except where opaque, but
passable surfaces (water, lava, etc.) are involved; I have one Opcode tree
per BSP leaf/node. This is also where I was running into the problems with
0-volume meshes, because a few leafs contain only a single triangle.

> However, I suspect this won't be faster than the dumb single-tree
approach.

It seems faster to me, but then I am expecting it to be faster to begin with
;)

Thanks,
  Marco