Static Unique Point ID on Changing Topology?

[Anti-Distinctlyminty]

Hi all,

I've been trying to do something that involves a Solver SOP and changing topology and point count of a model. Now, I ran into issues as soon as my point count changed, as there are a bunch of wrangle nodes that do stuff based on stored point numbers.

So, is there are unique ID that I can use instead of point number? Something that remains constant, regardless of changing geometry?

 

tldr: When point count changed, it messes up stuff I've done (because it's based on stored point numbers). Is there an alternative that remains constant?

[amm]

If point number is exported as custom attribute, it will be resistant against any deletion, later. But it will be copied to possible 'clones' (it seems this depend on method, how point are added), so there should be a 'counter' after each new creation, for newly created points, something like maximum value of all saved attributtes, plus number of added points.

I don't see anything shorter than that.

[Anti-Distinctlyminty]

If point number is exported as custom attribute, it will be resistant against any deletion, later. But it will be copied to possible 'clones' (it seems this depend on method, how point are added), so there should be a 'counter' after each new creation, for newly created points, something like maximum value of all saved attributtes, plus number of added points.

I don't see anything shorter than that.

 

It's a shame that there doesn't seem to be a persistent point identifier. I've not used particles, but I think they do have this - called $ID.

It's a shame I have to do all of this manually :/

 

Edit: I'm going to try and use findattribval to find the stored original point number.

Edited January 1, 2016 by Anti-Distinctlyminty

[f1480187]

Create an ID manually before messing with geometry, that's the most straightforward way. Enumerate SOP is a shortcut for creating an integer attribute with default value of -1, using Attribute Create or any of VEX/VOP nodes. -1 will be assigned to newly created geometry without IDs. Then you can use check "if (@id == @ptnum) { // your code }", it will work much faster then iterating over geometry. If you're matching two inputs, findattribval() is a normal way, but since H15 you have a special parameter for matching topology on wrangle nodes. It defaults to "id" attribute or point/vertex/primitive numbers if no such id exists. Instead of finding number by id and then getting an attribute by this number, just use "v@opinput1_foo"-syntax. Inputs there numbered from 0: @opinput0-3_foo, although 0 is obviously unnecessary. It differs from @OpInput1-4 string variables containing input operators' paths, just be aware of that.

[fathom]

if you're just looking for consistency and not uniqueness, then you can add id on your initial data with a pointwrangle ("i@id=i@ptnum;") and then add some offset to the ptnum for new points entering your system each iteration ("i@id=i@ptnum+rand(f@Time/3.45)*1000000").  you can't match points by id, but id will be consistent frame to frame and would be suitable to act as a seed for random value calculations.

[Anti-Distinctlyminty]

If you're matching two inputs, findattribval() is a normal way, but since H15 you have a special parameter for matching topology on wrangle nodes. It defaults to "id" attribute or point/vertex/primitive numbers if no such id exists. Instead of finding number by id and then getting an attribute by this number, just use "v@opinput1_foo"-syntax. Inputs there numbered from 0: @opinput0-3_foo, although 0 is obviously unnecessary. It differs from @OpInput1-4 string variables containing input operators' paths, just be aware of that.

 

Yes, I ended up storing the point number and using findattribval to find that point later.

I'm still on H14 - I looked to see if there was anything that effected my work, but I missed these improvements to wrangle nodes.

With respect to the @id special parameter for matching topology - can you explain this or link the documentation? I can't seem to find it :/

[f1480187]

It is quite non-essential stuff. No need to update to get one line of code instead of two. But the H15 feels quite stable anyway, and new stuff is cool. The parameter can be found in "Bindings" tab on Attribute Wrangle node. Just read the H15's help of the node about this parameter. It allows you to write this:

@P = @opinput1_P;

Instead of such common cases:

int match_pt = findattribval(1, "point", "id", @id);
@P = point(1, "P", match_pt);

// If topology still match and no need in IDs.
@P = point(1, "P", @ptnum);

By the way, I've found where zeroth input's virtual bindings can be used. It works like a rest attribute. When you change @P for example, via @opinput0_P we still can retrieve original position. Although in most cases - including this - instructions may be reordered or temp vectors can be used as a preferred solution.

@P = @opinput1_P;

// Just to get nice result similar to Attribute Copy SOP. Unmatched points
// will return default value of {0, 0 ,0}. idtopoint() is one of the new
// shortcuts for common findattribval() function usage.
int pt = idtopoint(1, @id);
if (pt == -1)
{
    @P = @opinput0_P;
}

id.hipnc