At our studio we are using Maya and Blender with Ayon. In Maya we have the very solid cbId workflow, where you can publish and assign looks.
I did not find such a workflow for Blender. Before I reinvent the wheel I was wondering how are other studios using Blender and Ayon in this regard. What is the process of going from animation to lighting with alembics and reassinging shaders? Or are their workflows that are completely different?
Thanks!
A Quick Note:
AYON USD contribution workflow is the recent alternative for cbId workflow.
Hi @Nielsm
I wouldnât say we are a standard bearer for this but we have spent some time looking into this particular workflow here at THE LINE.
We too, use an animation > lighting pipeline of Maya and Blender with AYON, and this is dictated by the aesthetic we generally go for as a studio. We use Lineart and grease pencil heavily, so some of our workflows are borne of being able to preserve these setups at the lighting stage, yet still being able to re-unify the animation from the animation phase.
As youâve found out, the industry alembic workflow is wholly destructive, which is great when you have the tools to re-unite shaders with assets, but a pain without it.
Thereâs also the fact that Blenderâs implementation of alembic is centred around their datablock architecture, so itâs not quite the same as other DCCs. I actually found it similar to the old PC2 workflow, where the vertex cache is added to the base geo. This is how we use it, rather than destroying the geometry, we version the alembic path inside the MeshSequenceCache from the ABC animation. This way we can update animation changes without destroying any L&R setup. We have an addon to handle this but itâs something @BigRoy has kindly looked into implementing âproperlyâ in AYON as well.
What we also implemented on the 3d mechs during our Overwatch/Transformers job was a kind of workflow clone of the Look Assigner from AYONâs Maya host.
This uses blendscene to extract and publish a file containing the shaders from a particular asset, with custom attributes added to the shaders (like a simpler version of the cbld workflow) The look assigner is able to grab these shaders in the L&R file and reassign them to the assets in the scene. Thereâs some extra bits like override shader assignment and handling blenderâs cloning protocol (automatically adding .001 .002 etc)
The source code is on our github which you are welcome to grab - please note itâs a tool that was built around the specific way we work. So it might give you a steer as to how we approached it. Itâs not 100% tied to AYON but itâs certainly trying to be! It does allow us to use quite a lot of the benefits of AYON between the two DCCs 
Final thing is also to do with compositor graphs setups for lighting. This also needs to be non-destructive, as there might be steps to comp and adjust custom AOVs before piping out the results to the output. (we might combine EEVEE and Cycles renders into the same output stage, e.g. for reflections) So we look to re-path output nodes rather than re-creating, based on a solid and defined output schema we set in pre-production.
Thanks for the detailed description of your workflow! Sounds exactly what Iâm looking for. Iâll take a detailed look into the look assigner and see if itâs adaptable for our way of working.
@mustafa_jafar USD is definitely something on my wishlist to (eventually) implement, but it requires a different approach from the start of the project. Plus Iâm wondering how the implementation of USD in Blender is nowadays 
sure, no worries! Iâd say our workflow isnât particularly forward thinking but it does align with Blenderâs ABC/Datablock workflow. One thing to note about Maya > Blender is unitscales. Stuff natively made in Maya result in huge scales on objects imported in Blender, even with ABC. We lock AYONâs blender host to 0.01 scale to fix this. (otherwise light values, clipping planes are really troublesome)
Hi,
Instead of Alembic, we try to publish .blend files.
In Blender we use Ayon-->Load to get the geometry (for example version v003).
Then we attach some material to that object.
Later, if we use Ayon-->Manage to change the geometry version (for example v004), the material and all its nodes disappear
To sum up :
If we publish the model with no material, we canât change the model product version (as it breaks the material that is attached after publish).
If we publish the model with a material, we canât change the material (because it would be lost in case of modeling product change)
So, basically, we canât separate modeling and shading.
It has been logged here : Material disappears when using Inventory to change a model version ¡ Issue #109 ¡ ynput/ayon-blender ¡ GitHub
Reading the messages above, related to Alembic in Blender, itâs not a solution right now.
And fbx also has the same problem as .blend files.
So it leaves us with 2 solutions :
Iâd cross of USD for the foreseeable future. The implementation in Blender to me doesnât feel like more than import/export and interchange with other DCCs than that it really feels like the format to use to store blender-related looks.
Anyway, another option is potentially the Load Alembic and managing it as a datablock (draft PR). Basically instead of reloading the geometry meshes itâd just update the Blender datablock, meaning any local changes would remain intact on top of it.
Youâd just need to however make sure youâre able to assign your looks to it in any meaningful way - for example with a workflow like @VertexApe describes. If the look was readily applied youâd basically have a now completely updatable and cache-applyable object while keeping local edits applied (only really swapping the assigned cache). It does start feeling a bit like a Maya geometry cache workflow like some were doing back in 2010 (if not much before that).
The Ayonâs team released it today, in the latest version of ayon-blender : 1.0.21
