[vtk-developers] revision of rendering process
Lisa S. Avila
lisa.avila at kitware.com
Tue Jun 26 17:39:48 EDT 2001
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
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
- 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
- We give up the future ability to render overlapping volumes (without
merging them prior to rendering) and to cast secondary (shadow, reflection,
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.
More information about the vtk-developers