1) You can read some good articles about fast terrarian rendering. You can find links for them on www.gamedev.net/opengl

2) There is also Painter's algorithm to remove non-visible surfaces. This algorithm described in many good graphics books. But i think it might be too slow for rendering small polygons. In this case i recommend you to use z-buffer (render terrarian with just updating z-buffer, and then render all objects with normal z-buffer testing), or, if your terrarian polygons will be as small, as object's polygons, you can make a rendering list and sort all (terrarian and objects) polygons by av. z-value and then render them in back-to-front order. That's the way we used in our little 3d landscape engine (look at the demo http://codexorg.webjump.com/eng/codex/main.htm )

Thanks for the advice. I've already implemented z-buffering in my engine, so rendering polygons that aren't supposed to be there is not a problem. Perhaps if I used a "reverse" painter's algorithm combined with my idea for splitting everything up into little chunks, rendering them in a front to back order. This would make sure that many more polygons would be cought by the z-buffer before being rendered. The problem is that I'm already sorting all the polygons in the scene by their material so that I can render all polygons of a single material (and texture) and a time. This supposedly gives you a good performance benefit, but I have yet to do any comparative testing on the matter. It'd be a shame if it just wasn't worth it, because it was very annoying to design the engine so that doing that sorting is fast and easy. Anybody else done testing on how much doing that kind of material sorting speeds up rendering? I wonder if it would be a better boost in speed to do the front to back sorting instead...

Rendering front-to-back using z-buffer isn't a good idea, especially on Pentium with it's branch prediction overheads. Comparing values in z-buffer isn't a good idea.
But you can accelerate this (as maded in all 3d games, i belive) if you will render all faces you know will not intersect with each other (terrarian surface, for example) with just z-buffer update mode (no comparison)
and then render all other objects with z-buffer compare mode (as i already describe in previous posting)

Well, after some thought I just decided to totally forego implementing a software rendering mode in the engine I'm making, so z-buffering would be done by the video hardware. It's just not worth it now that fast 3D hardware acceleration is quickly becoming the standard. That being said, I would think that if I were to rely on the z-buffer at all it would be best to use front to back sorting in order (which I probably will NOT end up doing anyway...) to eliminate as many polygons as possible.

I've been playing around with a 3D rendering engine for outdoor scenes with arbitrary geometry and I thought I'd throw a few ideas around this board about how to do VSD for the world geometry. I was thinking that perhaps some people out there might have some ideas to help me along and that I might even be able to spark ideas in others. Any comments are very welcome.

To start out, the world will be made up of two discrete types of objects. The first will be a simple triangulated heightfield as the underlying terrain. The second will be structures of arbitrary geometry resting on that terrain (houses, towers, bridges, etc...). In the end, I'm hoping to turn this engine into a role playing game of some variety. Well, as for VSD, I thought that using separate methods for the two different types of geometry would be the best approach.

For the terrain I thought I'd just test where the viewing frustum intersects the terrain and render everything within those boundries. That's the fastest method I could figure out to render an arbitrary heightfield.

As for the structures that rest on top of the terrain, I came up with a sort of two part VSD method. It involves breaking them up into smaller "chunks", each being of relatively small size and constant texture and then computing the bounding spheres/boxes for these chunks and testing them against the viewing frustum. As these primitives are easier to clip and this could quickly eliminate the portions of the structure that are outside of the viewable area. Then I could use front-side (done before transformation and lighting) backface removal on the remaining polygons to come up with a smaller visible set. The problem with this method is that it only culls out the polygons that either are outside the viewable area, or not facing the user. It does nothing for polygons that are occluded by other polygons. Here is where I was really wondering if anybody had any better ideas or even possible improvements on my idea.

Hi,

Zbuffer and only frustum really isn't enough to keep large outdoor environments fast.
I've created antiportal support which act as occluders, you can place them inside buildings for example. everything in the volume behind the antiportal won't be processed by my engine. Also it is important to create some sort of hierarchies in your world. Like octrees. Split up your landscape into sectors, and split these large sectors up into smaller ones etc etc.
Then check the boundingboxes of the large sectors against the frustum and occluders, if they are not visible then you can skip all elements inside the sector. If it however is visible you check the smaller sectors within this sector etc...

It's also cool to automaticaly generate occluders inside high hills and mountains. This really can speed things up. Also level of detail is very important on landscapes. There are many ways to do this.

I hope I helped you a bit in the good direction with this message.

- John vd Burg
Programmer of Oxygen3D http://www.mysticgd.com/oxygen3d.htm