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)

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'

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! ❤️

Here is a small breakdown what we need to achieve... when creating Render publish instance(s)

1. Output Renderlayer Beauty and any present AOV
2. Output Composite (optional - so user could disable it if not needed)
3. Output Custom File Output nodes user adds before triggering creation of the Render publish instance

1. and 2) been obvious but speaking of 3) we should look for any already present File Output nodes with any connections and include those for Render too - maybe via some custom tags/ naming so they could be taken into account for publishing too??

Also worth mentioning that any user output can originate from any node graph location/AOV so it makes sense to just detect the file output node

And last but not least, there can be situation where user having already a lot of inputs in File Output node and we should again take those into account, more or less valid as 3) too

4. And imho the most tricky part... dealing with file output location, file name and version plus file format (bitdepth etc) as some of those AOVs need different file specs (e.g. Crypto need to be 32bit full float) and also what if user wants just 8bit PNGs

@BigRoy @moonyuet I still think there is quite a value in current implementation and maybe just briefly checking whats the issue with the additional render layer(s) (which are broken atm) but the rest is functional could be good idea too....

as if just minor issue tweaking might lead to fully functional rendering from blender before we introduce this refactoring above. I can imagine that been caused just by some API change within new Blender release (as the rendering features were introduced when blender 3.6 been released and got broken with blender 4.x)

@LiborBatek thanks for the breakdown, I'm currently working towards (not fully functional yet):

• Old legacy render instances will automatically convert to being tracked from the AYON File Output node instead. So old instances should continue to work.
• Creating a render instance when there is NO render instance yet and no Comp File Output node yet, trigger full AYON setup from settings (create the render setup).
• Creating a render instance when there is NO render instance yet, but there is a Comp File Output node, then just imprint that file output node and start tracking it. This is somewhat similar to ayon-maya where you MAY have multiple render setup layers already - as soon as you create the Render instance there then it'll detect the existing render setup as publishable layers.
• Create a render instances when there is already a render instance/comp file output node - that's where I'm still thinking about how that would work. As far as I understood it doesn't actually make sense in Blender to have multiple File Output Nodes? We can support it and work towards it - I just know too little of Blender to say something worthwhile there.

In short, if there's NO render comp setup yet - it behaves like before, creating from settings a render setup. If there is, then it just uses what your scene has set up as what you want to publish and now will NOT break your existing configurations. The end goal here is that, over time, we remove the "setup from settings" logic or change it around in such a way that one could e.g. publish and load rendersetups - or start from workfile templates, that each could act as the "render setup" replacement on first creation - but with way more studio control, then they can actually configure ALL of what Blender has to offer and we do not need to care about maintaining each render pass of Blender in our settings manually.

Thoughts @LiborBatek ?

And imho the most tricky part... dealing with file output location, file name and version plus file format (bitdepth etc) as some of those AOVs need different file specs (e.g. Crypto need to be 32bit full float) and also what if user wants just 8bit PNGs

What's tricky about it? The user has technically full control to configure their scene - all we need to do is correctly parse the File Output Node and its values, which I believe I am doing now ;) (e.g. collecting their colorspaces, etc.; although we do not actually care about bit depth in the publishing)

I still think there is quite a value in current implementation and maybe just briefly checking whats the issue with the additional render layer(s) (which are broken atm) but the rest is functional could be good idea too....

as if just minor issue tweaking might lead to fully functional rendering from blender before we introduce this refactoring above. I can imagine that been caused just by some API change within new Blender release (as the rendering features were introduced when blender 3.6 been released and got broken with blender 4.x)

Could you point me to the "Additional Layers" bug or create an issue for it if there isn't yet? I can look into that along the road to fix if it's just a minor point.

• Create a render instances when there is already a render instance/comp file output node - that's where I'm still thinking about how that would work. As far as I understood it doesn't actually make sense in Blender to have multiple File Output Nodes? We can support it and work towards it - I just know too little of Blender to say something worthwhile there.

Blender is allowed to have multiple File Output Nodes for render output.
Do you think that it's good idea to allow users to create the render instance on new or existing file output nodes but also supports to collect data from certain file output nodes through the setting in Publisher UI?

Moreover, we can make it more artist-friendly, like creating some templates settings which can be driven in ayon settings, so that artists can just choose whether they want to do multipart or not etc.

@BigRoy @moonyuet I still think there is quite a value in current implementation and maybe just briefly checking whats the issue with the additional render layer(s) (which are broken atm) but the rest is functional could be good idea too....

as if just minor issue tweaking might lead to fully functional rendering from blender before we introduce this refactoring above. I can imagine that been caused just by some API change within new Blender release (as the rendering features were introduced when blender 3.6 been released and got broken with blender 4.x)

I have made some tests and it seems that it doesnt fail on multiple ViewLayers but its not supported atm...as it gives no errors once triggering creation Render publish instance and any additional ViewLayers been simply ignored as seen below (2 layers present and just single been taken into account for outputs by AYON)

@BigRoy thx for your breakdown! it all sounds thrilling and awesome! love it already :)
speaking of that "tricky part" I guess wen do need to alter the file output names a lot as users could have some weird naming and not using any versioning so we might need to forcing some proper ones ( e.g. variant, viewlayer, version etc.) and also alter the file path accordingly as those arent dynamically created within blender at all...

does that sound still easy? if yes then perfect!!

I mean similar formatting like we already have once hitting create render instance>