How would we mix usd texture? I tried all the ‘mix’ nodes.
Now we are here. Is it strictly necessary to have another ‘USD’ VOP node to be able to do this? I am somewhat confused sometimes about why VOPs of different renderers can't work together, even when just trying to use the basic math functions.
USD Preview Surface shaders don't support even the simplest of mathematical operations. It defines a “shading language” with only 4 or 5 funcitons, a limited set of connections allowed between those functions. It is defined as a lowest-common-demoninator that all other shading languages should be able to implement, and which should also be easily implementable in a GL shading context without having to dynamically author GLSL code for each USD material. As such, even addition, multiplication, and layering operations are not supported by the USD Preview Surface “language”.
OdFotan I am somewhat confused sometimes about why VOPs of different renderers can't work together, even when just trying to use the basic math functions.
VOPs of different renderers can never work together.
I understand a little bit that these VOPs are like little programs that people have wrote, but what's somewhat confusing or misleading to me, as someone who is not super-duper technical, is that you seem to work with just normal ‘vector’ data, if you loop at the VOP inputs and outputs, right.
The vector output of a Houdini texture VOP looks the same as the vector output of a USD Texture VOP. Same datatype when you hover over the output, and same color on the dots, etc.
Do you guys think it could maybe somehow be made a little more clear, on these outputs, that it is more than than just vector data we are working with? Whatever more that is.
Do you think that is a reasonable ‘rfe’, or am I missing something?
- How can we inspect these things? When I click ‘View VEX Code’, I see not much code, I suppose this code links to files on disk or something?
Traditionally, VOPs were used to generate shader source code (like VEX, RSL, OSL, etc), where a VOP represents a snippet of code. And they still are.
But their role expanded to represent shader as a whole (like surface shader, etc), whose code has already been compiled, and is available to renderers as a file on disk (etc).
The VOPs that represent the standard USD shaders are of the second kind. They don't generate code (that's why you can't “view VEX code). Instead, when cooking, a LOP interprets them (their parameters and connections), and translates them to USD primitives.
After all VOP is a high-level abstraction. It can represent a shippet of code, or a readily available shader. They were used to prototype the TOP nodes at the beginning. They can be interpreted as anything you want, if you write an appropriate ”interpreter“ or ”translator".
As for data types for different renderers.. it is really data types for different languages. And it is up to the renderer to support the languages. Eg, an OSL Shader builder has an output of a ‘color’ type that you may want to connect to a ‘color’-typed input of Pxr Disney shader. It turns out that RenderMan supports both OSL and RIS, and allows such arrangement. So the network is correct and works.
On the other hand, currently, Karma does not support OSL, so if you plug an output of an OSL Shader Builder to an input of a Principled shader, then that will not work.
So that whole input-output compatibility becomes quite nuanced, because in theory RenderMan may decide to support VEX, and plugging OSL shader to Principled shader is going to be legal, but only when rendered in RenderMan and not other renderers.
Anyway, we need to revise the language customization and renderer support in VOPs to make it all more clear and to support shader writing workflows that became possible in LOPs.
jsmack VOPs of different renderers can never work together
Oooh, so close …. there used to be VOPs that would define VEX for Mantra and RSL for PrMan, but I think that'll all a thing of the past now with RIS.
I know, but I'm not sure if the truly generic VOPS count as ‘from different renderers’. And there are some exceptions still. A few third parties choose to parse mantra principled shaders as their own native material as well as nodes like the bind or parameter vop.
