[ODE] BSP And ODE?

[Nathan Ostgard]

The collision detection between all three games is very similar, so
what you know for Quake 2 is pretty valid for Quake 3 as well.

You're correct that the visible face list gives you something that is
ready to stick directly into OPCODE, but that doesn't mean it's the
_correct_ thing to stick into OPCODE. All of the collision information
specified by the map designer is stored in the brushes and brush
planes... if you eliminate these and use the triangles intended for
rendering instead, you're throwing out a lot of useful information. In
my opinion, if you're trying to write something to use maps that were
intended for Quake 3, that is a bad idea.

If you're just using the Quake 3 map format, however, with your own
maps... then you can still take the brush method and not have any
problems. It simple takes a quick preprocessing step of converting the
brush planes into triangles. It's most likely quick enough that you
could do it in real time. I say most likely because I haven't had a
chance to actually try it out, yet. The source code is already out
there, though - all of the Quake compiling tools do it, because the
map is stored as brushes before you compile it to BSP.

The conversion is trivial... simply take each brush, create a large
polygon from the first plane, and do the same for each plane in the
brush, clipping the other polygons as necessary. Then convert this
into triangles. It's not very computationally intensive. When you're
finished, you have a simplified set of triangles to throw into OPCODE.

It's no different from using the faces in the end... you're simply
taking one extra step in order to use the information that was
intended for collision detection.

- Nathan Ostgard

----- Original Message -----
From: "Marco Grubert" <mgrubert@conitec.net>
To: <ode@q12.org>
Sent: Wednesday, May 07, 2003 1:27 PM
Subject: Re: [ODE] BSP And ODE?


> Hi,
> I only know the Quake 1/2 specifications- maybe they have changed
things-
> then just ignore my post.
> The visible face list gives you ready to use polygons that can be
put into
> opcode, as opposed to mere BSP splitting planes that would need to
be
> evaluated to a mesh before they can be used for collision detection-
so you
> would have some severe runtime overhead. BSPs are fine for spheres
of
> pre-determined size, but for general collision detection, it's a
headache.
>
> One other question though: if you use leaf data from a Quake tree,
how do
> you deal with 0-volume meshes? I am storing the visible leaf faces
in a
> tricollider on a per-leaf basis. This works fine, unless there is
only one
> face per leaf in which case severe hacking seems to be required in
order to
> prevent crashes.
>
> - Marco Grubert
>
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode