[vtkusers] Cell data in a vtkPolyData object

[Clinton Stimpson]

Ok, there was more to it than I thought.  Thanks for the warning.
Thanks,
Clint

Sander Niemeijer wrote:

> Yes I have tried this.
>
> If you do this when you've added your mixed typed cells in random 
> order you will end up with a reordered list of cells. And if you add 
> your cells in the appropriate order (vertex/line/poly/strip) then a 
> BuildCells() will have no apparent effect.
>
> If you look at the implementation of the vtkPolyData class you will 
> see that vtkPolyData::InsertNextCell() performs the same 
> this->Cells->InsertNextCell() calls that vtkPolyData::BuildCells() 
> uses. So as long as you call your vtkPolyData::InsertNextCell() in the 
> right order you will do the same as vtkPolyData::BuildCells().
>
> Just for clarification, let me restate the problems I'm having:
>
> 1) Adding mixed typed cells in random order to a vtkPolyData object 
> can have all kinds of nasty side effects because the ordering of cells 
> can be changed while scalar data that you associate with these cells 
> doesn't get reordered! According to John this is known behavior, but 
> the fact that this kind of behavior is not documented anywhere, makes 
> this a bug in my opinion (either the class documentation should make 
> this behavior explicit, or the vtkPolyData class should allow adding 
> cells in a mixed ordering and KEEP that ordering).
>
> 2) Even if you add cells in the right order to a vtkPolyData object 
> you will still get problems when you use a scalar color lookup table 
> with a vtkPolyDataMapper2D (see my other e-mail in this thread). As 
> far as I can see this is due to the vtkOpenGLPolyDataMapper2D class 
> handling the cell types in a different order. If this is indeed the 
> case then even VTK internally does not keep to this fixed ordering of 
> cell types in the vtkPolyData object.
>
> So as far as I can see, there IS a problem. And given the complexity, 
> I think it will take quite some time before we can see this problem 
> fixed properly. The easiest solution now would probably be to 'fix' 
> the vtkOpenGLPolyDataMapper2D class and to add the behavior about the 
> ordering to the vtkPolyData class documentation.
>
> Best regards,
> Sander
>
> On vrijdag, aug 27, 2004, at 14:42 Europe/Amsterdam, Clinton Stimpson 
> wrote:
>
>>
>> Did you ever try calling vtkPolyData::BuildCells() after you modify the
>> cells in the vtkCellArray's that a vtkPolyData references?
>>
>> Clint
>
>
>