Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 1 of 3 123 LastLast
Results 1 to 10 of 25

Thread: GL_TRIANGLES vs GL_TRIANGLE_FAN/STRIP

  1. #1
    Intern Newbie
    Join Date
    Jan 2011
    Location
    Brazil
    Posts
    44

    GL_TRIANGLES vs GL_TRIANGLE_FAN/STRIP

    Using Vertex Index Objects, is there an efficiency difference between glDrawArrayElements(GL_TRIANGLES,...) and glDrawArrayElements(GL_TRIANGLE_FAN/STRIP,...)?

    I know that in the old OpenGL (glBegin()/glEnd()), there was a big efficiency issue since, using TRIANGLES, the user'd request that OpenGL repeat a series of triangles in a mesh. However, in version 3.3, since you throw all the indexes at once, does OpenGL do some optimizations for you, removing unnecessary repetitions? I'm guessing not, but hope dies last.

    If OpenGL doesn't optimize and there is a significant difference, then here's the practical problem. My program needs to display a triangle mesh that's spit out by a third-party program. The output file is nice and simple, basically in the format:
    Code :
    VRTX (vrtx-id) (x-coord) (y-coord) (z-coord)
    VRTX (vrtx-id) (x-coord) (y-coord) (z-coord)
    VRTX (vrtx-id) (x-coord) (y-coord) (z-coord)
    ...
    TRGL (vrtx-id) (vrtx-id) (vrtx-id)
    TRGL (vrtx-id) (vrtx-id) (vrtx-id)
    TRGL (vrtx-id) (vrtx-id) (vrtx-id)
    ...
    Where everything in parentheses is a place-holder for values. So, basically, it declares all the vertexes and their coordinates and then lists the different triangles to be made. This makes it quite perfect for use with OpenGL, but there's just one problem: the triangles are given in a seemingly random order, so there's no obvious way to implement it using either TRIANGLE_FAN or _STRIP. Is there some common or clever algorithm to rearrange these so that either FAN or STRIP can be used instead of TRIANGLES?

  2. #2
    Senior Member OpenGL Lord
    Join Date
    May 2009
    Posts
    6,015

    Re: GL_TRIANGLES vs GL_TRIANGLE_FAN/STRIP

    Using Vertex Index Objects, is there an efficiency difference between glDrawArrayElements(GL_TRIANGLES,...) and glDrawArrayElements(GL_TRIANGLE_FAN/STRIP,...)?
    Um, yes. The full answer is much more complicated.

    Oh, and there's no "glDrawArrayElements".

    On most meshes, you will have more index data when you use GL_TRIANGLES than with GL_TRIANGLE_STRIPs (fans are almost completely useless. There are a few corner cases where they're useful, but outside of the obvious, don't bother). Naturally, this takes up more memory and therefore more bandwidth to read.

    This is the only concern you have if you aren't interested in doing any processing of your data. If all you want to do is spit the triangles out exactly as they were given to you, then this is your only concern.

    However, if you're interested in maximum performance, then you need to process your data. You will need to implement an algorithm that rearranges the order of triangles so that it improves vertex processing time via more efficient usage of the post-T&L cache.

    There are algorithms to do so for triangle lists and for triangle strips. The stripping algorithms are not as efficient at the task however, since they still need to form effective strips. They will still be smaller in memory though, which for exceedingly large meshes can be important.

  3. #3
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,789

    Re: GL_TRIANGLES vs GL_TRIANGLE_FAN/STRIP

    Your hardware's vertex cache can only work if it's given indexes to work from. Indexes may consume more bandwidth, but indexed triangles can give much more efficient triangle reduction in your mesh. Modern hardware is more likely to be better optimised for indexed triangles; in particular because they're what modern games use. One feeds off the other.

    Run Doom 3 under GLIntercept some time and have a look at the draw calls it uses; you won't find one single strip or fan in the entire scene. Everything goes through "glDrawElements (GL_TRIANGLES, ...".

  4. #4
    Intern Newbie
    Join Date
    Jan 2011
    Location
    Brazil
    Posts
    44

    Re: GL_TRIANGLES vs GL_TRIANGLE_FAN/STRIP

    Quote Originally Posted by mhagain
    Your hardware's vertex cache can only work if it's given indexes to work from. Indexes may consume more bandwidth, but indexed triangles can give much more efficient triangle reduction in your mesh.
    Oh, I'd certainly use indexes. My question is merely if there is a considerable difference between glDrawElements(GL_TRIANGLES,...) and glDrawElements(GL_TRIANGLE_STRIP,...), but I think that has been appropriately answered.

    And I have no idea why I wrote it as glDrawArrayElements before...

  5. #5
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,789

    Re: GL_TRIANGLES vs GL_TRIANGLE_FAN/STRIP

    You can still use glDrawElements (GL_TRIANGLES,...) but order your vertexes as if they were a strip. There should be no difference at all unless the hardware has some really exotic components especially optimised for strips.

  6. #6
    Advanced Member Frequent Contributor
    Join Date
    Oct 2009
    Posts
    592

    Re: GL_TRIANGLES vs GL_TRIANGLE_FAN/STRIP

    mhagain, you mean GL_TRIANGLE_STRIP? Yeah, I agree.

  7. #7
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,789

    Re: GL_TRIANGLES vs GL_TRIANGLE_FAN/STRIP

    Quote Originally Posted by ugluk
    mhagain, you mean GL_TRIANGLE_STRIP? Yeah, I agree.
    No, I don't mean it. Wherever did you get that idea from?

    OK, by all means use GL_TRIANGLE_STRIP if you want, and have fun fooling around with degenerate triangles and/or primitive restart. And get a best-case vertex reuse of 1 per tri (instead of a common case of 0.65 and best of 0.5) that limits the amount of geometry you can use. And have nothing more than a heavy investment in an overly complex and fragile renderer to show at the end of it. Have fun handling complex models that need to be represented by a combination of strips and fans too.

    Otherwise order your vertexes and indexes in the most appropriate layout and just use GL_TRIANGLES with no messing.

  8. #8
    Intern Newbie
    Join Date
    Jan 2011
    Location
    Brazil
    Posts
    44

    Re: GL_TRIANGLES vs GL_TRIANGLE_FAN/STRIP

    Yes, well the problem is exactly that I don't know how to order the vertexes. The triangles are given with out-of-order indexes (1-2-3 20-40-35 2-67-9), so part of my question is exactly if there is a known algorithm to sort these triangles into handy ordered lists.

  9. #9
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,789

    Re: GL_TRIANGLES vs GL_TRIANGLE_FAN/STRIP

    Sure; have a look here: http://www.opengl.org/discussion_boa...;Number=257252

    A Big Dirty Secret is that if you're coding on Windows you can actually use D3D to do this too, even in an OpenGL program; the D3D optimization functions don't require a device to be created.

    It's worth just using the data as-is and seeing if performance is acceptable enough without optimization though. You might find that you run quite well without needing to commit to ordering the triangles at all.

  10. #10
    Senior Member OpenGL Lord
    Join Date
    May 2009
    Posts
    6,015

    Re: GL_TRIANGLES vs GL_TRIANGLE_FAN/STRIP

    OK, by all means use GL_TRIANGLE_STRIP if you want, and have fun fooling around with degenerate triangles and/or primitive restart. And get a best-case vertex reuse of 1 per tri (instead of a common case of 0.65 and best of 0.5) that limits the amount of geometry you can use. And have nothing more than a heavy investment in an overly complex and fragile renderer to show at the end of it.
    ... What?

    All of the stuff we're discussing is on the pre-processing side. It has nothing to do with making a "renderer", so strips vs. list would introduce neither complexity nor fragilty into the renderer. Nor would either side limit "the amount of geometry you can use."

    Vertex reuse is not the end-all-be-all of vertex processing performance.

Posting Permissions

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