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).
