So how do I group by primitive area in H16? I assume I use the group expression node.. but I'm not having much luck trying to do “prim(”../measure1“,$PR,”area“,0)>0.5 .

It also seemed less than intuitive to type in the nprims or npoints expression in the group range sop to get the “Nth” prim.. or to get just the first and last points.

The H16 group docs really need some useful examples attached, even though its basic stuff that ppl have done for years, its not obvious what the new syntax is, or sometimes even which of the 5 group nodes to use. I have seen ppl suggest using a wrangle instead of the group expression node entirely as its a bit more forgiving.

There are some changes that have to be done to move from HScript expressions to VEX. The group expression is using VEX.

1) prim() expression in VEX doesn't use the final 0 since VEX can handle vectors. It also has reversed the primitive number & attribute name.
2) $PR should be @primnum as local variables are replaced with bindings.
3) We strongly encourage using wires into the group expression rather than paths to nodes. These tend to be easier to maintain in any case. The inputs to the node are 0, 1, 2, 3, so “../measure1” can be replaced by 0 if it is the primary input. (This is also true with the HScript expression, which also supports 0, 1, 2, 3). If you do want to refer to another node somewhere, VEX requires a “op:../measure1”. This is because it treats strings as files on disk by default, so you have to let it know you want a live node instead.


If it is your first input that has the area attribute; and you area building a primitive group, you can just directly bind the area attribute and make things even simpler:


You should not need to type nprims() or npoints() in the group range sop. It has an option to measure from the ends which will implicitly use those. So, for example, to get the last two points:

Method: Relative to Start End
Start: 0
End: 2
Invert Range: True

Thanks for the tip on the “Nth”, prim/point.. that is much simpler and about as fast as typing N like before. Ironically I got the tip to use nprims() from a video on using the new group sops.. So again, perhaps some examples in the docs would clear up confusion and best practise.

Sadly I am still not having any luck with your group by area instruction. Even when the measure sop is directly above the group expression node in input 0.

Pasting - prim(0, ‘area’, @primnum) > 0.5 or @area > 0.5 into the Vexpression field just makes me a group with no members.

Any chance you could post an example file on a stretched out box or something

Duh.. sorry I realize now that 0.5.. is huge.. it needs to be more like >0.0005 to get something meaningful

Thanks

Ok, a lightbulb went off during this, thank you for your help! I thought I was smart for a few seconds but then realized I am not

So I have used a connectivity and a partition node to give all the mesh pieces a $class prim attribute. I then used a attribpromote with the “mode” function to create a detail attribute with the most prevalent piece - most polys. And called it “main_class”.

I plugged the attribpromote into the 2nd input of the group expression node.

Then tried @class==`detail(1, ‘main_class’, @primnum)` and it worked.. same as typing @class==79.

Unfortunately when I scrub the timeline and get a new mesh with a new “main_class” value.. of 171.. the expression fails. Any ideas?

Glad it is coming together. I agree this transition is difficult.

The problem is the backticks. Backticks escape you from the VEXpression back to the old-expression world. However, VOPs evaluates all of its code on frame 1. This avoids the code itself being animated which leads to atrociously bad performance as stuff would recompile every frame. The solution should be this:


Note detail does not require a primitive number as there is only one of them.

That is a very clever idea to use the Mode parameter to find the most common class! That hadn't occurred to me before.

Awesome, works perfect. Thank you. I tried removing the @primnum earlier, since I knew detail should not need this 3rd argument, but I guess the backticks were generating an error so I kept it in. Thanks again.