Hi Ken,<br><br>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.<br>
<br>Well, I'm again getting too deep into the details so I should stop after adding in well more than my 2 cents worth :)<br><br>Andy<br><br><div class="gmail_quote">On Thu, Mar 21, 2013 at 10:33 AM, Moreland, Kenneth <span dir="ltr"><<a href="mailto:kmorel@sandia.gov" target="_blank">kmorel@sandia.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word">
<div>
<div>
<div>Andy,</div>
</div>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>-Ken</div>
<div><br>
</div>
<span>
<div style="border-right:medium none;padding-right:0in;padding-left:0in;padding-top:3pt;text-align:left;font-size:11pt;border-bottom:medium none;font-family:Calibri;border-top:#b5c4df 1pt solid;padding-bottom:0in;border-left:medium none">
<span style="font-weight:bold">From: </span>Andy Bauer <<a href="mailto:andy.bauer@kitware.com" target="_blank">andy.bauer@kitware.com</a>><br>
<span style="font-weight:bold">Date: </span>Thursday, March 21, 2013 7:20 AM<br>
<span style="font-weight:bold">To: </span>David Lonie <<a href="mailto:david.lonie@kitware.com" target="_blank">david.lonie@kitware.com</a>><br>
<span style="font-weight:bold">Cc: </span>VTK Developers <<a href="mailto:vtk-developers@vtk.org" target="_blank">vtk-developers@vtk.org</a>><br>
<span style="font-weight:bold">Subject: </span>[EXTERNAL] Re: [vtk-developers] vtkCellArray memory layout<br>
</div><div><div class="h5">
<div><br>
</div>
<blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5">
<div>
<div>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.<br>
<br>
Andy<br>
<br>
<div class="gmail_quote">On Thu, Mar 21, 2013 at 8:40 AM, David Lonie <span dir="ltr">
<<a href="mailto:david.lonie@kitware.com" target="_blank">david.lonie@kitware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>On Wed, Mar 20, 2013 at 7:12 PM, Bill Lorensen <span dir="ltr"><<a href="mailto:bill.lorensen@gmail.com" target="_blank">bill.lorensen@gmail.com</a>></span> wrote:<br>
</div>
<div class="gmail_extra">
<div class="gmail_quote">
<div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
A backward compatible approach might use an additional offset array into the existing cell ids array.<br>
</blockquote>
<div><br>
</div>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Dave</div>
</div>
</div>
</div>
<br>
_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">
http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.vtk.org/mailman/listinfo/vtk-developers" target="_blank">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br>
<br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div></div></span>
</div>
</blockquote></div><br>