Cell and portal scenes and level geometry

[kalie]

Hello everyone, my searches on this topic have proven fruitless, I apologize if it is my searching skill that is lacking!
I hope someone can give me some insight!

I have a small 3d game in development. The typical scenes will be indoor, room and corridor areas similar to a lot of FPS games. After reading about various options, I've gone with a cell and portal design for my overall scene management (similar to the portal connected zone manager in Ogre). Each cell uses a loose octree for internal space partitioning. This seems to work very well for managing visibility, rendering, and collision of objects in the cells (discreet mesh objects that can move around)

My question is, how is level geometry typically handled in a structure like this? By level geometry, I mean the walls and floors (and other static polygons that make up the boundaries of a room). Currently, the geometry of each cell comes in (from blender) as a series of polygons sorted by material so that they can be rendered with a minimum of state changes on the graphics card. For rendering, this seems to work just fine -- I can just sequentially draw all visible cell's level geometry fairly quickly.

But, I want to utilize my octree to be able to efficiently find level geometry for collisions and such, and potentially cull parts of a cell that aren't visible. Material sorted poly meshes are often very broad, with a combined bounding box that spans most of the cell (for instance if all the walls are the same wood-paneled texture--- this gets even worse if I start using texture atlases). This means that for collision (or visibility ) checks, almost the entire cell would be returned each time if I tried to simply drop the polygons as a whole into the octree. This seems wrong to me, so I'm wondering if there's a good way of representing this level geometry in a cell and portal structure that I'm missing.

My current debate is between
- Leaving level geo as it is, and just brute force all collision/visiblity checks with level geometry. It might be simple enough that trying to handle it with my spacial partitioning is overkill that won't pay off.
- Duplicating the geometry -- sorting polys into material groups for rendering, and somehow partitioning the geometry into manageable hunks for collision detection. For this, how would I split them up? By octree planes? at which subdivision level?
- split all level geometry into chunks based on octree partitions for both rendering and collision. Again, not sure how finely to split them up.
- something else? how do people do this? all the things that I've read seem to skip over this point as if it is obvious

Any thoughts? I feel like I'm stuck on this, and it seems like it should be trivial...

PS. I should note that I'm not using Ogre for this, but it looks as though my design is pretty close to how Ogre's scene management works, so I wager Ogre geniuses have some advice that would be very pertinent.

Thanks,
Kalie

[kalie]

In case anyone is curious and/or having a similar problem where this question is coming up in a search, I figured I'd post an update on how I'm planning on proceeding with this. I'd still welcome feedback from folks here of course, especially if someone spots something that will cause problems for me later on!

So I had been more or less mixing rendering with collision requirements in my head, wanting to use the same structure and solution for both. While seemingly well suited for rendering, batching level geometry by material is a fairly ugly structure for collision. By simply dropping these polygons into a best-fit bounding box and letting the octree handle that, every collision check returned the level geometry. the polygons create volumes that are extremely non-convex, of course, (in fact, typically exclusively concave) and not even connected in many cases.

In short, what I really needed/wanted was a fairly flexible and efficient collision determination strategy for level geometry.

What I've chosen to do:
- While constructing my vertex buffers for the level geometry rendering batches, I also redirect the vertecies to an array of world-space 'hullfacets' -- basically triangles.
- I then create a general purpose collision hull from these facets. The general purpose hull is an AABB bvh tree storing facet indexes in the leaves. The collision hull is interfaced by collider objects (rays, bounding boxes, spheres, etc etc) to perform collision tests. Note the aabb tree is the most general collision hull along side simple AABBs, OBBs, Cylinders, ellipsoids, etc.
- The collision hull is associated with a scene node and thus can be transformed (yucky for AABB trees, but level geometry doesn't move much)
- The scene node can be placed in the octtree for a sort of broad phase collision test, using an AABB around the collision hull to identify its position. Many queries still return the level geometry, but I hope that the relatively low number of triangles and temporal coherence will eventually be able to help with that.
- Portal and cell continues to be of assistance, as the level geometry remains paritioned by portals and collision tests generally won't happen across cells unless they also collide with the portal.
- An axis sweep and prune strategy for collision may eventually replace the octree for collision determination, although I don't know that that will do much to improve level geometry handling.

Anyway, let me know if anyone has any thoughts about this strategy or potential pitfalls that i've not encountered yet!

Thanks,
Kalie

PS. I just noticed this got moved to the off-topic forum... while I'm not using ogre, I think these are similar problems people would encounter with ogre? It certainly applies to the 'Larger graphics field'.... oh well.