I am having trouble assigning a single material from the same library to two different objects in the material library node.
As soon as I assign the material to the second object, the second object renders white (no material).

I have to make a copy of the material with another name and the same settings to render properly. Am I missing something? Is this an USD issue/"feature"? I tried with MtlX and Redshift materials.

Why are simple things like that always an obstacle in Houdini?

Works fine with assignmaterial LOP instead assigning it diretly on the materiallibary.

For one material assigned to multiple geometries, see below. I'd recommend using a Material Linker instead, much more convenient!

I just tried and it does like the drag and drop onto the primitives field could use some extra functionality. For me dragging from the SGT pane to the primitives field on the node replaces the existing primitives. I though shift + drag might add add to the section. For lists of primitives I miss some of Katana's UI where it expands out to a more manageable line-per-entry style format.

BrianHanke
For one material assigned to multiple geometries, see below. I'd recommend using a Material Linker instead, much more convenient!

Image Not Found

Damn, I never would have thought of that. That would be quite messy with a lot of objects anyway. Gonna try the linker.

Thanks guys for all your help. I thought I was missing something. I still wonder why the most obvious workflow is the one that doesn't work... A bag of tripwires this software is...

Manuko
Works fine with assignmaterial LOP instead assigning it directly on the material libary.

Tried it but didn't dive very much into it and didn't get it to work. Who would have thought that assigning a material requires the help from the community
Thanks though!

OneBigTree

BrianHanke
For one material assigned to multiple geometries, see below. I'd recommend using a Material Linker instead, much more convenient!

Image Not Found

Damn, I never would have thought of that.

Thanks guys for all your help. I thought I was missing something. I still wonder why the most obvious workflow is the one that doesn't work... A bag of tripwires this software is...

Notice that the material library material entry list is called "number of materials." It be impossible to create the same material twice. The way the list of entries works is later entries overwrite the earlier ones. This can be useful for debugging, where you might have duplicate entries to compare looks. What these two conflicting entries mean is: make the ball blue; scratch that, make the grid blue. The material assignment node is different in that the entries are cumulative, Multiple entries can assign the same material to multiple objects. Material assignment node is the preferred workflow and assigning materials using the material library node is no longer the recommended one. The library's default material name field is '*' and the assignment disabled to configure it's intended purpose of material creation only.

Like Brian said, the library can still assign materials to multiple objects, if used correctly.

jsmack

OneBigTree

BrianHanke
For one material assigned to multiple geometries, see below. I'd recommend using a Material Linker instead, much more convenient!

Image Not Found

Damn, I never would have thought of that.

Thanks guys for all your help. I thought I was missing something. I still wonder why the most obvious workflow is the one that doesn't work... A bag of tripwires this software is...

Notice that the material library material entry list is called "number of materials." It be impossible to create the same material twice. The way the list of entries works is later entries overwrite the earlier ones. This can be useful for debugging, where you might have duplicate entries to compare looks. What these two conflicting entries mean is: make the ball blue; scratch that, make the grid blue. The material assignment node is different in that the entries are cumulative, Multiple entries can assign the same material to multiple objects. Material assignment node is the preferred workflow and assigning materials using the material library node is no longer the recommended one. The library's default material name field is '*' and the assignment disabled to configure it's intended purpose of material creation only.

Like Brian said, the library can still assign materials to multiple objects, if used correctly.

Yes I had a hunch it was something like that. It is still something you have to learn for half a day apparently if there's no one sitting right beside you who you could ask. Not very intuitive, especially when your used to just drag and drop materials onto objects in the viewport and the node itself looks as if it would work the way I tried.

Anyway, I think the mat linker is the way to go for me since it provides at least a rudimentary overview over what is assigned to what without having to dive into individual nodes.
Thanks again.

OneBigTree
Yes I had a hunch it was something like that. It is still something you have to learn for half a day apparently if there's no one sitting right beside you who you could ask. Not very intuitive, especially when your used to just drag and drop materials onto objects in the viewport and the node itself looks as if it would work the way I tried.

Dragging materials onto the viewport from the scene outline creates a material assign node.

jsmack

OneBigTree
Yes I had a hunch it was something like that. It is still something you have to learn for half a day apparently if there's no one sitting right beside you who you could ask. Not very intuitive, especially when your used to just drag and drop materials onto objects in the viewport and the node itself looks as if it would work the way I tried.

Dragging materials onto the viewport from the scene outline creates a material assign node.

Really? Why is no one showing that in any tutorial then I was using the material library because that is what I've seen in tuts. I thought that is how you do it.
Again: Thanks.

Edit: But you still have to have a material library to get access to materials in the first place unless the imported objects already have mats assigned in the object context. And if you do this with many objects you get a lot of assign nodes...

So there is a mat lib node that has theoretically all the necessary functions but you still need more nodes to keep everything more manageable and at least somehow accessible.
It still is convoluted and unintuitive, sorry.

You can have multiple material assignments in a single Assign Material LOP. If you continue to drag and drop materials onto objects it will append to the existing node.

Siavash Tehrani
You can have multiple material assignments in a single Assign Material LOP. If you continue to drag and drop materials onto objects it will append to the existing node.

But isn't that the same functionality you have in the material library already? And again, a bunch of strings gets messy when you have a ton of objects with the same material. Makes it hard to find what is assigned to what.

It would all be so much easier if we could just drag the material onto the object in the scene graph where it should be displayed under the object, that way you could drag the materials between object and quickly see what object has which material.
That would be the start of an actual scene tree, where you could manage more than strings....

OneBigTree
It would all be so much easier if we could just drag the material onto the object in the scene graph where it should be displayed under the object, that way you could drag the materials between object and quickly see what object has which material.
That would be the start of an actual scene tree, where you could manage more than strings....

Nothing is stopping you from organizing it that way. The organizational hierarchy doesn't equal the relational hierarchy the way it might in some other apps' scene graph trees. USD has no such limitations. However, you might want to locate materials under the prim they are assigned to for referencing and organizing purposes.

I don't see the case for assigning the same material to 'a bunch of objects' being a common one. Either locate the objects under a common ancestor and assign the material there, or create a specialize reference to a common material under each object and assign that object's specialized material. That would make it easier to change an object's material properties without changing the structure of the scene.

jsmack

OneBigTree
It would all be so much easier if we could just drag the material onto the object in the scene graph where it should be displayed under the object, that way you could drag the materials between object and quickly see what object has which material.
That would be the start of an actual scene tree, where you could manage more than strings....

Nothing is stopping you from organizing it that way. The organizational hierarchy doesn't equal the relational hierarchy the way it might in some other apps' scene graph trees. USD has no such limitations. However, you might want to locate materials under the prim they are assigned to for referencing and organizing purposes.

I don't see the case for assigning the same material to 'a bunch of objects' being a common one. Either locate the objects under a common ancestor and assign the material there, or create a specialize reference to a common material under each object and assign that object's specialized material. That would make it easier to change an object's material properties without changing the structure of the scene.

First, I don't know how to organize it this way. I am using solaris only because I want to get familiar with Karma. I do have neither the knowledge nor the time to learn to do all the things you suggest, no matter how helpful that may be once it is actually configured.

I am, however, surprised that you see assigning material to a bunch of objects an edge case. If you have ever tried to clean up, restructure, reshade and or reassemble a CAD dataset consisting of thousand of cryptically named parts in hierarchies that make sense from an engineers point of view but is completely unsuited for a viz project, then you would embrace anything that lets you quickly grab a hundred objects and assign a "screw-metal" material to them. That happens a lot. Not everyone works for Holly, Bolly or any otherwood.
Again: The amount of work that has to be done in Houdini to achieve any of this, even though is is achievable, is still significantly higher than in most of the tools I have used in the last 30 years. This reminds me of the guys using Maya when I used Softimage. Every time I asked them how to do something I knew from Softimage in Maye, the answer was: You write a script. And thus while they were achieving amazing functionality in Maya, almost on par with what I was using, by writing their scripts, I was already rendering.
I have the same experience in Houdini now. As I said in my first post in this thread: Even the simplest things in Houdini can be an obstacle. I never had to ask the any community for something like this.
If it the outcome would be learning a super efficient system that speeds up the actual creation process - I wouldn't mind. But it is not. At least not if you don't want to make your own tools. While other people are already rendering....
Its not that I don't want to learn. I am almost 60 and just switched to Houdini 2 years ago. I just can't afford sometimes for something so simple. And It shouldn't be necessary. A toolbox should make work easier, not more complicated.

jsmack
Nothing is stopping you from organizing it that way.

I do not see anything that allows me to configure the scene graph. Can you point me in the right direction?

(I wasn't talking about the solaris node tree btw. I know how to organize that I meant the tree/list view, solaris and object contect )

This is somewhat tangental, but is there a way in the assignmaterial lop to just append the current selection into the primitives field? Right now I can't actually figure out how to do that, which seems like it would be one of the most common workflows once the materials are added to the node.

Going a little fancier, it seems to me like an additional swatch view for assignmaterial, where the colors of the materials are visible would be nice. Right now if you have a dozen materials specified in assignmaterial it seems tedious to have the 5x per material parameters on display with scrolling involved, when all you want is to quickly get a visual on the correct material and then append to the primitives field via a click or two.

Dragging material from tree to object is ok in my testing. Except
some refresh problems that can be solved by mouse clicking.

Thanks @jerry7 the material drag and drop from the SGT pane works for me as well, but it's too much mouse movement for doing bulk assignments. Unless you can restructure an asset by material, a bulk assignment workflow really needs to be select + hotkey imo so that you only leave the viewer to change the 'current' material.

antc
Unless you can restructure an asset by material, a bulk assignment workflow really needs to be select + hotkey imo so that you only leave the viewer to change the 'current' material.

Use the select widget on the material assignment prim path, then select to you hearts content. Hit enter and all the select prims will have their paths entered into the box.

jsmack

antc
Unless you can restructure an asset by material, a bulk assignment workflow really needs to be select + hotkey imo so that you only leave the viewer to change the 'current' material.

Use the select widget on the material assignment prim path, then select to you hearts content. Hit enter and all the select prims will have their paths entered into the box.

Hmm so for me that almost works, but again it doesn't appear to be additive. Each time I use it it effetely clears the current assignments which doesn't seem particularly useful.