Search - User list
Full Version: How To Implement Separate Render Passes in Solaris?
Root » Solaris and Karma » How To Implement Separate Render Passes in Solaris?
jlapre
The Mantra render node has an Objects tab with Candidate Objects and Force Objects fields.
e.g. I have a houdini scene with a starBackground, planet and moon /obj/geo nodes.
I want to render separate passes of each.
So I can have a Mantra node called starBackground with starBackground in the Force Objects field.
The same for planet and moon mantra nodes.
These can be daisy-chained and the bottom node submitted to our render farm.

however, I don't see a corresponding Objects tab in the LOPS Karma node.
How would you implement a daisy chain of karma nodes in LOPS?
Each one would render the starBackground, planet and moon separately?
I could do it with Prune LOPS for each pass, but is there a better way of doing this?

Thanks
jsmack
you could use prune lop, but then the objects won't exist for holdouts, shadows or reflections.

The render geometry settings node can set the ray mask for phantom or matte behaviors. These can be set differently at the bottom of the node graph with a usd render node branching off of each one. Another, more advanced option is to use context options to switch settings on nodes further upstream of the rop.
tamte
You can look inside of the Karma ROP to see how it's implemented there
Tim Crowson
Standard approach is to probably use RenderGeometrySettings LOPs. This node lets you set visibility flags on objects. You need one node for each type of vis override you wish to do. For example, one node for phantom objects, and another for matte objects. You likely won't need a third node for primary/camera objects, since that is the default state of most prims anyway.

And since that can get tedious for each pass you wish to render, making an HDA out of it would help a lot.
jlapre
I'll give the RenderGeometrySettings LOP a try. Thanks jsmack, Tomas, and Tim!
jlapre
The problem I'm running into using RenderGeometrySettings, is that there are many objects in my scene.
To Tim's point, it is tedious having to manually turning off visibility for all the objects in the scene except the one object I want visible in this render pass.
I'm falling back to the prune LOP, because it has the Prune Unselected toggle.
It would be helpful if the RenderGeometrySettings LOP had a similar toggle. i.e. apply to unselected.

Unfortunately, using Prune LOPS, I can't daisy chain Karma renders, as the parent Prune LOP appears to override the child Prune LOP. Even though I have Make Invisible selected instead of Deactivate.
Mark Wallman
Hi. To select lots of objects one thing you could look into is the collection LOP, best. Mark
antc
Would a lop pattern that selects the inverse of the object you want be easier maybe? For example

* - /moon/** & %type:Boundable

Would match all geometry primitives that are not in /moon
jlapre
jsmack
to use context options to switch settings on nodes further upstream of the rop.

Hi jsmack, could you elaborate on what you mean by "use context options to switch settings on nodes further upstream of the rop."?

I studied the karma render rop in the /out context, but I don't think it's using what I had in mind. i.e. a way to daisy chain karma LOPS, each with their own geometry visibility.

Thanks
jlapre
Mark Wallman
Hi. To select lots of objects one thing you could look into is the collection LOP, best. Mark

Hi Mark, I'll take a look at the collection LOP.

Thanks
jlapre
antc
Would a lop pattern that selects the inverse of the object you want be easier maybe? For example

* - /moon/** & %type:Boundable

Would match all geometry primitives that are not in /moon

That might be what I'm looking for. I'll give that a try.

Thanks
jlapre
Ok, I think I got antc's suggestion working.
Please refer to attached screen grab and simplified hip file.
I use a Render Geometry Settings LOP to isolate the starBackground.
Then I append a karma LOP to render the starBackground.
In order to isolate the planet, I first have to hide all geometry with another Render Geometry Settings LOP.
Then I make the planet visible with anotherRender Geometry Settings LOP.
Then I append a karma lop to render the planet.
They appear to be doing what I want.

However, I want to be able to daisy chain the karma lops so I can submit both passes to our qube farm.
When I try to render the bottom karma lop, it doesn't render karma lops higher in the chain.
How do I mimic the behavior of linked Mantra Rops?
Thanks
antc
To schedule render dependencies I think you'll need a ropnet or top network. If you dive into the karma lop you'll see that it's just a karmarenderproperties lop followed by a usdrender rop. So I would try and keep the configuration for each pass in it's own branch (for simplicity) and terminate each branch with a karmarenderproperties lop. In a ropnet you can then build the appropriate network of usdrender rops (one for each pass).
jsmack
Like antc said, don't daisychain the karma nodes, they aren't rops. Each modifies settings of the node before it so you might get unpredictable results. For example, if the first karma node defines an aov, later karma nodes will still render that aov since it's on the stage.

I've attached a scene that uses context options to vary the visibility of objects on the stage with several usdrender nodes at the bottom of the tree.
jlapre
thanks, antc, and Jsmack. I'll check it out Jsmack's example file.
jlapre
jsmack, you have a switch node that references a variable called @layer, but it's complaining that it can't find it.
Sorry if I'm overlooking it, but where is it defined?
Inside your ropnet you are merging all the fetch nodes.
I see that the merge node has Render and Controls... buttons.
However, we are using Qube as our render farm manager.
One of our technical directors, Erik Krumrey, wrote a Qube submission script to accept Karma nodes, but not a merge node.
We would need to write a custom submission script to accept a ropnet/merge node.
How do others on this thread submit multiple Karma passes/layers on your render farms?
Thanks
jsmack
jlapre
jsmack, you have a switch node that references a variable called @layer, but it's complaining that it can't find it.
Sorry if I'm overlooking it, but where is it defined?

It's a context option, it's defined on the fly by the context. In this case the usdrender rop pushs the value onto the stack. You can see a context options parameter on usd and usdrender rops. There are also nodes specifically for setting context options.

jlapre
Inside your ropnet you are merging all the fetch nodes.
I see that the merge node has Render and Controls... buttons.
However, we are using Qube as our render farm manager.

The merge node is just for executing locally. You'll need to use your farm's dependency node for submitting to your farm.

Back when my studio used Qube, we had a custom set of nodes and an abstraction layer for submitting from Houdini.
Piledriver
Hi, i also have toruble to concatenates karma render passes i tried with pdg but i dont know why uses a lot more disk space, i tried also your setup with ropfecth and crashed my pc.. i really don't know how manage it
antc
Piledriver
Hi, i also have toruble to concatenates karma render passes i tried with pdg but i dont know why uses a lot more disk space
Without more details about exactly what's getting written to disk it's hard to know what might be going on there.

Piledriver
i tried also your setup with ropfecth and crashed my pc.. i really don't know how manage it
Again without more info it's hard to help. If you drop down a ropfetch in tops and point it at the rop merge node from jsmack's scene and cook it you should be able to see the output log by double clicking the dot representing the task. Is there anything in the log there?
Piledriver
about your first question i noticed why the disk space its increased and its because when i render on disk with karma there is also a temp usd file that it's out only whe rendering, and so manually render the karma rops one by one work, but inside pdg its like the temp usd don't disappear for every karma nodes
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Powered by DjangoBB