Talk:Pipeline IDs

I want to summarize what we have first: The current VTK architecture allows for arbitrary attributes that are associated with either points or cells. These attributes can be of any finite precision, numeric type as well as strings (limited support, only first pass). Filters have the choice of either passing, copying or interpolating these attributes to their output. Usually, a filter copies or interpolates all attributes at once. It has the option of turning off the copy of one or more attributes. A filter does this when it wants to override or remove an attribute. The problems with global ids arise from the fact that they are always copied. There are very few filters that know what global ids mean and all others either copy or interpolate the global ids like all other attributes.

I think ids should continue to be attributes. This way, they can be colored by, filtered etc. It looks like what we need is the capability of associating some description of what an attribute is. We currently have six hard coded descriptions: scalars, vectors, normals, tensors, texture coordinates, other. In the past, these were very important because they were the only ways to tell filters what to process. Their meaning have lessened since the support for multiple attributes and SetInputArrayToProces() have been added. Now we can tell (certain) filters which array to process by name. However, all other attributes are still copied or interpolated by default. It looks like we need a way of telling filters that some attributes should only be copied in certain cases and interpolated in others. For example, interpolating ids rarely makes sense. Copying of some ids may be OK as long as they are not duplicated.

Another issue is the fact that ids may end up using a lot of memory unnecessarily. For example, if the source of an id is a block, the same id is associated with many points. In this case, it may make sense to use a run-length encoded array as opposed to the current, linear arrays we have. The rearchitecture of data arrays due to the addition of string arrays makes this easier but does not fully address it.

I want to mention here that ids are not always necessary. For example, instead of using ids to mark which part a polygon comes from, we can use multiblock and hierarchical datasets. When one of these is used, the pipeline keeps track of separate blocks throughout and at any point we can tell what block a polygon belongs to relatively easily (it might not be as fast as getting an attribute but it still is very fast).

Berk 16:30, 11 Jan 2006 (EST)

I've added a few lines to the article yesterday that I think clarify what IDs are and how they should be processed.

I am experimenting now with dealing with the IDs at the DataSetAtributes level, ie adding another attribute type SCALARS,VECTORS,...,IDS, and controlling the copying and interpolation of ID arrays there. One potential problem with this approach is that we can only designate one array for the PointData and one array in the CellData as "The" ID array.

DeMarle 11:40, 24 Feb 2006 (EST)