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 :)

Quote:

---

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?

Well, Corndebee is correct that you should only render what the camera can actually see, and the viewing frustum does so, but you still calculate the entire scene, I'm sure there's a way to dynamically adjust your loop to include only things which lie in the viewing frustum after being projected, but I'm sure it involves lots of maths. Try looking into Vertex Arrays/buffers, in which you can load all the vertices into a buffer and have the implementation render them without doing a loop.

If you have a grid it's pretty easy to compute what may be visible. Just take your position and redner all tiles from <pos.x - width, pos.y - height> to <pos.x + width, pos.y + height>. you'll still be rendering stuff that's not in the view frustum but it's be much faster than rendering the entire scene.

What about if you're doing something like terrain, where not calculating something that lies outside of the viewing frustum may mess up the geometry on the terrain.? And if we're talking perspective projection, then the calculation won't work always depending on how far out the pixel is being placed.

If your terrain is laid out as heights on a grid than you can still use the approach. It's definately not optimal but its an easy way to render large terrains based on view position. It won't mess up the geometry of the terrain but it will cause "popping" (as will any clipping method). Then you need vertex morphing to solve that (or just fog out the distance).

Doesn't storing the vertices in the buffers solve that problem, does the implementation not calculate what should be rendered from the buffer, or does it plot them all and let the frustum do the work of clipping out unseen vertices?

Quote:

---

Originally Posted by indigo0086

Doesn't storing the vertices in the buffers solve that problem, does the implementation not calculate what should be rendered from the buffer, or does it plot them all and let the frustum do the work of clipping out unseen vertices?

---

Everything you tell openGL to render will be sent through the graphics pipeline (the expensive part), only the part that ends up viewable will be rendered into the frame buffer. So you should avoid rendering things that are not in the view frustum (they will be processed in the pipeline even though they aren't viewable). Vertex buffers don't solve this problem for you.

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.

The rendering frustum IS the way you determine what to render. there is no faster way of determining if something is in the scene or not. There are however ways to 'remember' that something wasnt in the scene last frame, and hasnt moved relative to the scene, so therefor is prolly not in the scene this time either.

Wow thanks for the tips :o, 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?