Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 10 of 15

Thread: Draw order for a game renderer

Hybrid View

  1. #1
    Junior Member Newbie
    Join Date
    Jan 2009
    Posts
    20

    Question Draw order for a game renderer

    I'm writing a rendering subsystem for my game and would like to know what I should aim for in terms of drawing order. Some points on the game's rendering:

    -The rendering is pretty simplistic, it just uses texture billboard quads (i.e. rotated to always face the viewer) for every creature / item, each of which appear on a polygonal terrain / surface.
    -I don't need z-buffering since I'm using partly-transparent textured quads to give the illusion of form. I use the painter's algorithm instead.
    -The game is for fairly standard-grade x86/64 desktop systems (standard OpenGL, not ES).

    For the render order, so far I have this:

    by depth (necessity for accurate draw order / painter's algorithm)
    -by program (context changes here must be costly!)
    --by texture in program (I have *heard* that texture context changes are costly...)
    ---by mesh that uses that texture(glVertexAttribPointer, not horrifically costly?)
    ----by discrete entity transform (every entity using this mesh)

    Does this order make sense? I have no idea how to go about this decision, except by ordering from what I think is the most expensive context switch (to happen least frequently), down to the least expensive (to happen most frequently). I would love to be able to put program before depth, but obviously that would break the painter's algorithm! Also I don't know if "render by texture" is in the most suitable place here. In fact, unless someone shows me a better way, I will probably have just one shader program for all my in-game objects because otherwise it's going to lead to a LOT of shader program changes. That would lead to:

    by program
    -by depth
    --by texture
    ---by mesh
    ----by discrete entity transform
    Last edited by Nick Wiggill; 08-26-2012 at 07:22 AM.

  2. #2
    Super Moderator OpenGL Lord
    Join Date
    Dec 2003
    Location
    Grenoble - France
    Posts
    5,580
    Your second option seem better, a priori.
    Texture switches are quite costly too, how many texture switches do you expect ? Try to pack in texture atlases or texture array.

  3. #3
    Junior Member Newbie
    Join Date
    Jan 2009
    Posts
    20
    Atlases are a definite. Cheers for the encouragement.

    I had a related discussion about the above question elsewhere, centred around using the painter's algorithm vs using the z-buffer (I was planning on foregoing the latter in favour of the former).

    My understanding, now, though, is that the z-buffer does depth ordering correctly EVEN IF we switch shader programs halfway through rendering all our objects. If this is so, I'd like to use the z-buffer... this would also mean I could use approach 2, obviously.

    Does this sound about right?

  4. #4
    Junior Member Regular Contributor Kopelrativ's Avatar
    Join Date
    Apr 2011
    Posts
    214
    Quote Originally Posted by Nick Wiggill View Post
    Atlases are a definite. Cheers for the encouragement.
    Before doing this change, try rendering you "world" with one single texture. That will give you an idea how much you can gain with an atlas. I did that in my voxel-based project, and could notice no difference. So the actual gain depends on your situation (as always). And of course the result can be different on different hardware.

    Using atlases have disadvantages and requires some effort, so it may be a good idea do some testing first.

  5. #5
    Junior Member Regular Contributor Kopelrativ's Avatar
    Join Date
    Apr 2011
    Posts
    214
    Quote Originally Posted by Nick Wiggill View Post
    Does this sound about right?
    There is the obvious question that should have been asked first: Have you done some performance measurements that show you may have a problem?

    If not, don't worry. It could be much better to implement a logic that is easy to understand and follow. To optimize draw order, there are ways of iterating through all the data, without drawing, but saving in sorted lists of what shall be drawn, and then iterate over the lists as a second stage.

  6. #6
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,128
    In regards to switching textures I can remember a project I ran on an GeForce 8600 M GS mobile GPU - which is obviously not that powerful - where I did something like 130 texture switches per frame and it didn't make any difference. Try to really profile into that!

    As always: Start with some order that seems reasonable, run and profile both the CPU and GPU times of at least some coarsely defined sections of your application, find out what's taking the most time, optimize and repeat the process until you're either satisfied or can be sure that no further optimization makes sense or is possible. Don't assume stuff - gather and deal with real performance data.

  7. #7
    Super Moderator OpenGL Lord
    Join Date
    Dec 2003
    Location
    Grenoble - France
    Posts
    5,580
    Re zbuffer or painter's algorithm :
    using partly-transparent textured quads to give the illusion of form
    Does that mean you use blending ? Or simply alpha tested shapes ?
    Because with blending, zbuffer is mostly unusable.
    Without blending, you should absolutely use a zbuffer, and draw sorted by shader then texture !
    One could also use a coarsely sorted polygons and draw front-to-back to take advantage of early-z optimisations, useful if you have complex shaders that do not modified the fragment depth.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •