Mutliple depth-buffer render passes

Development
1

Hi all (but esp @ken-martin ), we have some multiscale data we’re rendering that runs into problems with depth-buffer precision; we can’t fit the frustum to the entire dataset’s bounds without severe z-fighting due to a lack of depth-buffer resolution.

Our idea is to adapt this multi-frustum rendering scheme to VTK’s renderer. The idea is to render the scene with the frustum far away, then reset the depth buffer and re-render with the frustum closer – repeating the process a number of times dependent on the size of the scene bounds. This would be implemented as a new vtkRenderPass subclass (say vtkDepthFrustumPass). I assume the vtkDepthFrustumPass::Render() method would internally re-render some other pass once for each set of hither/yon planes?

Does anyone have suggestions on how to do this? Specifically, my concerns are

  1. I’m not sure how to arrange it relative to existing render passes, especially depth peeling. If we use depth peeling internal to each depth-frustum render, it looks like we should change vtkOpenGLRenderer's DeviceRenderTranslucentPolygonalGeometry() method to use vtkDepthFrustumPass instead of the depth-peeling pass it currently uses as the outer layer?

  2. How could our new render-pass cull different props for each pass (based on whether the prop bounds overlap the current depth-range being rendered)?

2

Your idea sounds fine and a render pass should be able to do that pretty easily.

Take a look at TestFramebufferPass to see how you can do depth peeling as a pass. You could use that example and just yank the framebuffer pass part of it. As long as you nest the right passes in the right order it should be fine. e.g. your frustum pass would be at the top like “fop” is in the test I referenced.

One issue we have is that a few passes have been built-into the renderer. Which doesn’t always play nice with the more general render pass approach. In the long run we should have the renderer always use passes. So while if you set this all up correctly it should work fine, someone turning passes on directly on the renderer would break it. (the solution being make rendering always use a pass and then those options just change the pass setup)