offset understanding

[michaelw]

hi there, I'm still not very sure how Index and Offset works.

With my understanding, if we do this:

 	 duplicateSource(0,context);[/CODE]

the "gdp" should always have the offset continuous at very beginning (matching "index"), and if we delete some points or primitives later, the offset should be the same but the index will be re-ordered to be continuous.

But this is not always the case. Here is one example confusing me for sometime:

drop down a simple "box" SOP and then a "divide" SOP. Use "bricker polygons" option to divide it into a little more dense grid. In my case, I set them as "0.4, 0.4, 0.4".

after this, append a very simple node I made to check for point offset, point index, primitive offset, primitive index.

in this case: "point offset" matches "point index", both of them are continuous. but "primitive offset" doesn't match "primitive index".

So can anyone explain how "offset" works internally in hdk? Could I say if I create a new gdp and use "appendOffset()", the offset numbers are continuous?

Thanks,

Edited November 27, 2012 by michaelw

[edward]

From http://www.sidefx.com/docs/hdk12.1/hdk_geometry_intro.html

Each element has a unique offset into the attribute arrays (GA_Offset). The GA_Offsets are immutable except under a defragment operation. That is, as elements are added or destroyed, the GA_Offset for an element will remain the same. Each element also has an "ordered" index (GA_Index). The GA_Index of an element will change if elements before it (in order) are deleted. As a note, the GA_Offset for a primitive is also used to lookup the GA_Primitive object in the detail's primitive list.

The offset/index mapping is maintained by the detail in a GA_IndexMap structure. An index map keeps track of the offsets and the indices for all the elements in a detail.

[michaelw]

Thanks edward. I saw that explanation in hdk document, but I thought it only happens within one sop.

In my example, if I write the geometry to disk and read it back in, the primitive offset will be continuous. Does that mean all geometries written to disk will re-order their offset to match with their index?

[edward]

I saw that explanation in hdk document, but I thought it only happens within one sop.

I'm not sure what you mean here. It all depends. Say you had SOPs A -> B -> C. Then if B deleted a point in the middle, then the offsets in C may have a gap (assuming a defragment operation was not performed by the cooking engine in between). As you can imagine, having gaps allows for fast deletions at the cost of wasted memory. So, there are heuristics which will periodically defragment if there are too many holes.

Does that mean all geometries written to disk will re-order their offset to match with their index?

Yes, because we do not write out the data in the holes because that would be wasteful. Another way to think of it is that GA_Offsets should be used much the same way as pointers were used in the old geometry library. You should not expect values to be contiguous, but they might happen to be. And if you saved to disk and then reloaded, then there is no expectation that the pointers are the same. Ditto for GA_Offset's. Another implication of this is that you should not expect GA_Offset's to necessarily be the same in between calls to cookMySop(); ie. do not cache them for use across cooks.

A side benefit of GA_Offsets over pointers though is that there is what we call a "monotonicity guarantee" between GA_Index and GA_Offset. Suppose you have the GA_Indices A_i and B_i with corresponding GA_Offsets A_o and B_o respectively. Then if A_i is less than B_i, you are guaranteed that A_o is less than B_o (and vice versa).

Could I say if I create a new gdp and use "appendOffset()", the offset numbers are continuous?

It currently does, but there are no guarantees that it will in the future. The only thing you should expect is that the new offset will be greater than any pre-existing offset.

[michaelw]

thanks edward. this time it makes more sense to me:)