Extending Render Pass Usage

   735   3   4
User Avatar
Member
2 posts
Joined: June 2014
Online
Hi,

It's my first time using Solaris, coming from a background with Katana and Gaffer. I'm currently familiarizing myself with the Render Pass system and looking for some clues.

Generally, the way it's implemented is useful, but seems to be lacking some advanced features. Ideally, I would like to be able to do more to a pass, than what is exposed in the Render Pass node.
In Gaffer for example, a similar RenderPass system is also implemented, but comes with the additional benefit that any created pass can also be accessed via the context-system. This in turn means, that I can do arbitrary overrides on a given Render Pass (eg using switches, driven by RenderPass context). This is useful in scenarios where one might want to do overrides to a light, surface shader, etc on a per-pass basis which is a common task.

I understand that it is possible to replicate something similar in Solaris, but I'm curious if there are any plans to extend the Render Pass system, or whether there might be any similar options I have missed.

Thanks in advance,
Julius
User Avatar
Staff
634 posts
Joined: June 2020
Offline
What is exposed in Solaris right now is the USD Render Pass node in its vanilla state, along with support in husk for pass-driven rendering (i.e., you can specify the pass you want to render) and in Karma for "visibility" (global, camera, matte) overrides.

We do have Context Options (https://www.sidefx.com/docs/houdini/ref/contextoptions.html) in Solaris which would - at least largely - enable what you're after, and you can absolutely treat them as a pass-management system. Conditional overrides to a light, for example, will push you outside what the USD Render Pass can offer, which means you'll need to author per-"pass" USD files. In contrast, if you limit your overrides to the visibility controls offered by the Render Pass, you can author a single USD file with several passes.

There is definitely an interesting space here for further tooling&workflow design, with a multitude of potential solutions.

Hopefully that provides more clarity than confusion
User Avatar
Member
2 posts
Joined: June 2014
Online
Thanks a lot for the reply. That all makes sense.

I'm pondering how an implementation with a broader scope of features would look like. Ideally I would like to make use of the USD RenderPass system, but with the limitations I suppose I have to add another layer in the form of context options on top. Use the built-in RenderPass system to handle visibilities and use context variables for any additional per-pass overrides.

Consider the following example. A simple scene with a sphere, a cube and corresponding passes. The RenderPass nodes are used to set visibilities. Now, I want to do more to a given pass than setting visibilities only. In the cube pass I want to modify the rotation of the light. For this I'd need an additional variable. (I understand that in theory I could output the pass directly without a switch, but in a multishot scenario I might want to do overrides per pass in a specific shot branch).
Now the issue with this approach is that I need to manage both the active pass and the corresponding context option:



I tried looking through the API to find a way to grab a callback or similar of the currently selected RenderPass in the viewer, but had no luck. How could one go about this? I could skip the RenderPass system entirely and create a separate pass system, but of course it'd be great to utilize what is already available.

Hope that all makes sense. Thanks in advance,
Julius

Attachments:
solaris_rp_01.png (562.4 KB)
solaris_rp_02.png (569.6 KB)

User Avatar
Member
9727 posts
Joined: July 2007
Offline
I think you are expecting too much out of it
RenderPass prims are an USD concept which is currently more about simple visibility settings than anything else despite the overloaded name
To make it do additional overrides and changes to the stage at the render time (which is when the Render Pass is used), this would need to be supported by USD, since at that point Houdini and LOPs are out of the loop

if you need to modify the stage stick to context options and LOPs, which allows for quite clean workflows
Tomas Slancik
CG Supervisor
Framestore, NY
  • Quick Links