<div dir="ltr">On Thu, Mar 21, 2013 at 10:20 AM, Andy Bauer <span dir="ltr"><<a href="mailto:andy.bauer@kitware.com" target="_blank">andy.bauer@kitware.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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:<br>


<br>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.<br><br>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.<br>


<br>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.</blockquote>

<div><br></div><div style>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.</div>

<div style><br></div><div style>The vtkCellArray issues will likely have to wait until another project comes along...</div><div style><br></div><div style>Dave</div></div></div></div>