2025-01-14 Shape Keys Performance

Shape Keys Performance

Attendants:

  • Bastien Montagne.
  • Hans Goudey.
  • Dalai Felinto.

Meeting to go over potential development approches to improve performance for shapekeys.

The original proposal of converting them to generic attributes proved to be “naïve”.

Sparse Storage Shape Key Type

User option to decide whether Shape Keys should use sparse storage.

  • This is a compromise to avoid having to refactor Shape Keys completely.
  • It simplifies backward and forward compatibility (untying it from the 5.0 targets).
  • Sparse attribute propagation is not a big problem, since shapekeys don’t need to be handled via modifiers (beyond on Applying modifiers).

Notes:

  • This approach may not result in substantial performance improvements.
    • It is easy to test though.
  • The changes are probably centered when leaving and entering edit mode and when sculpting shape keys.
    • Applying modifiers
    • Shape key operators (all these operators are not performance critical and can use temporary non-sparse storage)
  • Work can start on edit mode first, to validate the performance gains.

Deliverables:

  • Performance MVP (branch):
    • New sparse storage.
    • Sparse data evaluation (biggest unknown).
    • Operators to convert back/forth.
  • Usability MPV (experimental):
    • Edit mode, maybe sculpt mode
    • Some operators
  • Feature completion (main)
    • Operators
    • Sculpt mode

Mockups

Shape Keys showing a new “Storage” column, to indicate whether the Shape Key is sparse of full data:

Operators to convert from/to sparse storage:

Idea: Allow users to pick their data storage from the get-go:


Follow up meeting: 2025-02-13 Shape Keys Management

5 Likes

Are shape keys performance such a big issue? Although not in the same level of production environment as Blender Studio, I work with shape keys intensely, often on a daily basis for facial animations. I have multires objects with high levels of subdivisions and a large number of shape keys, all of them heavily animated. I also convert shape keys back and forth with custom operators, and things like that.

I have not seen performance issues yet, especially issues that would make me think an immediate stop-gap solution was needed.

Shape keys need a really big refactor tho, which everyone knows of course. They’re incompatible with every modern development in Blender (node tools, library overrides, layered animation, sculpt brushes, etc.). It’s a matter of time when they will have to be refactored, and given that, and also fact that this would also probably mean pausing other projects I don’t see much advantage in this. All I see is that my UIlist will be even more cluttered now with new column of icons :sweat_smile:

10 Likes

I am always for making things faster, and I know these are just meeting notes, but it would be really useful to link to some profiling you have done so we can understand what cases are slow.

2 Likes

Note that performances here do not only cover ‘speed’, but also ‘size on disk/size in RAM’ topics.

The primary impact of shapekeys sparse storage is expected to be on size of data, which may in turn improve evaluation speed.

6 Likes

I sincerely hope shape keys receive the attention they deserve.
Currently, the issue with shape keys lies more in functionality than performance.
Shape keys need to be applicable to any state of geometry, just like in Maya.
The biggest challenge our studio faces right now is that shape keys cannot be used on top of animated caches.
I truly hope for greater improvements to make shape keys more powerful and versatile.

5 Likes

An update/clarification.

While what Bastien said is correct (the impact on file size would be noticeable), there is indeed the assumption that performance is an issue.

But is it? As many pointed out, without a benchmark it is hard to say.

As a follow up to this meeting I’ve just talked to Rik (Lead Animator here at the Blender Studio) and even he is not sure.

I asked him to come up with a benchmark file representative of the character complexity he expects, with the amount of shape keys he may need.

Ultimately he also acknoledge that there may be a bigger need for tooling to automate some processes, than performance itself. I should hear back from him in 2-week time, I will then update this task/reply here.

10 Likes

You mean, to use them to do corrective shapes? (small adjustments for final animated shots)

2 Likes

If we consider characters that use many shape keys as corrective morphs, i.e. driving shape keys with bone movements, it is a huge issue. One such example is Daz3d characters imported into Blender. It is literally impossible to pose such characters without massive lag. You can temporarily turn off the corrective morphs to pose more smoothly, but it is not a default Blender option, and it causes quite a few problems, because Blender does not differentiate between corrective morphs and other shape keys, such as face movement morphs. And while I understand Blender and Daz3d are different softwares, it is possible to pose in Daz3d with the corrective morphs on without lag. But at the same time, Daz3d is lacking a lot of features that Blender has, which is why a lot of people import Daz3d characters into Blender to use Blender’s features.

1 Like

Yes, Shape keys should be applicable not only to skinned geometry but also directly on animated caches like Alembic and USD.
In Maya, blend shapes can be created immediately on any state of geometry and easily managed through grouping. This feature is incredibly powerful.

Perhaps that’s why many people argue that shape keys should work directly within modifiers.

5 Likes

Unfortunately I can’t provide files, but I have files that can be good for benchmarks, and for me, performance hasn’t been issue, and I would assume neither has been RAM usage, which I haven’t checked, but I would’ve noticed I think, especially on my weak machine. Filesize however turns out indeed increases for lot of shape keys, but tbh it’s the least of my priorities when it comes to shape keys, so I haven’t really paid attention to it.

@TheLittleMouse that’s a good example, but I think it would be important to know whether performance impact in that case comes from shape keys, or from rig (or modifiers, etc.). I think if you have those files developers might find them useful for benchmarking.


As a sidenote (just to voice my experience, in case it’s helpful in designing) my issues with shape keys has been:

  • Having a separate type of Action (animation not being stored in the same action as an object).
    This makes action management quite difficult during animations, because you’re keeping track of two actions. It becomes difficult when NLA is to be used. But more importantly when it comes to animation toolings, because either tools don’t work on shape key actions, or you need to remember to perform operation on two actions. I had to develop my own bake operator for this for example very early in my “shape key career”. This will become bigger issue as new action block matures, and user won’t be able to store shape keys and object transforms in same action as different layers.

  • Not being able to add shape keys on library-overriden objects. Whole “Geonodes shapekeys” workflow shouldn’t have to exist. You can’t even select shape key now on lib-overriden meshes.

  • Being a separate data-block and not being stored in Mesh has been a hell. Especially for python stuff. There is new unique issue once in a while.

  • It only allows linear interpolation, while in some other softwares you can do non-linear, use effectors as drivers and etc. This is a big topic, but basically not being attribute blocks certain advanced workflows, especially for facial animations.

  • I haven’t had pleasure of using node tools yet basically, because it’s incompatible with shape keys, which is all I use. Even basic stuff like storing and restoring masks is inaccessible for me now.

  • Sculpting shape keys cause issues on non-0 multires levels, but that’s probably more of a multires issue than shape keys.

  • Shape key management is hell for complex projects. No groups/collections like TreeView stuff and I have to do shape keys with “____________” as name like a caveman. Once you have more than 10 shape keys you’re in chaos mode.

6 Likes

I’m aware this might be completely unrelated to shapekeys and their performance, but I think it’s worth mentioning anyway, sorry if it’s too off topic.
The biggest issue we have at the studio when setting up characters is related to symmetry, when using sculpting tools to edit symmetrical characters shapekeys the symmetry is broken, so after that if we have to fix weight painting for example, we’re forced to do it on each side separately because the mirror options no longer work.
The workaround is to edit shapekeys in edit mode (almost vertex by vertex) but that takes way too long compared to edit them in sculpt mode. Especially when the characters are mid to high poly.
I mentioned this once on the sculpt/paint chat and Julien Kaspar said the way sculpt and edit mode handle symmetry is different, or something like that. So I don’t know if it’s possible to unify that so the symmetry of meshes is always preserved no matter what tool is used to edit the mesh.

Also, +1 to the above comment by @nickberckley, management especially gets really tricky with complex projects (more than 20 shapekeys are already difficult to handle)

3 Likes

That is true. Maybe there are other things causing the lag. I have turned off many things, including modifiers, to test which things affect the performance heavily, but I can’t test if the rig is set up inefficiently.

As for providing files, this forums doesn’t allow me to upload Blend files, and I guess even if I am allowed, the file size would go over the size limit anyway, because character files are huge.

Another thing is, because Daz3d is a software specific for customising characters, its characters have a nude body, and then you add clothes to them. Not sure if I am allowed to share such things. Another complication is the characters I tested on are actually video game characters.

So, having said all that, I can’t easily provide the files or the links, and I doubt Blender developers can publicly use those files as benchmarks. I can say I downloaded the files from a website called Mustard. I think developers can find it just by Googling “Blender Mustard”, but that’s not much help if you can’t publicly use it. Blender developers make their own files for benchmarks. It’s just that if you really need to know where I encountered such problems.

In short, from my testing, shape key performance does affect posing heavily, which is my answer to the question on whether improving the performance is needed. But part of the problem is related to this:

I am fine with having to (or being able to, really) turn off corrective shape keys when I’m posing. It is after all wasteful to have the computer compute all that, even if there is no lag. But there is no way to do that now. The addons that give the option to turn off the corrective shape keys, can only do so by turning off all shape keys. I need the non-corrective shape keys for posing.

Being able to group the corrective shape keys into one, and then turning only them off, will probably make the performance improvement less important.

Edit: And slightly unrelated. Shapekeys can only be accessed on a mesh. They cannot be accessed from the rig in pose mode. That makes it quite difficult to use.

It is similar to this problem, except it is even worse, because at least you can control both the object’s transforms and shapekeys with the object selected. You can’t do that after going into pose mode with the rig.

Totally this. At the end of the day I can get an OK cloth simulation for example and export/import as an Alembic cache. But then there is always small spots of mesh clipping, etc and to be able to just apply a few shapekeys over the animation for quick fixes.

Of course even better would be to be able to do that directly to the baked simulation.

Now, it possible that new functions/features like this may highlight a bigger performance issue. But if the current feature set of shapekeys isn’t changing, then I’m not so sure there is really much of a performance that needs to be addressed at this stage.

2 Likes

I wanted to provide a simple file that displays performance issues with shapekeys. Having other people saying this isn’t a problem for them is wild to me, as sculpting with shape keys has always resulted in a laggy experience on my side when working with highpoly meshes, before retopology takes place.

This workflow is useful to quickly test changes without committing to it, and to have the freedom of mixing such changes by arbitrary amounts. Naturally, sculpting layers would make the need for this to be more performant obsolete.

When I have to go through this, I usually duplicate the sculpt, sculpt on it, then use the “Join as Shapes” feature to transfer the changes on the duplicate to a shape key of the original. This workaround avoids the performance issues entirely.

On the demo file below, sculpting with the shape keys present, versus deleting them completely and then sculpting, makes quite a big difference regarding brush responsiveness in sculpt mode.

Demo file

I have uploaded it to google drive as I don’t see the option to upload it to this forum directly

11 Likes

Thanks all for your input! I see a lot of valid points: Ultimately it comes down to refactoring the entire shapekey system (long term) vs ‘quality of life’ improvements of the current system (short term) like better tooling/operators and UI improvements. This is up for Blender development to make this a priority.

4 Likes

This will also have impact on I/O.

For glTF, I can not see any blocking point, as

  • we already manage IO of attributes
  • we already manage sparse data for shapekeys IO
2 Likes

Personally, If we are going to change shapekeys, I’d rather it be for long term. Blender 5.0 is coming up, why not just rewrite it and make it as gorgeous as can be? Sure some better performance right now would be nice, but this seems like a really nice long term goal, what with animation 2025 in the works and what not.

8 Likes

Realtime Facial Mocap
I know Blender is not made for things like these but, in my attempt to make a real-time character inside blender, one of the limiting things where the more shape-keys u add even if its low-poly mesh it will get laggy, i had around ~80 shape-keys on this character and the total polycount excluding the hair-cards were less than 10k faces, i wud really like both efficient shape-keys and being able to sculpt on alembic files using shape-keys and being able to apply shape-keys with modifiers, another thing is there’s a lot of addons that adds utilities to shape-keys like being able to apply shape-keys when there’s modifiers on the model, etc, and u can fix your clothe-sim or whatever with modifiers easily (smooth mod and displacement mod). but there’s none to add performant shape-keys.

Hey quick question, why is this proposal naive? Is it because of performance/code issues or UX thing?

Because creating a “fake shape key” in GN is possible today in Blender. You just need an alternative position attribute and then you mix between those too, it’s just there are no proper tools to manipulate attributes in edit mode for now. Just curious :slight_smile:

Here’s what I’m talking about what is possible today in GN

6 Likes

I’m doing something similar; I couldn’t get shapekeys to work with an object that also had a geonode modifier on it - (the keys just wouldn’t evaluate?), so just gave up using shape keys and do everything with bones and nodes now.

2 Likes