Reading the blender docs and testing the system, the workflow to rig a model is not consistent and doesn’t take advantage of the power of Blender library link.
Creating a model in OP puts the objects under an empty. This is not an usual way to create a model hierarchy, the main approach is to parent the sub-objects to the main object. Furthermore, placing an empty before the first model disallow to use the parenting operators of Blender, the modifiers won’t be created neither auto weights and vertex groups… If we use the workflow described in the creating rigs doc, it changes the parent from the empty to the armature and breaks the hierarchy and the update.
The proposed workflow deals only with
The model creator must keep the objects hierarchy, it means to drop the parenting to an
empty when creating an instance, and rely on collections and custom properties data. This system has been designed with 2.93, doesn’t work for 2.83 and is compatible with 3.x series. Depending on your Blender versions support policy, some extra steps can be added for older versions (making all local, adding an empty to replace the collection…).
publish part remains untouched, I’d like to add the possibility to enable/disable the formats to export, but that’s another topic.
The modeling remains the same: create the model as you like. Creating the instance will put everything under a collection considered as the root.
After creating the instance, the hierarchy would look like that:
All information currently associated to the root object is now stored in the collection’s custom properties.
Link model will act like a usual Blender
Link... with an automatic
Make library override... and not create a disturbing set of
AVALON_ collections. This way the scene looks like that:
For both advanced and basic rigs, the process is the same as creating a model, a collection is created to be the root of the rig, we don’t change the hierarchy.
In Blender, rigging implies to paint the weights or assign vertex groups for example, the user can make the object and some datablocks local, we could ease that by adding an operator somewhere, the datablocks are always the same for the rig task (this system will be usable for a later shading/render/lighting design). For a fully non-destructive workflow, I suggest to update the actual
model version with this new rig-ready mesh, this way later modeling modifications can be done without having to redo all the rigging work.
Same as loading a model.
In a layout scene, you load rigs and models. You can move them around using the
Armature or the controllers you set for your rig. It is not recommended to move the collection but this is not an big issue. Rigs and objects (like cameras) can be posed and animated roughly. Once you’re done, you create a
Loads all objects under the
You load a layout, link any other rig you need, and then create the
Animation instance. This way, if any addition is made in the
Layout it’s updated in the
Animation collection without any intervention.
Actions (actual animation data) are associated to the object, then modifying the armature/rig doesn’t affect the animated parts, unless an animated element has been deleted.
Same as layout.
The subset update would rely only on custom properties data and not deal with any arbitrary hierarchy (apart from collections) and try to use as much as possible the libraries if the entity has not been made local. Then it would only change library paths, or link the datablocks and assign then to the objects.
If the target library is the hero version, the update is automatic and transparent, without any code to run on the OP side.
As mentioned above, making something local make the update less easy and we can evaluate some study cases to try automating as much as possible, relying on custom properties. But we cannot deal with all manipulations or dirty workflows/crisis fixes, this will require human intervention. At least, this system has a very flexible design with a turnkey workflow.
This system is valable for next tasks but tests have to be done to make as few make local as possible and keep the most as links. This part deals with POCs for some use cases we have identified as major, which are not currently supported by the Blender implementation.
In blender the
material (a.k.a shader) can be associated to the mesh data or to the object, I propose to associate it to the object, therefore the object have to be made local to work with the subset and the mesh data is still linked to the
model. Creating a look will reference all the materials associated to the object. Publishing a look will create a
.blend file with the materials, considered as the materials library to be targeted and linked for other tasks.
It may happen you assign different materials to a bunch of faces. This case forces you to toggle to
Edit mode and then requires the mesh data to be local. I’d handle it by updating the
model with the modified mesh data to be the new reference, this is the same problem/solution as for the
Here is a schema to sum up!
NB: Lighting (or some other steps) are not indicated because we haven’t discussed them, but the essential must be there, feel free to raise any concern.
Here are my test data, librairies linked with relative paths: