[vtk-developers] RE: Your checkin
Lorensen, William E (CRD)
lorensen at crd.ge.com
Mon Jan 22 11:12:38 EST 2001
I understand eliminating ImageToStructuredPoints. StructuredPOints is just a shell class.
Why the other changes? Does this mean we have no compatibility path with vtk3.2 and back?
How can I have my own classes work with vtk before last Friday and vtk after that date?
Bill
-----Original Message-----
From: Charles Law [mailto:charles.law at kitware.com]
Sent: Monday, January 22, 2001 11:13 AM
To: Lorensen, William E (CRD)
Cc: vtk-developers at public.kitware.com
Subject: Re: Your checkin
At 04:33 PM 1/19/01 -0500, you wrote:
>I noticed you changed the image api. Will this affect any of our internal
>filters?
>
>Bill
Yes and No.
Elimination of EnlargeOutputUpdateExtent:
I intend to remove the EnlargeOutputUpdateExtent method completely. Right
now it only has a legacy warning around it. This does change some filter
internals. In the future, the Execute() (no parameters) method should be
overridden and it should set its own output extent and allocate it own
scalars (just like graphics). I changed all of the sources in VTK to use
this approach. Take a look at vtkDEMReader for an example.
Elimination of ImageToStructuredPoints:
All filters will have to take vtkImageData instead of
vtkStructuredPoints. This is not a big change because right now structured
points is an empty subclass of vtkImageData. The primary role of
vtkImageToStrucutredPoints was to crop the image if the source returned a
larger extent. This is now vtkImageData's responsibility, and the
consuming filter has to indicate that it wants only the extent
requested. It does this with the method
"vtkDataObject::RequestExactExtentOn()". Since many superclasses do this
for you (i.e. vtkDataSetToDataSetFitler), most filters can ignore this method.
Also, we may want to change all the structured points sources to generate
vtkImageData.
Charles.
More information about the vtk-developers
mailing list