Thread: openGL rendering

Hello

I've mainly used things like GDI and SDL to do graphics, I've now started to use openGL but I can't get my head around some things -- I've read books and articles all over the place too.

Hypothetically say I want to show 1,000,000 (1000x1000) tiles. My program renders the openGL scene as quickly as possible in a big loop, should I be rendering all 1,000,000 tiles (every frame...)? (Even though they're out of the viewport).

Such as

Code:

 ____________
|-----------*|
|            |
|     #######|*************
|     #######|*** to 1000 >
|_____#######|*************
      *********************
      *********************
      *****to 1000 down****
      *********************

? Where # are visible tiles and * are out of view.

Am I supposed to just describe the scene and let openGL handle the rest? Or shouldn't I be drawing quads for the out of view tiles? Like:

Code:

static void renderMap(void)
{
    int r = 0, c = 0;
    for(r = 0; r < rows; r++)
    {
        for(c = 0; c < cols; c++)
        {
           /* render each tile for the current row/col */
            glBegin(GL_QUADS);
                glVertex3f();
                glVertex3f();
                glVertex3f();
                glVertex3f();
            glEnd();
        }
    }
}

Which is called every frame :\, 1,000,000 tiles -- am I supposed to do that, or only redraw specific ones?

I plan to move around the map (in the little visible section on the screen). In GDI I'd only render what I could see (per frame), I assume it's different for GL?

Thanks

10,000 (1000x1000)

Umm ....


Anyway, no. You're supposed to render only the stuff the camera can actually see.

>10,000 (1000x1000)
Opps -- I was only out by a factor of 100, ha.

Anyway thanks, I assume it's okay to partly render out of the screen? For example tiles which are on the border? Like:

Code:

 ____________
|-----------*|
|            |
|     ########
|     ########
|_____########
      ########

I've also seen code examples of people drawing quads say 25 units out of the screen (when at 0 depth etc), then using gluLookAt() to 'move' around the quad... Is that wise/okay?

The best approach is to not send the vertices down the pipeline. The only real way to do this is to automatically know before transformation which vertices fall inside the frustum. Since transformation of invisible or non-visible vertices is extremely expensive you want to avoid it at all costs.

Most solve the problem in terrain engines by using a quad tree. Essentially each patch of terrain has a bounding volume associated with it. Spheres work well but AABBs serve well as bounding volumes too. Spheres are easier to test but are less accurate and AABBs are more accurate but more expensive to test - to a point.

The basic premise is you extract the planes from the viewing frustum and then test the spheres or the AABBs against these planes. If the bounding volume is completely inside of the frustum then all of it's children are too. If the bounding volume is completely outside, then all of it's children are too. If the bounding volume intersects the frustum then you must drill down into it's children volumes/patches to determine which ones to render. Do NOT split the patches along frustum planes. This is more expensive than sending a couple hundred extra vertices to the card which will be clipped. Essentially the hardware clipper is more efficient than any split algo you will come up with.

A quad tree is relatively easy to setup and reduces down to dividing your huge mesh into patches of smaller meshes. Once you get the brute force quad-tree working then you can begin working on a level of detail or LOD algorithm to further reduce the graphic and vertex load.

I do not know how to do this in OpenGL but in Direct3D I never sent vertices down the pipeline that were not going to be rendered. On an old GeForce 3 64 MB card I was getting about 80 to 90 FPS using this approach. There are screenshots of this on the board if you do a search.

For an excellent look at LOD do a search on this board. Perspective is the one who finally got an LOD algo to work and it works very well.

Terrain rendering is not for the faint of heart and can get quite complex. Sophisticated engines like those found in FSX use adaptive quad-trees and real-time texture generation techniques to arrive at the final mesh and texture.
You can find articles on the FSX engine on the game's website. They explain the adaptive quad-tree quite well.
You can also go to www.vterrain.org for links and articles on just about every topic there is in terrain and/or skybox rendering. This site will lead you to a site for Hugues Hoppes (sp?) which was a key player in developing the FS2004 cloud and terrain engine. His articles on geo-mipmapping are very close to what FS2004 and FSX utilize to present seamless, boundless, horizon to horizon terrain rendering. Microsoft's Flight Simulator series has been probably the best terrain renderer ever as of late and several have tried to copy it but failed. I highly recommend getting FSX just to see how they do the terrain rendering and what the final outcome is. It is nothing short of amazing.

Wow thanks for the tips , especially Bubba -- thanks for the links and heads up.
I keep my 'tiles' in a 2d array of tiles, I'm not using the depth buffer in my program at all so could I not just send the vertices (my tiles) down the pipe which are visible? Do the calculations myself?