Removing the "Multi Modifier" option of the armature modifier

Feature & Design Feedback
,
21

Rigging nodes is a long way out still. We should improve Blender as much as possible now so that it is I’m a good state for when we make the switch. Armature deformation, being at the core of any rig, is too important to tolerate any performance loss.
I myself have never seen any use for this option except mixing linear/quaternion blending for the bones. This is a feature a certain other very popular software controls with its (vastly more difficult to use) version of weight painting.

I think we should make the breaking change for a few important reasons:

  1. I disagree that the problems mentioned in the first post are not problems for artists.
  2. we have many times as many users of blender who could benefit from faster, cleaner armature code
  3. one of the most oft-cited reasons for preferring other software, in my experience, is performance in heavy scenes with animated characters. While I think those people are mostly having the problem because they don’t know how to set viewport/render options… Let’s just try and make Blender faster so they can’t use that excuse anymore, and have to pivot to something even more niche.
  4. the rigging module should not cater to users who are scared of complexity and unwilling to A/B test. Tech art is Inherently complex, and the further we move in the direction of Everything Nodes, the less complexity is hidden from the user. This comes with the ability to group nodes, which hides the complexity without masking it altogether.

So I suggest:

  • create a new GN node to handle armature deformation and a default GN group to fix up modifers that used the option in versioning.
  • if that is too much trouble, break compatibility and put a detailed example workaround in the changelog
  • in either case, add an option to blend linear/dual-quat skinning so that the main use-case can be restored in an easy, artist-friendly way. This may even be detected and fixed in version code.

Basically, it is worth it to take a small hit (minor break in compatibility that only affects a handful of users) to avoid a bigger hit (slower performance that affects almost every user and scares some away from Blender entirely).

And regarding rigging nodes: when it is ready, each node should do ONE thing and do it well! The current armature code does not do that, so it will lead to work when we port it over!

6 Likes
22

I think the only real usecase for the multi-modifier option I have ever heard of is mixing linear and dual quat skinning based on weights

I know geo nodes are awesome, but they’re also… slower than stuff that has been purpose built for one specific thing. I think for now simply adding an option like suggested here is a good solution:
image
I don’t think there’s going to be many people using duel armature modifiers who wouldn’t be able to also quickly rectify this in a file after the move to 5.0

I think on a broader note, supporting bone based deformation in geo nodes would be great, but also seems to make a future where blender supports GPU accelerated armature deformation even more fantastical. And since that is often the biggest bottleneck in rig evaluation, I think having a modifier with limited but well thought out options, which is also FAST is very important.

3 Likes
23

“How much faster” in terms of viewport playback speed is an important metric, whether the code is clean or not.

If one gains 10FPS due to cleaner code - by all means, it’s a compelling argument. If it’s something like “30ms faster in playing, after play button clicked” - then not.

While I think those people are mostly having the problem because they don’t know how to set viewport/render options…

Agreed. And the solution is fix the people.

the rigging module should not cater to users who are scared of complexity and unwilling to A/B test.

For myself, it is not a fear factor of complexity, just because it’s complexity. Complexity in and of itself has to offer something that is worth the effort to deal with it. I know the above 4-node-setup was just a quick mockup of “here’s something”, but it wasn’t even in the same room as the party I want to go to. You can’t sell me on multiple node stacks, that might only duplicate what I have now - but also require MORE work on my end to use, with a speed gain that is (at present) dubious.

The armature modifier (not just in blender, but other softwares are also similar) isn’t perfect for all situations, but it’s pretty good for the ones that are most expected and most used. Same with IK solvers. Turning it all into nodes, just because some artist wants to be able to have access to a random value that most others don’t care about… I’m not against nodes, as already stated. But to convince users it’s something they want to use, it has to BE something they want to use.

On a semi-related note, I’m sure some have seen that rigging node setup that’s been developed in the past few months and is on blendermarket. I’ve taken a look at it. It does look interesting, it does look like it has some good thought put into the design. But do I want to use it, instead of more traditional rigging as I am now? No, i don’t. I don’t see what it’s offering that I need, but I don’t already do (and do easier.)

Just because something IS a node system, doesn’t make it better than something that is not.

3 Likes
24

Why would functionality be removed so it can possibly be replaced with geometry nodes that don’t currently exist? Wouldn’t it make sense to make the replacement nodes first and then talk about removing stuff? Bit of a cart before the horse here

4 Likes
25

To be fair, I am suggesting we replace it with a setup that is as simple for the end user (a vertex group in the modifier to blend between linear/quat skinning). So for the end user it should be easier in the only example of its use any of us have seen in the thread! Even if we do go with a workaround, it could be done in a much simpler way with the addition of an armature skinning node. Frankly, I think all the modifiers should be accessible through the node system!

Rigging with nodes isn’t necessarily about expanding control into ever-more complex and niche areas. To me, it’s more about streamlining workflows by making rigging easy to repeat and extend.

Would you mind linking the addon you mentioned? It sounds very interesting.

26

It can be done with the existing nodes. The suggestion to add a new node would just make it an easier transition.

27

Let me rephrase- why would a single click checkbox be removed for a six modifier, double-digit node count solution? If something can be done in one click, a replacement by nature of the definition of “replacement” needs to be able to do it in roughly the same amount of clicks. I could drive my car into a ditch and walk everywhere, sure, but that’s not a replacement for driving

3 Likes
28

Well, I am saying we replace it with something simpler (a vertex group to control linear/quaternion blending).
The “here is how to do it with geometry nodes” thing has everyone freaking out about the potential change because the solution is kind of ugly… But it is just a mockup to show it can be done, to make the point “we should do this with nodes when the nodes system is ready for it, because this is the kind of problem nodes solves”
I think we need a more elegant solution before making the change, ideally something that doesn’t break compatibility. But if it is easier to refactor, clean up, and improve armature code without the multi-modifier feature - the benefits outweigh the cost.

5 Likes
29

Another vote here for using the current multi-modifier setup to blend volume preservation with non volume preservation rigging (for underarms/shoulder blades, mostly, but also other areas of the bodies). All of my rigs depend on this. It’s a well-known technique that is easy to implement as an artist with a single checkbox. A sprawl of geometry nodes is a downgrade.

“The benefits outweigh the cost” sounds like the kind of justification used to wedge eevee-next into 4.2 while it had/still has multiple workflow and performance issues for some types of scenes.

Please, if you make this change, finish the implementation as much as possible first. I keep limping along with features in an awkward state where there’s 80% of a new solution that kind of works, but the missing 20% contains critical features or improvements that hold me back from adopting it. Usually either the old solution is branded as legacy and no longer accepts fixes, or the old system is straight up gone. And the new system will be done “someday”. I hate to see the list growing.

6 Likes
30

We already have something simple, you add a second Armature modifier and paint a vertex group. It works, it’s been in place for ages and it’s very artist friendly.
Would just having a direct vertex group option in the modifier make things a little clearer, sure, but it then also doesn’t really change anything, while breaking every existing setup.
Unless doing that, removing the ‘multi modifier’ option/code actually results in a noticeable performance increase (viewport FPS), then it’s not worth it.
Of course the only way to find that out, would be for Lukas to actually do the work and compare the results.

Yeah, sorry, but based on past history, that just doesn’t fly with me. Hair and cloth simulation has been largely left untouched for ages, while at almost every turn, whenever an improvement/feature/tweak has been suggested, the general reply has basically been “it’s going to be replaced by nodes and so isn’t worth the dev time at the moment.”

It’s been there for 18 years so it can’t be that huge a deal or something would have been done about it sooner.
Add to that there’s no way at the moment to know what performance difference removing ‘multi modifier’ would have and also what performance hit any ‘feature’ replacement would have. Tho I think I can be pretty sure that the example node setup at this stage would be slower.

I’m going to have to somewhat disagree there. While power and flexibility is important, I think everything should be as user friendly as possible.
What are we trying to say here, that if you want to make various types of art, you need to have a PhD in mathematics first.

Lets not forget Blenders core value, "Freedom to create’. To me that also means making it as easy as possible to create what one can imagine and want to create. Now sure, have the power and the tools in the background for those that want to or in the case of very complex/involved productions, actually need to dig deeper. But ideally, for 98%+ of users, they don’t have to dive into that level of complexity.

4 Likes
31

Apparently there would be no performance penalty

32

It would be more ethical of you to disclose that as the developer of the paid rigging nodes addon Mantis Nodes, you stand to financially gain from deprecation of armature functionality and have a vested financial interest in pushing development towards rigging nodes

ETA: I don’t believe there’s anything inappropriate about asking for disclosure when someone has a undisclosed financial agenda in a conversation. I will however remove my opinion and leave only facts

33

Isn’t the purpose of refactoring this code to implement armature deformation in geometry nodes?

If so it could be removed before refactoring, as long as the refactor and armature deformation node land in main at the same time. Ideally with versioning.

Which weights is this referring to?

If it’s the weights for binding bones to vertices, I think those definitely should stay vertex groups for now. The whole weight painting workflow is built around that. The ability to customize those weights may be quite niche.

If it’s the influence weight, I guess it can be a regular attribute since I imagine it’s not hard to connect a vertex group to that.

34

Also ideally with native UX tools that give the artist an elegant way to create and modify the necessary attributes.

That was noted (and subsequently fell off the radar) when edge and face groups were removed from Blender, so would be good to not repeat that.

2 Likes
35

I was referring to the weights binding bones to vertices, and I just mentioned that because it’s very easy to convert a vertex group to a generic attribute in geometry nodes, and the existing design handles the difference transparently (inside of geometry nodes anyway). I don’t mean to talk about replacing vertex groups with attributes in general. But maybe better to keep it simple and just require vertex groups still.

I’d think the influence weight wouldn’t even be a node input anymore, it would be trivial to do the mixing separately with geometry nodes.

To be clear, edge groups never existed.

36

Thanks for correcting that; I must have been thinking of some other situation, might have been a suggestion to add edges to the other 2, or something. Dunno (shrug).

ETA - ah, is was this.

But - I think to the overall - point remains. Right now, artist can just drop the second armature and move forward. If we have to start tagging various things as attributes to flow into a node (or, several nodes), then better tools (and probably solid examples in the manual) to assist in that will go a long way towards making the remove of multi-modifier more accepted.

With versioning - one cannot just assume that if a mesh has 2 armature modifiers on it, that one of them IS using MM and can thus be removed and versioned away. So would have to check beyond that.

1 Like
37

This influence is sometime used to deform different parts of the body with different modifiers. If the mixing happens afterwards, performance could be worse.

Edit: unless the armature modifier works in a field, then I guess some work could be optimized out?

38

I know you’re likely just trying to make sure these tools are the best they can be, but to me it feels as though you are being rather combative to someone who is doing good work and showing possible solutions to a problem. Mantis rigging nodes is free and open source and @Josephbburg is doing good work and has been very reasonable with his suggestions and his tone, while it feels like you are being a bit aggressive (might just be me misreading things, but I’m probably not the only one)

8 Likes
39

That’s entirely fair. As I’ve said everything I want to say here anyway, I’m going to step out of this conversation to avoid turning it in the wrong direction

40

Why?

Why complicate the process with now having to add and manage (name) node groups, which are then also a modifier in the stack, while having to feed/link in vertex group(s) and possibly feed back out attributes to feed into another node group (based on current quick demo setup), just to get what can already be done pretty simple.

Then on top of all that, hope that performance is at least the same.

Then there’s still one of the overall problems with Nodes, and that is the lack of any real easy way to view/manage node groups. They not an ‘object’ or asset on their own. You can’t view or edit a node group without first assigning it to an actual object.

4 Likes