This is continuing from a previous topic. I have the following node tree which selects the surrounding points of each point and stores the total number and the index of those points.
I want to be able to repeat the store index part of it ‘tot’ times (which is the total count of points in the selection), so that each points index is stored.
I’ve tried putting a repeat zone inside and outside of the For zone, but in both cases I don’t get what I want. It can repeat for each point inside the For zone, but then I end up with point 0’s values stored on EVERY point.
I’m not really sure what I’m trying to do is possible, but I feel like it should be. Creating the name strings dynamically is easy enough, I just can’t seem to get the correct values on each point…
Just to be clear, this version works, so long as there are less than 12 points:
Hi ! I don’t have a solution right away, but it looks to me an over-abuse of attributes. On the overall it’s not how you’re supposed to work with GN.
Of course it doesn’t prevent you from doing so, but it’s natural that it ends up in something clumsy.
That same logic could work better with python where it’s more natural to create lists of list. Or maybe eventually we’ll have list support in GN so everything can be stored in one attribute rather than creating one attribute per points count.
Basically, while handling those 12 attributes is probably fine on the overall, 120 attributes might start to feel a bit sluggish, and I bet that 1200 attributes is going to makes things slow.
Since we don’t have a clue of what you’re trying to do it’s hard to advice you better, anyway, generally when I come to this I’ll try to see if there isn’t a way to get to the same result differently. And skip all that attribute storing …
It’s something that I learned with GN is that there are different ways to do the same things, even if a solution can work sometimes it’s too limited and you need to take another route !
Ok I get it !
I’m not sure if it’s that better, but you can create N copies of your point set and use the node to sort index by a value.
Then you access these data using the sample index node. If you have 50 points, the first set goes from index 0 to 49, the second from 50 to 99 and so on…
Performance wise I’m not sure it’s better since it’s creating points rather than storing index. But it might be worth giving it a shot…
However it seems a bit simpler to scale if you don’t want to be limited to 12 points, or how much copies of these nodes you’d like to make.
As said, it’s rare that there is only one solution to a problem…
