Hi

OK. So I am trying to assign materials in Solaris to groups rather than the Xform like the “material” node in obj. I am making an asset which rely on other nodes after. Splitting the assets into individual pieces to reform it back again in Solaris is not practical. Is there any way to do this. I have record a small video to explain what I am trying to do. Best Mark

Hi.

OK if anyone else is stuck on this The answer is do not tick “import groups”. Go further down inside the import data tab in a SOP import. There you will find a option saying “subset groups”. If you tick this you can import the groups and Solaris will see those groups. from there is is just the standard way to assign materials.

Best

Mark

Why not use the name attribute to split the geometry into multiple mesh prims rather than use geometry subsets? The name sop can create names from existing groups. I've found geometry subsets sometimes have funky behavior with materials bleeding from one subset onto another.

Hi Jsmack

Can you provide an example/screenshot of the name SOP. I am in the stage context and cannot find any name SOP, or are you talking about something in the sopimport? I have had a look in the sopimport and cannot see anything called name attribute either.

Thanks in advance!

best

mark

The Name SOP would be added in your source SOP network that you're importing with the SOP Import LOP. Let's say you have a model in your SOP network with all your groups. Append a Name SOP, put * in the Group Mask field to process all groups, and check Name from Group. This will create a primitive attribute called ‘name’, with the values being the names of your groups.

SOP Import will automatically use that attribute to bring the groups in as separate ‘Mesh’ Primitive Types, as opposed to using Subset Groups which are giving you ‘GeomSubset’ Primitive Types. If your attribute is called something other than ‘name’, you would enable Path Attributes under Primitive Definitions and add the attrib there.
Like jsmack said, there is a bit of funkyness/buggyness with the subset groups, and bringing your groups in as meshes has the advantage that you can transform them independently.

I was having trouble the other day getting groups from OBJ space to LOP space, so I tried to get what jsmack was talking about.

For how I like to work, I think this approach is going to be better than trying to work with ‘geo’ groups.

Here's an example.

in the sop context the name sop has a name from group checkbox. this way you can add a name attribute in sops based on your groups and the sopimport lop will split your geo based on those groups to mesh prims.

The name SOP is found in the geometry context, the same context as the source for sop import. Use it in the node graph leading up to the SOP referenced by sopimport.

Edit:
heh, a bit of a dog pile here.

Hi all

Thanks for all the insights.

This seems like a clean way of doing it.

Best

Mark

DaJuice
The Name SOP would be added in your source SOP network that you're importing with the SOP Import LOP. Let's say you have a model in your SOP network with all your groups. Append a Name SOP, put * in the Group Mask field to process all groups, and check Name from Group. This will create a primitive attribute called ‘name’, with the values being the names of your groups.

SOP Import will automatically use that attribute to bring the groups in as separate ‘Mesh’ Primitive Types, as opposed to using Subset Groups which are giving you ‘GeomSubset’ Primitive Types. If your attribute is called something other than ‘name’, you would enable Path Attributes under Primitive Definitions and add the attrib there.
Like jsmack said, there is a bit of funkyness/buggyness with the subset groups, and bringing your groups in as meshes has the advantage that you can transform them independently.

Was sitting for a few hours trying to get materials applied to groups. This worked perfectly. Thanks a ton!

BabaJ
I was having trouble the other day getting groups from OBJ space to LOP space, so I tried to get what jsmack was talking about.

For how I like to work, I think this approach is going to be better than trying to work with ‘geo’ groups.

Here's an example.

Thank you BabaJ.
But what if my imported geo is alembic, with hierarchy i dont want to change?
Like i have Alembic at SOP level, couple group nodes and i want to import it to Solaris?
I want to keep the hierarchy of the alembic intact, but i want to use groups i manually created to assign shaders?

martinkindl83

BabaJ
I was having trouble the other day getting groups from OBJ space to LOP space, so I tried to get what jsmack was talking about.

For how I like to work, I think this approach is going to be better than trying to work with ‘geo’ groups.

Here's an example.

Thank you BabaJ.
But what if my imported geo is alembic, with hierarchy i dont want to change?
Like i have Alembic at SOP level, couple group nodes and i want to import it to Solaris?
I want to keep the hierarchy of the alembic intact, but i want to use groups i manually created to assign shaders?

The alembic hierarchy is retained when sublayered onto a stage. Any location in the hierarchy can be a target of a material assignment. No groups required.

jsmack

martinkindl83

BabaJ
I was having trouble the other day getting groups from OBJ space to LOP space, so I tried to get what jsmack was talking about.

For how I like to work, I think this approach is going to be better than trying to work with ‘geo’ groups.

Here's an example.

Thank you BabaJ.
But what if my imported geo is alembic, with hierarchy i dont want to change?
Like i have Alembic at SOP level, couple group nodes and i want to import it to Solaris?
I want to keep the hierarchy of the alembic intact, but i want to use groups i manually created to assign shaders?

The alembic hierarchy is retained when sublayered onto a stage. Any location in the hierarchy can be a target of a material assignment. No groups required.

Thank you jsmack.
I have very different opinion on assigning materials directly to alembic xforms/shapes. I would never do that.
My proven workflow consist of creating unique not overlaping groups and assigning materials to my groups.
I would like to replicate suchá workflow in Lops. For now easiest would have been just import those groups from sop level, but that doesn't seems to be supported.
Can you please atleast advice what would have similar effect on usd? I looked into collections.

martinkindl83
I have very different opinion on assigning materials directly to alembic xforms/shapes. I would never do that.

USD only supports assigning materials by location, or collection. But a collection is just a list of locations.

I don't think alembic can be imported from sops. You can replicate your groups that were created in sops by copying the prim group patterns and stripping the ‘@path=’ from them before using them in the assign material field or when creating a collection. The assign material node can also create a collection for you.

Thank you for fast reply. I don't understand why I would need to strip down the @path attribute? As that's what builds the hierarchy.
What about converting my groups to simple string attribute and then create collections based on that attribute?
Idea is to have collections (if collection is the clisest I can get to groups in Lops) before my material assign node.

martinkindl83
Thank you for fast reply. I don't understand why I would need to strip down the @path attribute? As that's what builds the hierarchy.

The @path= is for houdini group syntax. The material assign node uses the paths directly.

martinkindl83
What about converting my groups to simple string attribute and then create collections based on that attribute?

Yes, but if not already present in the alembic, how to get the attribute into lops? Possibly a sopmodify to and add attributes to the usd packed prims, but that sounds a lot more round about than simply using the same pattern in a collection or material assign node. If your alembic geometry contains an attribute that could be used to assign materials, then yes that is a way to assign them. It would require writing the alembic with the attributes to match beforehand.

martinkindl83
Idea is to have collections (if collection is the clisest I can get to groups in Lops) before my material assign node.

This is possible. The collection tools can use various patterns and expressions to create collections.

Thank you for quick reply.

I do load my alembic at sop level, create my unique groups for shading and then sopimport them to LOPs.

I can build my uniqueGroup tool in LOPs in the future, but i need to be certain what approach i will be using. If collections are the best thing to use. Ideally i want to have unique “containers” that would contain unique geometry, and later on, i can use those “containers” to assign materials.
In SOPs, easiest was to work with Groups, make sure they contain unique assignments (one object cant live in two groups) and then assign shaders based on groups. As the logic here is the same - you cant assign two materials to one object.

Another option would be to create “my own hierarchy” just for the shading purposes, but that doesnt sounds right, as i already might have some nice hierarchy coming from alembic. Just not the hierarchy i would like for shading though.

martinkindl83
I do load my alembic at sop level, create my unique groups for shading and then sopimport them to LOPs.

I would not. Loading an alembic at sop level still unpacks when imported into LOPs.

martinkindl83
I can build my uniqueGroup tool in LOPs in the future, but i need to be certain what approach i will be using. If collections are the best thing to use. Ideally i want to have unique “containers” that would contain unique geometry, and later on, i can use those “containers” to assign materials.

Collections are more or less groups. Collections can have overlaps, but paths cannot overlap. Overlaps don't matter for material assignments as only the last assignment will be used. The assign material lop can create collection-based assignments encoded at the usd level. This would allow the collection to be composed. Using collections created in other ways to assign materials directly does not as it applies the material directly to the locations as if no collection were used. This only matters if you want to be able to modify the collection downstream.

Assigning materials by hierarchy is often the simplest since it makes it possible to assign one material to the majority of parts, and then make exceptions here and there with assignments at lower levels of the hierarchy. Geometry isn't always authored in a way to makes the assignments by hierarchy convenient.

jsmack
Geometry isn't always authored in a way to makes the assignments by hierarchy convenient.

Thank you.
Im doing some reading of USD at tokeru, that might give me some more answers.
But in a mean time. How would you shade and assign materials in the following scenario?

You have 150 materials, you have asset with 20.000 pieces. There is no usable hierarchy for shading and no usable names on the pieces.

I have created whole workflow in SOPs to make this possible to work with, now im trying to do similar in LOPs.

My problem is that if you will have one materialAssign node, where you assign all pieces by selecting them in viewport, next time you asked to change pieceA from materialA to materialB, you have to go and find the materialA tab (with 150tabs, its very hard), remove it from materialA, then find materialB tab and add it to materialB.
What i have instead in SOP is “group”node that allows only unique assignments, so one object can live only in one group. once i assign that piece to another group it gets automatically removed from previous group. User creates 150groups, that later on correspond to creating 150 materials, that are assigned based on the group name. Basically replicating shadingGroups from maya or XSI groups logic.

Option with USD might be to “recreate” hierarchy based on materials and then be assigning materials based on that hierarchy. That sound reasonable, but im little bit of worried about “killing” the original hierarchy. As in some cases it might be actually good and can be used for other things down the road.

I would think collections can handle that workflow. Also, with the way materials are assigned in usd, there's no need to remove the shape from the collection to assign a different material than its collection's material, as later assignments overwrite previous ones. However I think you can still use the collection node to make a new collection that equals “collectionA - partB” for clarity.