[ODE] Another simple BSP colliding question

[Megan Fox]

I don't claim that it's the best option (I'm a PC developer with more
available memory than I know what to do with), but you can always just
create a trimesh out of your entire static environment (well, whatever
portion of your entire level, or whatever collision pieces are
necessary for the given loadzone).  Both OPCODE and ODE have systems
in place to optimize out large chunks of the world when it comes to
collision (ODE with quadtree and hash spaces, and OPCODE with
something similar though I don't know what precisely), so the extra
data floating in space shouldn't be too much of a problem in terms of
speed.

... but, like I said, I'm sure there are better ways of going about
it.  In my case, I keep the entire region physically active to allow
world entities to interact in proper physical fashion even when away
from the player, but I imagine you could ditch that in a non-RPG/more
linear game.

-Megan Fox

> I know this was asked before, but I have never seen anyone mention BSP Brushes.
> 
> They are used for collision in quake (3 and im not sure about others)
> so that might be a nice solution for collision detection... ? What
> would you say?
> 
> On the other hand, there is a tri-collider, where I could build
> tri-colliders for visible leafs, and then use that information...
> would that make sense? What would be better?
> 
> Brushes make a nice candidate, since not all the space needs to be
> computed for collision. Yet im not sure since there might be quite a
> few brushes...
> 
> Please advise on what I should do.. Thanks!
> 
> Tim
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode
>