Yeah Beta XPU doesn't yet support the various BSDFs. You will not be able to create standard surface from scratch and render with XPU. Even if you build a nodedef/nodegraph using those python scripts.

The pros of visibility-variants is the prims are always available for edits; the downside is USD does some level of composition/processing, even for invisible prims.

Variant-exclusive prims, where the prim doesn't exist except in its variant, are more efficient for USD (because USD has no awareness of the contents of un-selected variants). The cons are that you don't have the prims available to overlay changes, unless you loop through all of the variants.

I'm sure there are other pros/cons to each approach, but those are the ones I can think of.

There is also the Restructure Scene Graph LOP [www.sidefx.com] that can do some measure of restructuring (reparenting, renaming, removing). It requires sub-layer flattening of the inputs, but is another option to keep in mind for these sorts of cases.

It's because the Assign Material LOP can only see cube1 or sphere1 at a time. If the node can't see a primitive, it won't author a material binding. USD supports authoring to a pure "over", which basically says "if a prim is ever defined here, give it this material binding". Most LOP nodes don't work like this, because usually that's not what people want/expect.

It's usually better for the assignments to either be authored within the variant. Even if the material itself is not defined within the variant.

Another approach is to only control visibility or activation in the variants. This means that all (or nearly all, if using activates) of the prims are present, and can be edited by LOP nodes. I believe this is the approach Pixar takes for model variants. I've attached an example of visibility-variants.

Hope this helps!

For those who are interested in some of the stuff @tamte is referring to, here is a little summary. Hopefully it provides a bit of context.

MaterialX makes artist-produced looks portable between renderer/shading language details. The shader definitions (i.e. nodedefs) can be implemented by code or as nodegraphs. Most renderers use their supported code generator (OSL, MDL, etc..) to generate shaders for their renderer, from the .mtlx documents.

When a new nodedef is code-implemented, support for the different shading language code-generators is expected. That's the downside to the code approach, as it can take longer to get those ready for contribution. The up-side is you can do whatever the shading languages support. OSL, MDL, GLSL, (and now Metal [github.com]) all have their differences/quirks, but at this level one is dealing with actual shading languages. An example is Worley's GLSL implementation [github.com], as contributed by Mark Elendt.

If a nodedef is implemented as a nodegraph, the existing codegen will just work. However you are limited to working with existing nodes, and not a shading language. Some lower-level behavior required by in shaders may be difficult or impossible to implement. Or the implementation is exceedingly awkward and requires vast numbers of nodes.

As mentioned in the previous message, Karma doesn't use MaterialX's codegen. Code-implemented nodedefs are written in VEX or C++, by Karma developers. Nodegraph-implemented custom MtlX shaders only need mtlx2karma.py(json-representation/registration) and and mtlx2hda.py(create VOP node for users), to be usable by Karma.

tamte
how does one implement a new node that works for all MtlX renderers?
I assume implementing codegen targets will not make it work for Karma since we've been told Karma is not using any of those languages
But if Nodegraph doesn't have many basic functions what are the options if we don't want to implement basic libraries (like random, matrix math, quaternions, ...) using only available very elemental math functions from scratch?

Karma is unique, but adding a new node for all MaterialX renderers, requires adding support to the various shading languages MaterialX supports, if it cannot be built using nodegraphs. When new code-implemented shaders are added to the standard library, than SideFX would need to add support to Karma CPU/XPU for a given node.

As of today, Karma doesn't provide a way for users to Karma/MtlX code-implemented shaders. We know it's something many people expect/need. For now the only low-level shader authoring support we have is pure VEX shaders for Karma CPU.

These are great, nice work @Faitel!

In addition to Orbolt, have you considered making some PR's upstream to the MaterialX project? Here are some that we've contributed recently:

• MtlX Unified Noise [github.com]
  
• MtlX Color Correct [github.com]
  
• MtlX Bump [github.com]
  

If you check out those PR's they can give you a feel for what it took for the PR to be accepted. There were also some discussions on #materialx channel of ASWF slack. Some of these nodes feel like they'd be good nodegraph contributions. The MtlX TSC may prefer some of them to be lower-level, and implemented in code for their codegen targets (OSL, GLSL, MDL, and soon Metal), but it wouldn't hurt to submit a PR.

The MtlX Graphs can be output from HDAs pretty easily (using vop2mtlx.py that ships with Houdini), then hand-edited into the standard library files (which is how I did it for those PRs). Or you could try the new MaterialX Graph Editor, and see if that's easier.

The Asset Reference node is just a convenient wrapper around the vanilla Reference, Set Variant, and Transform LOPs. Often when referencing assets, you want to position them and/or make variant selections. This saves you from having to create multiple nodes to do these tasks.

BTW, the viewport team would appreciate a bug report for MtlX shader issues in MtlX. They are keen to squash these! If you build a material in the USD MaterialX Subnet, you won't mix in Karma-specific nodes by accident.

Thanks!

The procedural does output primvars:idon the Procedural Prim curves. I think the problem is the int to float connection, which for some reason isn't just auto-converted in every case? Also generating simple random numbers for Karma/MaterialX in-shader is more awkward than it should be, we're working on it.

Hope this helps in the meantime.

Hair Procedural only supports velocity based blur in Houdini 19.5. The velocities authored on the guides gets transferred onto the deformed/generated hair. We hope to support multi-sampled blur in the future.

Can you share a hip file? And which renderer are you using? Is the renderer providing the error message?

The For Each LOP is not actually changing the variant, it's just cycling through the variant set's values (i.e. all of the "model" variants). Similarly, when iterating over primitives or numbers, those are just values filling out the context option values.

To see these values in this case, you could use a Set Variant LOP. Set the prim path to "/model" and variant set name to "model". Then you can use `@VARIANTNAME` set the variant. If you don't want to author the setting of this variant, append a Layer Break after the Set Variant node.

To edit the variants via For Each LOP, you'll also need an Add Variants LOP. You just need to make sure all of your additions/modifications are children of the variant primitive (i.e. "/test" in this case).

This is a workflow we want to improve in future releases. Hopefully this example helps in the meantime.

I haven't heard of this happening with Nuke and Karma... but if no one else chimes in, and you're rendering with Karma, I'd suggest logging a bug through support or the website form [www.sidefx.com], with an example hip file as well as the .exr

Thanks. I'm inclined to think there is a bug in the Quixel export... if it works fine with renderers other than Karma/HoudiniGL, then I'd go ahead and log an issue with Support; but I can't tell why it's not working, other than it looks like something about the Normals map is wrong.

What you're trying to accomplish is better handled with PDG, if I'm understanding everything. For-Loops in LOPs/SOPs aren't really intended to write files to disk mid-stream, but PDG is great for this. In theory you could use the built-in loop on the Component Geometry Variants LOP, but in your particular case, each asset is so wildly different, you don't really gain much by combining them all into 1 "uber" asset with variants (especially if the goal is to just get a bunch of KB3D assets into Solaris).

Coincidentally, I had been started an example for a similar purpose, so I cleaned it up and applied it to the free minerva mission kit [kitbash3d.com]. The converted material will render with Karma CPU, but not the XPU beta, since KB3D authored these as principled shaders for Mantra. I am not sure of all the details necessary to get a USD Preview Surface or Usd MaterialX Standard Surface material, but I'm sure it's possible.

Drop this file next to the original "kb3d_missiontominerva-native.hip", and it should work as expected. I've set "ASSET_NAME" to "Asset_M" in the Context Options Editor panel, for preview while setting up the graph. Because this hip file re-uses the original .bgeo files directly and are using the textures as-is, the exported USD files and gallery thumbnails only take up ~2Mb of disk space.

Hope this helps!

I'm not sure why this would slow down the assign material node; the viewport slowness due to displacement/normal-map materials can be resolved by using PolyFrame to author tangentuattribute on the geometry.

If you can share a hip file, that would make it easier to help figure out what the issue is.

I'm not sure which one you're referring to, that could be corrupted. If you select the mesh prims in the Scene Graph Tree, and look at the Scene Graph Details, you can see what the name of your surface parameterization is (i.e. stor uv- some USDZ files have decided to use st0by default...). As long as that name is in the USD Primvar Reader, it should work; you may also want to double-check that the type matches your primvar (i.e. is it a vector2 or vector3).

I wouldn't think any seam issues are in the shader; but you might need to log a bug through support, where you can securely/confidentially share the files with us if necessary to resolve the bug.

The material issue is because you are not assigning any materials to the generated "RenderProcedural" prim (i.e. /houdinihairprocedural1)

For instancing, the current procedurals process requires that the procedurals prim and their targets be active and directly editable on the stage. This means that instancing the same procedural setup multiple times can require some setup. There is an example available on the Hair Procedural's help card; I've also modified your hip file to demonstrate how to set this up, and added a few sticky notes.

That error about a missing attribute is actually because the procedural tries to import the instanceable geometry, which gives it nothing. So instead of saying "I have no geometry" it says "This attribute is missing" - while this is technically true, it's also very unhelpful. We are working on improving the error reporting messages for the procedurals and some of the underlying technology they leverage.

Hope this all makes some sense, and helps get you unblocked.

Yes; you would put the variant set blocks within each other, like this. You also need to ensure that the nested variants are authored on the same prim as the outer-most variantset, or on a child of that prim; the data within the variant must be encapsulated beneath that primitive.

Hope this helps