Playing around with grouping points in various ways, using the Group POP. I’m wondering if it would be possible to offer more flexibility in terms of the pattern options. Currently, pattern matches with point indices.
A couple questions:
Is it possible to overwrite given point indices with custom ones?
Would it be possible to extent the “pattern” field to take information from an arbitrary attribute?
For example, I create the attribute “customIndices”, and pattern has an option to select that attribute, instead of being limited to given point index values.
Same idea for other operators that may use this logic, like the Delete POP for example.
While in most cases one can work around this by making custom attributes first with some condition and then grouping them accordingly, it seems more natural to do it directly, which is why I thought suggesting it
Just to clarify, let’s say your pattern is [0-10:2], which expands to 0 3 5 7 9, and you have an attribute customId, you would want to select points that have customId matching 0, 3, 5, 7 or 9?
Also I’m not sure I understand the difference between your 1. and 2.
Or by 1. do you mean in general, not in the context of group/delete?
If yes, points don’t have a stored index, it’s just the point number.
(maybe related to Point ID consistent after Delete - #3)
In general at least in TD we call index something sequential (as in it always goes from 0 to N-1), not to be confused with identifier as in PartId attribute for particles, which is a permanent unique identifier.
And to expand a bit each vertex reference a point index, so if the point indices change the vertices update their reference (if points are reordered with the sort POP, the vertices point indices change to match)
Otherwise to get back to 2 I’m thinking it might be already possible with some kind of lookup and/or point reordering, which is something we could streamline, otherwise currently since these are point numbers (or primitives) we know only one point matches each, but nothing would guarantee multiple points don’t have the same customId value, which might have performance implications or some points not being selected.
I’ll aim to do a toe with some examples but wanted to clarify the question first, thank you!
Yes, as in your first example, I thought could be handy to be able to match to a “customId” for the selected pattern, since one sometimes wants to artificially create that reference.
With 1 I meant in general. For instance when sorting the points with a sort POP one gets a new order that can be used by the group POP to make a group. The geometry doesn’t change of course. You mean that those are point numbers and not really indices which are uniquely attached to each point?
I found myself in a (rather odd) situation trying to make a shape shifting Rubik’s cube where I needed to overwrite the point number values to something specific so that my grouping could update appropriately after 1 rotation of a subgroup of cubes. That’s why I wanted to check if those are possible to overwrite (in another way than with the sort POP).
Getting a bit confused while writing here again about it
But yeah, if you have a chance for a toe with some examples about 2 would be fantastic. A network is worth a 1000 words
In POPs, “index” is invariant, and is not an attribute. You cannot write to it. It also appears in the built-in attributes as_PointI, PointU and PointCy. Same goes for vertex index of a primitive, and primitive index of a POP, they are invariant and not attributes. Index is also referenced/used in all the Lookup POPs in the same way.
Like line numbers in a text file, they are invariant, but you can shuffle around what goes in them.
As for applying patterns to other attributes, the Attribute pages on the Delete POP and Group POP enable this - is it the syntax that is more cumbersome?
For what it’s worth, I’ve been setting a attribute to 0 vs 1 then using that in downstream logic like in Math Mix to mask behavior. But that may not address your examples in the toe.
