2
\$\begingroup\$

Is there a way to use something similar to PolygonOffset to make a depth test more permissive (move fragment depth towards eye) but still write the original depth value to the depth buffer? The only thing I can come up with is a tricky two pass solution using a stencil buffer, but I'd like to avoid that if possible.

Context of my question: We have an entity with a particle based smoke plume that is often in front of a semi-transparent building. Do to some constraints with batching, the building gets drawn after the smoke plume. Originally the smoke plume particles were rendered with a depth test but no depth write. This caused the building to be drawn on top of the smoke.

Turning the depth write on for the smoke particles fixes the building, but now the smoke particles interfere with each other. Ideally, I'd like to find a way for them to stop interfering while still writing to the depth buffer.

\$\endgroup\$
2
  • \$\begingroup\$ Did you take a look at glDepthFunc? opengl.org/sdk/docs/man/docbook4/xhtml/glDepthFunc.xml \$\endgroup\$
    – glampert
    Commented May 15, 2014 at 18:22
  • \$\begingroup\$ If you "lie" with the depth testing, you'll eventually get some other undesirable artifact, where the smoke appears in front of something it should be behind. I think you should revisit how to draw the smoke last... \$\endgroup\$ Commented Feb 10, 2015 at 5:45

1 Answer 1

1
\$\begingroup\$

I think you may be interested in glDepthRange (...). That affects the mapping from NDC [-1.0,1.0] to window-space Z (the depth buffer stores window-space Z) during the viewport transformation. Effectively the nearplane becomes nearVal and the farplane becomes farVal. You can fool with this to bias and/or rescale your assigned depth values, but GL clamps these values to [0.0,1.0].

Since all testing is done in window-space, you can simply modify the mapping between passes to make depth tests more "permissive." If you are clever, you can even reverse the mapping and the direction of the test to alter precision distribution.

\$\endgroup\$
6
  • \$\begingroup\$ Thanks for the response! Unfortunately, I think this will still write the biased window-space Z value to the depth buffer, instead of the original value. This might be useful if I was drawing the smoke particles individually (I could call glDepthRange after each particle to sequentially push the near plane forward), but they're currently being rendered with one draw command. \$\endgroup\$
    – Shadow503
    Commented May 16, 2014 at 13:39
  • \$\begingroup\$ @Shadow503 Ah, I think I misunderstood what you were trying to do originally. I thought you just wanted to draw the smoke always in front of the building, but with depth testing between particles. That could have been solved by dividing the scene into two discrete depth ranges. May I ask what hardware you are targeting? There is a GL4 era feature called conservative depth that will allow you to test using the original depth, but write a different one. I know that is the reverse of what you want, but I think you can tweak some things to make it useful. \$\endgroup\$ Commented May 16, 2014 at 16:39
  • \$\begingroup\$ That sounds like exactly what I'm looking for; I'll check it out! \$\endgroup\$
    – Shadow503
    Commented May 16, 2014 at 16:52
  • \$\begingroup\$ I've been trying to use ARB_conservative_depth extension. I managed to get it running but I found that the early z test doesn't appear to be happening. Is it possible alpha blending is preventing early z from occurring? \$\endgroup\$
    – Shadow503
    Commented May 19, 2014 at 18:47
  • \$\begingroup\$ Alpha blending will not prevent it from working, alpha testing on the other hand will. That is to say, if you use discard in your fragment shader. You may need to add layout(early_fragment_tests) in; to the beginning of your fragment shader to force this behavior. That said, if you are using alpha blending then you already have a pretty strict required draw order, I am not sure why you want to write to the depth buffer at all in this situation? \$\endgroup\$ Commented May 19, 2014 at 18:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .