[vtk-developers] revision of rendering process

[Lorensen, William E (CRD)]

I believe we have classes in gevtk that may be affected. Could you post the proposed API?

Bill

-----Original Message-----
From: Lisa S. Avila [mailto:lisa.avila at kitware.com]
Sent: Wednesday, June 27, 2001 9:41 AM
To: Lorensen, William E (CRD); 'Lisa S. Avila';
vtk-developers at public.kitware.com
Subject: RE: [vtk-developers] revision of rendering process


Hello Bill,

My changes don't really affect the geometric rendering portion of the 
rendering process and therefore I think the work done to improve that can 
be kept separate from this work. I will not be making any changes to 
RenderOpaqueGeoemtry(), RenderTranslucentGeometry(), or RenderOverlay(). I 
will be making only minor changes to vtkRenderer (pulling out the helper 
class vtkRayCaster and removing any ray cast or render-into-image specific 
code). The bulk of the change will occur in vtkRayCastMapper which will 
obtain the functionality currently present in vtkRayCaster. Mappers of this 
type will respond to the RenderTranslucentGeometry() call, and will render 
the image they generate as a texture mapped polygon through the center of 
the volume (similar to how the VolumePro mapper works now, and not too far 
off from the vtkVolumeTextureMapper2D).


Let me know if you'd like more details or have any questions.


Lisa





At 07:22 AM 6/27/2001, Lorensen, William E (CRD) wrote:
>Perhaps this is a time to address performance issues in the rendering 
>process. Also, I think the vtk
>developers should be involed in some sort of a review process of this 
>significant change.
>
>Bill
>
>-----Original Message-----
>From: Lisa S. Avila [mailto:lisa.avila at kitware.com]
>Sent: Tuesday, June 26, 2001 5:40 PM
>To: vtk-developers at public.kitware.com
>Subject: [vtk-developers] revision of rendering process
>
>
>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
>
>
>_______________________________________________
>vtk-developers mailing list
>vtk-developers at public.kitware.com
>http://public.kitware.com/mailman/listinfo/vtk-developers
>
>_______________________________________________
>vtk-developers mailing list
>vtk-developers at public.kitware.com
>http://public.kitware.com/mailman/listinfo/vtk-developers