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