Use real-time GPU isosurface rendering for in Isodose module

[cpinter]

In addition to generating model nodes for the isosurfaces (which results in model hierarchies that are hard to keep in sync and hard to handle when multiple dose volumes are present), add support for GPU-based isosurface rendering. See Kitware blog post https://blog.kitware.com/gpu-rendering-of-isosurfaces/

• This should be the default way of showing isodose in 3D
• Explore whether this can be used for 2D
• Current method needs to be kept, in order to allow exporting of isodose surfaces

Related tickets: https://github.com/SlicerRt/SlicerRT/issues/18 https://github.com/SlicerRt/SlicerRT/issues/8

[MichaelColonel]

I'm going to add support for GPU isosurface volume rendering for 3D view as a part of VTK practice. According to VTK example it shouldn't be very hard.

A couple of questions beforehand:

1. Should i register a new mapper for volume rendering as it described in docs?
2. Should i create a derived display node from vtkMRMLGPUVolumeRayCastRenderingDisplayNode or i can use that display node class directly?

[lassoan]

As an experiment, you can just put the volume rendering actor and mapper directly in the VTK renderer (see helpful code snippets here).

The most important thing to try if it works well with multi-volume rendering (if you use a separate volume raycast mapper for each volume then they are not composited correctly). It would be completely useless if we could only render a single volume at a time.

In addition to this, you also need to test if point picking works on these surfaces (can you place a markup fiducial on the rendered surface?).

Even if everything works well, you would still need a solution for slice display. You would also need to implement non-linear transform support for volume rendering. Volume rendered surfaces cannot benefit from advanced physical based rendering options, screen-space ambient occlusion, surface textures and shaders.

Overall, it seems that using volume renderer for displaying isosurfaces would require lots of programming effort and you would end up with a solution that is much more limited in several aspects compared to what we have now. Probably there are other things that you could work on that have much better cost/benefit ratio.

[lassoan]

To solve the original problem of having many nodes in the scene, a much better solution could be to show isodose surfaces and lines using a single segmentation node.

[MichaelColonel]

Maybe you are right, it doesn't worth the effort.

To solve the original problem of having many nodes in the scene, a much better solution could be to show isodose surfaces and lines using a single segmentation node.

I can add a check box on the module panel to select if the isodose surfaces should be stored as a segmentation node.

[cpinter]

I like the idea of putting the isodose surfaces into a single segmentation node. In that case the key thing will be to make the master representation closed surface to avoid unnecessary and unexpected conversions.