"Double Symmetry" in Weight Painting #84520

New Issue

Demeter Dzadik · 2021-01-08T14:25:43+01:00

Demeter Dzadik commented

2021-01-08 14:25:43 +01:00

Situation

Currently there are two types of X-axis symmetry available in weight paint mode. Let's refer to these by their current python API names.

use_mirror_vertex_group_x uses old symmetry code which relies on finding vertices on the opposite side of the mesh from the vertices affected by the brush stroke. This supports vertex group name mirroring, and is therefore the more useful option when trying to weight paint symmetrical characters.
use_mirror_x uses new code which is shared across all painting modes, and mirrors the actual brush stroke, hence works even on asymmetrical meshes. Also supports Y and Z axis symmetry as well as Radial. However, this does not support vertex group name mirroring, which is essential for weight painting.

Problems

Currently, it's possible to have both of these options enabled at the same time. The resulting behaviour in this case is catastrophic, as two totally separate symmetry implementations run at the same time.
This will happen frequently, because you could easily forget to toggle use_mirror_x off when switching from another mode's symmetrical workflow into weight paint mode. You must toggle it every time you change modes.
Weight operators like Smooth Vertex Weights is only symmetrical when use_mirror_x is enabled.

<Solution 1 & 2 have been removed from here as they are no longer relevant.>

Update and Solution 3:

use_mirror_vertex_group_x is grayed out until use_mirror_x is enabled.
If both of the above options are enabled, Blender will use the "old" symmetry implementation, meaning that Y, Z and Radial symmetry become grayed out.
This prevents the new and old symmetry implementations from both being active at the same time.
As long as you keep use_mirror_vertex_group_x enabled, you won't have to worry about changing symmetry settings when switching between weight paint mode and sculpt/edit mode.
You would only ever disable use_mirror_vertex_group_x if you need Y, Z or Radial symmetry, which is fairly rare.
You can not have Y, Z or Radial symmetry at the same time as vertex group name aware X symmetry. This is not a new limitation, this wasn't possible in the past either.

Adding vertex group name awareness to the "new symmetry" would be a bigger undertaking with threading headaches, but hopefully something that can happen in the future.

CC @angavrilov @dr.sybren @jpbouza-4 @PabloDobarro @BassamKurdali in case I missed anything :)

### Situation Currently there are two types of X-axis symmetry available in weight paint mode. Let's refer to these by their current python API names. - `use_mirror_vertex_group_x` uses old symmetry code which relies on finding vertices on the opposite side of the mesh from the vertices affected by the brush stroke. This supports vertex group name mirroring, and is therefore the more useful option when trying to weight paint symmetrical characters. - `use_mirror_x` uses new code which is shared across all painting modes, and mirrors the actual brush stroke, hence works even on asymmetrical meshes. Also supports Y and Z axis symmetry as well as Radial. However, this does not support vertex group name mirroring, which is essential for weight painting. ### Problems - Currently, it's possible to have both of these options enabled at the same time. The resulting behaviour in this case is catastrophic, as two totally separate symmetry implementations run at the same time. - This will happen frequently, because you could easily forget to toggle `use_mirror_x` off when switching from another mode's symmetrical workflow into weight paint mode. You must toggle it every time you change modes. - Weight operators like Smooth Vertex Weights is only symmetrical when `use_mirror_x` is enabled. **<Solution 1 & 2 have been removed from here as they are no longer relevant.>** **Update and Solution 3:** - `use_mirror_vertex_group_x` is grayed out until `use_mirror_x` is enabled. - If both of the above options are enabled, Blender will use the "old" symmetry implementation, meaning that Y, Z and Radial symmetry become grayed out. - This prevents the new and old symmetry implementations from both being active at the same time. - As long as you keep `use_mirror_vertex_group_x` enabled, you won't have to worry about changing symmetry settings when switching between weight paint mode and sculpt/edit mode. - You would only ever disable `use_mirror_vertex_group_x` if you need Y, Z or Radial symmetry, which is fairly rare. - You can not have Y, Z or Radial symmetry at the same time as vertex group name aware X symmetry. This is not a new limitation, this wasn't possible in the past either. Adding vertex group name awareness to the "new symmetry" would be a bigger undertaking with threading headaches, but hopefully something that can happen in the future. CC @angavrilov @dr.sybren @jpbouza-4 @PabloDobarro @BassamKurdali in case I missed anything :)

Demeter Dzadik commented

2021-01-08 14:25:43 +01:00

Added subscribers: @angavrilov, @Mets

blender-admin commented

2021-01-08 14:25:43 +01:00

#84838 was marked as duplicate of this issue

Demeter Dzadik commented

2021-01-08 14:27:34 +01:00

Added subscribers: @PabloDobarro, @jpbouza-4, @BassamKurdali, @dr.sybren

Sybren A. Stüvel commented

2021-01-08 17:08:05 +01:00

Added subscriber: @JasonSchleifer

Sybren A. Stüvel commented

2021-01-08 17:08:05 +01:00

To me this seems a clear description of the problem. I'd also prefer solution #1, but take that with a grain of salt, I'm not a rigger.

Sybren A. Stüvel commented

2021-01-08 17:09:36 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'

Diogo Valadares Reis dos Santos commented

2021-01-08 22:48:08 +01:00

Added subscriber: @Diogo_Valadares

Juan Pablo Bouza commented

2021-01-11 17:23:28 +01:00

Ok, so I had not worked with master in a while and I had to check what all these changes do, so correct me if I'm wrong in anything that I say...

So, the introduction of use_mirror_vertex_group_x has solved an issue I had mentioned in our Animation & Rigging modules meetings, which was that many times you wanted to use symmetry in weight painting but not in edit mode and vice-versa. This applies to the weight painting while editing shapekeys workflow, for instance. Not remembering to turn on or off the option could ruin your work.

The solution I had proposed for this was to just stop sharing the state of the option between modes.... But now all these new changes were introduced...

Therefore, about the use_mirror_x option, I totally agree with Demeter in everything regarding this option in weight painting, as a rigger it's totally useless and it breaks your vertex groups if you are not careful about turning it off.

On the other hand, removing it from weight painting mode would deprive us from the very rare use case of needing to paint symmetrically between the Y and the Z axes....

So, the solution I would propose would be the same I initially mentioned......... Why on earth do we even have to share the state of these options between modes? Sharing them only leads you to making mistakes. I really don't see any harm in just making them separate options for each mode, that way the user can decide what they want to use in each mode freely.

I think this would enable total customization, no more space for user mistakes, and eventually we could even talk about default options for each mode.... For instance, x-mirror should definitely be off by default in weight painting mode.

I would also like to add that introducing the Vertex Group X checkbox in Weight Painting mode, kind of clarifies the original confusion with had in the GUI between the "X" button and the "x-mirror" button. So +1 for that change.

Ok, so I had not worked with master in a while and I had to check what all these changes do, so correct me if I'm wrong in anything that I say... So, the introduction of use_mirror_vertex_group_x has solved an issue I had mentioned in our Animation & Rigging modules meetings, which was that many times you wanted to use symmetry in weight painting but not in edit mode and vice-versa. This applies to the weight painting while editing shapekeys workflow, for instance. Not remembering to turn on or off the option could ruin your work. The solution I had proposed for this was to just stop sharing the state of the option between modes.... But now all these new changes were introduced... Therefore, about the use_mirror_x option, I totally agree with Demeter in everything regarding this option in weight painting, as a rigger it's totally useless and it breaks your vertex groups if you are not careful about turning it off. On the other hand, removing it from weight painting mode would deprive us from the very rare use case of needing to paint symmetrically between the Y and the Z axes.... So, the solution I would propose would be the same I initially mentioned......... Why on earth do we even have to share the state of these options between modes? Sharing them only leads you to making mistakes. I really don't see any harm in just making them separate options for each mode, that way the user can decide what they want to use in each mode freely. I think this would enable total customization, no more space for user mistakes, and eventually we could even talk about default options for each mode.... For instance, x-mirror should definitely be off by default in weight painting mode. I would also like to add that introducing the Vertex Group X checkbox in Weight Painting mode, kind of clarifies the original confusion with had in the GUI between the "X" button and the "x-mirror" button. So +1 for that change.

Demeter Dzadik commented

2021-01-12 10:56:58 +01:00

Added mention of splitting weight paint symmetry off from the shared symmetry options to the original post.

And just to clarify, I didn't suggest removing the YZ symmetry options, just merging the current function of mirror_vertex_group_x into use_mirror_x. use_mirror_y and use_mirror_z could still be there, for their one in a million year use case :D

Added mention of splitting weight paint symmetry off from the shared symmetry options to the original post. And just to clarify, I didn't suggest removing the YZ symmetry options, just merging the current function of `mirror_vertex_group_x` into `use_mirror_x`. `use_mirror_y` and `use_mirror_z` could still be there, for their one in a million year use case :D

Demeter Dzadik commented

2021-01-12 17:44:00 +01:00

I just discovered that weight operators are only symmetrical when the X toggle is enabled, which makes this situation even worse, edited OP accordingly.

Juan Pablo Bouza commented

2021-01-12 21:01:33 +01:00

Ok, so I've also been thinking about this too and as Demeter mentions, all of these solutions still have the original problem of being shared across modes.

On the other side, I can totally see that sharing these symmetry options between Sculpt and Edit mode is cool for when you are sculpting...

I also vote for Solution 1.

But then, as it seems that sharing the symmetry option is beneficial to one type of user and not to others, couldn't we make that an option?

So, what about adding this "share x-mirror between modes" option either at the user preferences or at the tools panel? Does that make sense?

That way, depending on what you will be doing, you can turn sharing on or off.

Ok, so I've also been thinking about this too and as Demeter mentions, all of these solutions still have the original problem of being shared across modes. On the other side, I can totally see that sharing these symmetry options between Sculpt and Edit mode is cool for when you are sculpting... I also vote for Solution 1. But then, as it seems that sharing the symmetry option is beneficial to one type of user and not to others, couldn't we make that an option? So, what about adding this "share x-mirror between modes" option either at the user preferences or at the tools panel? Does that make sense? That way, depending on what you will be doing, you can turn sharing on or off.

Pablo Dobarro commented

2021-01-13 03:58:30 +01:00

In my opinion, the core issue here is that "Weight paint" is considered a "paint" mode which shares a lot of code and functionality with sculpt/vertex/texture paint, and that should not be the case. The requirements and features that are needed for the brush engine in weight paint and the rest of the painting modes are completely different, Trying to share code and unify them introduces these kinds of conflicts and limits the development of new features for both modules. As an example, a feature like D8377 being part of the shared brush engine is completely useless for weight paint, but because it is implemented as part of the general brush engine for the rest of the modes, it will be supported automatically, introducing irrelevant settings and messing up the UI o weight paint.

In this particular case, the ##use_mirror_x## setting matches the behaviour of that setting in any other painting mode, just like any other brush engine option, even if that does not make any sense for rigging.

If we agree that weight paint should not be considered a paint mode, the ideal situation for it would be to have its own brush engine, with its own settings, and implementing symmetry the way is required for rigging and nothing else. The idea of the ##use_mirror_x## property in meshes is to tell the tools that the object is intended be symmetrical on the X axis. If weight paint requires its own symmetry settings on top of this (or even ignore the ##use_mirror_x## properties completely and implement symmetry in a different way), that is ok.

I find reasonable to have ##use_mirror_vertex_group_x## as its main symmetry setting exposed in the toolbar, and then a different property (not the shared ##use_mirror_x## property) for the corner case of replicating strokes along the XYZ axis.

In my opinion, the core issue here is that "Weight paint" is considered a "paint" mode which shares a lot of code and functionality with sculpt/vertex/texture paint, and that should not be the case. The requirements and features that are needed for the brush engine in weight paint and the rest of the painting modes are completely different, Trying to share code and unify them introduces these kinds of conflicts and limits the development of new features for both modules. As an example, a feature like [D8377](https://archive.blender.org/developer/D8377) being part of the shared brush engine is completely useless for weight paint, but because it is implemented as part of the general brush engine for the rest of the modes, it will be supported automatically, introducing irrelevant settings and messing up the UI o weight paint. In this particular case, the ##use_mirror_x## setting matches the behaviour of that setting in any other painting mode, just like any other brush engine option, even if that does not make any sense for rigging. If we agree that weight paint should not be considered a paint mode, the ideal situation for it would be to have its own brush engine, with its own settings, and implementing symmetry the way is required for rigging and nothing else. The idea of the ##use_mirror_x## property in meshes is to tell the tools that the object is intended be symmetrical on the X axis. If weight paint requires its own symmetry settings on top of this (or even ignore the ##use_mirror_x## properties completely and implement symmetry in a different way), that is ok. I find reasonable to have ##use_mirror_vertex_group_x## as its main symmetry setting exposed in the toolbar, and then a different property (not the shared ##use_mirror_x## property) for the corner case of replicating strokes along the XYZ axis.

Sybren A. Stüvel commented

2021-01-18 11:42:04 +01:00

I think I agree with @pablodp606. If these modes are so different, it would help to separate them. I do feel that the "painting" nature of weight painting means that the mode would still be best developed & maintained by the Sculpt, Paint & Texture module.

Pablo, how much work do you think your proposal would be, vs. what the other guys are suggesting?

I think I agree with @pablodp606. If these modes are so different, it would help to separate them. I do feel that the "painting" nature of weight painting means that the mode would still be best developed & maintained by the Sculpt, Paint & Texture module. Pablo, how much work do you think your proposal would be, vs. what the other guys are suggesting?

Alexander Gavrilov commented

2021-01-18 12:23:36 +01:00

In #84520#1092431, @PabloDobarro wrote:
The idea of the use_mirror_x property in meshes is to tell the tools that the object is intended be symmetrical on the X axis. If weight paint requires its own symmetry settings on top of this (or even ignore the ##use_mirror_x## properties completely and implement symmetry in a different way), that is ok.

In the most common case (dealing with actually symmetrical characters) it is fine to have a shared symmetry setting. It is just that it has to be interpreted differently for weight paint. Think about it from the user's point of view, not how it seems 'convenient' or 'logical' on the implementation side: it is quite reasonable to have a common setting to tell that the object is supposed to be symmetrical in the X direction. However, unlike sculpt or color painting, weight paint basically supports multiple paint layers, commonly with separate 'left' and 'right' copies, and symmetry has to take those left and right sides into account.

I.e. weight paint symmetry isn't something totally different on the conceptual level (i.e. from the user's point of view, instead of thinking about the implementation), it is just more advanced by supporting multi-layer symmetry. It doesn't need to ignore the generic property that "tells the tools that the object is intended to be symmetrical", but the generic implementation associated with it that is too simple for layered weights.

Also note that weights can also be edited in mesh edit mode, and I think some weight operators can be called in edit mode too. This is actually a related bug: most weight operators currently use the 'common' flag, so you can't conveniently use them in weight paint. I.e. weight symmetry also has to be considered in the context of mesh edit mode.

> In #84520#1092431, @PabloDobarro wrote: > The idea of the use_mirror_x property in meshes is to tell the tools that the object is intended be symmetrical on the X axis. If weight paint requires its own symmetry settings on top of this (or even ignore the ##use_mirror_x## properties completely and implement symmetry in a different way), that is ok. In the most common case (dealing with actually symmetrical characters) it is fine to have a shared symmetry setting. It is just that it has to be interpreted differently for weight paint. Think about it from the user's point of view, not how it seems 'convenient' or 'logical' on the implementation side: it is quite reasonable to have a common setting to tell that the object is supposed to be symmetrical in the X direction. However, unlike sculpt or color painting, weight paint basically supports multiple paint layers, commonly with separate 'left' and 'right' copies, and symmetry has to take those left and right sides into account. I.e. weight paint symmetry isn't something totally different on the conceptual level (i.e. from the user's point of view, instead of thinking about the implementation), it is just more advanced by supporting multi-layer symmetry. It doesn't need to ignore the generic property that "tells the tools that the object is intended to be symmetrical", but the generic implementation associated with it that is too simple for layered weights. Also note that weights can also be edited in mesh edit mode, and I think some weight operators can be called in edit mode too. This is actually a related bug: most weight operators currently use the 'common' flag, so you can't conveniently use them in weight paint. I.e. weight symmetry also has to be considered in the context of mesh edit mode.

Demeter Dzadik commented

2021-01-18 12:44:50 +01:00

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.

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.

Pablo Dobarro commented

2021-01-18 18:19:27 +01:00

Pablo, how much work do you think your proposal would be, vs. what the other guys are suggesting?

My proposal is more a long term roadmap to start considering decisions. To get to that point, it depends on the availability of the other involved modules.

To me, the ideal situation would be reusing the current paint code (brushes, stroke operators, tool settings...) for Weight Paint and Attribute Paint/Edit, and them building a new one properly designed for sculpt/texture painting (like the one the Grease Pencil module has). The current painting feature are probably more than enough for the requirements of a weight/attribute painting tool, but it is too limited for implementing the features required for sculpting and texturing. After splitting the code, the animation and nodes/simulation modules should be able to freely adapt the old painting code to the needs of those areas.

For tackling this issue in particular, both solutions are straightforward to implement. If you decide that you want to reuse the current flag with a different meaning it is a matter of changing the flag when it is used in the code. If you want a separate flag (which I think it makes more sense in order to avoid confusion in the code about having a flag that does two different things in different places), the it needs to be added and replaced.

> Pablo, how much work do you think your proposal would be, vs. what the other guys are suggesting? My proposal is more a long term roadmap to start considering decisions. To get to that point, it depends on the availability of the other involved modules. To me, the ideal situation would be reusing the current paint code (brushes, stroke operators, tool settings...) for Weight Paint and Attribute Paint/Edit, and them building a new one properly designed for sculpt/texture painting (like the one the Grease Pencil module has). The current painting feature are probably more than enough for the requirements of a weight/attribute painting tool, but it is too limited for implementing the features required for sculpting and texturing. After splitting the code, the animation and nodes/simulation modules should be able to freely adapt the old painting code to the needs of those areas. For tackling this issue in particular, both solutions are straightforward to implement. If you decide that you want to reuse the current flag with a different meaning it is a matter of changing the flag when it is used in the code. If you want a separate flag (which I think it makes more sense in order to avoid confusion in the code about having a flag that does two different things in different places), the it needs to be added and replaced.

Alexander Gavrilov commented

2021-01-18 18:46:42 +01:00

it is a matter of changing the flag when it is used in the code.

Basically, the smallest change that would make things way way better (and the first step to 'solution 2') is to suppress the use of the 'regular' X symmetry for painting when in weight paint mode and the weight-paint specific X symmetry flag is enabled, so you cannot have two X symmetry modes enabled at the same time. Then you can leave the common flag enabled in weight paint without causing problems.

To get full 'solution 2' you then need to check both flags wherever the weight specific flag is used, which is easy to find with a text search. I can help with this second step, but I don't know what is the correct place to do the suppression part.

> it is a matter of changing the flag when it is used in the code. Basically, the smallest change that would make things way way better (and the first step to 'solution 2') is to suppress the use of the 'regular' X symmetry for painting when in weight paint mode and the weight-paint specific X symmetry flag is enabled, so you cannot have two X symmetry modes enabled at the same time. Then you can leave the common flag enabled in weight paint without causing problems. To get full 'solution 2' you then need to check both flags wherever the weight specific flag is used, which is easy to find with a text search. I can help with this second step, but I don't know what is the correct place to do the suppression part.

Yolao Heinz commented

2021-01-19 14:29:03 +01:00

Added subscriber: @Yolao

Yolao Heinz commented

2021-01-19 14:29:03 +01:00

This comment was removed by @Yolao

*This comment was removed by @Yolao*

RedMser commented

2021-01-19 17:06:55 +01:00

Added subscriber: @RedMser

Demeter Dzadik commented

2021-01-21 17:32:36 +01:00

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. @PabloDobarro would you be able to implement this in the near future, or are you too busy?

It was also brought up though that neither of these solutions address the issue that some people are facing, which is that sometimes they simply don't want symmetry options to be shared across different modes. I think that can be handled separately from this issue, and discussion regarding that already has a place in #79785.

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](https://devtalk.blender.org/t/2021-01-21-animation-rigging-upcoming/17143) to go for the first solution. @PabloDobarro would you be able to implement this in the near future, or are you too busy? It was also brought up though that neither of these solutions address the issue that some people are facing, which is that sometimes they simply don't want symmetry options to be shared across different modes. I think that can be handled separately from this issue, and discussion regarding that already has a place in #79785.

Philipp Oeser commented

2021-02-11 13:51:19 +01:00

Added subscriber: @lichtwerk

Sebastian Parborg self-assigned this 2021-02-16 01:29:02 +01:00

ronan ducluzeau commented

2021-02-18 21:31:32 +01:00

Added subscriber: @zeauro

ronan ducluzeau commented

2021-02-18 21:31:32 +01:00

I agree most of people don't want symmetry shared across modes because they don't switch between modes to use same tools or work on same attributes or parts of edited object.
Weight can be precised in Edit Mode, too. That may make sense to have simmilar symmetry options between edit mode and weight paint mode.
You can use Edit mode to select UV Islands, too. In that case, that is annoying to share same symmetry options between Texture paint mode and Edit mode.
Modes are not brushes. An asset creation speed session, polishing session or a motion design session where mesh polys, UVs, weights, vertex colors and textures are edited is a completely different thing than a modeling, sculpting or painting session where user focuses on one task.
If you switch from one mode to another, most of time ; it is do to do a completely different task.

And anyways, whatever weight painting mode status is. Both types of symmetry are useful.
A motion graphic designer painting attributes to feed geometry nodes may want a global weight group/attribute for the whole mesh.
In that case, desired symmetry is same kind as in edit/sculpt/texture paint mode. Weight group is expected to be symmetrical to comply to mesh shape.
Another example of that can be a weight group to control density of hair particles for fur. It is generally a giant weight group that is supposed to be symmetrical like animal mesh is.
A rigger works more often on multiple weight groups. If the armature of the rig is symmetrical, that means that for one bone/weight group : there is a symmetrical bone/weight group.
Here, the expectation is that modification of one weight group is transferred to its symmetrical.

So, there is no discussion about a good/frequent or bad/useless symmetry case.
The only acceptable solution is the one where UI makes it clear for the user what the options are doing/allowing.
IMO, we should expose symmetry like in other modes, rename Vertex Group X by Symmetrical Vertex Group Only or simply L/R symmetry.
Enabling the option should greyed out X, Y and Z buttons and a reminder that Vertex Group L/R symmetry is active should be exposed in Viewport.

I agree most of people don't want symmetry shared across modes because they don't switch between modes to use same tools or work on same attributes or parts of edited object. Weight can be precised in Edit Mode, too. That may make sense to have simmilar symmetry options between edit mode and weight paint mode. You can use Edit mode to select UV Islands, too. In that case, that is annoying to share same symmetry options between Texture paint mode and Edit mode. Modes are not brushes. An asset creation speed session, polishing session or a motion design session where mesh polys, UVs, weights, vertex colors and textures are edited is a completely different thing than a modeling, sculpting or painting session where user focuses on one task. If you switch from one mode to another, most of time ; it is do to do a completely different task. And anyways, whatever weight painting mode status is. Both types of symmetry are useful. A motion graphic designer painting attributes to feed geometry nodes may want a global weight group/attribute for the whole mesh. In that case, desired symmetry is same kind as in edit/sculpt/texture paint mode. Weight group is expected to be symmetrical to comply to mesh shape. Another example of that can be a weight group to control density of hair particles for fur. It is generally a giant weight group that is supposed to be symmetrical like animal mesh is. A rigger works more often on multiple weight groups. If the armature of the rig is symmetrical, that means that for one bone/weight group : there is a symmetrical bone/weight group. Here, the expectation is that modification of one weight group is transferred to its symmetrical. So, there is no discussion about a good/frequent or bad/useless symmetry case. The only acceptable solution is the one where UI makes it clear for the user what the options are doing/allowing. IMO, we should expose symmetry like in other modes, rename Vertex Group X by Symmetrical Vertex Group Only or simply L/R symmetry. Enabling the option should greyed out X, Y and Z buttons and a reminder that Vertex Group L/R symmetry is active should be exposed in Viewport.

Demeter Dzadik commented

2021-02-19 12:48:09 +01:00

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 will update the task description to avoid further confusion and to keep everybody in the loop. I also encourage everyone to test the related patch (D10426). The behavior is already nailed down(based on yesterday's animation module meeting), there are just some UI things to iron out.

> 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 will update the task description to avoid further confusion and to keep everybody in the loop. I also encourage everyone to test the related patch ([D10426](https://archive.blender.org/developer/D10426)). The behavior is already nailed down(based on yesterday's animation module meeting), there are just some UI things to iron out.

Demeter Dzadik changed title from ~~Confusing Symmetry settings in Weight Painting~~ to "Double Symmetry" in Weight Painting

2021-02-19 13:12:38 +01:00

ronan ducluzeau commented

2021-02-23 09:41:29 +01:00

Why being able to use both symmetries, at same time, would not be pertinent ?

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.

D10426 is destroying that ability to solve a problem of confusion induced by a sharing across modes that no user asked for.

While I agree this would be good to support, I think it's a separate issue.

Absolutely not. that is what is motivating your D10426 patch.

People are confused by persistence of Vertex Group_X option, they forgot they have enabled before switching between modes.
The solution can not be to make symmetry less powerful.
It is to remind that Vertex_Group_X is still enabled by making this more obvious.
You could add a text reminder warning in Viewport.

You could make Symmetry more powerful by making it available for vertex groups of bones autonamed Fr/Bk or Top/Bot.
Or you could allow to use radial symmetry for X axis when Vertex Group X option is on.
Instead of that, you are choosing to make it more stupid. Supposedly because some users are not careful.
Reality is that they are confused because they were not used to sharing of symmetry options between modes or are discovering the .R/.L symmetry ability.
Instead of letting a chance to people to figure out what is happening and integrate what could be useful to them, you are litteraly presuming that they will stay confused. So, tool should become stupid to be easily understandable.
That does not make sense.

X,Y,Z symmetry or radial symmetry should be available when Vertex Group X option is enabled.
That is simply making painting work faster when it is pertinent to use it.
And if there is a problem of discoverability, that is a problem of presentation.
That is not a problem of allowing too much freedom.

Why being able to use both symmetries, at same time, would not be pertinent ? 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. [D10426](https://archive.blender.org/developer/D10426) is destroying that ability to solve a problem of confusion induced by a sharing across modes that no user asked for. >While I agree this would be good to support, I think it's a separate issue. Absolutely not. that is what is motivating your [D10426](https://archive.blender.org/developer/D10426) patch. People are confused by persistence of Vertex Group_X option, they forgot they have enabled before switching between modes. The solution can not be to make symmetry less powerful. It is to remind that Vertex_Group_X is still enabled by making this more obvious. You could add a text reminder warning in Viewport. You could make Symmetry more powerful by making it available for vertex groups of bones autonamed Fr/Bk or Top/Bot. Or you could allow to use radial symmetry for X axis when Vertex Group X option is on. Instead of that, you are choosing to make it more stupid. Supposedly because some users are not careful. Reality is that they are confused because they were not used to sharing of symmetry options between modes or are discovering the .R/.L symmetry ability. Instead of letting a chance to people to figure out what is happening and integrate what could be useful to them, you are litteraly presuming that they will stay confused. So, tool should become stupid to be easily understandable. That does not make sense. X,Y,Z symmetry or radial symmetry should be available when Vertex Group X option is enabled. That is simply making painting work faster when it is pertinent to use it. And if there is a problem of discoverability, that is a problem of presentation. That is not a problem of allowing too much freedom.

Demeter Dzadik commented

2021-02-23 13:08:01 +01:00

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.

I see what you mean now.
Current master does actually support the following case:

symmetry_funky_use_case.blend

So, we need to think of how to preserve this while still fixing the issue of having to change symmetry settings every time we change modes.

Hopefully you'll agree that having both X symmetry and Vertex Group X enabled at the same time still has no use case. So, perhaps the solution is, from a UI perspective, that when Vertex Group X is enabled, only gray out Mirror X, rather than everything except Mirror X.

This would mean the two symmetry code paths are actually not mutually exclusive, but at least the two X axis symmetry options are.

@ZedDB For when you have time to work on this again, what do you think about this? Can this work from the code side?

> 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. I see what you mean now. Current master does actually support the following case: ![image.png](https://archive.blender.org/developer/F9830619/image.png) [symmetry_funky_use_case.blend](https://archive.blender.org/developer/F9830643/symmetry_funky_use_case.blend) So, we need to think of how to preserve this while still fixing the issue of having to change symmetry settings every time we change modes. Hopefully you'll agree that having both X symmetry and Vertex Group X enabled at the same time still has no use case. So, perhaps the solution is, from a UI perspective, that when Vertex Group X is enabled, only gray out Mirror X, rather than everything except Mirror X. This would mean the two symmetry code paths are actually not mutually exclusive, but at least the two X axis symmetry options are. @ZedDB For when you have time to work on this again, what do you think about this? Can this work from the code side?

ronan ducluzeau commented

2021-02-23 13:38:57 +01:00

Hopefully you'll agree that having both X symmetry and Vertex Group X enabled at the same time still has no use case.

Yes. I would say almost none.
Objectively, nobody wants to produce similar weight groups to skin symmetrical bones.

But being able to enable X symmetry does not mean that you are enabling it during entire painting of weight group.
There is always ability to produce symmetrical weight groups that has a symmetrical part and an identical part.

Maybe, there is a use case for vertex groups used for restriction.
For example, vertex groups used to restrict a shapekey.
User creates a shapekey moving both sides of mesh, duplicates it and use 2 vertex groups to obtain a shapekey for left side and another one for right side.
There could be a case where whatever side is concerned, you should always obtain a symmetrical deformation for a part of mesh.

But that will probably be anectodal compared to bones rigging. For those rare cases, there is always ability to copy and mirror vertex group.

>Hopefully you'll agree that having both X symmetry and Vertex Group X enabled at the same time still has no use case. Yes. I would say almost none. Objectively, nobody wants to produce similar weight groups to skin symmetrical bones. But being able to enable X symmetry does not mean that you are enabling it during entire painting of weight group. There is always ability to produce symmetrical weight groups that has a symmetrical part and an identical part. Maybe, there is a use case for vertex groups used for restriction. For example, vertex groups used to restrict a shapekey. User creates a shapekey moving both sides of mesh, duplicates it and use 2 vertex groups to obtain a shapekey for left side and another one for right side. There could be a case where whatever side is concerned, you should always obtain a symmetrical deformation for a part of mesh. But that will probably be anectodal compared to bones rigging. For those rare cases, there is always ability to copy and mirror vertex group.

Sebastian Parborg commented

2021-02-24 21:22:18 +01:00

@zeauro I actually fail to see any common use case where you would want to have vertex group mirroring on and the symmetry options on at the same time.
To me, without having the ability to dynamically change the mirror plane origin while painting, the symmetry options will not really help when weight painting character rigs.
From talking with riggers in the animation module, they seems to agree.

Now of course we should not only design weight painting to only cater to character riggers. However, a lot of your examples doesn't seem to have any concrete use case
just "someone could find it useful, maybe". Which is bad as we can't design software around "maybe useful" functionality.

So I want concrete and simple examples of when having both symmetry and vertex group mirror on at the same time would be useful.
I don't want a wall of text, I want pictures and or short video clips of use cases where you would have both active at the same time and the result of having them on at the same time improves the workflow.

If we manage to get this, then we have concrete use cases that we can base our design on moving forward.

@zeauro I actually fail to see any common use case where you would want to have vertex group mirroring on and the symmetry options on at the same time. To me, without having the ability to dynamically change the mirror plane origin while painting, the symmetry options will not really help when weight painting character rigs. From talking with riggers in the animation module, they seems to agree. Now of course we should not only design weight painting to only cater to character riggers. However, a lot of your examples doesn't seem to have any concrete use case just "someone could find it useful, maybe". Which is bad as we can't design software around "maybe useful" functionality. So I want concrete and simple examples of when having both symmetry and vertex group mirror on at the same time would be useful. I don't want a wall of text, I want pictures and or short video clips of use cases where you would have both active at the same time and the result of having them on at the same time improves the workflow. If we manage to get this, then we have concrete use cases that we can base our design on moving forward.

Demeter Dzadik commented

2021-02-26 16:03:47 +01:00

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 without a legitimate use case example, we should go ahead with the original plan of making the two symmetry types mutually exclusive, because the upsides will outweigh the downsides for the average user. But I concede that this is now more controversial than originally anticipated, so I would bring up these concerns on the next animation module meeting, which is next Thursday. If there's no use case example by that point, I think most people will agree to going ahead with the "fix". Even if that happens, once Attribute Edit starts becoming a thing, we can re-introduce this functionality with a proper UI and code design, rather than as a bug.

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 without a legitimate use case example, we should go ahead with the original plan of making the two symmetry types mutually exclusive, because the upsides will outweigh the downsides for the average user. But I concede that this is now more controversial than originally anticipated, so I would bring up these concerns on the next animation module meeting, which is next Thursday. If there's no use case example by that point, I think most people will agree to going ahead with the "fix". Even if that happens, once Attribute Edit starts becoming a thing, we can re-introduce this functionality with a proper UI and code design, rather than as a bug.

Roman commented

2021-03-04 10:07:49 +01:00

Added subscriber: @rwman

Demeter Dzadik commented

2021-03-04 18:57:33 +01:00

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.

Just to note here what was discussed in the [Animation Module](https://blender.chat/channel/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.

ronan ducluzeau commented

2021-03-05 12:50:47 +01:00

just "someone could find it useful, maybe". Which is bad as we can't design software around "maybe useful" functionality.

OK. I agree. I overreacted with a bad argument. I was upset by confusion between symmetries introduced by this patch.
The only concrete usecase I am used to, is to use symmetry to fill an area with but there are other ways to be quick.
As I said in my second comment ; there is still ability to copy and mirror vertex group.
But you find a good argument to be careful.

To me, without having the ability to dynamically change the mirror plane origin while painting, the symmetry options will not really help when weight painting character rigs.

Sincerely, a custom plane/origin of symmetry is something that would be appreciated in all painting modes.
I thought about it when I wanted to sculpt symmetrical patterns on an arm.
And I hope since several years, now ; that will happen one day.

Could the patch potentially block a future adoption of such thing ?

>just "someone could find it useful, maybe". Which is bad as we can't design software around "maybe useful" functionality. OK. I agree. I overreacted with a bad argument. I was upset by confusion between symmetries introduced by this patch. The only concrete usecase I am used to, is to use symmetry to fill an area with but there are other ways to be quick. As I said in my second comment ; there is still ability to copy and mirror vertex group. But you find a good argument to be careful. >To me, without having the ability to dynamically change the mirror plane origin while painting, the symmetry options will not really help when weight painting character rigs. Sincerely, a custom plane/origin of symmetry is something that would be appreciated in all painting modes. I thought about it when I wanted to sculpt symmetrical patterns on an arm. And I hope since several years, now ; that will happen one day. Could the patch potentially block a future adoption of such thing ?

blender-admin commented

2021-04-02 14:44:26 +02:00

This issue was referenced by fa9b05149c

This issue was referenced by fa9b05149c2ca3915a4fb2670c87a648d927336c

Sebastian Parborg commented

2021-04-02 14:46:21 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Sebastian Parborg closed this issue

2021-04-02 14:46:21 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

"Double Symmetry" in Weight Painting #84520

Situation

Problems