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 3 of 3

Thread: Sorting for Transparency

  1. #1
    Junior Member Regular Contributor
    Join Date
    Apr 2014
    Posts
    109

    Sorting for Transparency

    Hello,

    So I would like to optimize my drawing calls to account for transparency.

    Long story short, what I have been doing is sorting all of my OpenGL meshes from opaque to fully transparent before the scene is loaded and then drawing.

    However, after reading, you must also sort from furthest to nearest.

    The problem is I am not sure how this can be done dynamically in the scene with an std::vector or QVector based iteration of all of my objects I need to draw.

    Consider the logical steps I am going through now:

    1. Load all of my objects into Computer RAM via loaders.
    2. With loaders I assign the correct materials to the object (colors, textures, etc.)
    3. Sort by transparency
    4. Load into OpenGL
    5. Draw into OpenGL using the rendering loop.

    I guess what I am asking is how do people sort the objects drawn from furthest to nearest per frame based on the active camera position?

    What's the high speed way that I am missing?

    Thank you.

  2. #2
    Intern Contributor
    Join Date
    Mar 2014
    Posts
    59
    What you want as no nice solution :
    - oit (order independant transparency) not perfect but works
    - depht peelling : need a lot of tweak and may be slow

  3. #3
    Senior Member OpenGL Guru
    Join Date
    Jun 2013
    Posts
    2,523
    Quote Originally Posted by tmason View Post
    I guess what I am asking is how do people sort the objects drawn from furthest to nearest per frame based on the active camera position?
    You need to use a topological sort.

    You can't use std::sort (or qsort() etc) because (in general) there isn't a total ordering. To make matters worse, the graph may well have cycles, in which case you have to split polygons in order to break cycles.

    If the objects' positions relative to each other are fixed, you can generate a BSP tree on loading (or beforehand). This makes it much simpler to determine the correct order for any given viewpoint. However, for complex geometry, it will typically require many polygons to be split.

    Quote Originally Posted by tmason View Post
    What's the high speed way that I am missing?
    Depth peeling. See e.g. here.

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
  •