Limitations
As highlighted in other pages there is a limitation to using divide / multiply loops when rebuilding with materials and lightgroups simultaneously. As separate rebuild blocks they must rebuild back to the beauty before merging to the larger rebuild through a divide / multiply loop, this is because the loop shows the difference between the rebuild and the beauty it's compared against.
In testing AOV_rebuild this became apparent to me for objects / materials that could be considered emissive. Only occurring in the additive rebuild as the subtractive method takes from, and then adds back to the beauty for each AOV, (so taking away then plussing back an empty emission AOV from the beauty does nothing). The emissive objects / materials are still in the (beauty) rebuild B pipe and can be taken from / plussed back if a lightgroup AOV has been assigned to these objects / materials.
Compared to the additive rebuild where the composite starts from an empty image and each AOV must be plussed back to rebuild the beauty, an empty emission AOV means a missing emission AOV in the materials rebuild breaking the larger rebuild as it's passed through a divide / multiply loop. In the same regard (additive rebuild) if an emissive object / material is rendered through a lightgroup AOV and not an emission AOV, and if there are no other lightgroup AOVs to rebuild the lightgroups block back to beauty before it's passed through a divide / multiply loop, this will break the larger materials & lightgroups rebuild.
As highlighted in the SideFX doc's this is a topic that is often a point of confusion for those who encounter it...
https://www.sidefx.com/docs/houdini/solaris/support/lpe.html
To show how the difference between emissive objects and light sources can be problematic for AOV_rebuild's additive rebuild divide / multiply loop I made some test renders (download link below) using Refining_Karma_Renders.hip (course link also below)
https://drive.google.com/file/d/1oVDAC-iFaeBTs-isUS_eOqc0xtpHIKxb/view?usp=sharing
https://www.sidefx.com/tutorials/refining-karma-renders/
Included in the test nuke script 'AOV_rebuild_karma_examples_v002.nk' are some rebuilds to show how the additive rebuild can break out of the box without the correct settings; and also how this can be fixed with one setting (at least for this Karma example).
Lets take a tour of the issue here to understand it in full.
Take note how Lightgroup Regex assigns visiblelights AOV to the lightgroups rebuild.
That's not very convenient! Let's think back to the SideFX doc's explanation of LPE's and how emissive objects / light sources render, then look at the problemaic AOV's from the render settings node in Houdini.
The fix for additive rebuild in this example?
Because of this I've added a feature to the additive rebuild whereby users can add duplicate AOVs to multiple (material & lightgroup) breakouts. It's not technically correct or relevant to this example but I thought it's a useful option and it comes with a warning to make users aware that duplicate AOVs in material and lightgroups breakouts can break the rebuild.
Thanks to Todd Manus www.itodd.net for first drawing this issue to my attention.
When using divide / multiply loops for additive rebuilds, each material and lightgroups block must rebuild back to the beauty before being merged through a divide / multiply loop.
Specific to the difference between emissive objects and light sources, for users unsure of the LPE events in their AOVs workarounds are..
- checking if the unassigned pipe is safe to use.
- using the subtractive rebuild.
As such this is documented as a limitation rather than 'known issue' to be fixed.
Had enough?
Jokes aside, there is one other observation worth sharing for those using Houdini 21.0.440. Although LPE events described in the SideFX doc's explain why emission and visiblelights AOVs render as they do, checking my test renders from Refining_Karma_Renders.hip I found emission AOVs rendered as both emissive objects and light sources while visiblelights rendered empty.
Tt's fixed in Houdini 22.0.368 and possibly in later versions of Houdini 21 but as I haven't tested in other Houdini 21 versions I can't comment on. So just something to be aware of.