Removing the "Multi Modifier" option of the armature modifier

Feature & Design Feedback
,
1

For Blender 5.0 we are considering removing the “Multi Modifier” option of the armature modifier. I would like to know if this feature is actually used by anyone and what people think about using geometry nodes as a replacement.
image
https://docs.blender.org/manual/en/latest/modeling/modifiers/deform/armature.html#options

This feature enables multiple armatures to deform the same base geometry in parallel and then mix results together, rather than applying one deformation on top of the previous. There are several reasons to remove this feature:

  • Difficult and badly documented: Only works correctly with several armature modifiers right behind each other.
  • Half-finished: comments mention the same feature should work for cage and lattice modifiers, but these were apparently never added.
  • Untested: There are no automated tests covering this code.
  • Complicates armature deformation code: I’d like to refactor and modernize armature deformation code, which would be a lot easier without this feature.

The same behavior can be achieved using geometry nodes now. It would be more convenient if armature deformation could be done as a node itself, but even in a conventional modifier stack the parallel mixing can be implemented:

  1. Store original positions as a named attribute
  2. Add Armature deformation (or any other deformation modifier)
  3. Store resulting deformation and reset to original positions.
  4. Repeat steps 2 and 3 for multiple modifiers, each writing to its own position attribute.
  5. Mix all the resulting position attributes.

Please let us know if you are actively using this feature!

Pull request: Modifiers: Remove “Multi Modifier” feature from armature modifier #139845

Original commit that added the feature 18 years(!) ago: Long outstanding feature request: “Multi Modifier”

5 Likes
2

So if you remove it, how does one do this?

5 Likes
3

With a node implementation of the modifier, I assume this would be trivial to do? at least from a user perspective. I imagine the node would return both linear and quaternion-interpolated vertex positions and you could mix them with a vertex group or something else. I’m not sure computing all vertex positions eargerly would be very efficient but I’m out of my depth here.

4

I wasn’t aware it was possible to feed hand painted vertex weight groups into a node setup? Have I been missing something all along?

2 Likes
5

Thank you, that’s an interesting use case. Ultimately this comes down to mixing of modifier results in general. The two armature modifiers are just deforming the mesh in slightly different ways, the actual implementation of the dual quaternion (aka. “preserve volume”) method isn’t relevant here.

If i’m not mistaken it will not work when vertex groups for the 2nd modifier overlap, because the vertex weight is used to mix the end result, rather than the relative group influence for a single vertex.

As i mentioned above, the same mixing can be achieved somewhat awkwardly with geometry nodes, storing the result of each modifier as an attribute, resetting the positions before the next one, and then mixing all the attributes in the end. I know this is less convenient, which is why i want to get an idea of how important the feature is considered. It’s unfortunate that the only direct way is this ancient incomplete hack. If we had armature deformation nodes the whole thing could be done in a single geometry nodes modifier.

I’ll wait for more feedback. If no good alternative is found we can maybe just keep it until armature modifiers become obsolete some time in the future.

1 Like
6

In my example they partly overlap, in that the vertex group for the preserve volume has weights on vertices that the main bone vertex groups are primarily deforming. Unless I’m not understanding what you mean by overlap.

As partly per my answer above, I don’t see how that’s currently a viable option, since as far as I know, we can’t directly weight paint attributes.

Again I may have things wrong here, but to use nodes, you’d have to:

  1. Weight paint a vertex group
  2. Convert it to an attribute for reference in a node group of some sort (that does ‘preserve volume’)
  3. Pose test it to see the effect
  4. Convert attribute back to vertex group
  5. Adjust weight painting as required
  6. Go to step 2 and repeat.
1 Like
7

not my area to comment really. but I think you made a typo

" * Complicates armature deformation code: I’d like to refactor and modernize armature deformation code, which would be a lot easier with this feature."

I think you meant “without” this feature so that code will be cleaner and easier in the refactor.

8

Yes. Thanks for the hint, will fix.

9

Yes, of course it is possible to paint vertex groups for use in geometry nodes. Unless we’re talking about different things ?

10

Can you use them directly or do you have to convert them to attributes?

If you have to convert them, then see my post about the resulting workflow, which is far from ideal.

1 Like
11

The use case I immediately thought of is the one that Anthony has mentioned.

While I don’t personally use that technique, it’s very common. I’ve seen it mentioned in posts on user forums, twitter, and youtube examples more times than I can remember. I have tried it, and found it works well. But in my case, I simply preferred the result I got with a single modifier. Each model and rig result is a matter of artistic preference, of course.

And for background, I’m not afraid of using genodes. I think they’re pretty awesome, and in manay cases use node solutions instead of the standard modifiers.

So having said all of that, I don’t believe removing this option is a good idea. To address some of the points supporting removal:

Difficult and badly documented

This is not a concern of the artist. If documentation is a problem with actual problematic ramifications, then the documentation needs to be addressed. We’ve all heard the saying of “I don’t know how it works, but it works.” Well - determining how it works is sometimes how the way forward needs to go. Or, just continue not knowing.

Only works correctly with several armature modifiers right behind each other.

This is not a problem. I have found that the best order for the modifier stack is for the armature to come BEFORE subdivision. This doesn’t indicate a problem with either modifier. Math often gives a different result depending on the order of operation - so does cooking food.

Half-finished: comments mention the same feature should work for cage and lattice modifiers, but these were apparently never added.

If the comments mentioned nothign about cages and lattices, would it still be considered half-finished? I don’t think “stage 2 never happened” quite qualifies as “and the rest therefore should not be here.” Especially when stage 1 works quite well for everyone who uses it.

Untested: There are no automated tests covering this code.

Again, not an artist problem. I note there’s a GSOC happening right now to create tests for development, so it looks like creating tests can be a solution for such problems.

Complicates armature deformation code: I’d like to refactor and modernize armature deformation code, which would be a lot easier without this feature.

Improve artmature performance overall would be a very welcome thing, I think. But it needs to be a feature that is 100% complete, in every way, with parity to existing use cases before removing existing features. Simply removing a modifier option today, because “one day, everything will be redone” is not a fair ask to the users.

The same behavior can be achieved using geometry nodes now.

Are we sure about that?

I’ve seen a PR recently for nodes, so that a geonode doesn’t “destroy” shape key data on the incoming geometry - and, this is a very great PR to see. But is that the last thing left, for data/feature that one loses when putting a node setup on geometry?

I don’t know the answer to that, but the answer would need to be known with full certainty before replacing an existing feature with “just use a geonode.”

On a side note - Lukas, you do a lot of great work in Blender. I hope you won’t take any of that as an attack on your skills, as a person, or your choice of tea vs soda vs coffee.

6 Likes
12

That’s only related to node tools, not the geometry nodes modifier. I do think it’s possible for this to be recreated with two geometry nodes modifiers. It would probably help the discussion to see that.

Another possibility is exposing a very basic version of armature deformation to geometry nodes. Eventually things should become much more flexible and node-based, but for now a builtin node with an armature object input and a geometry input/output would probably erase the concerns people have here. Only question I’d have on a design level is whether we’d want to allow using generic attributes as well as vertex groups for weights, since the distinction isn’t so clear inside of geometry nodes.

1 Like
13

As a proof-of-concept, here’s a modifier setup that reproduces the “Multi Modifier” feature using geometry nodes. The selected object on the right is the geonodes version, it matches the multi-modifier exactly.

image
image2554×1326 480 KB

The “Store Position” nodes first capture the undeformed rest position and then store a custom attribute (“result1”, “result2”) after each modifier. In the end the “Mix Positions” nodes use the same “Mix” vertex group to combine the results.

As i said, it’s not very pretty (5 modifiers instead of 2), but totally achievable and the nodes themselves are not very complicated. That being said, i won’t be removing this feature if there is significant use for it, which seems to be the case. It’s just another bit of technical debt, but one we can live with.

7 Likes
14

I think the use case mentioned by @Anthony_Gibbs could be fixed by having an extra Vertex Group input for Preserve Volume only, it’d be great to have the ability to choose just certain parts of the mesh to be influenced by the Preserve Volume option
image

8 Likes
15

That’s true, we can support this case more elegantly. The only problem i see is that making it backward-compatible would be difficult: Do we check if there’s a second modifier and remove it? Are there other use cases we might break that way?

For 5.0 we allow breaking compatibility somewhat, so maybe this change would be permissible just to provide the feature without full conversion.

1 Like
16

I honestly don’t know if there are any other use cases for this multi modifier workflow, can’t really speak for other users, but if 5.0 is supposed to break compatibility to some extent anyway, I’d say it’s worth doing the change for that version.

1 Like
17

It’s funny that Ton mentioned this on the original commit
image

10 Likes
18

I"m sorry Lukas, but as an Artist and not a ‘node nerd’, I take one look at all that and think, ‘what a mess’. We now have 6 items in the modifier stack, instead of just two and two node trees behind it all to try and make it work.

Add to that, I still have my same basic workflow question, how do I weight paint the preserve volume?
Based on your screen shot, can I just select the mesh, go to Weight Painting, make some adjustments, Tab back to object mode and scrub the timeline to see the affect?
Because that’s how it currently works.

Then add to that, given all the extra complexity, I’d wonder about the performance impact as well.

Yes, that’s pretty much what I would have expected from the get go, rather then just a single on/off switch. But it is what it is now and with in theory the whole rigging nodes and all that coming, I’m not sure it’s worth making any changes and maybe breaking something else.

7 Likes
19

now have 6 items in the modifier stack, instead of just two and two node trees behind it all to try and make it work.

My biggest concern would be how the additional node modifiers would behave in use with the other node modifiers I already have in place. Whenever i start getting attributes involved, or referencing another object within a second object’s node setup - there’s a lots of cross-checking involved to be sure nothing broke, with a slight side of paranoia involved.

Thinking of having to 4 more node modifiers, each in specific positions like that - each with very specific attribute tags all interwoven - scary thought.

4 Likes
20

Yeah, exactly. (No offense Lukas, you do great work), But it’s like adding extra complexity for the sake of using the latest cool feature (Nodes).

Still, I think at this stage the point has been made and it’s just going to all be left alone (maybe a little code/comment clean up, bit better documentation, etc), till a more complete full re-write/replacement is done. Blender 6.0 maybe…

While a clear use case has been established, something that maybe automated testing can be built around and hints that any later (Nodes setup) is ideally more simple and elegant.

2 Likes