[vtk-developers] vtkPolydata and cell data

[Will Schroeder]

The problem is this: there is an implicit ordering to the
verts/lines/polys/strips, respectively. So if you insert a bunch of polys,
and then a bunch of verts, you will find that your cell ids are scrambled.
That is, reading back the polydata you just created you will see the verts
appear first, followed by the polys. So the associated attribute data is no
longer consistent, etc.

Bad design, I take a lot of the credit :-) But in 1993 when we were writing
the book on our own time we had no idea where this crazy VTK thing would end
up...

W

On 3/18/08, John Platt <jcplatt at dsl.pipex.com> wrote:
>
>  Hi,
>
>
>
> In Aug 2004 JB wrote on this topic
>
>
>
> It's not so much that that the design of the polydata is bad, (well, it is
>
> really), but you need to know that all filters operate on cells in order of
>
> verts/lines/polys/strips and so all cell data needs to be stored in this
>
> order. Its extremely annoying and everyone who's used vtk for some length of
>
> time will have been bitten by this one - however, once you know about it,
>
> you always write your filters/importers/etc to operate like this and all is
>
> well.
>
>
>
> Could someone please give me a hint as to why? It's not obvious to me because vtkPolyData::InsertNextCell() returns a unique cellId which can be used for the cell scalars.
>
>
>
> Thanks for any help.
>
>
>
> John.
>
>
>
> _______________________________________________
> vtk-developers mailing list
> vtk-developers at vtk.org
> http://www.vtk.org/mailman/listinfo/vtk-developers
>
>


-- 
William J. Schroeder, PhD
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY 12065
will.schroeder at kitware.com
http://www.kitware.com
518-371-3971 (phone and fax)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20080318/547f4e63/attachment.html>