Hi all,

So I'm learning Houdini (I'm guessing there will be folk on here who know why *pours one out*).

I've not really figured out how to approach things in a Houdini manner, but what I'm trying to do now is set groups early on in my graph and then use them later after other operations have caused changes. I would imagine some types on nodes can't retain group information, but I've found very few which do. In the attached file GroupsDontSurvive, the subdivide operator blitzes them, where I'd expect it should be able to maintain the group for edges a they're subdivided.

The second group issue I've hit is having them not merge properly when there are pieces of geometry sharing the same positions. In the attached file GroupsDontMergeInSpace, I have two loft operators which have some inputs in common. Then, in the paths after them I add a group with the same name independently to each. After that, I have a merge operation followed by a bevel which uses the group. The edge loops which shared the same positions are only maintained from one of the input lofts. You can change which one by switching the order of the inputs to the merge node.

Any pointers on what I'm doing wrong would be fantastic. Oh, and I'm sorry that there wasn't any existentialism, that was a trick to get more readers.

Cheers,

Alan.

I'm also a little curious about groups after taking a look at the new foreach block and its lack of group support.

I'm wondering if moving to an attribute centric workflow is the new paradigm.



As for your issue Point/Primitive groups seem to be a little more clean throughout various operations, but as edge groups are fairly new in Houdini, maybe there's some kinks that need to be worked out there.

I'd looked at attributes, but they don't seem to have edge support. I guess I could try put it as point attributes, convert that to a point group, then convert that group to an edge group.

Probably the biggest challenge being new to Houdini is knowing the difference between a workflow and a workaround. For instance, the approach I suggested above seems more like a workaround.

Cheers,

Alan

Interesting; even though its the same behavior in H14, it seems like a bug to me…

skyphyr
Probably the biggest challenge being new to Houdini is knowing the difference between a workflow and a workaround.

Haha, there isn't as much of a difference as you think Not only is the line fuzzy, but it moves. Before POPs in DOPs, folks were recreating POP Forces in VEX, to speed up POP sims; but now, it's a workflow!

1. It's not problem of Merge SOP (you can replicate same issue with Mirror SOP) but it's problem of Polybevel SOP. Probably bug.

You can workaround this problem right now by moving one part a tiny bit up, then after polybevel move it back (if you have to).

2. Groups survive Subdivide SOP, but they are not subdivided.
For edge groups it could be problem, as they are defined by end points.
And when you subdivide mesh you will get different point indexing. So for edge groups it create group on the edges that are no longer existing in subdivided mesh.

You can check this if you create point group. After subdivision it will still exist, but it will not contain newly created points but only one that existed before subdivision.
It can be used in workflow for good, but in your example it works against you. You expected subdivided groups.

Right now you have to subdivide groups yourself. For single group it's not that hard.
You can convert your edge group to point group. Then do single subdivision, propagate point group to edges, remove edges that you don't want and repeat all that in for loop for number of subdivision you need.

If you can recreate edge groups procedurally it's much easier (see attached example).

In your example you can use OpenSubdiv Catmull-Clark subdivision for smoothed mesh, then do separate OpenSubdiv Bilinear. On this one recreate procedurally your edge groups and then use Group Copy (with Group Name Conflict set to Overwrite) to copy your recreated groups from OpenSubdiv Bilinear to OpenSubdiv C-C mesh (point indexing should match for these two).

Thanks, pezetko. I appreciate the help.

Cheers,

Alan

and yet, prim groups manage to survive a subdivision. There's got to be some black magic that can be done behind the scene to keep this, however there would also need to be a toggle to turn off that behavior for situations where you don't want the subdivided points in a group.

Yes groups have moved the way of attributes. And groups as fast as they are now in H15 are still slower than grouping things using the standard “name” and “path” attributes supported in most SOPs that need to work on partitions.

Groups are still great for modelling purposes as that is how they have been used traditionally.

If you didn't notice in H14, groups now show up as attribute membership in the Geometry Spreadsheet.

Agreed that there needs to be a standard clean up of all of the various methods.

For example style sheets work nicely in the viewport with group selections but selections on “name” or “path” not so nicely. As well group assignments to shop_materialpath work well too.

As for specific SOPs not managing groups properly, please submit bugs for each of these specific operators.

Thanks Jeff, I'm personally trying to make the transition from 12, so I'm missing out on the gradual transition process glad to have my intuition re: switching to attributes confirmed.

Oh a lot has changed since H12. Keep on asking the questions.

As for your support question earlier today about Bind VOPs, use the Add Attribute VOP instead. It creates attributes with the appropriate signatures.

I still use Bind VOPs to fetch volumes by name in to the first input these days.

Thanks Jeff