Sign in to follow this  
My_Mind_Is_Going

Portal rendering

Recommended Posts

I'm trying to figure out a strategy for rendering a big indoor level for a FPS-style game and I'm having trouble deciding on a good approach for managing occlusion culling (i.e. not drawing parts of the level that are not visible). For everything I've worked on previously, simple frustum culling (or octree-assisted frustum culling) has sufficed, so this is pretty new territory for me. I get that doing a Quake-style BSP rendering algorithm that draws polygons one at a time is pretty much irrelevant in this day and age. A portal system sounds promising from what I've read, but I'm a little concerned about making it work from an asset pipeline perspective. I'm most likely going to be working with levels created in 3ds Max, not something from a custom editor, so having someone specify all the sectors and portals by hand is probably not going to be possible. I've looked briefly at this article http://www.gamedev.net/reference/articles/article1891.asp about automatic portal generation. It sounds a little complicated but I suppose it could work. One thing I'm concerned about is that since this algorithm requires breaking up the geometry along convex boundaries it's going to disrupt things like material information specified in the exported file (most likely FBX). For instance if the artist creates a mesh with a particular texture in the scene, and the portal generation requires this mesh be broken up into several pieces in different sectors I guess I would have to group the triangles in each sector by texture so I can draw them correctly later. Anyway, I just wanted to see what people had in the way of recommendations for a general approach to take with all of this. I'd like to do something that's relatively modern (maybe something using hardware occlusion tests) and hopefully relatively simple. I'm not looking for absolute most efficient system, but just something to keep the amount of overdraw within reason. Thanks in advance for your input. [Edited by - My_Mind_Is_Going on March 11, 2010 11:16:59 AM]

Share this post


Link to post
Share on other sites
A basic portal system is probably a good way to go. It's relatively easy to implement using hardware occlusion querries.
I once used handplaced portals (Quads with special names inside the editor) and only did the partitioning into cells automatic. If you find a way to separate your "assets" from the basic mesh that defines your rooms and corridors, you can cut that mesh along the portals and use some sort of flood-fill algorithm to determine which polygons belong to which cell. Downside is, you get concave cells.

Share this post


Link to post
Share on other sites
Forgetting the portals specifically for now, let's say I'm just going to use a BSP to create convex groups out of the incoming geometry and for whatever reason have these groups represent the smallest renderable unit -- meaning I'll draw an entire group in one batch if possible, maybe in several small sub-groups if there are different materials to be used.

Maybe I'm thinking about this too narrowly, but I'm concerned about something like the following situation. Let's say there's a textured wall that looks like this:



(with the designated texture coordinates)

and it has to be split down the middle by the BSP algorithm giving something like this:



In order to be able to render the final split version without a perceptible difference from the original mesh, I need to do the following right?

1. Figure out a triangle tessellation for the four-sided polygons that have been created.

2. Figure out appropriate texture coordinates for the newly created vertices. This is the part that troubles me the most, particularly since the original geometry probably wouldn't even be this well behaved.

3. If there were other vertex attributes like colors, I would have to figure out what to do with these as well.

This seems like a pretty common situation so hopefully there's a standard way of dealing with it.

Share this post


Link to post
Share on other sites
I don't know if this is the standard way but:

Quote:
1. Figure out a triangle tessellation for the four-sided polygons that have been created.


Triangle fans usually work nice because the resulting polygon is always convex. However you should keep it as a quad (or polygon) until all splitting is done, as this might reduce the face-count. For example take a look at the example you gave above. After converting both quads into triangles you will have a total of 6 (triangle) faces. If you had kept the original mesh as one quad, the split would have produced two quads which gets converted into a total of 4 triangles.

Quote:
2. Figure out appropriate texture coordinates for the newly created vertices. This is the part that troubles me the most, particularly since the original geometry probably wouldn't even be this well behaved.

3. If there were other vertex attributes like colors, I would have to figure out what to do with these as well.


I try to think of it as a special case of linear interpolation. So if you split an edge from vertex V1 to vertex V2 at 1/3 of the way your resulting vertex Vnew would be Vnew = 1/3 * V1 + (1 - 1/3) * V2. The same works for all the other attributes like color (Cnew = 1/3 * C1 + (1 - 1/3) * C2) or texture coordinates, normals, ...

Whatever spatial partitioning you choose, if you need splitting I would recommend writing a small test application first to get familiar with splitting meshes along a single plane before diving into the full BSP/portal creation madness.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this