[vtk-developers] vtkCellArray memory layout

Thu Mar 21 11:50:44 EDT 2013

+1

David is investigating various options of creating a new unstructured grid
dataset subclass. This is one option he is going to look at.

-berk

On Thu, Mar 21, 2013 at 10:51 AM, Andy Bauer <andy.bauer at kitware.com> wrote:

> Hi Ken,
>
> Besides the cell array, Types (vtkUnsignedCharArray), Locations
> (vtkIdTypeArray), Faces (vtkIdTypeArray), FaceLocations (vtkIdTypeArray),
> and possibly Links (vtkCellLinks) should all be considered as related data
> structures for storing and accessing cell connectivity for doing the
> changes that Dave is working on. Not having to worry about the 4 cell
> arrays in polydata and other data structures for random access to the cells
> should limit the scope of his changes. My initial approach would be along
> the lines of having all of the above arrays are stuck in a single container
> class that mirrors the cell API of vtkUnstructuredGrid. Then these
> functions could be delegated to the "cell container" class, hoping that the
> extra level of indirection isn't a major performance hit.
>
> Well, I'm again getting too deep into the details so I should stop after
> adding in well more than my 2 cents worth :)
>
> Andy
>
>
> On Thu, Mar 21, 2013 at 10:33 AM, Moreland, Kenneth <kmorel at sandia.gov>wrote:
>
>>   Andy,
>>
>>  I like your observation that Catalyst users will probably not need to
>> create poly data, so not having abstract classes for that particular data
>> set are OK.  I agree with that assessment.  However, both vtkPolyData and
>> vtkUnstructuredGrid use the same vtkCellArray to store cell indices, so I'm
>> not sure how much that observation helps with the design decisions.  Unless
>> you want to change the interface for vtkUnstructuredGrid to use something
>> other than vtkCellArray, which would also change backward compatibility in
>> a way that is probably more disruptive that the vtkCellArray interface
>> changes David proposes.
>>
>>  -Ken
>>
>>   From: Andy Bauer <andy.bauer at kitware.com>
>> Date: Thursday, March 21, 2013 7:20 AM
>> To: David Lonie <david.lonie at kitware.com>
>> Cc: VTK Developers <vtk-developers at vtk.org>
>> Subject: [EXTERNAL] Re: [vtk-developers] vtkCellArray memory layout
>>
>>   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
>>>
>>>
>>>
>>
>
> _______________________________________________
> 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/6b054fa5/attachment.html>