There's finally support for Maya sets (Houdini groups)! The change is in today's build (14.0.372).

From the journal:

When inputting Maya mesh, if the mesh is a part of any Maya sets, these sets will be created as Houdini groups. When outputting Houdini mesh, if the mesh is a part of any Houdini groups, these groups will be created as Maya sets.

Also, since Maya implements material assignments using sets, any materials that are assigned to the input mesh will be represented as Houdini groups. Then, if these Houdini groups are outputted back into Maya, they will become material assignment inside Maya.

In the screenshot below, the yellow shows a typical selection set (set1, in this case). The Maya set names are used to name the Houdini groups.

The red and green are not vertex colors. They are actually two different Maya material assignments. Since material assignment in Maya are implemented as Maya sets, the material assignments are actually translated into Houdini groups (e.g. blinn1SG and blinn2SG from the screenshot). And since the asset outputs these Houdini groups back into Maya, the components are assigned back to the same Maya sets. This means the output geometry gets the same materials assigned to them.

Note that Maya sets are DAG nodes, so they require the usual sync'ing to receive updates.

Also, now that there's support for Maya sets, the “Split Geos By Group” doesn't really make sense. And I think the Maya sets should supersedes that option. So I've turned off that option by default.

I've also been playing with the idea of creating a separate primitive attribute for material assignment. This would be somewhat similar to Houdini's own “shop_materialpath” primitive attributes, which is used for material assignment.

Instead of creating Houdini groups for Maya's material assignments, the idea is to have a string primitive attribute on each polygon, such as “maya_material”, to store the name of the Maya material (e.g. blinn1SG and blinn2SG).

If this is implemented, then there would be no need to create those material assignments as Houdini groups (e.g. blinn1SG and blinn2SG), since this information is available on the primitive attribute.

Instead of simply using Houdini groups, I've changed the material assignment to use a primitive attribute “maya_shading_group”. This is similar to Houdini's “shop_materialpath” attribute.

From the journal:

Material assignments of input mesh are now passed as a primitive attribute called “maya_shading_group”. If the output mesh has this primitive attribute, material assignment will be done using it.

When the geometry goes into Houdini, it'll look something like the screenshot.

Hey Andrew!! This is an EPIC upgrade thank you so much! This is going to open a lot of doors for us! the back to back support for the maya_shading_group attribute was also pretty welcome.

its like xmas, but on summer!

(BTW I also saw your update for the attribute names for uvsets and colors! thank you for that too!)

Welcome! You can attach an example of a working file and h m, if not too much trouble? I would be very grateful!

Iskander
Welcome! You can attach an example of a working file and h m, if not too much trouble? I would be very grateful!

I'm not sure what kind of example you're looking for. I put together something quick showing a Maya set going into a Houdini asset, and the asset outputs a group back into Maya. The example doesn't do anything useful, but it shows how the Maya sets work.

Also, this thread is pretty old. So please start a new thread if you have more questions.

AWong. I'm a bit unclear about the design on this. You say you switched to a prim attribute rather than groups but in your example your only using groups?

I'm adding a prim attribute called ‘maya_shading_group’ on my input on the houdini side but not getting the same behaviour when in maya. For instance, an attribDelete gives this warning in the cook messages.
“Warning: Invalid attribute specification: ”no match for maya_*“.”

Though, right after this node I can use a partition node with the expression `@maya_shading_group` and it gives me a set with the original shading group (or is this in fact the set from the prim group?)

Also getting alot of these
// Error: line 1: Cannot add the following items to the set since they would break the exclusivity constraint: wal_cutter1_0.f //
Even though I delete all groups before adding a single one.

Would be good with a file showing how we should use the prim attrib.

Thanks!

kahuna031
AWong. I'm a bit unclear about the design on this. You say you switched to a prim attribute rather than groups but in your example your only using groups?

The prim attribute only applies to Maya material assignment. i.e. maya_shading_group
Other Maya sets are still converted into Houdini groups.

kahuna031
I'm adding a prim attribute called ‘maya_shading_group’ on my input on the houdini side but not getting the same behaviour when in maya. For instance, an attribDelete gives this warning in the cook messages.
“Warning: Invalid attribute specification: ”no match for maya_*“.”

Though, right after this node I can use a partition node with the expression `@maya_shading_group` and it gives me a set with the original shading group (or is this in fact the set from the prim group?)

Also getting alot of these
// Error: line 1: Cannot add the following items to the set since they would break the exclusivity constraint: wal_cutter1_0.f //
Even though I delete all groups before adding a single one.

Would be good with a file showing how we should use the prim attrib.

I've attached an example asset that shows deleting the Maya material (i.e. shading group), and then assigning some faces to a material again.

Hope this helps!

Thanks Andrew! Looks clear enough design wise and I seem to be able to repro this fine now in my setup. I think what made this hard for me to diagnose was that both obj sets and shading groups are sets and the maya tool therefor gets confused when their name is the same. Causing for example houdini prim group members to be added to a second shading group which is not allowed. As I was changing the maya_shading_group value I was also getting strange results.

Generally I think the design is solid but could be worth looking at the scripts to check if there's any risks object Sets/shadingGroup mismatch.

Something that hit me when tracking this down is that it would be very nice if we could get the nodes middle mouse info printed out in the cook message. This would allow us to quickly compare Houdini output to Maya result.

Also: seems that reassigning the input geo to one with different shaderGroups attachments doesn't correctly updates the outputs assignments. “Sync Asset” doesn't fix this but “Reload Asset” does.

Edit: I've tried both deleting the geometry and remove all material assignments before resyncing but the obsolete material assignments from previous input remains. Looks like something needs to be flushed internally. If there's any script functions that can fix this on my side I'd love to hear them, now I'm forced to use “reload asset”, rather than “sync asset” function in my wrappers which is a bit slower.

Edit2: Heads up to anyone working on material assignments on the maya side. If surfaces go flat green it's not Engine's fault but a Maya problem with updating shader assignments in the viewport [forums.autodesk.com]. Moving a vertex on a mesh can force it to update.

kahuna031
Also: seems that reassigning the input geo to one with different shaderGroups attachments doesn't correctly updates the outputs assignments. “Sync Asset” doesn't fix this but “Reload Asset” does.

Yes, I think I'm able to reproduce the issue. You might be able to workaround it by clearing the input first (i.e. disconnecting the input), trigger a cook, and then connect the new input.

Hi,
I think it would be really cool if we the HDA's group parameter had a button to create and assign selection sets in Maya.
Basically it would work like the group selection button in Houdini (where you click, select in viewport and then hit enter). But it would create a generically named set and put that in the field instead.

What do you think?

It does?

What versions are you on? Do you have an example video or something, so I can see if my engine is working as expected (and whether I am doing it right)?

It was always there - “Output Geometry Groups”. We turn them off at load but I remember asking for it to be off per default as they can cause issues in the scene (nothing in the scene can be named as a selection set, even when it is under a parent node - oh maya…). This broke our python wrappers as there was no way to catch the name collisions.

Oh I think I was not clear enough. I was thinking about the method to create selection sets to input into the HDA.
I think you are talking about the HDA-output of Houdini groups to selection sets.

Rethinking this, I suggest to add another way to set the input on the HDA. The goal should be, that you have an active component selection in Maya and when you set that to the input of the HDA, the HDA takes the objects and creates the Houdini groups under the hood and or assigns them automatically to a related group parameter.
So in my crappy picture. You selected the torus object, and make a component selection. Then you press set to selection on the HDA and the magic that should (in my opinion) happen, is that the object and the group input get filled automatically. Ideally without generating a Maya selection set in the scene. Or maybe it does generate a Maya selection set with some unique name and then deletes it after use.
Because Maya is actually not designed for handling those selection sets and we don't want to have an ever growing list of them.

As for your problem with name collisions on selection set output: Can't you use a string (or integer) parameter input on the HDA and use that to rename the output sets and use a python wrapper to keep track of the selection sets that already exist in the scene?
So basically every time you create a new HDA, the creation script puts in an incremented version of the existing set names, so that there is never a clash?

It's already mostly there - although we only use it for construction history mode now.
If you look at the houdiniInputGeometry node (well, if you do a listAttr) you can see there is an inputComponents attribute: e.g.

getAttr houdiniInputGeometry2.inputComponents;
// Result: vtx 20 : 22] vtx 40 : 44] vtx 59: 64] // can't seem to be able to escape this so it shows the actual output :-(


When we apply an asset as construction history, if you have components rather than shapes selected, we set that attribute the same way that a standard maya mesh construction history node, and then we create a inputPrimitiveComponent or an inputPointComponent group
(didn't do vertex or edge groups yet, mostly because the Maya api doedn't support double indexed components, and there weren't that many places that wanted edge groups).

The component selection isn't supported for the SetToSelection interface yet (because it gets more complicated for multiple object input, which was not an issue for construction history), but if there's an interest in doing that I will enter an RFE for that ase well.

I am probably doing something wrong, but I cannot recreate what you are describing. I am curious about the workflow.

Either way, please do make an RFE. This should probably be looked at at the same time as the pivot input/output suggestions I made, because that also deals with multiple input objects.