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