lower level of detail (LOD) rendering for Volume representation does not allow opaque surfaces for speed
This issue was created automatically from an original Mantis Issue. Further discussion may take place here.
When rendering a volume representation that takes 0.5 or more seconds to render, the polygonal lower level of detail representation for interaction is highly necessary.
As it is now, the LOD polygonal rendering is done translucently. This has two problems. First, the default configuration of paraview has depth peeling off (I think). Thus the translucent rendering is wrong due to ordering errors. Second, with depth peeling on, multiple render passes are necessary and for some (many?) cases the speed for the translucent polygonal rendering is unacceptable. (Especially compared to similar handling in VTK applications).
The default LOD rendering for the volume should be opaque polygons, not translucent ones. At the very least, there should be a way to set the LOD rendering to opaque, and as of now there isn't a way to do that.
Right now, the class vtkPVLODVolume is apparently responsible (at a reasonably high level) for this level of detail render handling. Digging down, I find that vtkLODProp3D is the class that is responsible for the rendering at various LODs, and, in the case of the volume rendering, the polygonal LOD is being rendering by a vtkOpenGLActor instance.
Essentially, this Actor needs to be forced to use 1.0 opacity or have some way so that the ultimate parent can request 1.0 opacity.
I hacked in a version of vtkLODProp3D.cxx and vtkLODProp3D.h to get the behavior I desire, which I am attaching. Essentially I just added a flag to decide whether to force a particular opacity value (I didn't add a way to set the flag--it's just on by default), and a particular opacity value (defaulted to 1.0) to force if the flag is true. This achieves my desired behavior. However, we need to determine if opaque is the correct default behavior and we probably need a way to let the user choose the opacity level for the LOD presentation. It seems logical to me to tie the LOD opacity to the opacity used when the component is being rendered as a surface. If this would be the case, the prop opacity would need to be set to the corresponding surface presentation opacity on creation, and any change to the surface rendering opacity would need to be copied to the volume LOD opacity. It might also make sense for the volume LOD to simply be the surface representation, rather than having a separate surface representation in the volume management.
(This bug is related to a couple others also having to do with volume LOD presentation)