[vtk-developers] vtkCellArray memory layout

[Andy Bauer]

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.

Andy

On Thu, Mar 21, 2013 at 8:40 AM, David Lonie <david.lonie at kitware.com>wrote:

> On Wed, Mar 20, 2013 at 7:12 PM, Bill Lorensen <bill.lorensen at gmail.com>wrote:
>
>>  A backward compatible approach might use an additional offset array into
>> the existing cell ids array.
>>
>
> Backwards compatibility is definitely the biggest obstacle to a change
> like this. This approach would lose some of the nice features we've
> discussed like super-fast VBO creation, but would be a step in the
> direction of allowing a cellId-based random-access API, which is more
> important for my needs at the moment. However, the memory overhead of
> duplicating the cell size information may be unacceptable in some cases.
>
> The other approach Berk proposed is to introduce an abstract class above
> vtkCellArray that only uses sequential access via GetNextCell, etc, and
> rewrite only selected filters to use this API, since coprocessing adapters
> should be able to handle sequential access without much trouble. (As I
> mentioned earlier in my reply to Will, The real thorn in my side for this
> project is the array-index random access methods). This would certainly be
> easier, and leave a major rewrite/redesign for a later project, perhaps one
> that has the resources to update VTK away from the fixed-pipeline GL
> approach.
>
> Dave
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtk-developers
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20130321/2e74fdf9/attachment.html>