Marco Dörner
Nov. 17, 2020 12:52:25
Hi,
I'm debugging an issue in our pipeline and think I might have tracked it down to this:
When duplicating a (redshift) material primitive I'm getting an error (see screenshot) plus a warning saying that the chosen primitive is no movable primitive.
If I render without the duplicate node my scene looks fine, but if I use (or even edit) the duplicated material afterwards things are getting funky (some textures not working anymore on the shader).
- Why does Solaris have a problem with duplicating shaders (or prims that have no transform)?
- Is there a better way of creating a copy that is still linked to a material “above” - so when the “above” material changes, the copy will so too?
mtucker
Nov. 18, 2020 15:44:09
I'm assuming you're using a Duplicate LOP for this?
I don't know where that error message is coming from. It's not part of the duplicate step, it is instead related to the translation of a VOP network to USD primitives. If you could attach a hip file someone here could take a look at why that error is being triggered. I also can't guess why the duplicate materials might now be working. In my simple test case with a USD Preview Surface material I was able to use and modify the duplicates successfully. I guess the problem may depend on how you are trying to modify the duplicates, so again a hip file would be useful.
The “transformable” warning (not an error, and you can safely ignore it) is because the Duplicate LOP tries to apply a transformation to each duplicate. There's really no value to that warning, so I'll look into suppressing it.
Marco Dörner
Nov. 20, 2020 07:17:28
Thanks. The error doesn't show up consistently so maybe it's independent of what I'm doing. The material error by now I could pinpoint to a redshift-bug (I think - unless they tell me otherwise ; ) )