Removing the "Multi Modifier" option of the armature modifier

[Baardaap]

@Anthony_Gibbs

Why complicate the process

In the ideal future it should works like this:

• The armature modifier is a (ready-made/asset) GN-tree.
• The interface of the GN tree in the modifier panel is more or less the same as the interface of the current armature modifier.
• The speed is the same as the current armature modifier or better.

(actually I could leave out the ‘armature’ for the list above as that is how all modifiers should look eventually).

If/when we get there (especially the speed part) remains to be seen, but I think we can all agree that that (somewhat hypothetical) rosy future would be a nice thing?

It would be just as easy to use as the current modifier panel, but with the added flexibility/interoperability of GN for those who want it. I think @LukasTonne was just trying to get feedback if this feature was actually used in the wild. Because if it wasn’t the way to the rosy future would be a teensy tiny bit faster/easier. However people here made it loud and clear that yes it is used in the wild. And Lukas already posted that he would keep that in mind and try to work with the technical debt as is.

Personally I would love @HooglyBoogly 's suggestion for a GN node wrapping the current armature modifier. It could later be broken up and replaced with a nodegroup and it would bring the flexibility of mixing/matching multiple armature modifiers right now in a more flexible way than the ‘hack’ of stacking 2 on top of each other which look like a table but behave like 2 parallel nodes with a mix node.

[Anthony_Gibbs]

@Baardaap

If/when we get there (especially the speed part) remains to be seen, but I think we can all agree that that (somewhat hypothetical) rosy future would be a nice thing?

Yes, I can see the potential of having much the same setup as now, while then also being able to dig deeper into say the node setup and do all sorts of other fancy adjustments, etc.

But then I still see a couple of big issues. First, as you say is performance, it all needs to at least be just as fast.
Second is what I pointed out above, there’s no easy way or UI to manage Node groups. It’s all only tied to some other object. I can see that all getting more and more annoying as time goes on, especially if every modifier in a stack is a node group in the background.

[Hadriscus]

@Anthony_Gibbs

there’s no easy way or UI to manage Node groups.

I’m not sure what you mean. What is “manage” here ?

[JulianPerez]

@Anthony_Gibbs

It’s all only tied to some other object.

Sorry I know this is off topic but 100% agree, we need a better way to manage node groups, materials and textures. These data blocks shouldn’t have to be tied to an object to be able to be created and edited.

[Anthony_Gibbs]

@Hadriscus

I’m not sure what you mean. What is “manage” here ?

My most recent use case was to take a couple of Node groups I was working with and thought were all working (more on that in a bit) and turn them into an asset library basically.

Ideally, I’d like to be able to just select the node groups (something you can’t really do anyway) and just click save and all that would be in the file is those Node groups and nothing else.

Then, after more testing, I’ve since found that they aren’t fully working. So I have to open the library file, add a new object, attach the Node groups, make the changes, delete and purge the object data and re-save.

Now sure, I guess one could just leave the ‘dummy’ object there, but it’s not really the cleanest solution and what happens if the library file happens to have a 100+ Node groups. Do you now have a single file for each or multiple objects with 10 Nodes only attached, etc.

Now, lets expand this to the ‘future vision’, where every modifier on every object is in fact a Node group. Is every attached Node group, even if it’s the same ‘modifier’, say an Armature, the exact same Node group or have you made some specific changes on a couple of objects? So 3 objects have one Armature Node group, 1 object has an edited unique Armature Node group and another object has yet another unique Armature Node group.

Now multiple that for say 100 objects in a scene, each with 3-4 modifiers (which are in fact Node groups). We now have 300-400 Node groups in use, some of which are used in multiple places (say default setups) while some have been edited and are unique and all of them have a Node group name (chances are Armature (for the default group), Armature.001 for the first unique one and Armature.002 for the second unique one.

Now, with all that, something in your scene/animation isn’t working correctly or is messed up, likely a Node group. But you can’t list/see/track/step through all the Node groups with info on what objects they are applied too and pull up the tree easily on each one while say watching the viewport playback and selecting various objects.

Now I’m not saying I have all the answers or any answers, I just feel that how things currently are, if Node group visibility and management is left how it is, but there usage is greatly expanded to ‘Everything Nodes’, I can just see things getting so much more complex with no easy way to view/search/edit or manage that complexity.

[Baardaap]

@Anthony_Gibbs

Now, with all that, something in your scene/animation isn’t working correctly or is messed up, likely a Node group. But you can’t list/see/track/step through all the Node groups with info on what objects they are applied too and pull up the tree easily on each one while say watching the viewport playback and selecting various objects.

While I agree the UI and datablock management could use some love it’s not really different from what we have now though? The Current (armature) modifier’s settings can also only be edited on the modifier stack of the object it’s on. You can’t even save a specific setting of a modifier as an asset at all.

[thorn-neverwake]

@Baardaap

The Current (armature) modifier’s settings can also only be edited on the modifier stack of the object it’s on.

I think what Tony means is that when you’re editing the settings on an armature (presently), you know you’re not changing what happens on a character somewhere else in the scene that also has an armature.

[Anthony_Gibbs]

@thorn-neverwake

I think what Tony means is that when you’re editing the settings on an armature (presently), you know you’re not changing what happens on a character somewhere else in the scene that also has an armature.

Yes, tho more so if you happen to make a change at the actual Node group level (for when the Armature is a node group), that it then doesn’t automatically impact every other object using an Armature (node group).

As such do you then have to remember to make it unique or will it do that automatically. Does it become a ‘unique’ specifically name node group every time you add an Armature ‘modifier’, even if you never change the node group, only the settings in the modifier stack.

Now potentially apply that to every single modifier that you add to an object, if that’s the future, then things can get very messy very fast.

@Baardaap

While I agree the UI and datablock management could use some love it’s not really different from what we have now though?

But it is very different, if there’s a node group behind every modifier on every object. As an old boss of mine use to say, it’s all got a lot of hairs on it (if everything nodes is the future).

[Baardaap]

@Anthony_Gibbs

As such do you then have to remember to make it unique or will it do that automatically.

We would sure need some streamlining in datablock management. I could envision an asset/nodetree flag where any modification would automatically cause it to become unique or some such system.

It’s useful to think these things through for sure. But that doesn’t imho mean that the goal to make everything a nodetree is bad in itself. It has too many advantages and the disadvantages are imho not (technically) hard to solve.

[Josephbburg]

1. my addon is free
2. I have stuck strictly to the facts
3. I have never suggested deprecating anything - only making improvements to the existing system and streamlining things
4. Even if what you said were true (it isn’t), my addon is built on the Blender features and introduces no new functinality besides a clever way of automatically building things. If you like how Blender’s rigging system works, it takes all of ten minutes to learn my node system and you don’t have to change how you rig anything – you just don’t have to click through 10 menus anymore
5. Deveolpment is moving toward Rigging Nodes with or without me, whether you like it or not. It has been the plan for years now already.
6. I would no longer have any way of monetizing my addon (by selling a supporting product) if Blender did the same thing and gave away a free component pack (which I would be happy to build for the community, at that point).

it is infuriating to me that you would do so little research and then lie about me. Just apologize and delete the post, please. Both your post and mine are clogging this discussion with unecessary banter, and I want to delete mine, too.

[LukasTonne]

I’m closing my PR for now. As the backlash here shows there seems to be a significant need for this feature, badly implemented as it may be. Any proper solution would require changes beyond what i would be comfortable getting into as a side project.

Since it seems to have gotten lost in the discussion, i want to point out again how this could be done in geometry nodes. The solution isn’t very elegant or practical, the only point is to demonstrate that it is possible. Having to manage attributes across multiple modifiers is breaking the modifier stack design, which is why native armature deformation in nodes would be necessary first.

Thanks everyone for your input!