I am looking for one node, which groups multiple selections.

It's not really a group, but an index attribute with ability to be selectable.

Perhaps you could post a hip that illustrates better what you want to accomplish.

Part of the mix might be using a group expression or wrangle node.

But that depends on your setup.

At the moment I am working by selecting different sets of primitives and assigning attribute index to it:

if(@primnum==1-10000)@index=1;
if(@primnum==100000-20000)@index=2;
if(@primnum==200000-30000)@index=3;
.
.
.

The goal is to do it inside one “multiple group” node.

Here's an example with a ‘detail’ wrangle(colored red):

Just note though that with the above you wrote, you are starting your index at 1.

In my example I start with zero(you can change it where I made a note of it).

Also, with your above example, notice your logic is saying, take 10,000 for example;

That with your first line prim number 10,000 will have i@index value of 1,

but on the next line you are also saying prim number 10,000 is to have i@index value of 2.

So the question is, which one?, or is there some reason you might want to have a crossover?

In my example I code it for the former.

If you want the crossover(the ‘boundary’ prim to have both) you will need to go with a separate named attribute for each boundary category.

I didn't code my example for this but it is possible with some string concatenation.

Let me know if this is necessary, and if I see the post and have time I will do it.

But if your going to have alot of ‘boundary categories’ with a high prim count, your memory usage could go up quite a bit.

In a pointwrangle, try something like

Don't have Houdini on me atm so no hip.

Perfect, thank you very much for this. Do you also know by any chance how to replace those values with a “selection parameter” (the one on the image below)

Yes…but why?

Is it something you want to source from? and if so what is the source you anticipate will be getting your numbers from?

Because if this is the case I suspect you may already have all what you need without having to go through any of the above post suggestions.

You should post a hip with an applied example of the whole context of what it is your trying to accomplish.

Otherwise, are you just wanting the ‘convenience’ of not having to type in the wrangle and prefer to do so in a string parameter?

In that case I attach hip file and a screenshot. What I am trying to achieve can be called a ‘convenience’ utility - after all the main purpose is to compress those multiple groups into one node.

Ok…but those separate group nodes is what separates your selected primitives into their own categories.

So you don't have to assign them as an index attribute; You can always just refer them by their group membership.

Getting rid of them, gets rid of the separate categories, i.e. If you select all the same primitives you did with 3 group nodes from only one group node; Then you lose the distinction.

If it's not arbitrary primitive selection, which it appears to be(such as ‘artistic’ primitive picking)…you could simply go with direct attribute creation with some algorithm based on conditions, like positions, distances, etc.

But for arbitrary picking(from within the viewport) into separate categories you'll have to go with mutliple group nodes…or like in the first example I gave you to manually enter their numbers.(the code could be modified to identify separate pair ranges of upper/lower limits too).

Another possibility is to put in an RFE that allows you to select multiple separate groups of categories with the same node i.e. clicking a + button for each successive group picking.

But if you have alot, then that node could become cumbersome and cluttered because you will have this long list to scroll in your parameter window.

And I am assuming you don't like the multiple group nodes because it's ‘cluttering’ your network window. What you could do after making multiple group nodes is wrap them all up in a subnetwork…leaving you with one node and a ‘tidier’ network. Gives you the freedom to return and make changes (remove/add group nodes easily).

But getting back to what you asked last…so if we read the strings of the group selection parameters of the group nodes…you still have to keep those group nodes.

I think what you really want is to be able to arbitrarily select primitives into separate ‘categories’ as you go along(working in viewport), having a single node store that information.

For that you'll have to dive into the HDK, unless of course Python in Houdini is robust enough at this point to do something like this; In either case, beyond my means to know how.

If you really need arbitrary picking; I think your best bet is to go with multiple group nodes and wrap them up in a subnet. You could use the primgrouplist function in a wrangle at the end of the group node'chain' to sort them into attributes names. No need to parse the string values to get the numbers.

Thanks BabaJ for this comprehensive reply. Yes, everything that you described is correct. Subnet-collapsing technique is what I've ended up using, but it is far from perfect. HDK-based ‘multigroup’ node it is then.

Perhaps you know somebody who would be willing to build that?

Also I have submitted RFE to sesi