Whoops, so much for "Good first issue"! I forgot about that task, thanks for the reminder. Maybe this task is sort of redundant then, since the design proposed in T61209 solves the same issues, and perhaps more elegantly. It's just a shame since that seems like a pretty daunting task that probably won't be tackled for some time, so until then I am left with shoving a "Purge All" button in the animation team's face and hope that they press it often. :/

Marking as "Good first issue" on Julian's suggestion, if any contributors would like to pick this up, it's probably(hopefully) simple on the implementation side.

You've got the best TODO's Dalai 😂

Tried opening a production file with the patch applied, and it just works! Thank you to the code doctor!

Here is a (hopefully) simpler file to see the issue:

This will be a big problemo for the Studio, as the forest creatures of Sprite Fright will use (and already are using) plenty of lattices, and will be (and already are) duplicated plenty of times.

I found a new way on latest master, I thought it's not worth opening a new task since it's quite similar:

• Duplicate an override collection
• Delete Library Override Hierarchy on both

That's pretty much it :)

Sorry, it should be under the ID Data sub-menu.

I would be okay with having to run a few search&replaces along the lines of "scaleiny"->"scaleinz" on my repositories if that's what we're talking about.

File currently crashes on my PC, posting stack trace as discussed IRL :)

Well, I really like your attitude, and am excited to see where this goes! :D

Benoit's advice seems on point, and we have a strict policy on filling out bug reports, this has too little information for a developer to investigate, so closing.

Accidently posted this in the patch instead of here first, but here is more relevant:

You can try 2.79, but since this isn't a bug report it doesn't really belong here, please use user help forums like https://blender.stackexchange.com/.

Before you burn too much time into this, it might also be good to have some devs from the PyAPI module take a look at the idea to make sure they're okay with it. @Campbell Barton (campbellbarton) perhaps?

So this is what you guys have been filling those whiteboards with!

Just to note here what was discussed in the Animation Module meeting (which is free for anyone to join): If no legitimate use case is provided soon to back up the Y/Z symmetry + Vertex Group X symmetry, we will most likely go ahead with the patch as it is.

Some rigging use cases:

• Add more "hacky" behaviour to the armature Symmetrize operator. (post-execute)
• Entering weight paint mode would put the relevant armature and shading settings in the correct state automatically. (pre-execute)
• Extruding a bone whose name already ends with a number would increment the number instead of adding .001. (post-execute)
• Run newly added text datablocks with Register enabled on Append/Link.

Would this mean addons could "change" (or at least add to) the behaviour of built-in blender operators, even those implemented in C? If yes, that sounds VERY exciting! Sign me up! :D

Oh I see, thanks for the clarification! That does sound like a bug indeed :)

Looks like you're running Windows Vista, which doesn't support recent Blender versions. You will need newer hardware and software to run Blender 2.80+. Until then, you're stuck with 2.79.

From the PyAPI:
id_data: The bpy.types.ID object this datablock is from or None, (not available for all data types)

Report contains no information, perhaps this was submitted by mistake, closing.

I think that's fair. It seems like this is one of those very awkward scenarios where potentially useful behaviour emerges from code that was never designed to work in the way that it works. Now if we try to fix it, it feels like we're removing a feature. It would be easier to justify the extra effort in preserving that behaviour if there was a legitimate use case to prove that this coincidental behaviour is genuinely useful. Also worth noting that this is fairly recent, and has caused issues ever since it was introduced, so it's not like we would be ruining a workflow that the industry has been relying on for decades.

I think if this was split out into a separate addon, it could be made more discoverable because then that addon could have the "Location" entry say View3D -> Pose -> Convert Rotation Modes. I would gladly do this sometime.

It is absolutely not a bad thing to be able to use Y symmetry to paint a Vertex Group.R and see same symmetric painting applied to Vertex Group.L at same time.

people don't want symmetry shared across modes

While I agree this would be good to support, I think it's a separate issue. The main issue here is that if you want symmetry in weight paint + any other mode, you always have to DISABLE it in weight paint mode, because you end up with two totally unrelated pieces of code(old+new symmetry) executing that were never meant to be used together.

Both types of symmetry are useful.

The distinction you're making between the two "types" of symmetry are not the two types that are being discussed here. Painting masks for modifiers, particles, geo nodes, etc, is supported by both implementations. As long as the vertex group's name has no side indicator (.L/.R) in it, the strokes will be mirrored to the same vertex group, which is totally fine.

I'm assuming you're talking about the header bar in some of your points, which is great because I totally forgot the symmetry options exist there, so it's great you caught that!
All of the above gets a +1 from me. Enabled by default on new meshes, include checkbox directly in header bar, move checkbox to top of Symmetry panel, +1 +1 +1!!

Thanks for the report, this is a known issue, take a look at T82404#1095103 for a workaround you can use until this is fixed!

+1, "Vertex Group Mirror" is an improvement over "Vertex Group X", and the information that this feature is exclusive to X axis is now communicated by the graying out of Y and Z so that works out nicely.

Just a few lines, yet so powerful! Seems to work! A name change from "Vertex Group X" would be welcome, if that can be snuck in this patch, but I actually don't have a good suggestion, and I'm terrified of naming discussions dragging out, so I don't mind that much.

Many thanks! :D One fewer weird little things in Blender ;)

Trying to assign this to the right people/places, let me know if any of this is wrong (or just rude)...

The surface deform modifier uses the transformation delta of each vertex of the target object to deform the modified object, so if the target object's vertex count changes, there's no way to know which new vertex corresponds to which old vertex. There's really no good way to design around this, other than better warning the user. Or you could have a button that duplicates the target object and removes generative modifiers, but that sort of functionality belongs in an addon.

I am 100% sure this is not a bug because I use this modifier on a daily basis and this is just its most common pitfall: The surface deform target object has generative modifiers on it that are only enabled on the render. You'd want to make a hidden duplicate of that target object and remove any generative modifiers from it, to use that as the surface deform target.

Just updated my Blender to test, thanks so much for the fix!

The same issue is present with cursor snapping. "Snap cursor to selected" snaps to the mesh object rather than bones. I'm guessing it's the same issue, but if not I can open a separate report. I'm also less confident that this didn't always work this way, but I don't think it did. It's definitely wrong either way though.

Tested! Thanks for the patch! I'm not a C coder, but I have some feedback on what it's doing:
Although doing what it should, there is a difference between this and how brushes do their normalization. The way this works is actually not necessarily better nor worse, but different:

• When a vertex only has a weight for one group, you shouldn't be able to subtract anything from it. This was always slightly controversial, but that's how brushes currently work with Auto-Normalize.
• Even when a vertex has weights from multiple groups, when you subtract all of one group's weight from a vertex, it should result in a weight of 0.0 still being assigned to that vert. Instead, it seems to un-assign that vert completely. I actually prefer this, but this is inconsistent with what brushes do. (Adding this as a feature would be totally nice though, but that's a discussion for another patch c:)

Weight paint mode is now 20% better and life is worth living again, thank you so much.

Praise the overlord! Thanks a lot! I guess this can be closed, if something like this happens again I'll come and break some hearts and re-open :D but I'm sure it won't! 🙏

The programmer will always have to worry about what object is being joined into what, because the operation will have completely different results depending on it. Using the active object for this seems completely logical and intuitive to me. As for the unwieldiness of setting the active object, that is addressed by operator context overriding elegantly and successfully.

With it in mind that both of these solution would be similarly straight forward to implement, there was a clear consensus in today's meeting to go for the first solution. @Pablo Dobarro (pablodp606) would you be able to implement this in the near future, or are you too busy?

I asked Pablo about his workflow with the Animation Layers addon and whether it would help test this patch, but the short answer is no. So we're back to naive testing! But still, that I can do.

Yep, that sounds correct! So it seems that the gradient tool is ignoring the auto-normalize setting.

Auto-Normalize should make sure that all deforming weights on each individual vertex add up to 1.0 at all times. So, the influence of Bone2 is expected to be subtracted from the influence of Bone1, as a result of making sure that their combined weights add up to 1.0 on each vertex.

After you've done the reproduction steps, you can go back to the Brush tool, and make a stroke with a very low brush strength like 0.00001. This will trigger the normalization, and the weights will be subtracted from Bone1 as expected.

The arguable behaviour of normalizing 0.0 to 1.0 has some use cases, like cleaning up automatic weights where a few verts didn't get assigned to anything. I can just go with any brush set to 0 strength to assign the vert to whatever bone I need, without touching any other weights.

(Also, since checkboxes should be on/off functionalities, this would ideally be an enum, but I guess in the context of nodes, enums are not so great?)

I do find it sad that turning it into an enum means losing the ability to plug a noodle in it. Admittedly, I don't see a use case, but what if there is one out there? :D

Thanks for taking the feedback Dalai!

If I understand this correctly and the checkbox converts local to world space, I'd advocate to naming the checkbox simply "Use World Space" because "Apply Transforms" has other meanings. I can see a world where user A asks for help regarding why their instances aren't moving with their objects, helpful user B tells them "Have you tried Apply Transforms?" to which user A goes in the 3D viewport and presses Ctrl+A and then is sad. ;)
(Also, since checkboxes should be on/off functionalities, this would ideally be an enum, but I guess in the context of nodes, enums are not so great?)

In T84750#1095648, @Sybren A. Stüvel (sybren) wrote:

In T84750#1095571, @Demeter Dzadik (Mets) wrote:

armature_a.users_remap(armature_b)

As far as I can tell this isn't exposed to PyAPI?

It is, but only if you spell it properly (my mistake)

It doesn't help that I'm blind! :D

How about a choice

I'm all for choice! :D I guess the safest default then might be "Never".

Perhaps this statement

Also note that, although I see the point of unifying symmetry options across different modes, there seems to be a consensus among riggers that weight paint mode should be an exception from this.

is no longer true if the behaviour was more in line with what's expected? In discussions it sounded like people wanted the symmetry options separate, EVEN IF it's working correctly. But maybe I misinterpreted this? I'm fairly neutral on this one, since I don't switch between weight/edit/sculpt mode in my work.