User talk:Dcthomp

I've been a little con-fused and a-mazed about why vtkAlgorithm::ProcessRequest passes input information as an array of pointers but output information as a single pointer... I finally took it upon myself to dig through the source and find out: input ports may have more than one connection while output ports may not. So, the input information is passed as an array of array of vtkInformationVector objects -- the first index specifies the input port number, the second index the connection number. This is because input ports may be marked as INPUT_IS_REPEATABLE so that many connections may be made to a port and each port may have some specific purpose. For instance, a filter like vtkGlyph3D[1] may wish to allow multiple input point sets to be glyphed (input port 0) but only allow a single glyph object (input port 1). Thus it is easy to group all of the objects that will serve the same function under one port.

My problem is that things are not the same for the ouput side. For instance, a reader may handle files that contain multiple datasets and wish to segregate the output objects by their data type or time step or some other index. This isn't impossible with the current setup, but it's not symmetric with the input mechanism. That lack of symmetry means more code in each application that hooks the reader up to different downstream inputs, even if the input ports are segregated in the same fashion as the reader outputs. Anyone care to comment on why this decision was made?

--Dcthomp 14:19, 29 Dec 2004 (EST)

I was looking at vtkGlyph3D and it appears that since the pipeline changes, there is now an unused member: Sources (of type vtkPolyData**). Is this correct? Also, vtkCellCenters::RequestData() doesn't appear to use the vtkDemandDrivenPipeline::DATA_NOT_GENERATED() key when the output will be empty. Is that because the key should only be used while update extents are being computed and not during the actual filter execution? Or is it just an oversight?

--Dcthomp 14:19, 29 Dec 2004 (EST)