This is working like a charm , looks like a super useful tool to have !
Now here is my problem :
I have different islands, I want to sort their point by some field, and I want to keep the first point of
the sorted list of each island. And I can’t figure out a way do to that.
I’ve build a simple test scene where each island is a plane, and I sort them by their X position.
My real scene is a bit more complex, there is an arbitrary number of points per island, ( it’s only points, not faces, edges) …
And I don’t sort them by their location.
Use an Integer Accumulator set to 1 which takes the island index as Group Index and capture the trailing value on each point - this will generate indices starting at 0 for each island… you can then just delete points where this custom index isn’t 0.
By the way i would use the group (topology) sort from the Group Attribute Statistic Node, which does essentially the same thing but is way faster and has a higher float precision. Have build that after i asked Christophe if i could use his search node for the Group Attribute Statistic Node. And he pointed me to the fact that the new (at that time) topology nodes could be used to implement the sort more efficiently.
Realized that for for Float attributes, i have the accidentally stripped the “bag to group set node” from the file because i got over the upload limit of 5 MB. And removed examples to reduce the file size, while just compressing would have been the way smarter.
Sorry for the circumstances, when i find time i will add the other examples to the original Thread. As i think this stuff could really benefit from better explanation.
Edit: The files are now updated (here and in the original thread). They now include the old examples. And a fix for min indices on the point domain (Sorry again to everyone who may have been send into the wrong direction).
That’s super kind to you to help me, that’s really appreciated !
I started to look at the files, it’s quite impressive !
For now I’m not 100% sure how to solve my actual problem yet, but I’ll keep testing !
In your example, you create the cubes and put them at the right place at the end of the tree.
Where in my case it would be simpler to delete the unwanted points. I don’t get how to do that yet, but that’s probably because I miss a bit of practice with your groups.
I’m not sure this is going to help, but here is basically my actual problem :
At the end I’m still left with a bunch of curves, and I initially kept the first of each groups ( castles).
It worked but sometimes it created weird stuff visually.
Now what I want to do is to add a rule to make sure the door is pointing toward the center of the island. I think it will work much better especially since I plan to add roads that goes from one castle to the other.
I think I managed to get the sorting done, and now I’m stuck with the removal
Silly thing is that I wanted to work on these roads and I’m stuck on a tiny detail with these entrances since yesterday
I’m questioning if this is the way to go and if I should look for a simpler solution
Thanks for reading and I’d be really happy to have your thoughts on that !
Had the same feelings when trying to understand, what was going on the original sort group from Christophe. At that time Jaques implementent the first visual feedback of attributes. That helped a lot to understand what was going on there. And as a consequence exploring and debugging node groups started to become more fun.
Me too… Sorry, could you not delete by the permuted index? Then you would not need the accumulator…
Just a suggestion: Would it make sense to start with the roads and end up with the doors?
Starting with some central point you could use shortest paths to create the road curves - terminating at random points on the edges of your “island” - then use these same points to be the doors - then generate the castle around the door… So, what I’m suggesting is to take your idea for generating the castles and flip the order of generation… Donno if that would work but it may be worth considering.
They are, right? Johnny Matthews had a native version implemented back in Dec 2021 and for some reason its still not been merged in
I’m not sure how, I tried a few things … The permuted index is like 7,2,8,4,3,1… I didn’t manage to find a way to keep the first one of each group but since I understand half of what I’m doing… maybe it’s possible
That’s quite interesting ! Right now the castles and the overall shape of the island are the two things we can setup manually by blocking out rough 3D shapes, I like to keep it that way so at least there is a bit of artistic control. But yeah if I had to start over I’d probably build it as you suggest.
Or I’d do something with even more control, and less automation…
I think I could have been much more organised from the start, but that’s probably what it takes to learn to do things the right way
And yes ! I remember the patch from Johnny Matthews, I can’t recall why it didn’t work in the end, it’s too bad that some really important features can’t be grouped by default. Anyway thanks to the community powerful tools like this ones really help a lot to do even more crazy stuff !
Hahaha ! Yeah sure visual feedback is soo helpful, I also looked at Christophe ones, even with viewer, spreadsheet courage and coffee, frankly I don’t know what of these two gif express the best my feelings when opening these groups :
Me also too again … and of course @zeroskilz is right it should be possible by the permuted index … but while checking it and trying to do it i found i broke the permuted index. I do not transfer them from the domain specific groups to the general case at all.
Will fix that when i find time (not atm). You could pick the point domain specific group out of the general one and use that index for the meantime.
Ok this statement was not correct. Have Forgotten that i once stripped the permuted index from the group. Did that to reduce the complexity of it. And because no good use case came to my mind (only for sorting, where i would use the builtin Topo Group Sort node only. Which still gives you the permuted index). So the following output should not exists it was only forgotten to be removed:
But still have broken something during that move. I accidently plugged the permuted index in the other indicies Field (“indicies min”). Which should just hold the same index for each group element pointing to the point with the minimum (for that group).
That output is meant to be used to get the the group minimas by index. This avoids ambiguties which could occure if you do it like Sozap did above. When you have group elements at the same spot. See how selecting by index is done below: