openGL rendering

This is a discussion on openGL rendering within the Game Programming forums, part of the General Programming Boards category; Hello I've mainly used things like GDI and SDL to do graphics, I've now started to use openGL but I ...

  1. #1
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459

    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
    Last edited by zacs7; 10-23-2007 at 02:21 AM. Reason: Opsies, 1000 x 1000 is not 10,000 ;)

  2. #2
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    10,000 (1000x1000)
    Umm ....


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

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  3. #3
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459
    >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?
    Last edited by zacs7; 10-23-2007 at 02:33 AM.

  4. #4
    Ethernal Noob
    Join Date
    Nov 2001
    Posts
    1,901
    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.

  5. #5
    Crazy Fool Perspective's Avatar
    Join Date
    Jan 2003
    Location
    Canada
    Posts
    2,640
    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.

  6. #6
    Ethernal Noob
    Join Date
    Nov 2001
    Posts
    1,901
    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.

  7. #7
    Crazy Fool Perspective's Avatar
    Join Date
    Jan 2003
    Location
    Canada
    Posts
    2,640
    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).

  8. #8
    Ethernal Noob
    Join Date
    Nov 2001
    Posts
    1,901
    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?

  9. #9
    Crazy Fool Perspective's Avatar
    Join Date
    Jan 2003
    Location
    Canada
    Posts
    2,640
    Quote Originally Posted by indigo0086 View Post
    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.

  10. #10
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,596
    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.
    Last edited by VirtualAce; 10-24-2007 at 10:40 AM.

  11. #11
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,189
    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.
    Until you can build a working general purpose reprogrammable computer out of basic components from radio shack, you are not fit to call yourself a programmer in my presence. This is cwhizard, signing off.

  12. #12
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459
    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?

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. OpenGL rendering problem
    By JJFMJR in forum Game Programming
    Replies: 8
    Last Post: 08-31-2007, 08:26 PM
  2. Linking OpenGL in Dev-C++
    By linkofazeroth in forum Game Programming
    Replies: 4
    Last Post: 09-13-2005, 11:17 AM
  3. OpenGL Window
    By Morgul in forum Game Programming
    Replies: 1
    Last Post: 05-15-2005, 01:34 PM
  4. OpenGL and Windows
    By sean345 in forum Game Programming
    Replies: 5
    Last Post: 06-24-2002, 11:14 PM
  5. opengl code not working
    By Unregistered in forum Windows Programming
    Replies: 4
    Last Post: 02-14-2002, 10:01 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21