Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>If I understand right, you want to disable depth writes because you draw both opaque and transparent objects. Apart from the fact that it doesn't work that way from within GLSL, it would not produce what you want, if it did.</p> <p>If you just disabled depth writes <em>ad hoc</em>, the opaque objects coming after a transparent object would overwrite it, regardless of the z order.</p> <p>What you really want to do is this:</p> <ol> <li>Enable depth writes and depth test</li> <li>Draw all opaque geometry. If you can, in a roughly sorted (<em>roughly</em> is good enough!) order, closest objects first.</li> <li>Disable depth writes, keep depth test enabled</li> <li>Enable blending</li> <li>Draw transparent objects, sorted in the opposite direction, that is farthest away first. This occludes transparent objects with opaque geometry and makes blending work correctly.</li> </ol> <p>If, for some reason, you can't sort the <em>opaque</em> geometry (though there is really no reason why you can't do that?), never mind -- it will be slightly slower because it does not cull fragments, but it will produce the same image.</p> <p>If, for some reason, you can't sort the <em>transparent</em> geometry, you will have to expect incorrect results where several transparent objects overlap. This may or may not be noticeable (especially if the order is "random", i.e. changes frame by frame, it will be very noticeable -- otherwise you might in fact get away with it although it's incorrect).</p> <p>Note that as datenwolf has pointed out already, the fact that several objects are in one VBO does not mean you can't draw a subset of them, or several subsets in any order you want. After all, a VBO only holds some vertices, it is up to you which groups of them you draw in which order.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. COI don't understand why such a burden is thrown on the client code. It's a thousand times easier to do after the fragment processing automaticaly and would boost performance a lot not involving computations on CPU. I'm geting more and more convinced that OpenGL dont use their brain when writing this more and more stupid standards.
      singulars
    2. CO@lukasz1985: The reason why it's such a burden is that you have a single depth value only. A scene with transparent objects has several depths per fragment where objects overlap, but you can only keep one (the closest-to-eye opaque one). For transparent objects, the Z order in which they're drawn on any given fragment is not well-defined (OpenGL cannot know a priori) but it greatly matters for the outcome. Therefore, you must sort them at application level. Using atomic ops and "fat" buffers, it is possible to do the "thousand times easier" way that you envision, but this has huge demands...
      singulars
    3. CO... both on memory, and bandwidth, and it only runs on very recent hardware, and it is not entirely trivial to do either (see [here](http://developer.download.nvidia.com/SDK/10/direct3d/Source/StencilRoutedKBuffer/doc/StencilRoutedKBuffer.pdf) for an example of such a thing). OpenGL has to take into account hardware that is not top of the line as well, and it still has to work when you don't two-digit gigabytes of video memory available. Hence it unluckily can't be all that evolved.
      singulars
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload