[ODE] BSP And ODE?

[Mohammad Bilal]

well yeah as I told you earlier, Im using OPCODE for my quake2 map loading engine and im feeding it with the triangulized vertices right at the start and its working very fine. Nathan mentioned a more efficent way of feeding OPCODE with simplified triangles built directly from the brushes in the map structure. Unfortunately I dont have much idea how to do that so for now, im gonna stick with the first approach.

Bilal

----- Original Message -----
From: "Pierre Terdiman" <p.terdiman@wanadoo.fr>
Date: Fri, 9 May 2003 15:45:12 +0200
To: "Mohammad Bilal" <prettyh8machine@mail.com>, <ode@q12.org>
Subject: Re: [ODE] BSP And ODE?

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

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