Page MenuHome

Cycles: Add support for adding custom AOV render passes
ClosedPublic

Authored by Lukas Stockner (lukasstockner97) on May 10 2019, 12:17 PM.
Tokens
"Love" token, awarded by AndreasAustPMX."Burninate" token, awarded by PiloeGAO."Pterodactyl" token, awarded by Pipeliner."Mountain of Wealth" token, awarded by TheAngerSpecialist."Love" token, awarded by astrand130."Love" token, awarded by Noss."Love" token, awarded by poor."Love" token, awarded by amonpaike."Love" token, awarded by 1D_Inc."Love" token, awarded by sam_vh."Love" token, awarded by Kramon."Love" token, awarded by mistajuliax."Love" token, awarded by wo262."Love" token, awarded by aliasguru."Like" token, awarded by dgsantana."Like" token, awarded by juantxo."Doubloon" token, awarded by lvxejay."100" token, awarded by 1seby."Love" token, awarded by bintang."Like" token, awarded by ofuscado."Love" token, awarded by bnzs."Like" token, awarded by kioku."Like" token, awarded by TheRedWaxPolice."Party Time" token, awarded by manitwo."Mountain of Wealth" token, awarded by irfan.

Details

Summary

In order to use these passes, AOV Output nodes need to be added to shaders.
For each node, a name can be assigned and a Color or Value input can be connected to it.

After adding a corresponding pass with the same name in the Render Pass settings, Cycles
will then render this pass, filling in the connected data for each shader that contains
a matching AOV output node.

In addition to that, there is also an option for baking a specified AOV pass.
Therefore, this patch depends on D3203.

Diff Detail

Repository
rB Blender

Event Timeline

Update to latest master and D3203

I was wondering if the addition of OSL AOVs enables Light Path Expressions in Cycles and if not how complicated would that be to impliment?
LPE's are invaluable in production and used widely in path tracers for a range of custom AOVs and light select passes.

I was wondering if the addition of OSL AOVs enables Light Path Expressions in Cycles and if not how complicated would that be to impliment?
LPE's are invaluable in production and used widely in path tracers for a range of custom AOVs and light select passes.

I recently started this thread https://devtalk.blender.org/t/light-path-expressions-for-custom-aovs/9193 that address this question.

I was wondering if the addition of OSL AOVs enables Light Path Expressions in Cycles and if not how complicated would that be to impliment?
LPE's are invaluable in production and used widely in path tracers for a range of custom AOVs and light select passes.

I recently started this thread https://devtalk.blender.org/t/light-path-expressions-for-custom-aovs/9193 that address this question.

Thanks! Great thread. I'll add any info I can to it!

Update to latest master and D3203

@Lukas Stockner (lukasstockner97) I implemented this in our build (not the public one yet) and it worked perfectly so far :)

But I hve several questions, I asked you this in blender chat, if you have some time go there so we can speeak about it :)

If you prefer I'll post the questions here.

Grat work man!

  • Don't add AOVC and AOVV prefix to pass names, allow any names. These prefixes are not a common convention for renderers, and easiest if users have flexibility over names in the EXR file.
  • Since names can now conflict with existing pass names, code was added skip such conflicting AOVs and warn about it in the UI.
  • Some internal refactoring was needed to make that work, since those prefixes were used to detect the pass type.
  • The AOV list user interface was tweaked to be more consistent, showing the name field without embossing and background if the item is active.
  • I left out baking passes part of the patch. I can rebase that bake pass patch on top of this one. The light groups is also next on my list to review, so I can do rebasing there if needed.
  • The limitation not mentioned in the description is that this does not work with OSL yet. I think we can add that later. Maybe the better solution will be to allow mixed OSL and SVM node execution in the future, so we don't duplicate code so much.

Lukas, as far as I'm concerned As far as I'm concerned this is ready to commit, let me know if you have objections.

This revision was not accepted when it landed; it landed in state Needs Review.Dec 10 2019, 8:53 PM
This revision was automatically updated to reflect the committed changes.

Noticed a couple UI things: adding a new AOV doesn't automatically create numbered names-- they're all called "AOV" rather than "AOV" "AOV.001" "AOV.002" etc. The "not a unique name" warning doesn't show up until you interact with it either.

I can't express how psyched I am to try this out. This will be so good for NPR workflows!

Is there any reason why the 'name' field is not a dropdown that reflects the AOVs in the scene?
Similar to vertex colors:


This would make it much more straight forward to assign things.
Cheers,
Andy

You are awesome guys!!!

Will we be able to use the custom AOV's the same way we use the override material for example?
So that we can apply the custom AOV's on all materials without putting the nodes in every material?

Going off of @Andy Goralczyk (eyecandy) 's and @Daniel Paul (DaPaulus) 's suggestions, I'd like to suggest putting the AOV outputs in the material output node, or all of them in one output node. There doesn't seem to me to be much benefit for giving each AOV its own node, selected by name. What will Cycles do when multiple AOV outputs by the same name exist in a shader? I suppose it will just use the active one as it does with material outputs.

But if they are all in the Material output node, then every material will have the AOV's exposed without having to add each one by name. Moreover, there will only be one of each AOV in the output. If this gets clutttered, the user can press Shift-H to hide unneeded sockets (although if the user added a custom AOV, they probably want to see it by default, anyway). And this doesn't preclude the possibility of using the existing node alongside it for more control (I suppose in this case the dedicated AOV node would 'override' the one in the material output.

Here's a picture of my proposed Material Output:

Question: Does the AOV color output apply color management or color space? Would it be possible to save data as a vector to this channel without color management messing it up? I've tried to use vertex colors for this in the past and I had to apply fixes to remove the color space conversion. I don't know for sure what the use case for doing this in an AOV would be, but I want to ask the question.

Thanks!

  • Autocomplete names in the node: yes, we should add this.
  • Adding .001: this is indeed a bug that should be fixed.
  • Vector output: there is no color management applied to this so it will work, but dedicated vector type should be added later.
  • View layer level material or shader node group that can be set to output AOVs for all objects: this would be good to add.
  • As part of material output: no, separate node is important to reuse in group nodes. We don't add two ways to do the same thing unless there is a really good reason.
  • As multiple sockets on the node: technically problematic because materials are used across view layers with possibly different AOVs, so not likely.

One more UI/UX suggestion-- I'd really love to be able to change the order of the AOV's in the view-layer tab in the properties panel, and also in the Compositor ViewLayer Input node.
I'm already using this feature, thanks so much for it! It's a Godsend.