2025-02-13 Shape Keys Management

[dfelinto]

Shape Keys Management

Attendants:

• Dalai Felinto
• Rik Schutte

Follow-up meeting to revisit the Shape Key benchmark file and clarify other development opportunities. Read the original discussion about Shape Keys performance.

Performance Benchmark

You can read the latest findings here. The conclusion so far is that performance is not the deal-breaker it was assumed to be.

Management

The term management is used here to include:

• Creating and updating
• Grouping

This concerns only riggers, and animators shouldn’t need to be aware of any of this.

Creating and updating

The current workflow Rik is exploring relies heavily on the “Join as Shapes” operator. He creates multiple copies of the object, and edit each one manually. Once the shapes are good-to-go, he joins them as shape keys into the original object.

This works well for the initial pass, but not for subsequent updates or to handle mirror shapes.

New operators/options that would help:

• Join as Shapes Mirrored
• Update Shapes
• Update Shapes Mirrored

Whether the “Mirrored” variants are an option in the re-do panel or their own operator entries is a discussion to be had with the animation module.

The Update Shape operator should follow the same “name to Shape Key” mapping that the Join as Shapes operator uses. Even warning/failing if there is a name mismatch.

The proposal moving forward is to prototype those operators in Python, test them in production, before committing to implement them in Blender.

Grouping

For Rik’s workflow in particular (though there is nothing particular about his workflow) he creates multiple related Shape Keys.

You can see in this example the multitude of mouth corner Shape Keys.

The way Layer Groups work is a good example of the behaviour that could be expected. The group itself contains no data, but is only an organization element.

The control expected on the group level is:

• Folding (to reduce visual clutter)
• Enable
• Lock

The values are still defined per Shape Keys.

---

This is more convoluted to be done than the “Creating and updating topics”. As such it is not a module task that may just get picked up. For this to be pursuited as a feature it will need to be prioritized/planned (and have its design fleshed out).

Batch Editing

The ability to batch select shapekeys in order to adjust them or move them at the same time.

Developer Note: This is only possible if we move away from UI Lists and use NavTrees. This is also a requirement for the Grouping feature, and equally demanding.

[JulianPerez]

@dfelinto

The current workflow Rik is exploring relies heavily on the “Join as Shapes” operator. He creates multiple copies of the object, and edit each one manually. Once the shapes are good-to-go, he joines than as shape keys into the original object.

Why is this workflow used? I know that it is the way it works in other software but if Blender allows the user to create/update shapekeys on the same object (and it is faster to do this way) I wonder if maybe there’s any advantage I’m missing here?

[josephhansen]

@JulianPerez

Why is this workflow used? I know that it is the way it works in other software but if Blender allows the user to create/update shapekeys on the same object (and it is faster to do this way) I wonder if maybe there’s any advantage I’m missing here?

I would second this. We use meshes with shapekeys every day at work, and none of the people I work with or myself do things this way. I don’t think this is a common workflow

[JulianPerez]

It’s common in Maya, but I’m not sure why one would prefer this workflow in Blender, other than importing external meshes and then join them as shapekeys, but that’s another thing altogether.

[PaulGriffin623]

Also would like to know more about this. My best guess is it’s because of the features provided by this workflow, which among other things helps reduce redundancy in the pipeline when baking texture maps? But several aspects of that workflow seem more like workarounds for issues with the multiresolution modifier and Blender’s baking system, rather than a superior solution for rigging in its own right.

[josephhansen]

Everyone I work with is a Maya user by training - I asked them today, and none of them have ever done this. It’s not a huge sample size, but I still don’t think it’s a common workflow

[thorn-neverwake]

@JulianPerez

It’s common in Maya

Because they want to do it that way in Maya, or because it’s harder to animate at the vertex level within the object with self-contained morph targets?

FWIW, I’ve set up morphs in Blender using multiple meshes with geonodes - when trying to solve a particular problem, instead of using regular shapekeys. I certainly did not prefer that way… it was an overall hassle. Having multiple character models, and then wanting to modify the base mesh (when nothing would ripple to the targets) - I didn’t find that efficient.

[JulianPerez]

@josephhansen

Everyone I work with is a Maya user by training - I asked them today, and none of them have ever done this. It’s not a huge sample size, but I still don’t think it’s a common workflow

@thorn-neverwake

Because they want to do it that way in Maya, or because it’s harder to animate at the vertex level within the object with self-contained morph targets?

That’s the way I was taught, and until I switched fully to Blender (8 or 9 years ago I think) I’m pretty sure it was the only way to create blensdshapes. I also remember the few good online learning resources that had anything related to 3D animation when I started studying (around 2008) only showed that method.
Coming to Blender from Maya at the time and learning that you didn’t had to duplicate a head a gazillion times to create blendshapes felt great hehe.

Going back to the topic of shape key management and performance, one thing that does lower performance a lot is using multires on meshes with shapekes. I’ve done that only a few times, but it’s very useful to be able to check how the detail is going to deform, without having to bake the detail to displacement and normal maps, check the deformation and then go back to the sculpt to fix things. Maybe the planned multires improvements are going to help with that…?

[SebVerkhozin]

@JulianPerez

Why is this workflow used?

In the productions I worked in, the riggers were more technical artists, and blend shapes were the responsibility of the character artists. So we exported a lot of blend shapes that the character artists had to fix. Character artists can sculpt in other software. I believe this is a widely used practice for scaling up production.

[RiccardoBancone]

@thorn-neverwake

I’ve set up morphs in Blender using multiple meshes with geonodes - when trying to solve a particular problem, instead of using regular shapekeys.

I think I’ve been thinking about doing that for a specific reason, but I can’t remember what the problem was in my case. Do you have a concrete example?

@JulianPerez

Coming to Blender from Maya at the time and learning that you didn’t had to duplicate a head a gazillion times to create blendshapes felt great hehe.

Same here, I’ve been using Maya for like 10 Years, then I switched to Blender in 2014 and never came back. My thought was “That Is how morph targets should be created”.

@JulianPerez

other than importing external meshes and then join them as shapekeys, but that’s another thing altogether.

I Agree, It’s still important to have the ability to create shape keys “maya style” (by creating/imporitng shapes as separated obkects) but I feel that the best or at least most conveniente way in many cases, is to have the shape keys “embedded” in the object or object data.

[Rikstopher]

@JulianPerez

Why is this workflow used? I know that it is the way it works in other software but if Blender allows the user to create/update shapekeys on the same object (and it is faster to do this way) I wonder if maybe there’s any advantage I’m missing here?

Hey Julian, thanks for the question. This particular workflow is well established in the animation industry (where maya is dominant indeed) for both feature films and series, and to be fair, there’s no right or wrong in how to implement or manage shapekey deformation given the possibility in Blender to do it all within the same mesh. In this particular case I’m planning to establish a workflow that is scalable for bigger animation productions, standardizing the facial rigging process in a way that a team of riggers can churn out 20+ characters with the same components. Therefore the main benefits of having external shapekey meshes are the following:

• Using temporary armature bones to create consistent shapekeys are a great way to allow a smooth transition between poses (for example mouthcorner deformation) These are fundamental for generating cohesive shapekeys that seemlessly blend together. By doing this setup on a separate mesh, avoids stacking all these modifiers into one mesh. Managing this mesh data separately gives the freedom to add temporary deformations without conflicting with the target mesh.
• Having a instant visual overview of all shapes in the viewport helps a lot when this layout is standardized. This means they are neatly categorized and mapped to distinct facial areas. This is mostly the same for a humanoid character, but can be customized when needed. Addressing director’s feedback on a rig that isn’t made by you, makes it a lot quicker to access and know where to look for, when the rigging department is using the same ‘visual template’. You don’t have to turn on/off shapekeys in order to find the right shapekey to iterate on.
• Splitting Weights is a method used to devide a broad shape into smaller chunks in order to assign them to ‘local’ control bones. This process is mostly automated and requires their own vertex groups for proper masking. Currently we use a Geometry Nodes setup to do this process quite efficiently, automating the splitting process. This allows us to iterate broad shapes easily and converting that shapekey into smaller chunks automatically.
• Updating Shapekeys are a key tool in this workflow. By using a script that automatically updates evaluated external mesh data to shapekeys with it’s corresponding name allows the rigger to iterate on broad shapes by using any deformation tool available without cluttering/interfering with the final model.
• Avoiding unnecessary data on the final rig like vertex groups used for masking, temporary armatures and other data necessary to control designed shapekeys. The final rig only contains the ‘baked’ shapekeys.
• Separate meshes allows their shapekey data to use as a way to iterate feedback, like layers. Where each new shapekey is a new pass, keeping track of the previous versions as shapekey layers.

The longterm plan is to provide an ‘facial rigging course’ on the Blender Studio website where these methods will be explained and applied to a new character rig.

Besides the workflow topic, this meeting note was mostly to share thoughts about improving shapekey management, which should ultimately benifit anyone using shapekeys regardless of specific workflows. The tool updates suggested are merely upgrades of what is already there and is mostly focused on applying operators on multi selection.

Hope that clarifies a bit !

[JulianPerez]

@Rikstopher

Hope that clarifies a bit !

Thank you very much for the detailed explanation Rik, it does makes things very clear.

So it is mainly about production scalability, not having worked on big productions I wasn’t aware of some of your points, so this is very helpful.

I’m glad you’re thinking about testing a workflow that’s suitable for both small and big productions, I agree that shapekey management becomes even more important when several artists are involved on their creation/editing.

@Rikstopher

The longterm plan is to provide an ‘facial rigging course’ on the Blender Studio website where these methods will be explained and applied to a new character rig.

Nice! That’s a topic that not many people doing educative content covers in detail. I assume it has to do with how time consuming (and difficult) it can be when done right.

[TheLittleMouse]

Personally, my characters are often set up in one blend file, and then linked in other blend files where I pose them in different environments with other characters. However, I can’t create shape keys on linked characters that are needed for a particular pose or to simulate deformation from collisions. Is there a plan to make it possible to create shape keys on linked characters/objects for a particular scene?

[MidnightArrow]

The way Layer Groups work is a good example of the behaviour that could be expected. The group itself contains no data, but is only an organization element.

To reiterate what I said in another thread (which Sybren Stuvel hearted), vertex groups, shape keys, attributes, etc all need better organization instead of dumping them into a flat list. Especially since vertex groups and shape keys are just going to become attributes at some point anyway.

IMO, this is a UI issue that should be solved with better widgets which can handle all the pertinent use cases, whereas hardcoding this specifically for shape keys in a UIList would just be pushing the real problem off to a later date while ignoring other, equally-valid pain points. Such as the massive amount of vertex groups required for rigging, or the need to mix vertex groups for very different uses (such as rigging, masking, modifier influence, etc) into an unordered jumble.

Personally I’d rather see a file system-like widget where things can be put into nested folders instead of a treelike widget where I have to keep collapsing, expanding, and scrolling through a massive list to find my data, though I’d still prefer that over the current implementation of a flat list with barebones sorting and filtering and no nesting whatsoever.

The ability to batch select shapekeys in order to adjust them or move them at the same time.

That was also mentioned by the animation team in the thread I linked, which reinforces that this should be a comprehensive UI-level change instead of a shape key-only thing.

Personally, my characters are often set up in one blend file, and then linked in other blend files where I pose them in different environments with other characters. However, I can’t create shape keys on linked characters that are needed for a particular pose or to simulate deformation from collisions. Is there a plan to make it possible to create shape keys on linked characters/objects for a particular scene?

That’s literally why Geonode Shape Keys exists. Though I do think it’d be nice if that feature was migrated to the core program and turned into vector attributes, it works well enough to shot-sculpt.

[MichaelBenDavid]

@Rikstopher

The longterm plan is to provide an ‘facial rigging course’ on the Blender Studio website where these methods will be explained and applied to a new character rig.

that would be excellent for any rigging amateurs and newcomers! but please also make it available in the blender studio youtube channel .

[dan2]

Just my 2 cents here, as I worked with the maya separate mesh workflow in high profile productions longer than I care to remember - from a VFX point of view the upsides in maya were:

• the ability to work on a separated part of a mesh (let’s say the head) and shape keys would work as long as the IDs are consistent with the whole body. In blender this would give you a vert count mismatch error.
• Shapekeys (blendshapes) in maya are also live, meaning I can tweak a shape for a smile on a separate mesh and see the updates effect on the main mesh in combination with other shapes, while also having the option to use external sculpting packages.

These are the main 2 things I’d say. The only way to get around it currently is geo nodes, but it’s a bit tedious and also doesn’t give live updates while sculpting. For those who want a brief overview of the VFX workflow, there’s a pretty decent one here from Gnomon.

The shape authoring that’s left half finished in Maya and is likely to stay that way is also focused on this worklfow.

I started to work on a more complete shape authoring solution for facial purposes, but I’m not a programmer and my freetime is limited so it’s dragging on.

[TheLittleMouse]

@MidnightArrow

That’s literally why Geonode Shape Keys exists. Though I do think it’d be nice if that feature was migrated to the core program and turned into vector attributes, it works well enough to shot-sculpt.

I didn’t know such an addon existed. Thank you.

By the way, I recognise you from the Diffeomorphic and Daz3d forums. Good to see you here.

[MidnightArrow]

I read through the original discussion about shape key performance again, and I’d like to bring up a few more things from the comments over there.

And the new attribute system has currently limitations (like lack of namespace) that would also need to be addressed to be usable for something like shapekeys (or vertex groups, which are another candidate for attributes).

Bastien Montagne also points out that attributes also need better organization, just like shape keys and vertex groups, for future development. Furthermore, he says:

Combining both would be a major project, requiring months of dev-time to be completed - in best case scenario.

Which is exactly why I’d prefer the devs not put it off. The sooner it’s worked on and finished, the sooner we, the end-users, can benefit from it. On several occasions, I’ve seen devs say something on the lines of “We shouldn’t make a hasty solution that people will come to rely on, because we’d lose the impetus to fix it later”. I think that is definitely an issue here.

Sybren Stuvel also says

This makes it impossible to share a mesh with corrective shapekeys between characters, as it is impossible to set different blend weights for different users of the mesh.

This is also an issue I have, like when I use characters from an asset store that rely on the same base mesh. So with this in mind, I’ve spitballed an idea for how to implement this, just to offer something to the discussion.

Instead of getting attributes/weights/shape keys from the object-data directly, each Blender object has an “AttributeManager” object associated with it. This object would be the “model” in the “model-view-controller” architecture. The AttributeManager sits between objects and object-data. At runtime, it collates all the different pieces of data into a quasi-file system, which is shown via the “view”, a new panel in the object’s properties. It creates hardcoded, Blender-specific folders to store different kinds of data. Such as .weights and .shape_keys. The AttributeManager object would also store metadata about each “file”, such as read-only, hidden, and also a value determining the strength/enabled status of the “file”. This would solve Dr. Stuvel’s issue above, since it’s stored on the object rather than the shape key datablock. The AttributeManager object would also allow an object to bring in “free-floating” attributes, which aren’t bound to a particular mesh and exist independently in the blend file. Such as a boolean mask to isolate the eyes of all the characters with an identical base mesh.

For the initial implementation, these folders are just a redirect to how the data is currently stored. So the .shape_keys and .weights folders are just another “view” (as in the MVC architecture) of the mesh’s object-data. But as the implementation matures, they can be deprecated and switched over, under the hood, into an attribute-based system with minimal changes since there is already a layer of indirection insulating them from the rest of the codebase.

[dfelinto]

Hi everyone, those are meeting notes, not a place for design discussions.

If there is any need for clarifications feel free to ask here. Rik had already addressed the questions about his workflow a few replies back.

Other than that, the best way to give feedback is getting involved in the module activities or to wait for feedback threads here on devtalk.