OpenGl sorting/displaying transparent polygons
CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 10 of 10

Thread: OpenGl sorting/displaying transparent polygons

  1. #1
    Join Date
    Nov 2003
    Location
    svk
    Posts
    10

    Post OpenGl sorting/displaying transparent polygons

    Im trying to display my scene through OpenGl, but transparent polygons are not displayed correctly, it looks like i have to distance-sort them and draw them sorted, farthest polygons first, nearest polygons last. I tried to do that by my algorithm, but sorting takes long time. Aint there any way to do it easier/faster ?

  2. #2
    Join Date
    Nov 2003
    Location
    Belgium
    Posts
    8,062
    No, you have to sort your transparent polys, unless you use another transparency method. IIRC, an additive blending mode does not require sorting.

  3. #3
    Join Date
    Nov 2003
    Location
    svk
    Posts
    10
    and how do i activate this additive blending mode please ?

  4. #4
    Join Date
    Nov 2003
    Location
    Belgium
    Posts
    8,062
    glBlendFunc(GL_ONE, GL_ONE);

  5. #5
    Join Date
    Nov 2003
    Location
    svk
    Posts
    10
    that does not help with the problem, it only boosts gamma alot.

  6. #6
    Join Date
    Nov 2003
    Location
    Belgium
    Posts
    8,062
    Try to ask your question on www.flipcode.com. There are a lot of people using OpenGL over there.

  7. #7
    Join Date
    Nov 2003
    Location
    svk
    Posts
    10
    Okay thank you.

  8. #8
    Join Date
    Sep 2002
    Posts
    1,747
    Or you can stick around over here at codeguru. There is a reason we have a graphics programming forum in the first place...

    Unfortunately, however, sorting is the correct way to do things. Alpha blending uses the already drawn pixels as an integral part of the calculation. Sometimes, simply turning off the depth buffer with glDisable(GL_DEPTH_TEST) (or not turning it on in the first place) can provide a quick hack to at least get around any other pixel modifications due to depth and provide a "flatter" basis for alpha blending, but it doesn't get around the initial mathematical problem.

    A nice way that I have begun using is to build a depth digraph of your objects. Basically every vertex is an object, and there is a directed edge going from one object to another the former is in front of the latter. The reason I store this graph is because it gives a nice place to store the drawing information for objects, and it has the benefit of being very easy to update as the camera or objects move (since often all that happens is that edges are added or deleted or vertices switch positions, which are both very fast calculations even if your scene is large).
    */*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/

    "It's hard to believe in something you don't understand." -- the sidhi X-files episode

    galathaea: prankster, fablist, magician, liar

  9. #9
    Join Date
    Nov 2003
    Location
    svk
    Posts
    10
    turning off depth filter ... hmm i think it wont help.
    Imagine: i have one opaque polygon, closer to me is one transparent and on top of it closer to me is another opaque. If i turn off depth sorting, then
    a) transparent polygon is drawn on top of both
    b) or furthest polygon will be drawn on top of transparent one
    aint that true ?

    I now thought of doing it like this:
    i calculate center coords of polygons. Then every time camera move i recalculate distance between polys and camera, and sort it. That should do it. (And i should do it for transparent polygons only, and draw them after opaque polygons, with depth sorting on)
    Would it work ? Im going to try it out.

  10. #10
    Join Date
    Sep 2002
    Posts
    1,747
    Yeah, the depth filter things doesn't do much useful unless your alphas are all in a limited middle range where there is much less of a difference between alpha orderings. Once you have very opaque or very transparent objects in the scene, the artifacts will be more obvious.

    The way you mention should work fine. I think its the way its usually done. The only thing to look out for is that you want to make sure your distance and sorting algorithms are fast, or you may have scanning difficulties if the camera needs to move really fast in a scene with many alphas or at the least it will affect your refresh rate. But most machines can handle a simple sort each draw without any problem (since there can be much more complicated things it needs to calculate anyways), and usually there are not that many transparent objects in the scene anyway.
    */*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/

    "It's hard to believe in something you don't understand." -- the sidhi X-files episode

    galathaea: prankster, fablist, magician, liar

Posting Permissions

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


Windows Mobile Development Center


Click Here to Expand Forum to Full Width

This is a CodeGuru survey question.


Featured


HTML5 Development Center