[vtk-developers] vtkPolydata and cell data

John Platt jcplatt at dsl.pipex.com
Wed Mar 19 05:31:55 EDT 2008


Hi Will,

 

It seems that the implicit ordering is enforced by BuildCells(). If you
look at a filter like
vtkDataSetSurfaceFilter::UnstructuredGridExecute(), it takes care to
make the calls

 

            newVerts->InsertNextCell()

newLines->InsertNextCell()

newPolys->InsertNextCell()

 

in the correct order. Setting the verts/lines/polys separately leaves
the internal cell array (vtkPolyData::Cells) null. At some stage in the
future, the null cell array will attract a call to BuildCells(). All is
well with any cell data because the filter has constructed the ouput
polydata in the implicitly assumed order.

 

But suppose a new filter builds it's output polydata using
vtkPolyData::InsertNextCell() instead. The internal cell array
(vtkPolyData::Cells) is updated as different cells are inserted
irrespective of the order. Since the internal cell array is now not
null, BuildCells() will not be called and the cell data ordering is
preserved.

 

It is this last suggestion that I would like clarification on. I must
stress that I have based all the above on code inspection only.

 

Thanks for your time,

 

John.

 

 

 

 

 

-----Original Message-----
From: Will Schroeder [mailto:will.schroeder at kitware.com] 
Sent: 18 March 2008 20:07
To: John Platt
Cc: vtk Developers
Subject: Re: [vtk-developers] vtkPolydata and cell data

 

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/20080319/c0b0771d/attachment-0004.html>


More information about the vtk-developers mailing list