Upcoming changes to vtk3.0

Will Schroeder will.schroeder at kitware.com
Wed Jul 21 09:16:15 EDT 1999


Hi Folks-

Many of you may have deduced that we are preparing to release vtk3.0 in the near future. In preparation for this, we are going to check in some changes that will likely disrupt the nightly builds for the next several days, and will introduce incompatibilities if you have written your own filter(s). (Note: interface to classes has changed little - application developers will likely see no differences.)

Here's a preview of these changes.

Will

-------------

Hi Folks-

This message describes the upcoming changes to VTK3.0. This is a major
release due to incompatible changes at the developer level. Application
developers (which is probably most of you) will see little or no change.


Credits
=======

Most of the work described here was performed by Charles Law at
Kitware. Technical review and assistance was given by Ken Martin at Kitware;
Jim Ahrens at Los Alamos National Lab (parallel methods and system
testing); Mike Papka at Argonne National Lab (streaming in the graphics
pipeline, parallel isosurface, streamlines, and other algorithms); Lisa Avila
at Kitware (multithread support; multithreaded streamlines); and Bill
Lorensen and Jim Miller at GE CRD (technical review and improvements). In
addition, once this work is checked in, Jim & Bill will enforce VTK quality
standards.


Motivation
==========

There were several problems with previous versions of VTK that we addressed:

- The Update() method was not centralized and could be found in several dozen
   different spots in the code base.

- There was no easy way to traverse through the visualization network and
   discover all the inputs and outputs of each filter.

- Reference counting for filters with multiple inputs/outputs was complicated
   and not located in a single code module.

- The image and graphics pipeline architectures and update mechanism were
   quite different, we wanted to unify the system.

In addition, there were several features we wanted to add:

- Streaming support in the graphics pipeline. In the imaging pipeline, data
   is automatically split into pieces based on per filter memory limits, the
   result being that any size data can be processed on any size computer (even
   data larger than virtual address space!)

- In the future, distributed parallel processing (supporting data, pipeline, and
   task parallelism) such as MPI. (The near-term changes described here will 
   position VTK to support MPI; MPI support will not be available until a little later.)


What Changed (Summary)
======================

The application developer (i.e., user of classes) API did not change. We may
try to move the constructor and destructor into the protected section of the
class for the final VTK3.0 release; this will impact you only if you don't
use New() and Delete() to create and destroy objects.

The class developer (i.e., creator of classes) can no longer directly
reference the input and output instance variables in a class. So if you
currently use "this->Input" and "this->Output" inside a filter class, you
must use "this->GetInput()" and "this->GetOutput()" to access this in version
VTK3.0.

We've also modified the Update() mechanism to support asynchronous,
distributed, streaming updates. This will be a transparent change unless you
want to adapt your filter to take advantage of streaming. As part of the
changes to Update(), we also eliminated the vtkImageCache class, and brought
the vtkStructuredPoints and vtkImageData classes closer together. (Note:
additional work will be necessary to flush out this functionality.  For
example, the creation of port filters for asynchronous, distributed
communication, and modifying individual filters for streaming, will be
added.)


Details
=======

Impact on Users:
The application interface has changed very little.
--------------------------------------------------

- GetCache() in image sources has been removed.  GetOutput() is now the only
   option.

- UpdateImageInformation() has been renamed to UpdateInformation().


If you wrote your own filter/source: You will need to ...
-------------------------------------------------------

- The visualization pipeline superclass hierarchy has been reorganized
   significantly.  However the low level filter superclasses
   (vtkDataSetToDataSetFilter) are the same, so the reorganization may not
   affect you.

- The superclasses now manage all inputs and outputs.  All references to the
   instance variables this->Input and this->Output must be changed to access
   through the methods this->GetInput() and this->GetOutput().

- If you wrote a filter with multiple inputs/outputs: you must remove your
   Update() method, and let the super classes manage the references to your
   other inputs (i.e. Glyph->Source).  This entails removing your instance
   variables pointing to the inputs, writing Set/Get methods that access the
   super classes array of inputs/outputs.  The super classes have conviences
   methods to help (i.e. vtkProcessObject::SetInput(int idx, vtkDataObject
   *input);).

- If you wrote an imaging filter, little should change for you.  The imaging
   superclasses still implement the old API. If you reference an image cache
   directly, you can replace this to a direct reference to image data.


Update methods have changed significantly
------------------------------------------
- ExecuteTime removed from vtkSource: UpdateTime added to vtkDataObject.

- MTime vs ExecuteTime check moved from vtkSource, vtkFilter ... to
   vtkDataObject

- DataReleased manipulation and check moved into vtkDataObject.

- ForceUpdate removed

- UpdateInformation method added to graphics

- UpdateImageInformation changed to UpdateInformation in imaging.

- GetPipelineMTime added to graphics (as part of information).

- GetPipelineMTime is now part of information in imaging.	

- Update changed to InternalUpdate

- Information is only computed once in imaging (for Update not InternalUpdate).


Input management has changed
----------------------------
- vtkProcessObject has a list of inputs.

- All vtkDataObject Input ivars have been removed from 
   subclasses of vtkProcessObject.

- Methods added to set and get input in subclasses of vtkProcessObject.
   They map Names (Input/Source ...) to index into input array.

- All References to input Ivars changed to access through methods.
   this->Input   changed to   this->GetInput(). ...

- GetDataSetType() changed to GetDataType and moved to vtkDataObject.

- Old method left in for legacy compatability.


Image and graphics pipeline merged
----------------------------------
- vtkImageCache no longer exists (vtkImageData now connects image filters)

- Graphics pipeline now supports streaming.


  


-----------------------------------------------------------------------------
This is the private VTK discussion list.  Please keep messages on-topic.
Check the FAQ at: <http://www.automatrix.com/cgi-bin/vtkfaq>
To UNSUBSCRIBE, send message body containing "unsubscribe vtkusers" to
<majordomo at gsao.med.ge.com>.  For help, send message body containing
"info vtkusers" to the same address.     Live long and prosper.
-----------------------------------------------------------------------------





More information about the vtkusers mailing list