Polygon management question

If my aim is to eventually produce some sort of program which has open terrain with buildings that can be accessed without ‘zoning’ what should I be trying to study, and can you give me a heads up on where to find good info?

I’ve done a bit of poking around, and found mostly stuff on bsp trees, quad trees, and octrees, but from what I’ve read, they seem more like data structures that would be used to manage indoor type surroundings.

Thanks much.

Actually, I think quad and octrees are more suited to open terrain than buildings. I myself would like to know if there’s a technology well suited for both indoor and outdoor rendering, but I have not encountered any. The things I’ve seen so far always use separate technologies for in- and outdoor rendering.

(e.g. as far as I know wurmonline (www.wurmonline.com) uses quadtrees for the terrain and bsp for the buildings, although the wurmonline developers on this list will now probably tell me I don’t know what I’m talking about ;))

Portals are good for mixing indoor and outdoor type scenes. You can use the portals to find the initially visible sectors. Then each sector can have its own specialised data structure if need be (like bsp for indoor, or quadtree for outdoor). Or if a sector is small enough you can just brute force it since the portals give you only whats visible anyway.

If you’ve got good portal placement, you can do without anything like a bsp for indoors, since the portals and sectors do a better job. And let you have weird tardis-like spatial inconsistancies. The only problem being that portal and sector placement almost always has to be done by hand, unlike the other methods which can be auto generated.

This is a potentially dumb question, but I’m going to ask anyway…

Assuming that the terrain is using a quadtree, and the buildings are using bsp trees, I have a few questions:

  1. It must be that each individual building has it’s own
    seperate bsp tree. True?

  2. How do trees etc get drawn correctly? It would seem
    that they would have to be linked to the terrain
    drawing somehow so that they would be correctly
    drawn behind hills, etc.

  3. Same deal for the buildings…if they are being
    controlled by their own local bsp trees, how does
    the overall rendering scheme know to draw a house
    partially behind a hill?

If the answers to these questions are too long, or simply
to boring to answer I’ll understand. I think the people here are so far beyond these type questions that it’s just not interesting to them, but I can’t really see how I can go forward until I can somehow learn the answers. If someone would rather point me to a tutorial that would be fine…or a textbook.

Not boring at all, I’m still asking myself the same kind of questions :slight_smile:

I can tell you that, yes, trees and other “decorations” need to be somehow linked to the terrain. Or better they need to be linked to the same quad tree “leaf” as the terrain they’re standing on (although you could of course have different quad trees for your terrain and your decorations, but it’s the idea that counts).

With respect to the buildings and their bsp trees… I’m not so sure, but I guess those buildings will be linked to the quad tree in a similar manner as the trees but instead of just renderinig a model of a tree an entirely different renderer takes over the rendering of the building.

I’m pretty sure it’s the responsibility of the quad tree renderer to determine if a tree or a building is behind a hill.

This probably won’t get you one step closer to writing the actual code, but discussiong it like this might at least give us some ideas :slight_smile:

Yeah, you will need a separate bsp tree for every building. As long as they don’t intersect (and if they do, just merge them into a single building). You can then calculate a bounding box/circle for the whole bsp and bung it in the terrain’s quad tree just like anything else. Likewise for trees, calculate a bounding object and stick it in the quad tree.

Assuming you’re using OpenGL getting objects to draw in the correct order is easy, you just let the z-buffer do its magic. Doing a rought front-to-back sorting may be a good optimisation but its not a major concern.

@Orangy Tang: just a question, I can easily imagine how to do frustrum culling using a bounding sphere/box for all objects including entire BSPed buildings. What has gotten me stumped so far is how to do occlusion culling for quad tree terrains and such. Do you have any experience with that? Any pointers to good information on how to accomplish occlusion culling? I found something a while ago but it really looked like a lot of work.

Occulsion culling seems to have lots of different ways to do at the moment, and with no ideal general solution. Portals and sectors gives you good occulsion culling, but isn’t really suitable for terrains. Modern cards have occulsion queires which can test if an object is visible or not (effectivly testing against the depth buffer) but I’ve not heard these being very good in practice.

This is one of the most comprehensive (and practical!) occulsion methods I’ve seen, but its not something I’ve experimented with much. The book Real Time Rendering also has a shed load on this, but its full of scary maths.

I’d be inclined to say that for most outdoor games you rally don’t need it though.

This is more of a comment than a question.

Well, Orangy Tang, you certainly dispelled one of my great misunderstandings about how OpenGL works…I assumed that letting the z-buffer take care of drawing order was slow, and only fit for things that moved around in the scene. I suppose I got that idea from reading about software rendered games like Doom and Quake 1.

Anyway, thank you for your comments on this post, as I’m sure it will be a great help to know where to begin:)