[vtk-developers] vtkCellArray memory layout
David Lonie
david.lonie at kitware.com
Thu Mar 21 10:29:35 EDT 2013
On Thu, Mar 21, 2013 at 10:20 AM, Andy Bauer <andy.bauer at kitware.com> wrote:
> The track that you're on with creating an abstract class above
> vtkCellArray is the first approach I would take on this. That said, I'm not
> sure it's the best but I haven't thought of anything better yet either.
> I've been thinking about this as well with going through the data
> structures for the Catalyst Users Guide I'm working on. A couple of points
> I think are worth mentioning:
>
> 1) These changes would typically be used in sources only unless they were
> shallow copied in subsequent filters that don't modify the grid topology.
>
> 2) I would think that only changing the way vtkUnstructuredGrid stores the
> cell topology would be sufficient for co-processing/Catalyst. I don't see a
> lot of people that are going to want this functionality for vtkPolyData in
> their sources. This probably avoids most of the vtkPolyData + VBO creation.
> Additionally, we're considering turning on immediate mode rendering by
> default for Catalyst generated scripts due to running on memory limited
> machines, possibly with no disk cache, which means that display lists won't
> be generated. The reason for this is that memory segmentation can cause
> problems on these HPC machines.
>
> 3) I also think that while looking at this it would be nice to review the
> Allocate() implementations for polydata and unstructured grids. For a known
> amount of cells, I think these always under-allocate the space needed to
> store the grid topology information in vtkCellArrays, even if all of the
> cell types are single vertices.
Thanks for the input, Andy. Berk and I discussed the problem this morning,
and we're thinking about something similar to your second point,
introducing a new DataSet that is similar to vtkUnstructuredGrid, but with
a generic cell API (no pointer access, cell based random access, etc).
Rather than trying to make the simulation code's cell data fit into the
vtkCellArray API, we'll just abstract cell access at the DataSet level and
tweak the filters we're interested in to work with the new class.
The vtkCellArray issues will likely have to wait until another project
comes along...
Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20130321/8a89440f/attachment.html>
More information about the vtk-developers
mailing list