Creating new attribute overrides for RenderPasses.

[Matthias Bjarnason]

Hey everyone,

I'm currently exploring Gaffer's (1.5.16.1) Render Passes and EditScope workflows (using provided example scene) and have hit a minor bump while trying to recreate the setup from scratch.

Should one not be able to "drag 'n drop" plugs (attributes) onto the column "plus" button, within the RenderPassOptionEdits window, to add overrides to ones render passes? Surely creating them all manually can't be the only way to operate the passes, yes?

Even the tool tip (hover over plus sign) mentions this but when I do nothing happens - I can hovever create a new column manually by hitting the button just fine.

Am I missing something or this a UI bug of sorts? Anyone here had the same problem or able to provide some info on what I might be doing wrong?

Any info greatly appreciated.

Best,

[Matthias Bjarnason]

Hmmm alrighty ...so, I was able to drag a couple of the predefined attributes from the Render Pass Editor window to the RenderPassOptionEdits window (window refresh a bit odd though). That then suddenly stopped working though (after 2 or 3 ... which I can't figure out why yet)

But this got me thinking: Are those predefined attributes/render options the only ones that can be overridden (or controlled) in the RenderPassOptionEdits window, maybe? Is that perhaps the case, that no other "custom" attributes can be added to the Passes anyway and my previous attempts to drag other items in were futile from the start - an odd limitation to the system then ...but that's another discussion I guess?

Monday-brain not braining much - any help appreciated :D

Best,
-M

[Murray Stevenson]

Hi Matthias,

The intended workflow is to use the Render Pass Editor UI to create overrides for your render passes, rather than edit a RenderPassOptionEdits spreadsheet directly. You'd normally do this by choosing an EditScope as your edit target and then double clicking cells in the Render Pass Editor to create edits (much like you'd use an EditScope make edits from the Light Editor and Attribute Editor). When you do this, the Render Pass Editor automatically creates edits within the RenderPassOptionEdits processor of the target EditScope, adding rows and columns within the spreadsheet as necessary. While it's technically possible for you to manually create columns for new option overrides in a RenderPassOptionEdits spreadsheet, they'd need to be named exactly right for the Render Pass Editor to find them, and they wouldn't actually do anything unless you hooked the column up correctly to the internal OptionTweaks node, which does the actual work of modifying the options. Thanks for asking these questions by the way, it's very useful feedback and it sounds like we should consider hiding the "add column" button on the RenderPassOptionEdits spreadsheet to avoid future confusion.

Are there any option columns in particular that you're missing in the Render Pass Editor? The Arnold options currently available for editing there are a subset of the total list of Arnold options, ones that we've found to be the most adjusted per-pass in production. We do intend to support adding and removing columns in the UI, though for now if there are additional options that you wish to edit in the Render Pass Editor, they can be registered within a startup file using calls like the one below to register new columns for those options.

`GafferSceneUI.RenderPassEditor.registerOption( "Arnold", "ai:light_samples", "Sampling", "Light" )` # Register a column for the "ai:light_samples" option within the "Arnold' group, under the "Sampling" tab, with a column title of "Light"

For a bit more info, you can see how the standard set of Arnold option columns are registered here: https://github.com/GafferHQ/gaffer/blob/edde9ecdf987da2b3a305668bf8d55e533de47b6/startup/gui/renderPassEditor.py#L108-L125

Cheers,

Murray

[John Haddon]

On Tue, Aug 26, 2025 at 5:25 AM Murray Stevenson <mur...@gafferhq.org> wrote:

The intended workflow is to use the Render Pass Editor UI to create overrides for your render passes, rather than edit a RenderPassOptionEdits spreadsheet directly.

Just to expand on this, the entire purpose of EditScopes is to provide a point in the graph in which the UI can make edits on your behalf. They facilitate direct editing of the scene in UIs like the Viewer and Render Pass Editor, where the node graph isn't exposed directly. When working in the Graph Editor and Node Editor you're working directly on the node graph itself, and you'd typically use the regular nodes (StandardOptions, ArnoldOptions, Spreadsheet etc) instead.

 

[Matthias Bjarnason]

Hey John and Murray,

Thanks for the detailed info - very helpful indeed.

Yes, I did learn ...after more frantic plug dragging and button pressing ...that in order to get the attributes visible in the spreadsheet all I needed was to "activate" the attributes by double clicking them (as you mention)... not drag drop. Starting to explore this workflow, I just assumed that this method was a bit more robust already (and bit more artist friendly) - thinking all render tweak options/attributes upstream (not just a subset) could be added to the tables and "easily managed" in one place. Even going so far as to control which AOVs would be enabled/disabled per layer/pass ...and as you mention, preferably without having to register these at startup or manually creating the columns by hand.

Currently in our workflow we break out each render layer/passes to separate branches to be dispatched, each containing all the "regular" attribute tweak nodes and overrides as required (we're not much into the spreadsheet workflows yet). Although perfectly fine and clear/readable, I've been exploring other methods to see if we can improve our setup and node overviews to be perhaps a bit less cluttered. Hence this exploration of the built in (new) EditScopes and RenderPasses - seems I just came at this from a slightly off-angle.

I have yet to explore this more in-depth and, with your very helpful info, we might find a way to use this to improve our current workflow/script setups but it sounds like we might want to wait a bit longer.

Thanks again,
- M