Solaris instance lights and attribute variation

In Solaris we can instance lights onto points.
Make sure your points have  N & Up attributes, like you would with any instanced geo.

The more interesting stuff will be the intensity, exposure, "color" etc.

I know there's a post about this on Matt Estela's CGwiki, but I *think* it applies to an older version of Houdini/Solaris & the instancing method they use there is different - "reference" instead of point instancing. Never sure which is actually better or more efficient!

But how do we access them?? Here's a list of the stuff we can access (taken from the SideFX website)

Primvars

In Solaris/USD, you have access to several light-specific primvars. You can use attributes on the scatter points to drive these primvars. Here’s a list of the available primvars:

• intensity (intensity)

• exposure (exposure)

• width (width)

• height (height)

• color (color)

• radius (radius)

• color temperature (colorTemperature)

• diffuse multiplier (diffuse)

• specular multiplier (specular)

Note that width, height and radius are only available with area lights, while the remaining primvars are available for any kind of light source.

SideFX recommends using Attribute Adjust sops to access these attribs. They're a bit neater and user friendly than wrangles I suppose!

Below is how you use it... plug your points into the Attrib Adjust and type this into the name:

`encode("light:color")`

Don't forget the back ticks - ` `

The same applies to Attribute adjust float, for something like Intensity.. `encode("light:intensity")`

Also.. if you want to do stuff to these attributes in a wrangle (after they've been created), they get given a funky name, but these can be accessed normally

For instance (lol), here i'm multiplying the intensity of the lights with the speed at which they move at in a wrangle.

I'm not sure if the assigned name is the same each time so do check... 

render var for aov, karma, solaris

 
This seems to be the least painful way to make an AOV - using a "render var" node just before the Render Settings.

I've named the node itself "pref", so a $OS can pick up the naming.
Under the Standard tab, set the data type and source attribute name. My attrib is called "rest" and it's a vector 3 float. The source is Primvar, which means it comes from the mesh.

Next, on the Husk tab (this might be located under standard, depending on your Houdini version), the name box is what you'll want to call your AOV (here we use $OS to take the node label, pref in my case) and then the format that we are writing out - color3f (rgb).

rendering with karma/solaris in a more "normal way"

 Just a way to work as if you have a render view, instead of in the viewport.

 In Stage, make a Clone Control Panel tab (where your parameters are)


click the Clones with a arrow button, make a new Local one, select Karma CPU or GPU..
Drag your karma render settings node onto the "Node".
Now you can toggle a render on and off in a Render Gallery window & it will save a snapshot each time (might be good or bad....).

geometry and material variants, instancing in solaris

Variant workflow. Use the Component builder + Geo Variants to build some variants. You'll use the Component Material node to create the mat variants, then packaged them out with the component output. Bake this as a USD.

 

Load your cached out USD. Attach an "explore variants" node and set the mode to explore. Set spacing to zero so they're all at the origin.

Then plug it into an Instancer. Specify the primitives you want to prototype (use in instancer). Make sure you UNTICK "Only Copy Specified Prototype Primitives". The rest is as normal (eg make some points inside the instancer and give it an index attribute).

Now all of your variants are in play.

This seems a bit longwinded, but I guess it does work and fits within a pipeline a bit nicer? It also works nicely with the variant systems that exist in Houdini/Solaris.

BONUS - if instead of using the Instancer in "Point Instancer" mode, you use "Instanceable Reference", you gain access to each and every instance. If you do this, you can actually use the Set Variant nodes to change particular instances, eg. you switch one of them to be a pig and make it red instead of green. Performance does take quite a big hit if you do this though. 

crowds in solaris/karma

 Bring in crowd from obj using SOP Crowd Import node (here it's still packed agents). Create Instanced SkelRoots is preferred I think

Stylesheets don't work with Karma/Solaris (as far as I know!) To target props/shapes in a crowd you're best off using Collections. Here we're making collections of the hammer prop. 

It's important to tick Allow Instance Proxies in Collection!

The syntax is %reference:/path
In the example it's %reference:/crowd/agentdefinitions/ball/shapelibrary/l_hammer

Here's the stage scene outliner thing

Assign the materials to the collection by typing in the name. Eg. %hammer

Be sure to expand the Material Binding and tick Include Descendant Primitives in Collection
You might have to change the Strength to Stronger or Weaker than Descendants too.

I couldn't see a good way to access point attributes (eg. per agent float/int values) but Material X does read them - so I guess use switch RGB and stuff like that?

This seems to be the user data equivalent-

This seems to be the best switch RGB equivalent-

Just plug em in like this - just like Arnold

And ta da...attributes and collections targeting different bits of a crowd!