[ODE] BSP And ODE?

[Mohammad Bilal]

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..??
And you're sure that this whole making of triangles out of brushes at the load time of the map isnt going to take much time ??

Bilal

----- Original Message -----
From: "Nathan Ostgard" <nostgard@lvcm.com>
Date: Wed, 7 May 2003 14:13:31 -0700 
To: <ode@q12.org>
Subject: Re: [ODE] BSP And ODE?

> 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
> 
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode

-- 
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup