[vtk-developers] equivalent to vtkImageReader2 for polydata

[Michel Audette]

Dear fellow VTK developers,

enclosed below is a snipet of an ongoing discussion on the development
of a flexible vtkPolyData reader that is similar to vtkImageReader2,
i.e. open polydata in a variety of file formats, which is needed by a
project of mine. Recent comments were provided by Berk Geveci and Brad
King.

I welcome any comment by fellow developers on how to proceed. The
suggestion by Brad King below appears to be a good roadmap.

In response to Berk, my justification for calling this reader
vtkPolyDataReader2 was based on a notion of backward compatibility,
given that this reader is exactly analogous to vtkImageReader2.

I'm open to calling it vtkFlexiblePolyDataReader or something in that
spirit, but some thought should be given to renaming vtkImageReader2
in a comparable manner, otherwise the naming convention becomes even
more confusing. Moreover, it's been suggested that I also implement
such a reader for vtkUnstructuredGrid, so one option would be to call
all of these vtkXXXReader2 for now, and vtkFlexibleReader at the next
release.

Cheers,

Michel

On Wed, Jan 27, 2010 at 9:30 PM, Berk Geveci <berk.geveci at kitware.com> wrote:
> First, do not call the darn thing vtkPolyDataReader2. Whoever came up
> with the name vtkImageReader2 should be ashamed of himself or herself.
> Use something like vtkAbstractPolyDataReader or vtkPolyDataReaderBase.
>
> Another thing: why aren't we creating a reader factory for all readers
> in VTK? We don't have to implement it for all readers yet but we could
> at least create a superclass that will eventually be the superclass of
> all readers. It would probably be a sublcass of
> vtkDataObjectAlgorithm. Is there a specific API for polydata readers
> that would make this not work?
>
> Also, I think that it is time to move this to the vtk-developers list.
> This is definitely a discussion to share with the rest of the VTK
> development community. Michel, can you do that please?
>
> Thanks,
> -berk
>
> On Wed, Jan 27, 2010 at 12:39 PM, Brad King <brad.king at kitware.com> wrote:
>> Michel Audette wrote:
>>> regarding this new class vtkPolyDataReader2 that implements a factory,
>>> one question that comes up is how to reconcile the fact that
>>> vtkPolyDataReader (.vtk file format) and the readers for the other
>>> file formats (.stl, etc.) are not derived from the same class.
>> [snip]
>>> my main problem stems from the fact that vtkPolyDataReader (.vtk
>>> files) and the other readers: STL, BYU, OBJ, etc derive from
>>> vtkDataReader and vtkPolyDataAlgorithm respectively
>>> (Why was it done that way?)
>>
>> This is historical.  vtkDataReader predates vtkPolyDataAlgorithm.
>>
>> - vtkDataReader provides common code shared by all .vtk readers
>> - vtkPolyDataAlgorithm provides common code for all polydata processing
>>
>>> Namely, many of the vtk readers that I would like to support derive
>>> from vtkPolyDataAlgorithm, whereas  vtkPolyDataReader derives from
>>> vtkDataReader. Given this information, the plan is to have
>>> vtkPolyDataReader derive from the new vtkPolyDataReader2, just like
>>> vtkImageReader and vtkImageReader2, but the question arises, which of
>>> vtkPolyDataAlgorithm and vtkDataReader should vtkPolyDataReader2
>>> derive from?
>>
>> A new vtkPolyDataReader2 should derive from vtkPolyDataAlgorithm.
>>
>> - The old vtkDataReader hierarchy should not be touched; it's legacy code.
>>
>> - vtkPolyDataReader must continue to derive from vtkDataReader to support
>>  projects that hold poly data readers through vtkDataReader* pointers.
>>
>> - vtkDataReader cannot derive from vtkPolyDataAlgorithm because it reads
>>  formats that are not polydata.
>>
>> Your real goal is to provide an entry in vtkPolyDataReader2's factory
>> that can read .vtk files holding polydata, right?  I suggest creating
>> a vtkLegacyPolyDataReader that derives from vtkPolyDataReader2 and uses
>> an instance of vtkPolyDataReader in its implementation.
>>
>> -Brad
>>
>>
>



-- 
Michel Audette, Ph.D.
R & D Engineer,
Kitware Inc.,
Chapel Hill, N.C.