Hi - it's me again with my questions about procedural workflows and Solaris. Today it's about the editMaterial node (I've only ever used it with RS nodes - with Karma nodes I never manage to make it work, maybe I'm doing something wrong there. Hopefully you can still understand my problem).

In a scene I have a materiallibrary where a simple (redshift) material and a constant connected to diffuse color is created. If I create an edit material afterwards and load the material I see it as I created - all good.
Now if in the materiallibrary I change the original material by breaking the connection on diffuse and instead connect the constant to spec color (or anything else) and then go back to my (already created) editmaterial node - nothing in here will have changed. Meaning the update did not come through (automatically).
What is worse, if I look at the stage (usda) file I can now see that the color constant is connected to both inputs - the diffuse color and the specular color - which is very wrong.

This kind of makes sense to me on the face of it: The original materiallibrary only writes one line into the code saying that spec color is connected (after the change). And because the editmaterial wasn't updated yet, it still has the shader loaded how it was before when the constant was connected to diffuse color. So it also writes this line into the code. None of the nodes write lines in the code about parameters they don't change, so the edit material doesn't remove the line in the code about the constant being connected to spec - it just adds its own one (which is now outdated).
Parameters have a checkbox next to them which tells the editmaterial if this value should be overwritten or just passed through - but there doesn't seem to be something equivalent for connections. In fact even deleting the color-constant in the editmaterial doesn't change anything - in the code it is still there (again makes sense, because now the editmaterial just doesn't add it's line about it. But it never removes existing lines from the code, it seems).

So now the questions:
1. am I using the editmaterial node wrong - is it not meant to be used in a procedural chain where the input could change?
2. is there a way to update the node to the current state of the input, without deleting it and placing down a new one? (like keeping all the already made changes)
3. is this maybe a purely redshift bug that I should bring up with them? As I said I never get it to work properly with a principled shader for example - all nodes connected to the shader are not loaded inside the editmaterial.


Any inside info on this is greatly appreciated!

PS: I have attached some pictures. 1,2 are from the original material, 3,4 are from the edit material without changes (they are identical), 5,6 are from the original material after changes were made (connection was changed), 7,8 are from the edit material after those changes - they don't come through in the interface, but now in the code we see both connections

Thanks for the detailed description and screen captures.

This kind of makes sense to me on the face of it

Your line of reasoning is correct. When the LOP chain is cooking, Material Library LOP authors the ‘diffuse_color’ input, and the Edit Material LOP authors the ‘transl_color’ input on top of it. That's what the state of VOPs inside dictates to do.

I think the point of confusion is that you assume the Edit Material LOP to be very dynamic, where the VOPs inside reflect both the material from the stage coming in on the LOP's input, plus any manual edits performed by the user after the first loading of the material to edit. Unfortunately, that's not the case. Edit Material LOP can load USD material and create VOPs, but currently can't automatically update them when the incoming USD material changes.

1. am I using the editmaterial node wrong

No per se. I think you just have too high expectations from the Edit Library LOP. It is not as dynamic as you hope, as mentioned above.

Marco Dörner
2. is there a way to update the node to the current state of the input, without deleting it and placing down a new one?

You can try loading the material again. It may preserve some of the edits, but overall the Edit Material LOP is not as robust yet to reliably update the network.

Marco Dörner
. is this maybe a purely redshift bug that I should bring up with them?

No, it's the current state of the Edit Material LOP that cannot handle such workflows.

Marco Dörner
As I said I never get it to work properly with a principled shader for example

Karma shaders are also much different than RedShift or RenderMan shaders, in that they create only a single Shader with embedded VEX code in it. So, Edit Material LOP can't re-create the VOP network, because there are no USD shader prims representing the original network.

Marco Dörner
Any inside info on this is greatly appreciated!

I hope I answered most of your questions. In short, the Edit Material LOP has many shortcomings that prevent doing what you would like. It is only a very basic LOP that handles only fairly simple networks.

That said, we have plans to work on that LOP and improve its capabilities. So, thank you for your feedback. It will help guide our design decisions.

Thanks a bunch for the detailed answer, that clears things up.