AY-7132_Refactor render workflow to manage render compositor network outputs instead of forced render structure

[BigRoy]

Changelog Description

Allow the Compositor's Node Output File to be the ground truth about the "output" of your render.

It should not matter whether it's the direct 3D render or whether you are doing slap-comp compisiting in-between. The idea here is that there just happens to be a node, with some input layers defined, which then end up defining the actual render products you want to publish.

Additional review information

Currently the so called "aov" suffix to the product is defined by the filename of the layer in the compositor node output file - but we could look into other options, like using custom attributes on the node or another explicit naming option for those. The logic is currently in the get_aov_identifier function.

• TODO: Currently the creator 'auto-collects' from the compositor node tree - which is very different of other behavior on publish instances. We should work towards fixing that. :)

Testing notes:

1. Build up a nice render network via the compositor node tree using the Compositor Node Output File and connecting your layers to it.
2. Go and publish.

AY-7132

[LiborBatek]

I will give it a shot and see how it performs....

But just by briefly seeing this PR I have to note that the main labour which need to be taken care of is the creation of that file output compositing node with corresponding node tree connections automatically originating from users selection of different AOVs within blender UI + viewLayer(s) present within blender scene as those are the most painful tasks to tackle manually (something blender lacks heavily compared to maya) user basically having just 2 options by default in blender

1. to go with multichannel EXR
2. manually hooking all nodes within compositor and using File output node for producing separate passes (same with render layers - "view layer" in blender terms)

Our legacy blender integration did that automatically for the user even tho been sort of rigid and blender-addon config driven (which is not desirable now and reasoning behind refactoring)

[LiborBatek]

So here are my findings so far:

1. It automatically creates file output node and connects beauty and composite outputs which is nice

2. If any AOVs enabled in View Layer Properties tab for output - these are not taken into account and got swiped off once Render instance got created (e.g. Mist, Normal passes) - which I quite expected, as you stated its not ready yet, so not real issue atm

3. Some weird "Render" instance pops up while working with the blender workfile and re-opening the publisher (see img below) - not sure what that really means

4. Once I try to publish the render it fails with following error:

Traceback (most recent call last):
  File "C:\Users\lbate\AppData\Local\Ynput\AYON\dependency_packages\ayon_2406251801_windows.zip\dependencies\pyblish\plugin.py", line 528, in __explicit_process
    runner(*args)
  File "C:\Users\lbate\AppData\Local\Ynput\AYON\addons\blender_0.2.4+dev\ayon_blender\plugins\publish\collect_render.py", line 46, in process
    output_paths = self.get_expected_outputs(comp_output_node)
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\lbate\AppData\Local\Ynput\AYON\addons\blender_0.2.4+dev\ayon_blender\plugins\publish\collect_render.py", line 136, in get_expected_outputs
    base_path: str = node.base_path
                     ^^^^^^^^^^^^^^
AttributeError: 'Collection' object has no attribute 'base_path'

[BigRoy]

But just by briefly seeing this PR I have to note that the main labour which need to be taken care of is the creation of that file output compositing node with corresponding node tree connections automatically originating from users selection of different AOVs within blender UI + viewLayer(s) present within blender scene as those are the most painful tasks to tackle manually (something blender lacks heavily compared to maya) user basically having just 2 options by default in blender

1. to go with multichannel EXR

2. manually hooking all nodes within compositor and using `File output` node for producing separate passes (same with render layers - "view layer" in blender terms)

Our legacy blender integration did that automatically for the user even tho been sort of rigid and blender-addon config driven (which is not desirable now and reasoning behind refactoring)

I want to remark that we should really try and get as much of that out of the AYON settings - and instead allow someone to build that almost like a template inside Blender or alike and then e.g. allow using that as an actual loadable product or as workfile templates, or something along those lines.

We should really allow anyone to create any custom node graph - no matter how complex - without us enforcing some structure from our AYON settings. Of course a simple "creation system" like we have we could preserve, but I think the actual usefulness is so much less than just using actual Blender node content somehow the user can actually author in a blender file itself.

The admin of settings may also not be the artist who knows blender - as such, configuring this "template" in settings is too far off from the artist who just knows blender.

Anyway, thanks for the quick test run on the draft PR. Some of the issues you mentioned I know why they happen and what would be the next step - but it's perfect having them clearly laid out and mentioned here, so thanks for that! ❤️