Jump to content

offset understanding


Recommended Posts

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

post-7537-0-47689000-1354033972_thumb.pnpost-7537-0-03840700-1354033973_thumb.pnpost-7537-0-38311900-1354033973_thumb.pn

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 by michaelw
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

post-7537-0-37940500-1354130522_thumb.pn

Link to comment
Share on other sites

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 Ai and Bi with corresponding GA_Offsets Ao and Bo respectively. Then if Ai is less than Bi, you are guaranteed that Ao is less than Bo (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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...