I tested out your scene and I think it comes down to the "Override Output Image" being set on the usdrender node - which will override the path for both renderproducts so they do both get written to disc, but the latter overwrites the former.
If I leave that parameter blank and instead set the path on the renderproducts I get both outputs. However - like in your screenshot above - the crypto passes are bugged in nuke.

Ah great, thanks!

Last question: in the documentation I read that there might not always be a resolved asset path (https://graphics.pixar.com/usd/release/api/class_sdf_asset_path.html#aa3c0d773856b74cc2641846038f06a4e) - is that a possibility in Houdini/Solaris as well or just when writing usd code yourself?

I attached an example, which contains 2 asset setups:
assetA.usd is created in /x/y/z/assetA on disc. It has a texture that lives in /x/y/z/assetA/tx/dif1.exr. In the material setup I reference this texture file as an absolute path, however when I write the usd file of assetA the output processor by default turns that into a relative path --> ./tx/dif1.exr. When I sublayer this assetA.usd into a new houdini scene the texture path I see in the scene graph detail pane is the relative one "./tx/dif1.exr".

Now however, in this new houdini scene, I create a second asset, assetB. With the help of a scripted tool I want to load any existing asset (assetA) and grab the texture from there. So my python script looks at the parameter "input:file" on the shader prim and from the assetA material and there reads the value "./tx/dif1.exr" - however now if I put this as is directly on my assetB shader it does not resolve correctly anymore.

zip file attached contains two subfolders for assetA and assetB. If you only open assetB.hip you'll see the problem.

We have a tool that creates copies of prims in Solaris. These prims have asset path parameters - which, as I understand it, can be relative to where the layer is saved or absolute.
Creating copies of the master prims works works fine for the houdini scenes (/usd layers) where the master prims are created but once those are saved as usds, sublayered into a new scene and then a copy is created the resulting (copied) asset path will also be relative - however relative to the asset from the file path of the master prim layer --> in the current scene this path will not work anymore.

So I wonder if there is a python way of taking a relative asset path and turning it into an absolute. On the USD ROP, I could turn off "Use relative paths" but I'm guessing they have their reason to be there - so I'm guessing I don't want to ban them altogether.

primitive.CreateAttribute(attributeName, Sdf.ValueTypeNames.<type>)

Types I found on the nVidia website: https://developer.nvidia.com/usd/tutorials [developer.nvidia.com]

also helpful: https://graphics.pixar.com/usd/release/api/class_usd_prim.html#a935381d7c7100b583fdcdb0e10dae9e6 [graphics.pixar.com]

Mark Wallman
Hi. Could you upload an example of that please?

Here you go.

jsmack

Tim Crowson
What I'm bumping on is how to query the USD camera in the shading graph... is this possible?

Does the toNDC node accept a USD camera directly?

There is no, 'a camera', there is only 'the camera'--the one being rendered from. toNDC/fromNDC use the rendering camera for calculations, they don't accept an arbitrary camera.

That node cannot be used with materialX though, can it?

@Tim:
We created a tool that projects NDC coordinates on the points of meshes as array primvar and one can use in the shader to get what you're asking - not perfect if render has displacement (I imagine), but close enough for our purposes.

We have used Redshift until December last year with Solaris and USD and until then string variables were not supported there either with no plans to change that (that we were aware of).

PS: Our workaround was to use a switch with all textures loaded in the material and use an integer primvar to select which texture to use. I'm guessing that would work in Karma as well - albeit it limits the scope of how many textures one can reasonably use and it needs to be pre-defined.

Hi,

I'm having trouble with the mtlxtransformnormal node - it seems no matter what space I'm plugging in nothing changes.
I have a vector (for demonstration a constant) that I plug in and the output is plugged into the base_color of a standard surface node - just to see what's/that something is happening.

But no matter what I type into the Fromspace and Tospace parameters the color never changes.
The help of the node isn't really helpful, it doesn't suggest what I can type there so maybe I'm just spelling it wrong. Any help is appreciated!

Oh wow, amazing. I did a quick search for that, but nothing came up - is that documented somewhere - like is there a list of other "hidden" parameters I can access with a dot?

While we're here: Is there a way then to get the ray origin (position of the camera)?

Oh boy, how could I have overlooked that! >_< Thanks!

Hi
Is there a way to get the world position of the current shading point into materialX - like there is a node for the normal, but I can't find one for position. The geompropvalue only seems to read primvars.
I could create a primvar from the point positions in sops, but that wouldn't move with animation.

Thanks for your help.

Ah, thanks guys. When I tried it this morning also usd_relationshipnames() showed the material:binding - so I guess I did something wrong yesterday. Works now!

Is it possible to set the material binding via wrangle node? I found the usd_boundmaterialpath command, but there seems no way of setting it. I also checked usd_relationshipnames and usd_attribnames but I don't see any material in either.

Cheers
M

Ah yes sorry, the referenced file is an alembic. With "reference specific primitive" and a knowledge from the layout of the alembic I can achieve the same result.
I will try setting the USD_ABC_XFORM_PRIM_COLLAPSE env var you mentioned to get to the same result as before. Thanks!

I'm not sure I follow - both reference nodes point to the same file on disc in the screenshot.

I'm running into a problem trying to replicate the behavior of the reference node in H18.5:

As you can see in the screenshot on the left in 18.5 I could completely control the full path of the primitive, including the name. In H19 however it seems the name is set depending on the source - I can only control the path before.

From a pipeline perspective the old way was gold as in lighting we could build our scenes and didn't care if animation updated their camera. Now however, when the name changes, all nodes that use the (old) camera primitive as a parameter will fail and possibly silently where we don't notice until we render.

Is this a bug? If not, can the old behavior be achieved in another way?

The topic isn't Solaris specific, but because of how it can be implemented - esp. in Houdini - seems to fit here best.

I'd like to hear people's thoughts on why an asset would need different materials vs. a single one, when most (/all) aspects of the shader can be controlled by textures. Additionally - with primvars - the material can be further diversified (modifiers in the shading networks eg. color corrections of the textures driven by primvars), even the texture paths could be read from a primvar - so that pieces of the asset get different textures.

Only one material per asset/scene is of course an extreme case and I'm aware for things like skin, hair, ... - highly bespoke materials - you'd want a specific shader. But I'd like to get people's thoughs on the other 90%.

Hi

attached is a very simple scene of a sphere with a materialX standard surface shader. The diffusecolor should be driven by primvars on the object if those primvars exist - if not it should use the fallback color.

However this doesn't seem to work, no matter what I enter in "fallback", the outcome is always black. Am I doing something wrong?

Cheers,
M