[vtk-developers] revision of rendering process

Wed Jun 27 11:15:33 EDT 2001

Please give us plenty of notice before you check in anything. The past two weeks have been painful
with all the vtkIdType changes. Especially since it seems that it can't be done all at once (for some
reason). We try to keep GEVTK up-to-date every day. It's just too large to try to integrate after a
longer period of time.

Bill

-----Original Message-----
From: Lisa S. Avila [mailto:lisa.avila at kitware.com]
Sent: Wednesday, June 27, 2001 11:06 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,

I will be making these changes in two steps - first, I will move over the 
vtkVolumeRayCastMapper to the new way of using RenderTranslucentGeometry(). 
I will send a note out telling everyone this is done. Then you (and anyone 
else who needs to) can modify your mappers. Once all mappers are using the 
new rendering process, the two old stages will be removed.

I know you have mappers that use RenderIntoImage - these should be fairly 
simple to convert. Right now the process is

1) vtkRayCaster calls RenderIntoImage() on the prop that has a 
RenderIntoImage type of mapper

2) vtkRayCaster calls GetRGBAImage() on that prop

3) vtkRayCaster combines this image with all other images and puts the 
results up on the screen

The new process would be:

1) vtkRenderer calls RenderTranslucentGeometry() on all props. Your prop 
would do what it used to do in RenderIntoImage(). Then your prop will map 
itself to the screen (take the image produced and render it as a texture 
mapped polygon either directly (using OpenGL) or by creating an image actor 
or a plane with a texture map and rendering it)

If you have mappers that used the ray casting portion of the pipeline it is 
a bit more effort to move them to the new way. Probably the easiest thing 
to do will be to subclass off of vtkRayCastMapper (if you haven't already).

Lisa

At 10:19 AM 6/27/2001, Lorensen, William E (CRD) wrote:
>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
>
>_______________________________________________
>vtk-developers mailing list
>vtk-developers at public.kitware.com
>http://public.kitware.com/mailman/listinfo/vtk-developers