[vtk-developers] transparent foreground polygons occluding background geometry

[David Lonie]

Just want to point out that I'm currently rewriting the depth peeling
algorithm to use dual depth peeling. At the moment, my unoptimized
implementation is getting roughly 25% better performance over the standard
depth peeling, though the shader code is a bit more complex and requires
implementing three passes (Initialize dual depth buffer -> multiple peeling
renders -> alpha blend remaining fragments).

This isn't in master yet, but the current polydata shader code is here:
https://gitlab.kitware.com/dlonie/vtk/blob/dual_depth_peels/Rendering/OpenGL2/vtkOpenGLPolyDataMapper.cxx#L990

Current branch is in testing here:
https://gitlab.kitware.com/vtk/vtk/merge_requests/1357

I'm currently planning to make the DDP algorithm optional and leave the
existing depth peeling implementation around while it stabilizes, so
ideally there would be no immediate need to update your shader code when it
lands.

HTH,
Dave

On Thu, Mar 24, 2016 at 8:26 AM, Ken Martin <ken.martin at kitware.com> wrote:

> Your custom shader has to be written to work with depth peeling. When in a
> depth peeling pass it needs to do some texture lookups and discard
> fragments based on those lookups. I've included the general gist below. I
> use string replacements to handle it but you are free to use other
> approaches as long as the end result in a depth peeling pass has something
> like the following in it.
>
> Thanks
> Ken
>
>   // are we using depth peeling?
>   vtkInformation *info = actor->GetPropertyKeys();
>   if (info && info->Has(vtkDepthPeelingPass::OpaqueZTextureUnit()))
>     {
>     vtkShaderProgram::Substitute(FSSource, "//VTK::DepthPeeling::Dec",
>       "uniform vec2 screenSize;\n"
>       "uniform sampler2D opaqueZTexture;\n"
>       "uniform sampler2D translucentZTexture;\n");
>     // the .0000001 below is an epsilon.  It turns out that
>     // graphics cards can render the same polygon two times
>     // in a row with different z values. I suspect it has to
>     // do with how rasterization of the polygon is broken up.
>     // A different breakup across fragment shaders can result in
>     // very slightly different z values for some of the pixels.
>     // The end result is that with depth peeling, you can end up
>     // counting/accumulating pixels of the same surface twice
>     // simply due to this randomness in z values. So we introduce
>     // an epsilon into the transparent test to require some
>     // minimal z separation between pixels
>     vtkShaderProgram::Substitute(FSSource, "//VTK::DepthPeeling::Impl",
>       "float odepth = texture2D(opaqueZTexture,
> gl_FragCoord.xy/screenSize).r;\n"
>       "  if (gl_FragCoord.z >= odepth) { discard; }\n"
>       "  float tdepth = texture2D(translucentZTexture,
> gl_FragCoord.xy/screenSize).r;\n"
>       "  if (gl_FragCoord.z <= tdepth + .0000001) { discard; }\n"
>
>
>
>
> On Wed, Mar 23, 2016 at 7:08 PM, Brad Hollister <behollis at sci.utah.edu>
> wrote:
>
>> Hi,
>>
>> We have a problem with transparent foreground polys occluding geometry.
>>
>> We're trying to use depth peeling to handle foreground polygons with
>> transparency. However, while depth peeling is enabled,
>> GetLastRenderingUsedDepthPeeling() returns false.
>>
>> (The polygons also intersect other similar polygons so that some parts of
>> them are in front of others, while other parts of the same poly may be
>> behind others. Another reason to use depth peeling as opposed to depth
>> sorting, in our opinion.)
>>
>> We also require custom shaders, using
>> vtkOpenGLPolyDataMapper::SetVertexShader(), etc. From the test code @
>> http://www.vtk.org/gitweb?p=VTK.git;a=blob;f=Rendering/OpenGL2/Testing/Cxx/TestUserShader2.cxx,
>> it looks as though custom shaders can't be used with depth peeling in VTK.
>>
>> Thus, is there another way to enable depth peeling or to have transparent
>> foreground polys in our usage scenario?
>>
>> Regards,
>> Brad
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>
>>
>
>
> --
> Ken Martin PhD
> Chairman & CFO
> Kitware Inc.
> 28 Corporate Drive
> Clifton Park NY 12065
> 518 371 3971
>
> This communication, including all attachments, contains confidential and
> legally privileged information, and it is intended only for the use of the
> addressee.  Access to this email by anyone else is unauthorized. If you are
> not the intended recipient, any disclosure, copying, distribution or any
> action taken in reliance on it is prohibited and may be unlawful. If you
> received this communication in error please notify us immediately and
> destroy the original message.  Thank you.
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160324/e1555207/attachment.html>