In performance terms, for lookup with VEX (pcopen, etc.), is there any practical difference these days between storing points as .pc files or .bgeo?

For .bgeo, does ordered vs. unordered matter?

I just tried portal lighting for the first time in 20.5.

It looks like there is different behavior between XPU and CPU.

In XPU, the original dome lights remain visible. In CPU, they are turned off.

Is this expected?

Also somewhat related to this, is there a way to cache time samples on only *specific* prims, rather than the entire stage?

The scenario I have is that I am using the timeshift LOP on a particular prim, but there are no parameters to re-calculate the full frame range so I end up with a time dependency in the node graph. If I attempt a cache node afterwards, any value clips are cached in full per-frame which I don't want.

Is there an efficient way in Solaris to alter the timing of value clips?

Using "timeshift" + "cache" does not alter the clip metadata but the actual primitive attributes, which makes sense.

But if I know I can retime the clip information only and change the metadata it would be much more efficient. I have already been able to do this via a VEX script but it's lots of code that seems like it should be wrapped up somewhere in a node.

Here is some example VEX that I wrote to change clip metadata (we have internal examples that use spline lookups for more complicated retimes):

I'm trying to extract some AOVs from particles that are partially transparent and constant shaded. For mattes, for example.

Unfortunately it seems that AOVs are multiplied by the opacity no matter what... which seems wrong and difficult to work with, since... they're AOVs and theoretically should be able to do anything.

Maybe I'm getting old but I seem to remember doing this easily enough in Mantra.

So I now want to try the LPE approach and make an AOV for each subset of my particles' shader emission. Ideally a prim for each particle group, and tag them with a LPE tag and make a different render var for each.

Does that work?

If you're intending the boat to become an asset in a larger scene, I recommend setting it up using the Component Builder framework. You can use a pre-existing USD as an input file in the "Component Geometry" node, then in different branches you can activate / deactivate the masts and plug them into component geometry nodes.

If you're new to Solaris but have some Houdini experience I recommend Peter Arcara's tutorials here:
https://www.sidefx.com/tutorials/usd-asset-building-with-solaris/ [www.sidefx.com]

Shouldn't these eventually be visible in SOPs too, since that's a sanctioned way of working with COPs now?

LOP networks currently have a huge performance overhead if you are doing animation work that involves multiple deforming SOPs, camera moves, interactive tweaks, etc., mostly it seems due to time dependencies causing lots of unnecessary cooking in LOP networks.

Until that changes the old /obj workflow isn't going anywhere. That said, if you are just generating self-contained geometry, a SOP Create is a pretty good option, especially now that you can look through the LOP camera while working within the SOP context.

Yes, subnets are great! I use them probably more than a lot of people. If you do any programming, think of them as packaging little self-contained functions in your graph.

To honor the title of this thread, I return to the general question:

Is there any way to add EXR metadata using Husk that doesn't involve editing the render product? For example I'd like to set an attribute that holds the unique ID of the farm job that executed the render, but that isn't something that gets baked into a USD normally.

Pre-frame script is probably the way to go?

Yes, USD has reintroduced this nuisance. One easy way in Solaris to remove the scale is to use a parent constraint with the parent set to “/“ and have only scale checked.

I just had a similar question...

Is there any way to define render callbacks via HOUDINI_PATH, similar to either of these existing methods?

- add husk pre / post event callbacks via python startup scripts somewhere in HOUDINI_PATH
- create a file and register it, similar to the husdoutputprocessors workflow

In Karma CPU you can customize a lens shader and set the &valid value to zero to not render a pixel. See the docs here:

https://www.sidefx.com/docs/houdini/solaris/karma_lens_shader.html [www.sidefx.com]

animatrix_
Hi,

I don't think xyzdist would return all of them. I haven't tested this but I suspect it returns the polygon whose normal is pointing towards the origin point.

In any case if you want to detect all overlapping polygons, you could use xyzdist first to find the nearest prim and then fire a ray in that direction using the intersect_all VEX function to find all intersected prims along that direction:
https://www.sidefx.com/docs/houdini/vex/functions/intersect_all.html [www.sidefx.com]

intersect_all sounds like a good idea, but I tried this on a point inside of a tetrahedral and intersect_all doesn't seem to be aware that it's within the prim unfortunately, which *does* work when using xyzdist.

An idea for grabbing all prims is to use within a render time shader and accumulate samples, but looping over all prims is going to be too expensive.

A constraint for my requirement is that the points that define the prim don't necessarily overlap, just end up generating a prim that can be found in the same sample point.

What does xyzdist do if two prims are overlapping identically?

I'm asking because I wonder if there is a way to detect all prims that are exactly the closest (for overlapping triangles or tetrahedrals).

https://www.sidefx.com/docs/houdini/vex/functions/xyzdist.html [www.sidefx.com]

That did it! Thanks for the tip. Very cool to see this works!

EDIT: BTW, I did it manually instead of using loputils to keep the core code free of Houdini dependencies.

Hello,

I'm not sure where to find this info: is it possible, using only Python, to build a stage similar to the way stages are defined in a LOP network, where one can build and layer anonymous layers and then save them all to separate explicit paths using the USD ROP?

Here is what I would like to do:
- take the Solaris stage as an argument to a script in a Python LOP
- on this stage object, import various files, and create a USD layer for each. Add an explicit save path to each (but don't save yet!).
- build a hierarchy of layers using these imported files
- take the resulting stage output of the Python LOP, then save everything with a USD ROP

What I have tried to do so far in Python for each created layer is:
- create an anonymous layer and add prims
- create a "HoudiniLayerInfo" prim in the anonymous layer
- set the attribute "HoudiniSaveControl" to "explicit"
- set the "HoudiniSavePath" to my desired path

I hoped this parlor trick would convince Solaris to save my custom layers, but it did not seem to do so. The USD ROP just saved my root layer and ignored the anonymous ones, even though they had the save info prim embedded.

Is there a better way to do this? I'm aware I can just save the layers as I create them, but wanted to utilize the LOP output processors.

What's the recommended way to modify the PATH environment variable to pass on to work items? In the farm schedulers, PATH gets ignored because it contains paths in $HFS . I'd like to just be able to prepend or append extra paths to the running work item's environment without clobbering any existing path items on it.

I guess a Python pre-render script is the best approach?

Is there any way to tell Houdini the precision of an attribute when creating it using Python?

For legacy reasons there are some differences in how the root is handled and also how different network types are handled. For example you still need a separate topnet in the /tasks context, but not a separate ropnet in the /out context.

Slightly annoying in an OCD way but I would be surprised if this changes any time soon.