tylerart
Ok, I think I figured out that I have to reference the asset file directly into my stage, I can't just pipe into a new reference node with a new layer. Once I've referenced the file directly, it seems to work fine. I'm guessing there's a flag somewhere that I need to set, just not sure what I'm missing.

I'm not sure if this is the original thread/question, but your issue is related to composition strength ordering LIVERPS: the variant set opinions (i.e. "V") are weaker than the direct layer opinions (i.e. "L"). When you defined the sphere, you authored an active opinion. When you referenced the asset into a scene, that weakened the activation opinion on sphere1 down to an "R", and therefore the "V" opinion won out.

Also worth mentioning, USD does not allow animating Activation or Variant Sets selections. Sometimes Solaris gives the illusion that it can, because you can animate a LOP node, and it recooks and sets activation as the time changes. But when you write out your animation to disk, you'll only see the last value authored. Whereas with visibility, you would see multiple time-samples animating the objects on/off.

tylerart
An additional thought - If you have a scope with prims inside them, and deactivate the scope, you can't re-activate the scope again to bring those prims back, despite the data being in the usd file. It seems that the data below the scope is no longer accessible?

Setting active on the prim should compose the children prims into the stage. I think the only time the children of inactive prims are fully and completely removed, is when you flatten the stage. Otherwise, the data is still there, but just not loaded into memory.

Hope this helps!

No, this input doesn't actually do anything, and there are conversations on the MaterialX side to remove it because of that. If you need to transform the viewdirection, you can plug it into a mtlxtransformvector node.

nicholasralabate
Bump for question about light linker -- is it possible to use Light Linker on geometry lights? I am trying to light link an emissive volume, but it's not showing up at all on the "lights" panel of the light linker...

Not yet, but in a future release this will be possible, as Geometry Lights in USD are now decorated with an ApiSchema, so USD/Hydra recognize them as actual lights.

It's not always the case that layers == nodes, but where possible, LOPs will record a node's id to the "HoudiniPrimEditorNodes". This custom data is set per-primitive, and you can see it in the Scene Graph Details.

You can get at the nodes with a help function we have in loputils, by passing a lop node and prim path to loputils.getEditorNodes(). It just helps get node paths from the node ids stored as customdata.

This is used in the Scene Graph Tree's "Jump to Existing Editor Nodes" option, when you RMB on a prim.

Hope this helps!

It's also worth mentioning, you may need to reach out to the Arnold team for help getting this properly configured, if it's not a husk-relate configuration issue.

Huh, that's really strange; perhaps the Arnold USD plugin is somehow not setup correctly? That error message Can't find Hydra plugin 'Arnold'. suggests that while HtoA might be setup, somehow the USD-side of Arnold isn't? Does this VM have a GUI? And if you can launch Houdini through it, do you get any other clues, when trying to use Arnold in Solaris?

I'm also surprised that it says Karma XPU is also unsupported...

I'm not sure what else could be going wrong, but maybe log a bug with Support, and see if further help can come through that route. It may be some sort of a misconfiguration... and that's a safer place to share potentially sensitive info.

To use the short-hand in parenthesis, you need to put it in quotes (i.e. "Arnold") otherwise you're expected to pass the full name (i.e. HdArnoldRendererPlugin). It's similar for Karma, if you want to use "Karma XPU"instead of BRAY_HdKarmaXPU.

I think that's the issue here.

The light linker should be fairly functional (at it's core, it's just setting up collections), though please log any bugs you discover.

Yes you can control light linking with Python; this unit test from the USD repo should help get you going: https://github.com/PixarAnimationStudios/OpenUSD/blob/v24.08/pxr/usd/usdLux/testenv/testUsdLuxLinkingAPI.py [github.com]

If you find some use case where light linker works with Karma, but not RedShift, it's likely a bug for the RedShift team to look into. Otherwise, please log a bug for us. Thanks!

In USD, reading stages can be multi-threaded, but writing is single-threaded. As for VEX in LOPs, Python is better when operating entirely on USD prims. There is overhead to getting the USD data into VEX, in order to run the SIMD operations in parallel. While the kernels run, threads are saturated, but after those run, we're back to converting data and doing single-threaded writes to USD. This is also why adding VEX into your prim patterns can add a lot of overhead, compared to using the prim pattern functions. So Python is better for performance in LOPs, though VEX can be convenient to write (and is preferred when doing mixed SOP/USD read/write).

Python can be so fast, because it's often a pretty thin wrapper around the USD/SDF C++ operations. It's certainly possible to make the Python functions slow in LOPs, but I'm continually amazed at how much performance can be squeezed out of Python with Solaris.

I highly recommend this presentation by Mark Tucker (Solaris lead), where he goes over LOPs cooking details, and how to make your networks/nodes as performant as possible: https://www.youtube.com/watch?v=ukfe2gOJ3l0 [www.youtube.com]. A fair bit of the details make more sense when writing C++ LOP nodes, but also covers Python, VEX, profiling performance, etc...

Hope this helps!

Sorry I kept getting pulled away, after having this tab open for a bit. I think the subframe range and number of samples just needed to be higher; and then cache the frame range, but on 1's, on the GeoClipSequence.

By default, any unconnected `texcoord` inputs will rely on the default `primvars:st` texture coordinates. If you have UVs using a different name, then you'll want to connect your geomepropvalue reading those primvars, and connect them to the texcoord input. You might also need to convert the vector3 to vector2 explicitly, if it's behaving unexpected.

mtlximage has a recipe in 20.5, which adds some texture controls.

https://www.sidefx.com/docs/houdini/solaris/kug/textures.html#filter_controls [www.sidefx.com]

That node is currently implemented in Python, you can look inside and learn from it. There are also unit tests on the OpenUSD GitHub repo, that are written in Python that use Sdf Changeblocks and do some of these same editing operations.

There was some documentation issues where Transmission Roughness was still marked as not supported (fixed in tomorrow's cut), but everything except Transmission Scatter and Transmission Scatter Anisotropy are supported by Karma in Houdini 20.5.

Hope this is helpful!

Yeah Component Builder is intentionally simple/broad. Usually what I've seen is people do when they need mixed subdivs/meshes, is to append an Edit Mesh LOP [www.sidefx.com] after Component Geometry, to mark their subdivs. In the Scene Graph Tree, if you RMB on meshes, you can select Edit Primitive with New Node, which will create a Mesh LOP in edit mode.

You could also set osd_schemeSOP Attribute to define which parts are subdivs. We'd like to make this easier in a future release, but see this doc here for more info about the prim attributes: https://www.sidefx.com/docs/houdini/solaris/sop_import.html#subd [www.sidefx.com]

I can't imagine why the ROP's frame range would be ignored, in favor of the timeline set in the hip file; seems like a bug to be logged.

Seems to be working in 20.5.236 on my system. Try the latest version, and log a bug if it's still not working. Maybe there are OS/Driver/GPU specific bugs somewhere.

The Karma Lens Material is itself essentially a recipe. It isn't currently implemented that way, but it is something we plan to convert over.

But there isn't a Karma Lens Material LOP node type to "host" the recipe.

tomtm
Thank you goldleaf, it's good to have some sample files. It's rocket science :-)

No problem. We've also just added a related example to the Content Library. It's the Warehouse scene used for some of our launch demos. It has some complex and simple examples of light instances (as well as some other features/workflows).

https://www.sidefx.com/contentlibrary/warehouse-lights/
[www.sidefx.com]

tomtm
Just another question: What exactly means in Karma Primary Samples Minimum Samples -1? What is -1?

It means Karma will automatically pick the minimum number of Primary Samples to fire, before it starts the adaptive sampling. We'll have to make a not to clarify that info in the docs/user guide.