[vtk-developers] revision of rendering process

[Lisa S. Avila]

Hello,

In the next month or two I plan to revise the VTK rendering process. A 
brief description follows. I would appreciate hearing about any comments, 
questions, concerns you may have.

What I plan to do:

Remove two parts of our five part rendering process: ray casting and render 
into image. The functionality handled by these passes of the rendering 
process will now need to be handled in the individual mappers.

Why it is the way it is:

Back several years VTK was revised to add the five pass rendering process. 
One of the goals was to provide ray casting of multiple overlapping volumes 
with possible secondary rays (that is why the ray cast pass was added). 
Support was also required for the previously existing methods (that is why 
the render into image pass was added). Some other goals included providing 
better translucent rendering (which is why polygonal rendering was divided 
into to passes) and better annotation support (which is why the overlay 
pass was added).

The pros of the change:

- The rendering process will become simpler.
- The volume ray cast mapper will be able to provide low resolution ray 
casting while geometry is still rendered at full resolution.
- The rendering of each volume (when more that one exists) can be adjusted 
independently to achieve a desired frame rate.
- The speed of ray casting should improve by a small amount (some ray 
transformations that were broken into two steps can now be combined back 
into one)

The cons of the change:

- There will be some API changes (since the ray caster will be gone - all 
calls that were made to this class will have to be made to the individual 
mappers).
- Anyone with a mapper that uses ray casting or render into image but is 
not part of the public VTK will have to change their mapper to the new 
methodology.
- We give up the future ability to render overlapping volumes (without 
merging them prior to rendering) and to cast secondary (shadow, reflection, 
etc.) rays.


I think the potential features we give up are of less value than the 
simplification of the VTK render process (especially since I do not think 
we will ever implement these features). Also, the API changes should be 
minimally invasive - for example I do not think any of our tcl scripts 
would need to change.


Lisa