blender
/
blender
134
398
Fork 579
Code Issues 6.3k Pull Requests 754 Projects 19 Wiki Activity

Proposal: Unify Active/Selected Bone Colors and set current Blender Theme Colors as Default #112943

New Issue
Open
opened 2023-09-27 09:58:04 +02:00 by Ivan Cappiello · 33 comments
Ivan Cappiello commented 2023-09-27 09:58:04 +02:00
Member
Copy Link

OVERVIEW:

Rigging often requires to add custom colors to bones to make them more discoverable for the animators. Currently blender supports custom bone colors. Unfortunately either applying a theme or creating your custom color by default, along with the bone color itself, changes also active/selected color state. This makes very hard to understand consistently what is selected and what is not since blender ui theme gets completely overwritten by this change and by default users doesn't have the option to change only the unselect bone color.

CURRENT STATE:

in this example screenshot each of the four bones is using a different theme from blender defaults. All bones are selected and only one is active (the orange one). This is very difficult to understand visually and is also inconsistent with the selected/active state of the ui.

Current Blender Viewport

Test Blend File

RIGIFY APPROACH:

The current issue has been approached in rigify by introducing an unify active/selected color operator that will dynamically fetch the current blender theme settings and apply it to the selected theme so that only the bone color is customized and active/selected are left as blender ui theme is set.

Rigify Unifiy Panel Unified Colors

This will result in viewport as follows:

Blender Custom Colors Rigify Unified Colors

PROPOSED SOLUTION 1: CHANGE THE SETTING AT BONE LEVEL

With this approach a unified color checkbox will be added on each bone and set to ON by default and the default blende ui theme is used for color unification.

unified setting per bone
unified per bone on/off

Each bone can have a theme applied without changing the active/selected unified color. Or change it per bone by setting unify OFF.

Unified Theme Selection

If a custom theme is applied the bone will display the 3 color inputs for bone, active and selected states.

custom theme

This proposal try to apply minimal changes to blender ui by setting new default with unified selected/active colors fetching them from blender theme, while giving the users the option to explicitly set their customs.

This should also work well in conjunction with #112635

PROPOSED SOLUTION 2: CHANGE THE GENERAL SETTINGS IN THE MAIN PREFERENCES

Another possible approach could be changing the unified active/selected colors through the main blender theme preference under the bone color section.

In the following example a unified colors toggle is added in the bone color preferences and would be set to ON by default

Unified Bone Colors Preferences

While still having the unified colors, users can easily select an unified bone color theme from blender presets

Unified Bone Colors Preferences Theme Selection

By choosing a custom theme, users can define their custom color schemes. In this case the unified colors toggle will switch automatically to OFF and the color boxes for active and selected are shown

Unified Bone Colors Preferences Theme Custom
### OVERVIEW: Rigging often requires to add custom colors to bones to make them more discoverable for the animators. Currently blender supports custom bone colors. Unfortunately either applying a theme or creating your custom color by default, along with the bone color itself, changes also active/selected color state. This makes very hard to understand consistently what is selected and what is not since blender ui theme gets completely overwritten by this change and by default users doesn't have the option to change only the unselect bone color. ### CURRENT STATE: in this example screenshot each of the four bones is using a different theme from blender defaults. All bones are selected and only one is active (the orange one). This is very difficult to understand visually and is also inconsistent with the selected/active state of the ui. Current Blender Viewport <img src="attachments/f9cbd43b-6e26-47d2-a260-9a1582b52105" width="50%" /> [Test Blend File](https://projects.blender.org/attachments/d81614d3-2006-42d4-830b-159b039fb93f) ### RIGIFY APPROACH: The current issue has been approached in rigify by introducing an unify active/selected color operator that will dynamically fetch the current blender theme settings and apply it to the selected theme so that only the bone color is customized and active/selected are left as blender ui theme is set. <table border="0"> <tr> <td>Rigify Unifiy Panel</td> <td>Unified Colors</td> </tr> <tr> <td><img src="attachments/f04940b3-1c70-4a4a-b3b7-cc1d0c33b396" width="100%"></td> <td><img src="attachments/188f91d5-6b40-433d-9517-82d1e2bd406c" width="100%"></td> </tr> </table> This will result in viewport as follows: <table border="0"> <tr> <td>Blender Custom Colors</td> <td>Rigify Unified Colors</td> </tr> <tr> <td><img src="attachments/f9cbd43b-6e26-47d2-a260-9a1582b52105" width="100%"></td> <td><img src="attachments/dc04d2e4-ad55-4c8f-acdd-af8bb1b5b9d6" width="100%"></td> </tr> </table> ### PROPOSED SOLUTION 1: CHANGE THE SETTING AT BONE LEVEL With this approach a unified color checkbox will be added on each bone and set to ON by default and the default blende ui theme is used for color unification. <figure> <img src="attachments/8f9c6311-000a-410d-a568-873767a337f3" width="85%" /> <figcaption>unified setting per bone</figcaption> </figure> <figure> <img src="attachments/b2980a81-8918-4eee-afeb-dc0ca7438104" width="85%" /> <figcaption>unified per bone on/off</figcaption> </figure> Each bone can have a theme applied without changing the active/selected unified color. Or change it per bone by setting unify OFF. <figure> <img src="attachments/c1cf7d66-8994-4927-b150-76bf1eecea70" width="85%" /> <figcaption>Unified Theme Selection</figcaption> </figure> If a custom theme is applied the bone will display the 3 color inputs for bone, active and selected states. <figure> <img src="attachments/a4d7763e-80ae-4543-b53c-cf99df60eb62" width="85%" /> <figcaption>custom theme</figcaption> </figure> This proposal try to apply minimal changes to blender ui by setting new default with unified selected/active colors fetching them from blender theme, while giving the users the option to explicitly set their customs. This should also work well in conjunction with https://projects.blender.org/blender/blender/issues/112635 ### PROPOSED SOLUTION 2: CHANGE THE GENERAL SETTINGS IN THE MAIN PREFERENCES Another possible approach could be changing the unified active/selected colors through the main blender theme preference under the bone color section. In the following example a unified colors toggle is added in the bone color preferences and would be set to ON by default <figure> <img src="attachments/ca7a3b08-da62-4d14-a7d9-78b70a40c9c4" width="85%" /> <figcaption>Unified Bone Colors Preferences</figcaption> </figure> While still having the unified colors, users can easily select an unified bone color theme from blender presets <figure> <img src="attachments/fdf2dee8-b20b-479e-9da4-7cb50d31c1c8" width="85%" /> <figcaption>Unified Bone Colors Preferences Theme Selection</figcaption> </figure> By choosing a custom theme, users can define their custom color schemes. In this case the unified colors toggle will switch automatically to OFF and the color boxes for active and selected are shown <figure> <img src="attachments/9f58d510-b4e7-4d2b-8694-2677b5e12b58" width="85%" /> <figcaption>Unified Bone Colors Preferences Theme Custom</figcaption> </figure>
unified_boneColors_ON-OFF.jpg
83 KiB
unified_boneColors_before-after.jpg
74 KiB
Rigify_unify_operatore_before.png
84 KiB
Rigify_unify_operatore_after.png
82 KiB
Rigify_active-selected_viewport.png
373 KiB
unified_boneColors_ThemeSelection.jpg
113 KiB
BoneColorsIssue.blend
902 KiB
unified_bone_preferences.png
101 KiB
unified_boneColors_CustomTheme.jpg
92 KiB
unified_bone_preferences_themeSelect.png
122 KiB
Belnder current.png
891 KiB
unified_bone_preferences_themeCustom.png
102 KiB
Ivan Cappiello added the
Priority
Normal
Type
Report
Status
Needs Triage
 labels 2023-09-27 09:58:05 +02:00
Nathan Vegdahl added
Type
Design
 and removed
Type
Report
 labels 2023-09-27 10:32:21 +02:00
Nathan Vegdahl added this to the Animation & Rigging project 2023-09-27 10:34:44 +02:00
Nathan Vegdahl added
Module
Animation & Rigging
 and removed
Status
Needs Triage
Priority
Normal
 labels 2023-09-27 10:35:55 +02:00
Alexander Gavrilov commented 2023-09-27 11:10:47 +02:00
Member
Copy Link

I had a random crazy idea: would an arbitrary blend between the default selected/active and the per-bone make any sense? Like, basically, a literal slider that would do mix(bone, default, factor) to decide how distinct do you want the colors to be, or something.

Also, in my view this definitely should not be a per-bone option, either as a check box or a slider. It should be either in the armature, or user preferences: the former if we want the rigger to decide, while the latter leaves it completely to the rig user. The reason is that since the whole point of this is to make selected/active uniform, being able to set it per bone would be counterproductive.

I had a random crazy idea: would an arbitrary blend between the default selected/active and the per-bone make any sense? Like, basically, a literal slider that would do `mix(bone, default, factor)` to decide how distinct do you want the colors to be, or something. Also, in my view this definitely should not be a per-bone option, either as a check box or a slider. It should be either in the armature, or user preferences: the former if we want the rigger to decide, while the latter leaves it completely to the rig user. The reason is that since the whole point of this is to make selected/active uniform, being able to set it per bone would be counterproductive.
Ivan Cappiello commented 2023-09-27 11:36:34 +02:00
Author
Member
Copy Link

I had a random crazy idea: would an arbitrary blend between the default selected/active and the per-bone make any sense? Like, basically, a literal slider that would do mix(bone, default, factor) to decide how distinct do you want the colors to be, or something.

Looks pretty confusing to me. I'd avoid that since it only makes the color more unpredictable. UI should be as consistent and predictable as possible.

Also, in my view this definitely should not be a per-bone option, either as a check box or a slider. It should be either in the armature, or user preferences: the former if we want the rigger to decide, while the latter leaves it completely to the rig user. The reason is that since the whole point of this is to make selected/active uniform, being able to set it per bone would be counterproductive.

My proposal is to have the option per-bone and unified on (with blender current theme) by default. This default could be disabled through preferences. Having the option on the armature itself would make very difficult to customize a single bone when you need.

A general operator working on the armature could be beneficial too, but if we set it as I wrote above I believe most of the use cases are still covered. Rigify unify color is always available and can be ported to blender itself.

An open question from a coding perspective is if the "current theme" setting can dynamically read and match the Blender UI theme preferences. The main reason we have the update/unify operator in rigify is that the colors are written on the bones and would not change if that file is open in another blender instance with a different UI theme applied.

> I had a random crazy idea: would an arbitrary blend between the default selected/active and the per-bone make any sense? Like, basically, a literal slider that would do mix(bone, default, factor) to decide how distinct do you want the colors to be, or something. Looks pretty confusing to me. I'd avoid that since it only makes the color more unpredictable. UI should be as consistent and predictable as possible. >Also, in my view this definitely should not be a per-bone option, either as a check box or a slider. It should be either in the armature, or user preferences: the former if we want the rigger to decide, while the latter leaves it completely to the rig user. The reason is that since the whole point of this is to make selected/active uniform, being able to set it per bone would be counterproductive. My proposal is to have the option per-bone and unified on (with blender current theme) by default. This default could be disabled through preferences. Having the option on the armature itself would make very difficult to customize a single bone when you need. A general operator working on the armature could be beneficial too, but if we set it as I wrote above I believe most of the use cases are still covered. Rigify unify color is always available and can be ported to blender itself. An open question from a coding perspective is if the "current theme" setting can dynamically read and match the Blender UI theme preferences. The main reason we have the update/unify operator in rigify is that the colors are written on the bones and would not change if that file is open in another blender instance with a different UI theme applied.
Ludvik Koutny commented 2023-09-27 12:01:05 +02:00
Contributor
Copy Link

So we have overcomplicated, overreaching theme customization and solution to the problem of too many buttons is to add even more buttons? O_o

Blender should simply have a index based color generator which generates at least 32 visually distinct colors based on index. It should be used in many places across Blender including bones. So if we have up to 20 distinct bone colors, the generator would simply provide 20 visually unique colors, always same regardless of the theme. The selected and active states would them simply be brightness multiplied versions of those colors.

This would solve two problems:

  1. Theme editor would not dump 60 individual color swatches onto user to customize
  2. Bone colors would always be same, regardless of the theme

Blender is accumulating UX debt at insane pace past couple of years. Solving the problem of too many buttons by introducing more buttons just accelerates that further.

So we have overcomplicated, overreaching theme customization and solution to the problem of too many buttons is to add even more buttons? O_o Blender should simply have a index based color generator which generates at least 32 visually distinct colors based on index. It should be used in many places across Blender including bones. So if we have up to 20 distinct bone colors, the generator would simply provide 20 visually unique colors, always same regardless of the theme. The selected and active states would them simply be brightness multiplied versions of those colors. This would solve two problems: 1. Theme editor would not dump 60 individual color swatches onto user to customize 2. Bone colors would always be same, regardless of the theme Blender is accumulating UX debt at insane pace past couple of years. Solving the problem of too many buttons by introducing more buttons just accelerates that further.
Demeter Dzadik commented 2023-09-28 19:23:56 +02:00
Member
Copy Link

Bone color settings can exist on 3 levels:

  • Per bone
  • Per armature
  • Per user

I think you're putting everything per bone here, which results in excessive customizability, and a system that relies a lot on bulk editing operations. I don't think anybody wants to toggle unified active/selected colors on a per-bone basis. That kinda misses out on the "unified" idea.

I think the Unified Active/Selected Colors option should live at the per user level, same as the preset colors. Bones can choose to use preset colors (which makes their color live at the per user level), or use Custom Colors, which makes it live at the per bone level.

I wouldn't stress so much about allowing animators to see a rig the way that the rigger intended. If they want to do that, just leave your theme colors alone. If the rigger really wants to not allow that customizability, they can use custom colors. But it's not the rigger's responsibility to police the animators' theme settings. If a user breaks their Blender theme, that's their choice and their problem.

Bone color settings can exist on 3 levels: - Per bone - Per armature - Per user I think you're putting everything per bone here, which results in excessive customizability, and a system that relies a lot on bulk editing operations. I don't think anybody wants to toggle unified active/selected colors on a per-bone basis. That kinda misses out on the "unified" idea. I think the `Unified Active/Selected Colors` option should live at the `per user` level, same as the preset colors. Bones can choose to use preset colors (which makes their color live at the `per user` level), or use Custom Colors, which makes it live at the `per bone` level. I wouldn't stress so much about allowing animators to see a rig the way that the rigger intended. If they want to do that, just leave your theme colors alone. If the rigger really wants to not allow that customizability, they can use custom colors. But it's not the rigger's responsibility to police the animators' theme settings. If a user breaks their Blender theme, that's their choice and their problem.
👍 1
Ivan Cappiello commented 2023-09-29 08:55:47 +02:00
Author
Member
Copy Link

I think you are right.

My first approach was probably too much oriented to minor changes rather than rethink the mai n workflow. Also, after the meeting, I think the description doesn't help that much reviewers not directly affected by this issue to clearly understand it and envision how it may work in the future. I'll try to update the description along with the mockups to give everyone a bit more context.

I think you are right. My first approach was probably too much oriented to minor changes rather than rethink the mai n workflow. Also, after the meeting, I think the description doesn't help that much reviewers not directly affected by this issue to clearly understand it and envision how it may work in the future. I'll try to update the description along with the mockups to give everyone a bit more context.
Ivan Cappiello commented 2023-10-01 10:21:52 +02:00
Author
Member
Copy Link

@Mets i have updated the description including a visual explaination of the general issue, and both the possible solutions with some ui mockups.

@Mets i have updated the description including a visual explaination of the general issue, and both the possible solutions with some ui mockups.
Sybren A. Stüvel commented 2023-10-02 11:26:34 +02:00
Member
Copy Link

I wouldn't stress so much about allowing animators to see a rig the way that the rigger intended. If they want to do that, just leave your theme colors alone. If the rigger really wants to not allow that customizability, they can use custom colors. But it's not the rigger's responsibility to police the animators' theme settings. If a user breaks their Blender theme, that's their choice and their problem.

+1 for this.

I think that per-bone options would indeed be overkill; the idea seems to stem from the current limitations & how Rigify works around them, rather than a common workflow that could not be supported any other way (even with arbitrary changes to Blender, I mean).

Why not limit it to just an interface/animation preference? That could either be a boolean (toggle between specific colors or always using the default colors) or, as Alexander suggested, a slider to blend between the two.

What I'm still wondering about is what this option would do to the user interface. Would it also simplify the custom color interface, reducing the three color properties to one? But if it did, how would you set those colors for people who'd want this option to be turned off? And if you didn't, how would you show what people are actually editing at that time? Or would you disable the selected/active colors in the UI to show they're not used at the time? But if you do, how would you differentiate between "disabled" and "enabled but darker color was selected"?

> I wouldn't stress so much about allowing animators to see a rig the way that the rigger intended. If they want to do that, just leave your theme colors alone. If the rigger really wants to not allow that customizability, they can use custom colors. But it's not the rigger's responsibility to police the animators' theme settings. If a user breaks their Blender theme, that's their choice and their problem. +1 for this. I think that per-bone options would indeed be overkill; the idea seems to stem from the current limitations & how Rigify works around them, rather than a common workflow that could not be supported any other way (even with arbitrary changes to Blender, I mean). Why not limit it to just an interface/animation preference? That could either be a boolean (toggle between specific colors or always using the default colors) or, as Alexander suggested, a slider to blend between the two. What I'm still wondering about is what this option would do to the user interface. Would it also simplify the custom color interface, reducing the three color properties to one? But if it did, how would you set those colors for people who'd want this option to be turned off? And if you didn't, how would you show what people are actually editing at that time? Or would you disable the selected/active colors in the UI to show they're not used at the time? But if you do, how would you differentiate between "disabled" and "enabled but darker color was selected"?
Nathan Vegdahl commented 2023-10-02 11:49:22 +02:00
Member
Copy Link

I really like this overview of the problem. It makes it really clear why customized selected/active colors can be so visually confusing. Thanks @icappiello!

Of the solutions, I definitely prefer putting the option in main preferences. Like @Mets, I don't really see the purpose of this being per bone. It seems far more useful as a general user preference, to let the user decide how they like their bone selections to be visualized globally.

However, the current proposal for the main-preferences approach still feels more complicated than necessary to me. Specifically, it's not clear to me what the benefit of Unified Color Theme is. If the user wants to customize the selected/active colors, can't they just do it in the theme's 3D viewport colors as usual?

I really like this overview of the problem. It makes it really clear why customized selected/active colors can be so visually confusing. Thanks @icappiello! Of the solutions, I definitely prefer putting the option in main preferences. Like @Mets, I don't really see the purpose of this being per bone. It seems far more useful as a general user preference, to let the user decide how they like their bone selections to be visualized globally. However, the current proposal for the main-preferences approach still feels more complicated than necessary to me. Specifically, it's not clear to me what the benefit of `Unified Color Theme` is. If the user wants to customize the selected/active colors, can't they just do it in the theme's 3D viewport colors as usual?
Sybren A. Stüvel commented 2023-10-02 11:53:35 +02:00
Member
Copy Link

If the user wants to customize the selected/active colors, can't they just do it in the theme's 3D viewport colors as usual?

They can; it's already possible to simply change the theme and unify the 'selected' and 'active' colors. Where the option would come in, is in the case of custom colors. Those cannot be adjusted for the theme, and thus they'd need some 'global override' in order to still use the default theme colors when drawing the active/selected wireframes.

> If the user wants to customize the selected/active colors, can't they just do it in the theme's 3D viewport colors as usual? They can; it's already possible to simply change the theme and unify the 'selected' and 'active' colors. Where the option would come in, is in the case of custom colors. Those cannot be adjusted for the theme, and thus they'd need some 'global override' in order to still use the default theme colors when drawing the active/selected wireframes.
Nathan Vegdahl commented 2023-10-02 12:08:44 +02:00
Member
Copy Link

Where the option would come in, is in the case of custom colors.

I guess that's what I'm saying: I don't understand the purpose of having different selected/active colors for custom-colored vs non-custom-colored bones when this feature is on. I thought the purpose of this feature was to keep the selected/active colors consistent across all bones to avoid visual confusion. In which case, just having all bones use the current theme colors for selected/active seems both simplest and best to me.

But maybe I'm missing something.

> Where the option would come in, is in the case of custom colors. I guess that's what I'm saying: I don't understand the purpose of having different selected/active colors for custom-colored vs non-custom-colored bones when this feature is on. I thought the purpose of this feature was to keep the selected/active colors consistent across all bones to avoid visual confusion. In which case, just having all bones use the current theme colors for selected/active seems both simplest and best to me. But maybe I'm missing something.
Sybren A. Stüvel commented 2023-10-02 12:10:45 +02:00
Member
Copy Link

Oh that's not what I mean with "would come in". I meant: the existence of custom colors make this option useful. To flip it around: without custom bone colors we wouldn't even need this option.

Oh that's not what I mean with "would come in". I meant: the existence of custom colors make this option useful. To flip it around: without custom bone colors we wouldn't even need this option.
👍 1
Nathan Vegdahl commented 2023-10-02 12:38:55 +02:00
Member
Copy Link

Got it. That was just a misunderstanding, then: I was talking about the Unified Color Theme sub-option in @icappiello's mockup, not the main Unified Active/Selected option. I absolutely agree we want the latter.

Got it. That was just a misunderstanding, then: I was talking about the `Unified Color Theme` sub-option in @icappiello's mockup, not the main `Unified Active/Selected` option. I absolutely agree we want the latter.
Sybren A. Stüvel commented 2023-10-02 12:40:26 +02:00
Member
Copy Link

I was talking about the Unified Color Theme sub-option in @icappiello's mockup

Ah right, I forgot about that; I think that's indeed over-complicating things. Enabling the 'unified active/selected color' checkbox should just make all selected/active equal to the default bone selected/active color. IMO it shouldn't introduce yet another set of colors.

> I was talking about the `Unified Color Theme` sub-option in @icappiello's mockup Ah right, I forgot about that; I think that's indeed over-complicating things. Enabling the 'unified active/selected color' checkbox should just make all selected/active equal to the default bone selected/active color. IMO it shouldn't introduce yet another set of colors.
👍 2
Ivan Cappiello commented 2023-10-02 22:34:47 +02:00
Author
Member
Copy Link

@dr.sybren even if i really like your approach of keeping it simple, i also think this could be too restrictive for some users. If your intent is just either have an unified active/selected color or let the user go rogue, a single toggle can be ok.

I’ll be ok with it since imho active and selected color states should be defined by theme in the ui and that’s it!

What i was trying to envise is give the users some room for what the custom color were meant for. Let’s say that “blender theme” option is just a placeholder for whatever you want. Maybe it’s your user presets. You may want to have those without having to compile that each time.

the idea was that custom themes (once stored) could be selected along with the others in the bone group colors of the armature.

obviously if you want to lock the user out of this option, we don’t need any complication or mockup!

In other words, if i get it right you are suggesting that the colors should be kept as unified, unless the user disables the unify toggle. In that case he can just select the custom colors and that’s it?

@dr.sybren even if i really like your approach of keeping it simple, i also think this could be too restrictive for some users. If your intent is just either have an unified active/selected color or let the user go rogue, a single toggle can be ok. I’ll be ok with it since imho active and selected color states should be defined by theme in the ui and that’s it! What i was trying to envise is give the users some room for what the custom color were meant for. Let’s say that “blender theme” option is just a placeholder for whatever you want. Maybe it’s your user presets. You may want to have those without having to compile that each time. the idea was that custom themes (once stored) could be selected along with the others in the bone group colors of the armature. obviously if you want to lock the user out of this option, we don’t need any complication or mockup! In other words, if i get it right you are suggesting that the colors should be kept as unified, unless the user disables the unify toggle. In that case he can just select the custom colors and that’s it?
Sybren A. Stüvel commented 2023-10-03 10:15:09 +02:00
Member
Copy Link

@dr.sybren even if i really like your approach of keeping it simple, i also think this could be too restrictive for some users. If your intent is just either have an unified active/selected color or let the user go rogue, a single toggle can be ok.

I’ll be ok with it since imho active and selected color states should be defined by theme in the ui and that’s it!

👍

What i was trying to envise is give the users some room for what the custom color were meant for. Let’s say that “blender theme” option is just a placeholder for whatever you want. Maybe it’s your user presets. You may want to have those without having to compile that each time.

I don't know what you mean here. Themes are user presets. You can create entirely new themes too, as a user, if you want. No recompiling required. Currently users are already free to adjust the bone colors in their theme to their liking.

the idea was that custom themes (once stored) could be selected along with the others in the bone group colors of the armature.

obviously if you want to lock the user out of this option, we don’t need any complication or mockup!

"Lock the user out" is a bit dramatic. There are already 20 theme colors that anyone is free to adjust at any time. If these are not enough, that's a different topic than the feature we're discussing here.

In other words, if i get it right you are suggesting that the colors should be kept as unified, unless the user disables the unify toggle. In that case he can just select the custom colors and that’s it?

To disambiguate "the custom colors", how I expected this feature to work is:

  • "unify" disabled (default): bone colors work as they do now.
  • "unify" enabled: the bone "regular" color works as it does now. When drawing bones, "selected" and "active" colors are taken from the default bone colors in the current theme.

Note that the above doesn't distinguish "theme colors" from "custom colors", as IMO the behaviour should be the same for both.

To fully understand the proposal, I do feel that the questions I asked yesterday are still interesting to answer.

> @dr.sybren even if i really like your approach of keeping it simple, i also think this could be too restrictive for some users. If your intent is just either have an unified active/selected color or let the user go rogue, a single toggle can be ok. > > I’ll be ok with it since imho active and selected color states should be defined by theme in the ui and that’s it! :+1: > What i was trying to envise is give the users some room for what the custom color were meant for. Let’s say that “blender theme” option is just a placeholder for whatever you want. Maybe it’s your user presets. You may want to have those without having to compile that each time. I don't know what you mean here. Themes *are* user presets. You can create entirely new themes too, as a user, if you want. No recompiling required. Currently users are already free to adjust the bone colors in their theme to their liking. > the idea was that custom themes (once stored) could be selected along with the others in the bone group colors of the armature. > > obviously if you want to lock the user out of this option, we don’t need any complication or mockup! "Lock the user out" is a bit dramatic. There are already 20 theme colors that anyone is free to adjust at any time. If these are not enough, that's a different topic than the feature we're discussing here. > In other words, if i get it right you are suggesting that the colors should be kept as unified, unless the user disables the unify toggle. In that case he can just select the custom colors and that’s it? To disambiguate "the custom colors", how I expected this feature to work is: - **"unify" disabled** (default): bone colors work as they do now. - **"unify" enabled**: the bone "regular" color works as it does now. When drawing bones, "selected" and "active" colors are taken from the default bone colors in the current theme. Note that the above doesn't distinguish "theme colors" from "custom colors", as IMO the behaviour should be the same for both. To fully understand the proposal, I do feel that [the questions I asked yesterday](#issuecomment-1035367) are still interesting to answer.
👍 1
Ivan Cappiello commented 2023-10-04 11:46:05 +02:00
Author
Member
Copy Link

@dr.sybren i think we are not looking at the whole picture, or at least we both have a different one in mind.

I'd start form looking at how blender 3.6lts works:

  • You have 4 bones, you can customize their color giving each a separate one only through creating bone groups.
  • After a bone group is created the ui will apply default colors as color set for it. All the 3 colors regular select active are dark grey (greyed out?) and not accessible to the user.
  • Users are prompted to choose from a color theme set, each one having, along with regular also both its custom active and select color predefined. This preset can't be changed in the bone groups menu. So as soon as you choose a color theme the active and select colors start to get confused.
  • the ui shows also themes 16-20 that are not set so we know that it's up to user to customize at least those to have them at hand (presumably going into the preference panel)
  • but user can also define from the bone groups panel a custom color set which they can then directly edit from the bone groups panel itself. In this case choosing custom color set will apply by default a rainbow of colors R, G, B.

Pro:
users can easily create a custom color directly on the bone group without leaving the bone groups panel.

Con:
the whole system is oriented to inconsistence.

Easy fix:
make custom colors start with current theme's active and select color scheme. Most of the users may probably want to just separate the regular color of their bones. Most advanced users can still customize new select and active, for them nothing changes and at least the current colors they edit start from what UI team decided to have for those states.

additionally, having the unify button in the bone color preferences would make all the bone cold themes act the same, giving users the quick access to bone regular color themes with just one click instead of having to pick manually one.

let's look at what is possible in Blender 4.0:

We have now long awaited Bone collections.

  • so starting from the same point we have 4 bones, you can customize their color only per bone in its viewport display panel. This is why my proposal 1 was taking that for a design choice and was adding some options. All the same issues as 3.6lts applies here, but at bone level instead of at a bone group or bone collection level.

do we want to color the bones from the bone panel at per bone level or not? this is a main design question needs an answer imo before moving to a better proposal for unified colors. Assuming the current design has a reason to be, what a user should be supposed to do to both customize his bones regular and have consistency?

Let's say we move the “unify“ toggle is just in the preference panel. I like that as I said. but I do not agree it should stay off by default. The cases you want to customize blender settings are considered but not defined as how blender is supposed to work by default. What are the use cases we know may require to have all 3 color states be different?

  • regular color clashes visually with ui defined active and select color
  • users want that specific bone to act different from ui for a specific reason (someone reported hjalti used this on overlapping bones to be sure he selected the right one)

afaict there are no other cases. But please correct me if I am wrong.

that given, since customizing each of the three colors requires more clicks, shouldn't we separate regular bone color from what its select and active state is?

assuming that we want to manage this at a general level and not at bone level, the easiest solution would be moving the bone color option back to bone collections. Doing so, bone collections would actually work and same fixes may be applied to both 3.6 and 4.0

@dr.sybren i think we are not looking at the whole picture, or at least we both have a different one in mind. I'd start form looking at how blender 3.6lts works: - You have 4 bones, you can customize their color giving each a separate one only through creating `bone groups`. - After a bone group is created the ui will apply `default colors` as color set for it. All the 3 colors `regular` `select` `active` are dark grey (greyed out?) and not accessible to the user. - Users are prompted to choose from a color theme set, each one having, along with `regular` also both its custom `active` and `select` color predefined. This preset can't be changed in the bone groups menu. So as soon as you choose a color theme the `active` and `select` colors start to get confused. - the ui shows also themes 16-20 that are not set so we know that it's up to user to customize at least those to have them at hand (presumably going into the preference panel) - but user can also define from the bone groups panel a custom color set which they can then directly edit from the bone groups panel itself. In this case choosing `custom color set` will apply by default a rainbow of colors R, G, B. Pro: users can easily create a custom color directly on the bone group without leaving the `bone groups` panel. Con: the whole system is oriented to inconsistence. Easy fix: make custom colors start with current theme's `active` and `select` color scheme. Most of the users may probably want to just separate the `regular` color of their bones. Most advanced users can still customize new `select` and `active`, for them nothing changes and at least the current colors they edit start from what UI team decided to have for those states. additionally, having the unify button in the bone color preferences would make all the bone cold themes act the same, giving users the quick access to bone `regular` color themes with just one click instead of having to pick manually one. ---- let's look at what is possible in Blender 4.0: We have now long awaited Bone collections. - so starting from the same point we have 4 bones, you can customize their color only per bone in its viewport display panel. This is why my proposal 1 was taking that for a design choice and was adding some options. All the same issues as 3.6lts applies here, but at bone level instead of at a `bone group` or `bone collection` level. do we want to color the bones from the bone panel at per bone level or not? this is a main design question needs an answer imo before moving to a better proposal for unified colors. Assuming the current design has a reason to be, what a user should be supposed to do to both customize his bones `regular` and have consistency? Let's say we move the “unify“ toggle is just in the preference panel. I like that as I said. but I do not agree it should stay off by default. The cases you want to customize blender settings are considered but not defined as how blender is supposed to work by default. What are the use cases we know may require to have all 3 color states be different? - regular color clashes visually with ui defined active and select color - users want that specific bone to act different from ui for a specific reason (someone reported hjalti used this on overlapping bones to be sure he selected the right one) afaict there are no other cases. But please correct me if I am wrong. that given, since customizing each of the three colors requires more clicks, shouldn't we separate regular bone color from what its select and active state is? assuming that we want to manage this at a general level and not at bone level, the easiest solution would be moving the bone color option back to bone collections. Doing so, bone collections would actually work and same fixes may be applied to both 3.6 and 4.0
Ivan Cappiello commented 2023-10-04 11:55:13 +02:00
Author
Member
Copy Link

@dr.sybren i suppose these are the questions. If you find my answers are not in the post, I'll try to summarize them here.

What I'm still wondering about is what this option would do to the user interface. Would it also simplify the custom color interface, reducing the three color properties to one?

When unify is active in the preference (ON by default imo) yes. The other 2 swatches do not appear.

But if it did, how would you set those colors for people who'd want this option to be turned off?

Using the custom theme, as is now, just the custom theme defaults to current selected active unified as in main preferences. The user can tweak those, but starting from what is defined in blender itself

And if you didn't, how would you show what people are actually editing at that time?

only on custom color theme.

Or would you disable the selected/active colors in the UI to show they're not used at the time?

I'd make them not appear at all if unify is on. if off they are always defaulting to blender UI theme defaults, but you can customize them

But if you do, how would you differentiate between "disabled" and "enabled but darker color was selected"?

I don't get the question at all, sorry.

@dr.sybren i suppose these are the questions. If you find my answers are not in the post, I'll try to summarize them here. > What I'm still wondering about is what this option would do to the user interface. Would it also simplify the custom color interface, reducing the three color properties to one? When unify is active in the preference (ON by default imo) yes. The other 2 swatches do not appear. > But if it did, how would you set those colors for people who'd want this option to be turned off? Using the custom theme, as is now, just the custom theme defaults to current selected active unified as in main preferences. The user can tweak those, but starting from what is defined in blender itself > And if you didn't, how would you show what people are actually editing at that time? only on custom color theme. > Or would you disable the selected/active colors in the UI to show they're not used at the time? I'd make them not appear at all if unify is on. if off they are always defaulting to blender UI theme defaults, but you can customize them > But if you do, how would you differentiate between "disabled" and "enabled but darker color was selected"? I don't get the question at all, sorry.
Ludvik Koutny commented 2023-10-04 11:55:17 +02:00
Contributor
Copy Link

In which cases would you want to customize selected and active variants of the bone colors? In which cases would you want to do something different than having select and active colors be just different brightness/saturation of the bone color? Those should not be customizable. They should just be derived from the bone color internally. Otherwise you are literally offloading a work no one wants to do onto users. Or do you really want to for example have different hue for the selected/active state? So that a green bone turns cyan/red bone turns orange when you select it or make it active?

This is a prime example of malicious customization. Basically throwing so many settings onto users the best choice is almost always to not touch it and keep it at default. So you have still cluttered UI you need to maintain, but almost no one uses that UI because you are asking for them to do way too much pointless work.

In which cases would you want to customize selected and active variants of the bone colors? In which cases would you want to do something different than having select and active colors be just different brightness/saturation of the bone color? Those should not be customizable. They should just be derived from the bone color internally. Otherwise you are literally offloading a work no one wants to do onto users. Or do you really want to for example have different hue for the selected/active state? So that a green bone turns cyan/red bone turns orange when you select it or make it active? This is a prime example of malicious customization. Basically throwing so many settings onto users the best choice is almost always to not touch it and keep it at default. So you have still cluttered UI you need to maintain, but almost no one uses that UI because you are asking for them to do way too much pointless work.
Demeter Dzadik commented 2023-10-04 12:13:56 +02:00
Member
Copy Link

I don't mind if unified selected/active colors become the default preference, and of course, when that option is enabled, the individual selected/active colors don't need to be drawn in the theme/bone display UI.

This would be even less controversial if we use Alexander's idea of offsetting the base color's luminosity value, as opposed to just using a single color for each selection state. I updated that preset color proposal to use this logic. Now the selected/active colors still feel great, despite being set automatically, as an offset from the base color. There is also a .blend file to try it out.

This way people like me and Hjalti are happy, because bones with different base colors won't look exactly identical when selected. But people like Ivan are also likely to be happy, because they don't need to customize selected/active colors in order to have a good visual indication of selection state. So, best of both worlds!

I don't mind if unified selected/active colors become the default preference, and of course, when that option is enabled, the individual selected/active colors don't need to be drawn in the theme/bone display UI. This would be even less controversial if we use [Alexander's idea of offsetting the base color's luminosity value](https://projects.blender.org/blender/blender/issues/112635#issuecomment-1032606), as opposed to just using a single color for each selection state. I updated that preset color proposal to use this logic. Now the selected/active colors still feel great, despite being set automatically, as an offset from the base color. There is also a .blend file to try it out. This way people like me and Hjalti are happy, because bones with different base colors won't look exactly identical when selected. But people like Ivan are also likely to be happy, because they don't need to customize selected/active colors in order to have a good visual indication of selection state. So, best of both worlds!
👍 1
Sybren A. Stüvel commented 2023-10-05 12:37:16 +02:00
Member
Copy Link

In answer to @icappiello :

  • You have 4 bones, you can customize their color giving each a separate one only through creating bone groups.
  • After a bone group is created the ui will apply default colors as color set for it. All the 3 colors regular select active are dark grey (greyed out?) and not accessible to the user.

Sure, because it's either a theme color (so those colors are accessible, but via preferences), or a custom color (which enables setting those colors on the bone group).

  • Users are prompted to choose from a color theme set, each one having, along with regular also both its custom active and select color predefined. This preset can't be changed in the bone groups menu. So as soon as you choose a color theme the active and select colors start to get confused.

That last part ("So as soon as you choose ... get confused") is not "how Blender works", but rather a subjective interpretation.

  • the ui shows also themes 16-20 that are not set so we know that it's up to user to customize at least those to have them at hand (presumably going into the preference panel)

That's another issue; I agree it would be better to have these assigned by default too.

Easy fix:
make custom colors start with current theme's active and select color scheme.

IMO it makes total sense to start with something other than black/black/black. It's probably best to fully initialise them to the current theme's default bone colors. So not just 'active' and 'selected', but also 'regular'.

Most of the users may probably want to just separate the regular color of their bones. Most advanced users can still customize new select and active, for them nothing changes and at least the current colors they edit start from what UI team decided to have for those states.

I'm not 100% sure if what I'd want is possible, but it would be fantastic if we could make RNA understand that each color property has a different default value. That way we could make the default RNA values of the color.custom.{normal,select,active} equal to the current theme's default bone colors.

additionally, having the unify button in the bone color preferences would make all the bone cold themes act the same, giving users the quick access to bone regular color themes with just one click instead of having to pick manually one.

IMO, this is orthogonal to the rest of what you just described. I see these two things getting intertwined:

  1. Making it easier to work with custom colors (first part of what you write), vs.
  2. changing Blender's drawing code to respond to a new option in the preference (this part).

Both are interesting, and I don't think they should be discussed as one and the same thing.

do we want to color the bones from the bone panel at per bone level or not? this is a main design question needs an answer imo before moving to a better proposal for unified colors. Assuming the current design has a reason to be, what a user should be supposed to do to both customize his bones regular and have consistency?

IMO rigs should use the theme colors as much as possible. These colors should be picked well, but that's a different discussion (#112635).

Let's say we move the “unify“ toggle is just in the preference panel. I like that as I said. but I do not agree it should stay off by default.

The issue with having this option at all is that it can lead to yet more confusion. For example, a rigger could have this option on, while the animators have the option off, and then the animators see colors that the rigger might not have even bothered to update.

The cases you want to customize blender settings are considered but not defined as how blender is supposed to work by default.

What does this mean, exactly?

What are the use cases we know may require to have all 3 color states be different?

I wouldn't be suprised if people just want to have consistent bone colors. So the red bone stays red when it's selected, just a brighter shade of it. I agree that things can be hard to see with the default colors, but again picking a better set of colors is a different discussion.

that given, since customizing each of the three colors requires more clicks, shouldn't we separate regular bone color from what its select and active state is?

I also have a hard time understanding that sentence. Regular bone colors are already separated from their selected/active colors.

assuming that we want to manage this at a general level and not at bone level, the easiest solution would be moving the bone color option back to bone collections. Doing so, bone collections would actually work and same fixes may be applied to both 3.6 and 4.0

That's not "simple", please be careful in your wording -- if it were simple it would have been implemented as such already.

What I'm still wondering about is what this option would do to the user interface. Would it also simplify the custom color interface, reducing the three color properties to one?

When unify is active in the preference (ON by default imo) yes. The other 2 swatches do not appear.

Ok, but see below:

But if it did, how would you set those colors for people who'd want this option to be turned off?

Using the custom theme, as is now, just the custom theme defaults to current selected active unified as in main preferences. The user can tweak those, but starting from what is defined in blender itself

That doesn't answer my question. I'm thinking of this situation (like I describe above as well):

  • Rigger: has "unify" enabled, so no way to set the selected/active color of the bones. Creates a rig & changes bone colors.
  • Animator: has "unify" disabled, and will see whatever the bone's custom selected/active color have been set to. This may be a mess, because the rigger did not set those.

If having the "unify" enabled means that custom bone colors are always set to the theme-defaults, this has other issues:

  • Rigger: has "unify" disabled, so carefully chooses all the bone colors.
  • Animator A: also has "unify" disabled, so sees all the bone colors as the rigger intended.
  • Animator B: has "unify" enabled, and sees the unified select/active colors. Now they save the file, and Blender resets all the custom bone colors to their theme.
  • Animator A: continues working on the file, but now sees the theme colors of Animator B instead of the rigger-chosen colors or even their own theme colors.

This would mean that the theme of one user affects the colors seen by another user. This to me is not the right way to go.

And if you didn't, how would you show what people are actually editing at that time?

only on custom color theme.

What do you mean with that?

Or would you disable the selected/active colors in the UI to show they're not used at the time?

I'd make them not appear at all if unify is on. if off they are always defaulting to blender UI theme defaults, but you can customize them

But if you do, how would you differentiate between "disabled" and "enabled but darker color was selected"?

I don't get the question at all, sorry.

When some property is not used by Blender (for example on a mesh: the Auto Smooth Angle property when Auto Smooth is disabled) it usually still shown, but in a dimmed color. For regular UI elements this makes sense. However, for a color swatch it would be confusing, as you don't see the difference between "dimmed because not used" and "just a darker color was chosen".

Answer to @Rawalanche:

In which cases would you want to customize selected and active variants of the bone colors? In which cases would you want to do something different than having select and active colors be just different brightness/saturation of the bone color? Those should not be customizable. They should just be derived from the bone color internally.

Two reasons things are this way now:

  1. They were already this way, at least going back to Blender 2.57 (which is the oldest I happen to have installed on my computer). Removing features that have been there for so long (2.57 was released 12 years ago) can be done, of course, but should be well thought-out.
  2. Changing brightness & saturation of a color without affecting its hue is tricky, especially since it's pretty much impossible to do perfectly without taking the surrounding colors in consideration.

Blender could help setting the select/active colors given the 'regular' color, though, so that you don't have to always do this manually and still give users control over the final color selection.

This is a prime example of malicious customization.

Please reduce the drama and get a grip. We're simply trying to improve a 12-year-old feature. Calling things "malicious" doesn't help anyone.

In answer to @icappiello : > - You have 4 bones, you can customize their color giving each a separate one only through creating `bone groups`. > - After a bone group is created the ui will apply `default colors` as color set for it. All the 3 colors `regular` `select` `active` are dark grey (greyed out?) and not accessible to the user. Sure, because it's either a theme color (so those colors *are* accessible, but via preferences), or a custom color (which enables setting those colors on the bone group). > - Users are prompted to choose from a color theme set, each one having, along with `regular` also both its custom `active` and `select` color predefined. This preset can't be changed in the bone groups menu. So as soon as you choose a color theme the `active` and `select` colors start to get confused. That last part ("So as soon as you choose ... get confused") is not "how Blender works", but rather a subjective interpretation. > - the ui shows also themes 16-20 that are not set so we know that it's up to user to customize at least those to have them at hand (presumably going into the preference panel) That's another issue; I agree it would be better to have these assigned by default too. > Easy fix: > make custom colors start with current theme's `active` and `select` color scheme. IMO it makes total sense to start with something other than black/black/black. It's probably best to fully initialise them to the current theme's default bone colors. So not just 'active' and 'selected', but also 'regular'. > Most of the users may probably want to just separate the `regular` color of their bones. Most advanced users can still customize new `select` and `active`, for them nothing changes and at least the current colors they edit start from what UI team decided to have for those states. I'm not 100% sure if what I'd want is possible, but it would be fantastic if we could make RNA understand that each color property has a different default value. That way we could make the default RNA values of the `color.custom.{normal,select,active}` equal to the current theme's default bone colors. > additionally, having the unify button in the bone color preferences would make all the bone cold themes act the same, giving users the quick access to bone `regular` color themes with just one click instead of having to pick manually one. IMO, this is orthogonal to the rest of what you just described. I see these two things getting intertwined: 1. Making it easier to work with custom colors (first part of what you write), vs. 2. changing Blender's drawing code to respond to a new option in the preference (this part). Both are interesting, and I don't think they should be discussed as one and the same thing. ------------ > do we want to color the bones from the bone panel at per bone level or not? this is a main design question needs an answer imo before moving to a better proposal for unified colors. Assuming the current design has a reason to be, what a user should be supposed to do to both customize his bones `regular` and have consistency? IMO rigs should use the theme colors as much as possible. These colors should be picked well, but that's a different discussion (#112635). > Let's say we move the “unify“ toggle is just in the preference panel. I like that as I said. but I do not agree it should stay off by default. The issue with having this option at all is that it can lead to yet more confusion. For example, a rigger could have this option on, while the animators have the option off, and then the animators see colors that the rigger might not have even bothered to update. > The cases you want to customize blender settings are considered but not defined as how blender is supposed to work by default. What does this mean, exactly? > What are the use cases we know may require to have all 3 color states be different? I wouldn't be suprised if people just want to have consistent bone colors. So the red bone stays red when it's selected, just a brighter shade of it. I agree that things can be hard to see with the default colors, but again picking a better set of colors is a different discussion. > that given, since customizing each of the three colors requires more clicks, shouldn't we separate regular bone color from what its select and active state is? I also have a hard time understanding that sentence. Regular bone colors are already separated from their selected/active colors. > assuming that we want to manage this at a general level and not at bone level, the easiest solution would be moving the bone color option back to bone collections. Doing so, bone collections would actually work and same fixes may be applied to both 3.6 and 4.0 That's not "simple", please be careful in your wording -- if it were simple it would have been implemented as such already. > > What I'm still wondering about is what this option would do to the user interface. Would it also simplify the custom color interface, reducing the three color properties to one? > > When unify is active in the preference (ON by default imo) yes. The other 2 swatches do not appear. Ok, but see below: > > But if it did, how would you set those colors for people who'd want this option to be turned off? > > Using the custom theme, as is now, just the custom theme defaults to current selected active unified as in main preferences. The user can tweak those, but starting from what is defined in blender itself That doesn't answer my question. I'm thinking of this situation (like I describe above as well): - Rigger: has **"unify" enabled**, so no way to set the selected/active color of the bones. Creates a rig & changes bone colors. - Animator: has **"unify" disabled**, and will see whatever the bone's custom selected/active color have been set to. This may be a mess, because the rigger did not set those. If having the "unify" enabled means that custom bone colors are always set to the theme-defaults, this has other issues: - Rigger: has **"unify" disabled**, so carefully chooses all the bone colors. - Animator A: also has **"unify" disabled**, so sees all the bone colors as the rigger intended. - Animator B: has **"unify" enabled**, and sees the unified select/active colors. Now they save the file, and Blender resets all the custom bone colors to their theme. - Animator A: continues working on the file, but now sees the theme colors of Animator B instead of the rigger-chosen colors or even their own theme colors. This would mean that the theme of one user affects the colors seen by another user. This to me is not the right way to go. > > And if you didn't, how would you show what people are actually editing at that time? > > only on custom color theme. What do you mean with that? > > Or would you disable the selected/active colors in the UI to show they're not used at the time? > > I'd make them not appear at all if unify is on. if off they are always defaulting to blender UI theme defaults, but you can customize them > > > But if you do, how would you differentiate between "disabled" and "enabled but darker color was selected"? > > I don't get the question at all, sorry. When some property is not used by Blender (for example on a mesh: the Auto Smooth Angle property when Auto Smooth is disabled) it usually still shown, but in a dimmed color. For regular UI elements this makes sense. However, for a color swatch it would be confusing, as you don't see the difference between "dimmed because not used" and "just a darker color was chosen". ------------ Answer to @Rawalanche: > In which cases would you want to customize selected and active variants of the bone colors? In which cases would you want to do something different than having select and active colors be just different brightness/saturation of the bone color? Those should not be customizable. They should just be derived from the bone color internally. Two reasons things are this way now: 1. They were already this way, at least going back to Blender 2.57 (which is the oldest I happen to have installed on my computer). Removing features that have been there for so long (2.57 was released 12 years ago) can be done, of course, but should be well thought-out. 2. Changing brightness & saturation of a color without affecting its hue is tricky, especially since it's pretty much impossible to do perfectly without taking the surrounding colors in consideration. Blender could help setting the select/active colors given the 'regular' color, though, so that you don't have to always do this manually and still give users control over the final color selection. > This is a prime example of malicious customization. Please reduce the drama and get a grip. We're simply trying to improve a 12-year-old feature. Calling things "malicious" doesn't help anyone.
Demeter Dzadik commented 2023-10-05 13:42:03 +02:00
Member
Copy Link

would be fantastic if we could make RNA understand that each color property has a different default value

Just want to point out that this wouldn't only help with bone colors, it would be a huge general improvement for the few people who actually want to customize their Blender UI theme. 👍

moving the bone color option back to bone collections

Remember that a bone can be assigned to more than one bone collection, which was the reason why this wasn't done in the first place.

PROPOSED SOLUTION 2: CHANGE THE GENERAL SETTINGS IN THE MAIN PREFERENCES

I would go with this idea out of the two, but I don't think the "Unified Color Theme" option is valuable. Just the checkbox and the 2 colors seems fine to me, since this is already at the theme level.
Of course, if we can find some math-based color offset for selection states that everybody is happy with, then we don't even need the 2 colors, but for the purposes of this task that's somewhat unimportant.

> would be fantastic if we could make RNA understand that each color property has a different default value Just want to point out that this wouldn't only help with bone colors, it would be a huge general improvement for the few people who actually want to customize their Blender UI theme. 👍 > moving the bone color option back to bone collections Remember that a bone can be assigned to more than one bone collection, which was the reason why this wasn't done in the first place. > PROPOSED SOLUTION 2: CHANGE THE GENERAL SETTINGS IN THE MAIN PREFERENCES I would go with this idea out of the two, but I don't think the "Unified Color Theme" option is valuable. Just the checkbox and the 2 colors seems fine to me, since this is already at the theme level. Of course, if we can find some math-based color offset for selection states that everybody is happy with, then we don't even need the 2 colors, but for the purposes of this task that's somewhat unimportant.
Sybren A. Stüvel commented 2023-10-05 14:20:47 +02:00
Member
Copy Link

would be fantastic if we could make RNA understand that each color property has a different default value

Just want to point out that this wouldn't only help with bone colors, it would be a huge general improvement for the few people who actually want to customize their Blender UI theme. 👍

Don't hold your breath, though. To illustrate the kind of problems we'd face: It was already super cumbersome to even have the theme color index 'copy to selected'-able, and I imagine similar issues for the "reset to default" operator. It would not only need to know that it's a "float[3] array that's a color", but need much more context of where/how it's used.

<nerdy deep dive>
When you hover over the 'Bone Color' drop-down, the tooltip will show the whole path bpy.data.armatures["Armature"].bones["Bone"].color.palette. BUT, when you select "Custom Color" there and hover over the individual color swatches, it is not able to construct the path. This is because the function that should construct this path (rna_BoneColor_path_bone() in rna_armature.cc) only gets the "owner ID" and an identifier for the actual property. So, to determine the path to the ...color, it gets:

  • owner_id = bpy.data["Armatures"], and
  • property = a pointer to the BoneColor that is that particular .color property.

This means that that function doesn't even know which bone the color is on. Because the current memory allocation structure is the way it is, I wrote some code that juggles pointers to actually know which bone it's talking about. The only reason this is possible is because the bone embeds its BoneColor.

For the .color.custom property it's the same thing, but yet another level deeper. It can be done, but the code will be rather ugly & inflexible, as it's basically working around a limitation of Blender's RNA system.
</nerdy deep dive>

PROPOSED SOLUTION 2: CHANGE THE GENERAL SETTINGS IN THE MAIN PREFERENCES

I would go with this idea out of the two, but I don't think the "Unified Color Theme" option is valuable. Just the checkbox and the 2 colors seems fine to me, since this is already at the theme level.
Of course, if we can find some math-based color offset for selection states that everybody is happy with, then we don't even need the 2 colors, but for the purposes of this task that's somewhat unimportant.

With this in mind, in combination with the issues I described above, I think it's best to finish up #112635 first, and maybe also add the button to construct a sensible selected/active color from the regular color. That'll take away a lot of the manual steps, and make things easier to use & easier to keep consistent. We can then revisit this discussion, to see if it's even still necessary.

> > would be fantastic if we could make RNA understand that each color property has a different default value > > Just want to point out that this wouldn't only help with bone colors, it would be a huge general improvement for the few people who actually want to customize their Blender UI theme. 👍 Don't hold your breath, though. To illustrate the kind of problems we'd face: It was already super cumbersome to even have the theme color index 'copy to selected'-able, and I imagine similar issues for the "reset to default" operator. It would not only need to know that it's a "float[3] array that's a color", but need much more context of where/how it's used. `<nerdy deep dive>` When you hover over the 'Bone Color' drop-down, the tooltip will show the whole path `bpy.data.armatures["Armature"].bones["Bone"].color.palette`. BUT, when you select "Custom Color" there and hover over the individual color swatches, it is not able to construct the path. This is because the function that should construct this path (`rna_BoneColor_path_bone()` in `rna_armature.cc`) only gets the "owner ID" and an identifier for the actual property. So, to determine the path to the `...color`, it gets: - `owner_id` = `bpy.data["Armatures"]`, and - `property` = a pointer to the `BoneColor` that is that particular `.color` property. This means that that function doesn't even know which bone the color is on. Because the current memory allocation structure is the way it is, I wrote some code that juggles pointers to actually know which bone it's talking about. The only reason this is possible is because the bone embeds its `BoneColor`. For the `.color.custom` property it's the same thing, but yet another level deeper. It can be done, but the code will be rather ugly & inflexible, as it's basically working around a limitation of Blender's RNA system. `</nerdy deep dive>` > > PROPOSED SOLUTION 2: CHANGE THE GENERAL SETTINGS IN THE MAIN PREFERENCES > > I would go with this idea out of the two, but I don't think the "Unified Color Theme" option is valuable. Just the checkbox and the 2 colors seems fine to me, since this is already at the theme level. > Of course, if we can find some math-based color offset for selection states that everybody is happy with, then we don't even need the 2 colors, but for the purposes of this task that's somewhat unimportant. With this in mind, in combination with the [issues I described above](#issuecomment-1037785), I think it's best to finish up #112635 first, and maybe also add the button to construct a sensible selected/active color from the regular color. That'll take away a lot of the manual steps, and make things easier to use & easier to keep consistent. We can then revisit this discussion, to see if it's even still necessary.
Ludvik Koutny commented 2023-10-05 14:40:49 +02:00
Contributor
Copy Link

Please reduce the drama and get a grip. We're simply trying to improve a 12-year-old feature. Calling things "malicious" doesn't help anyone.

What I called malicious is a practice where you add so much customization that it doesn't pay off to customize anything because it's just too much work for too little gain.

It's malicious in a sense that it's usually a big chunk of code that has to exist and be maintained but it's not used by almost anyone, and this is a prime example of it:
image

Changing brightness & saturation of a color without affecting its hue is tricky, especially since it's pretty much impossible to do perfectly without taking the surrounding colors in consideration.

No it's not. On a scale of difficulty of problems to solve this is like 2 out of 10. Why would you need to take any surrounding colors into consideration? That would be up to user to define what the colors are. You would just not subject them to laborious work of specifying the same color thrice with identical S/V offsets.

def sv(color_in, s, v):  # pylint: disable=invalid-name
    color_out = Color(color_in)
    s = color_out.s * s
    color_out.hsv = color_in.h, s, v
    return color_out

def set_bone_color_sets(props, area):
    generic_colors = (
        props.color_red,
        props.color_orange,
        props.color_yellow,
        props.color_grass,
        props.color_green,
        props.color_aqua,
        props.color_cyan,
        props.color_blue,
        props.color_indigo,
        props.color_purple,
        props.color_magenta,
        props.color_pink
    )

    sv_normal = (0.9, 0.5)
    sv_select = (0.9, 0.7)
    sv_active = (0.9, 0.9)

    for index, color_set in enumerate(area.values()):
        color = generic_colors[index % len(generic_colors)]
        color_set.normal = sv(color, *sv_normal)
        color_set.select = sv(color, *sv_select)
        color_set.active = sv(color, *sv_active)

I already do that in my addon which has a sole purpose of making theme editing in Blender accessible to anyone, by fixing exactly what I called malicious customization above.

Not saying this is what blender should do, but that offloading the job of drawing a select\highlight effect of something by asking user to specify exact color of each permutation is just inappropriate.

All I want is the 60 color swatches to become 20.

> Please reduce the drama and get a grip. We're simply trying to improve a 12-year-old feature. Calling things "malicious" doesn't help anyone. What I called malicious is a practice where you add so much customization that it doesn't pay off to customize anything because it's just too much work for too little gain. It's malicious in a sense that it's usually a big chunk of code that has to exist and be maintained but it's not used by almost anyone, and this **is** a prime example of it: ![image](/attachments/b0c922ab-dfc0-4b01-a513-92b7832e209c) > Changing brightness & saturation of a color without affecting its hue is tricky, especially since it's pretty much impossible to do perfectly without taking the surrounding colors in consideration. No it's not. On a scale of difficulty of problems to solve this is like 2 out of 10. Why would you need to take any surrounding colors into consideration? That would be up to user to define what the colors are. You would just not subject them to laborious work of specifying the same color thrice with identical S/V offsets. ``` def sv(color_in, s, v): # pylint: disable=invalid-name color_out = Color(color_in) s = color_out.s * s color_out.hsv = color_in.h, s, v return color_out def set_bone_color_sets(props, area): generic_colors = ( props.color_red, props.color_orange, props.color_yellow, props.color_grass, props.color_green, props.color_aqua, props.color_cyan, props.color_blue, props.color_indigo, props.color_purple, props.color_magenta, props.color_pink ) sv_normal = (0.9, 0.5) sv_select = (0.9, 0.7) sv_active = (0.9, 0.9) for index, color_set in enumerate(area.values()): color = generic_colors[index % len(generic_colors)] color_set.normal = sv(color, *sv_normal) color_set.select = sv(color, *sv_select) color_set.active = sv(color, *sv_active) ``` I already do that in my addon which has a sole purpose of making theme editing in Blender accessible to anyone, by fixing exactly what I called malicious customization above. Not saying this is what blender should do, but that offloading the job of drawing a select\highlight effect of something by asking user to specify exact color of each permutation is just inappropriate. All I want is the 60 color swatches to become 20.
image.png
97 KiB
Sybren A. Stüvel commented 2023-10-05 15:20:55 +02:00
Member
Copy Link

What I called malicious is a practice where you add so much customization that it doesn't pay off to customize anything because it's just too much work for too little gain.

There's little use in arguing that something that's over 12 years old shouldn't have been added back then. Also caling this "malicious" is a bit weird, given its meaning.

... it's not used by almost anyone

In my experience, it's very likely for someone, who is adamant about knowing exactly how much a feature is (not) used, to be wrong about that.

Changing brightness & saturation of a color without affecting its hue is tricky, especially since it's pretty much impossible to do perfectly without taking the surrounding colors in consideration.

No it's not. On a scale of difficulty of problems to solve this is like 2 out of 10. Why would you need to take any surrounding colors into consideration?

Ok, I should have mentioned perceived hue. But yeah, this is how the eyes work. Indeed, there are definitions of "hue" that don't take perception into account, but given that this is about coloring things for humans to see...

That would be up to user to define what the colors are. You would just not subject them to laborious work of specifying the same color thrice with identical S/V offsets.

Again, please cut the drama. Setting a few colors is nothing "laborious", compared to the work involved to actually construct a nice rig, or to the animate a shot. Yes, it might be a bit annoying to do by hand, but that's it.

Also you're skipping over the "and maybe also add the button to construct a sensible selected/active color from the regular color" that I wrote at the end of my post. That would be another way to avoid this "laborious" work, while still keeping people in control over the colors they want exactly.

> What I called malicious is a practice where you add so much customization that it doesn't pay off to customize anything because it's just too much work for too little gain. There's little use in arguing that something that's over 12 years old shouldn't have been added back then. Also caling this "malicious" is a bit weird, given [its meaning](https://www.oxfordlearnersdictionaries.com/definition/english/malicious?q=malicious). > ... it's not used by almost anyone In my experience, it's very likely for someone, who is adamant about knowing exactly how much a feature is (not) used, to be wrong about that. > > Changing brightness & saturation of a color without affecting its hue is tricky, especially since it's pretty much impossible to do perfectly without taking the surrounding colors in consideration. > > No it's not. On a scale of difficulty of problems to solve this is like 2 out of 10. Why would you need to take any surrounding colors into consideration? Ok, I should have mentioned *perceived* hue. But yeah, this is how the eyes work. Indeed, there are definitions of "hue" that don't take perception into account, but given that this is about coloring things for humans to see... > That would be up to user to define what the colors are. You would just not subject them to laborious work of specifying the same color thrice with identical S/V offsets. Again, please cut the drama. Setting a few colors is nothing "laborious", compared to the work involved to actually construct a nice rig, or to the animate a shot. Yes, it might be a bit annoying to do by hand, but that's it. Also you're skipping over the "and maybe also add the button to construct a sensible selected/active color from the regular color" that I wrote at the end of my post. That would be another way to avoid this "laborious" work, while still keeping people in control over the colors they want exactly.
Nathan Vegdahl commented 2023-10-05 15:25:18 +02:00
Member
Copy Link

It's malicious in a sense that [...]

I understand what you're getting at, and I agree it would be better to avoid forcing users to specify every variation of a custom bone color. Indeed, I myself find that obnoxious as a user.

But it nevertheless seems significantly out of place to use the word "malicious" to describe the current situation. Specifically, I'm quite certain no one involved was/is intentionally trying to cause harm. So calling it "malicious" is more than a little hyperbolic, and is understandably going to ruffle some feathers.

> It's malicious in a sense that [...] I understand what you're getting at, and I agree it would be better to avoid forcing users to specify every variation of a custom bone color. Indeed, I myself find that obnoxious as a user. But it nevertheless seems significantly out of place to use the word "malicious" to describe the current situation. Specifically, I'm quite certain no one involved was/is *intentionally* trying to cause harm. So calling it "malicious" is more than a little hyperbolic, and is understandably going to ruffle some feathers.
Ludvik Koutny commented 2023-10-05 15:55:43 +02:00
Contributor
Copy Link

Again, please cut the drama. Setting a few colors is nothing "laborious", compared to the work involved to actually construct a nice rig, or to the animate a shot. Yes, it might be a bit annoying to do by hand, but that's it.

You just can't be reasonably using this argument for UX issues.
"Customizing 40 color swatches individually is nothing compared to building a complex rig, it's just a bit annoying."

Justifying poor UX by saying Blender users are used to laborious and complex tasks is just not a valid argument. If this is a standard to be established then we wouldn't even need a UI and all the operators could be just typed into a python console.

If things that have no business being difficult or inefficient are difficult and inefficient, then some other unrelated things being more difficult is not a valid argument for not solving the difficulty or inefficiency.

In my experience, it's very likely for someone, who is adamant about knowing exactly how much a feature is (not) used, to be wrong about that.

You are a core Blender developer, you have access to post on official resource sites such as devtalk. Post a poll asking users whom have made their entire own theme if they customized bone colors in the theme editor, including selected and active modes. If over 50% of the responses will be "Yes", then I hereby promise to send you $100.

Also you're skipping over the "and maybe also add the button to construct a sensible selected/active color from the regular color" that I wrote at the end of my post. That would be another way to avoid this "laborious" work, while still keeping people in control over the colors they want exactly.

That's all I want. Don't really care how it's implemented as long as 60 swatches become 20.

> Again, please cut the drama. Setting a few colors is nothing "laborious", compared to the work involved to actually construct a nice rig, or to the animate a shot. Yes, it might be a bit annoying to do by hand, but that's it. You just can't be reasonably using this argument for UX issues. "Customizing 40 color swatches individually is nothing compared to building a complex rig, it's just a bit annoying." Justifying poor UX by saying Blender users are used to laborious and complex tasks is just not a valid argument. If this is a standard to be established then we wouldn't even need a UI and all the operators could be just typed into a python console. If things that have no business being difficult or inefficient are difficult and inefficient, then some other unrelated things being more difficult is not a valid argument for not solving the difficulty or inefficiency. > In my experience, it's very likely for someone, who is adamant about knowing exactly how much a feature is (not) used, to be wrong about that. You are a core Blender developer, you have access to post on official resource sites such as devtalk. Post a poll asking users whom have made their entire own theme if they customized bone colors in the theme editor, including selected and active modes. If over 50% of the responses will be "Yes", then I hereby promise to send you $100. > Also you're skipping over the "and maybe also add the button to construct a sensible selected/active color from the regular color" that I wrote at the end of my post. That would be another way to avoid this "laborious" work, while still keeping people in control over the colors they want exactly. That's all I want. Don't really care how it's implemented as long as 60 swatches become 20.
Sybren A. Stüvel commented 2023-10-05 16:52:01 +02:00
Member
Copy Link

Again, please cut the drama. Setting a few colors is nothing "laborious", compared to the work involved to actually construct a nice rig, or to the animate a shot. Yes, it might be a bit annoying to do by hand, but that's it.

You just can't be reasonably using this argument for UX issues.

I'm going to stop this discussion right here. You're calling things malicious (note the intentional aspect of this, which Nathan also highlighted), and twisting my words as well (I wasn't saying this UX issue doesn't exist, I was merely putting your use of the word "laborious" into another perpective). This is not helping this design discussion at all.

> > Again, please cut the drama. Setting a few colors is nothing "laborious", compared to the work involved to actually construct a nice rig, or to the animate a shot. Yes, it might be a bit annoying to do by hand, but that's it. > > You just can't be reasonably using this argument for UX issues. I'm going to stop this discussion right here. You're calling things malicious (note the *intentional* aspect of this, which Nathan also highlighted), and twisting my words as well (I wasn't saying this UX issue doesn't exist, I was merely putting your use of the word "laborious" into another perpective). This is not helping this design discussion at all.
Ivan Cappiello commented 2023-10-09 09:41:16 +02:00
Author
Member
Copy Link

@dr.sybren

That doesn't answer my question. I'm thinking of this situation (like I describe above as well):

Rigger: has "unify" enabled, so no way to set the selected/active color of the bones. Creates a rig & changes bone colors.
Animator: has "unify" disabled, and will see whatever the bone's custom selected/active color have been set to. This may be a mess, >because the rigger did not set those.
If having the "unify" enabled means that custom bone colors are always set to the theme-defaults, this has other issues:

Rigger: has "unify" disabled, so carefully chooses all the bone colors.
Animator A: also has "unify" disabled, so sees all the bone colors as the rigger intended.
Animator B: has "unify" enabled, and sees the unified select/active colors. Now they save the file, and Blender resets all the custom >bone colors to their theme.
Animator A: continues working on the file, but now sees the theme colors of Animator B instead of the rigger-chosen colors or even >their own theme colors.
This would mean that the theme of one user affects the colors seen by another user. This to me is not the right way to go.

what I was proposing (without knowing if it is easy, difficult, possible or not) is that when unified color is on, the colors are dynamically shown as the blender theme sets it. They are not wrote in to the color itself either on file open or file save. Blender should override whatever the custom color was by displaying the theme's unified colors on load. If the rigger sets a custom color it stays in the file, just the user with unified option on will not see unless he disables the unification. This can also be triggered by the rigger's ui with a toggle pointing to the preference.

This is imo a customization overkill. The whole point of the proposal is to make blender act in a predictable way. Hyper-customization goes in to the opposite direction. I would agree with @Mets on this:

I wouldn't stress so much about allowing animators to see a rig the way that the rigger intended. If they want to do that, just leave your theme colors alone. If the rigger really wants to not allow that customizability, they can use custom colors. But it's not the rigger's responsibility to police the animators' theme settings. If a user breaks their Blender theme, that's their choice and their problem.

and this point to what I had probably not expressed that well here:

The cases you want to customize blender settings are considered but not defined as how blender is supposed to work by default.

What does this mean, exactly?

i was trying to say that the "Defaults" are created to define how a software is supposed to work by design. Customization is optional and is supported, but usually when you customize you do it at your own risk. So imo we should care more for what we pick as default against what the user is able to mess up by customizing.

@dr.sybren >That doesn't answer my question. I'm thinking of this situation (like I describe above as well): > >Rigger: has "unify" enabled, so no way to set the selected/active color of the bones. Creates a rig & changes bone colors. >Animator: has "unify" disabled, and will see whatever the bone's custom selected/active color have been set to. This may be a mess, >because the rigger did not set those. >If having the "unify" enabled means that custom bone colors are always set to the theme-defaults, this has other issues: > >Rigger: has "unify" disabled, so carefully chooses all the bone colors. >Animator A: also has "unify" disabled, so sees all the bone colors as the rigger intended. >Animator B: has "unify" enabled, and sees the unified select/active colors. Now they save the file, and Blender resets all the custom >bone colors to their theme. >Animator A: continues working on the file, but now sees the theme colors of Animator B instead of the rigger-chosen colors or even >their own theme colors. >This would mean that the theme of one user affects the colors seen by another user. This to me is not the right way to go. what I was proposing (without knowing if it is easy, difficult, possible or not) is that when unified color is on, the colors are dynamically shown as the blender theme sets it. They are not wrote in to the color itself either on file open or file save. Blender should override whatever the custom color was by displaying the theme's unified colors on load. If the rigger sets a custom color it stays in the file, just the user with unified option on will not see unless he disables the unification. This can also be triggered by the rigger's ui with a toggle pointing to the preference. This is imo a customization overkill. The whole point of the proposal is to make blender act in a predictable way. Hyper-customization goes in to the opposite direction. I would agree with @Mets on this: > I wouldn't stress so much about allowing animators to see a rig the way that the rigger intended. If they want to do that, just leave your theme colors alone. If the rigger really wants to not allow that customizability, they can use custom colors. But it's not the rigger's responsibility to police the animators' theme settings. If a user breaks their Blender theme, that's their choice and their problem. and this point to what I had probably not expressed that well here: >The cases you want to customize blender settings are considered but not defined as how blender is supposed to work by default. >>What does this mean, exactly? i was trying to say that the "Defaults" are created to define how a software is supposed to work by design. Customization is optional and is supported, but usually when you customize you do it at your own risk. So imo we should care more for what we pick as default against what the user is able to mess up by customizing.
Sybren A. Stüvel commented 2023-10-09 11:47:36 +02:00
Member
Copy Link

what I was proposing (without knowing if it is easy, difficult, possible or not) is that when unified color is on, the colors are dynamically shown as the blender theme sets it.

This to me was clear.

They are not wrote in to the color itself either on file open or file save.

👍 so that means my first example applies. I'll repeat that again below to avoid having to do too many lookups to earlier comments ;-)

Blender should override whatever the custom color was by displaying the theme's unified colors on load. If the rigger sets a custom color it stays in the file, just the user with unified option on will not see unless he disables the unification. This can also be triggered by the rigger's ui with a toggle pointing to the preference.

And this is where things get iffy IMO when it comes to the custom colors (so not customisation of the theme, but setting custom colors on the bones). This situation I think still applies:

  • Rigger: has "unify" enabled, so no way to set the selected/active color of the bones. Creates a rig & changes bone colors.
  • Animator: has "unify" disabled, and will see whatever the bone's custom selected/active color have been set to. This may be a mess, because the rigger did not set those.

Note that here "rigger" and "animator" are just terms for "the creator of the rig" and "the user of the rig". Within a studio one could argue they should just work together. But this also reflects on rigs that are offered to others on the Blender Studio site, Blendswap, and I'm sure plenty of other places.

This is imo a customization overkill. The whole point of the proposal is to make blender act in a predictable way. Hyper-customization goes in to the opposite direction.

I don't understand. Wasn't this "unified select/active wireframe color" switch your proposal?

> what I was proposing (without knowing if it is easy, difficult, possible or not) is that when unified color is on, the colors are dynamically shown as the blender theme sets it. This to me was clear. > They are not wrote in to the color itself either on file open or file save. :+1: so that means my first example applies. I'll repeat that again below to avoid having to do too many lookups to earlier comments ;-) > Blender should override whatever the custom color was by displaying the theme's unified colors on load. If the rigger sets a custom color it stays in the file, just the user with unified option on will not see unless he disables the unification. This can also be triggered by the rigger's ui with a toggle pointing to the preference. And this is where things get iffy IMO when it comes to the custom colors (so not customisation of the theme, but setting custom colors on the bones). This situation I think still applies: - Rigger: has **"unify" enabled**, so no way to set the selected/active color of the bones. Creates a rig & changes bone colors. - Animator: has **"unify" disabled**, and will see whatever the bone's custom selected/active color have been set to. This may be a mess, because the rigger did not set those. Note that here "rigger" and "animator" are just terms for "the creator of the rig" and "the user of the rig". Within a studio one could argue they should just work together. But this also reflects on rigs that are offered to others on the Blender Studio site, Blendswap, and I'm sure plenty of other places. > This is imo a customization overkill. The whole point of the proposal is to make blender act in a predictable way. Hyper-customization goes in to the opposite direction. I don't understand. Wasn't this "unified select/active wireframe color" switch your proposal?
Ivan Cappiello commented 2023-10-09 15:54:11 +02:00
Author
Member
Copy Link

• Rigger: has "unify" enabled, so no way to set the selected/active color of the bones. Creates a rig & changes bone colors.
• Animator: has "unify" disabled, and will see whatever the bone's custom selected/active color have been set to. This may be a mess, because the rigger did not set those.

Note that here "rigger" and "animator" are just terms for "the creator of the rig" and "the user of the rig". Within a studio one could argue they should just work together.

Yes! and also the studios has guidelines for that, blender supports a startup file (which can define if or not use the unified colors), or people can go form a desk to another saying "please disable color unification". Shouldn't the discussion be more focused on how we'd like to make it work?

A rigger (just a common definition for the one that has made the rig, that may or may not be the one using it - c'mon Dr. you are making it very hard to talk) may add a warning and a button in the rig ui if he/him-she/her wants the animator (just a common definition for the one that has to use the rig which may or may not be the one who has rigged it) to explicitly use his scheme.

I don't understand. Wasn't this "unified select/active wireframe color" switch your proposal?

yes. the whole point is we should decide if blender should (or should not) use unified colors. If answer is yes, we probably should accept that there will be some workflows not automatically working anymore.

> • Rigger: has "unify" enabled, so no way to set the selected/active color of the bones. Creates a rig & changes bone colors. > • Animator: has "unify" disabled, and will see whatever the bone's custom selected/active color have been set to. This may be a mess, because the rigger did not set those. > Note that here "rigger" and "animator" are just terms for "the creator of the rig" and "the user of the rig". Within a studio one could argue they should just work together. Yes! and also the studios has guidelines for that, blender supports a startup file (which can define if or not use the unified colors), or people can go form a desk to another saying "please disable color unification". Shouldn't the discussion be more focused on how we'd like to make it work? A rigger (just a common definition for the one that has made the rig, that may or may not be the one using it - c'mon Dr. you are making it very hard to talk) may add a warning and a button in the rig ui if he/him-she/her wants the animator (just a common definition for the one that has to use the rig which may or may not be the one who has rigged it) to explicitly use his scheme. >I don't understand. Wasn't this "unified select/active wireframe color" switch your proposal? yes. the whole point is we should decide if blender should (or should not) use unified colors. If answer is yes, we probably should accept that there will be some workflows not automatically working anymore.
Sybren A. Stüvel commented 2023-10-09 17:24:35 +02:00
Member
Copy Link

Yes! and also the studios has guidelines for that, blender supports a startup file (which can define if or not use the unified colors), or people can go form a desk to another saying "please disable color unification". Shouldn't the discussion be more focused on how we'd like to make it work?

You're missing my point: there are way more situations in which people use Blender, where they can't just walk over & talk with each other.

A rigger [...] may add a warning and a button in the rig ui if he/him-she/her wants the animator [...] to explicitly use his scheme.

When it comes to preferences, those should be kept literally for personal preferences. One user shouldn't dictate which preferences the other user should have. As I said before, for a studio it's up to them, but for individual Blender users it's different. Also I suspect that having this setting as a per-rig thing will create a messy situation, where two rigs in the same scene behave differently.

So all in all I feel this "unified colors" approach should not be optional. Either we do it, or we don't. If we do, it's a Blender 5.0 thing, which is fine.

> Yes! and also the studios has guidelines for that, blender supports a startup file (which can define if or not use the unified colors), or people can go form a desk to another saying "please disable color unification". Shouldn't the discussion be more focused on how we'd like to make it work? You're missing my point: there are way more situations in which people use Blender, where they can't just walk over & talk with each other. > A rigger [...] may add a warning and a button in the rig ui if he/him-she/her wants the animator [...] to explicitly use his scheme. When it comes to preferences, those should be kept literally for personal preferences. One user shouldn't dictate which preferences the other user should have. As I said before, for a studio it's up to them, but for individual Blender users it's different. Also I suspect that having this setting as a per-rig thing will create a messy situation, where two rigs in the same scene behave differently. So all in all I feel this "unified colors" approach should not be optional. Either we do it, or we don't. If we do, it's a Blender 5.0 thing, which is fine.
Alexander Gavrilov commented 2023-10-09 17:50:07 +02:00
Member
Copy Link

So all in all I feel this "unified colors" approach should not be optional. Either we do it, or we don't. If we do, it's a Blender 5.0 thing, which is fine.

It could potentially still be optional in the preferences, like a simple checkbox to synchronize all of the presets to the default active/selected colors. That would be less of a compatibility concern, and could even be hacked via just an operator button that sets all those colors to the common default ones.

> So all in all I feel this "unified colors" approach should not be optional. Either we do it, or we don't. If we do, it's a Blender 5.0 thing, which is fine. It could potentially still be optional in the preferences, like a simple checkbox to synchronize all of the presets to the default active/selected colors. That would be less of a compatibility concern, and could even be hacked via just an operator button that sets all those colors to the common default ones.
Demeter Dzadik commented 2023-10-19 15:55:25 +02:00
Member
Copy Link

So, AFAIK this task was discussed by the module. It was decided to delay New Bone Color Presets to 4.1 so it can be tackled together with this task. My understanding is also that this would get taken over by the core Anim Module dev team.

Rephrasing the meeting notes:

  • Add a "Colorize Bone Selection" userpref option, off by default, making the proposed unified select/active colors the default behaviour.
  • Selected/active bones' wire color is no longer affected by bone color, until that option is turned on.
  • When turned on, use a clever offset to come up with selection/active colors similar to what were in the New Bone Colors Presets proposal.
  • This allows reducing bone colors (theme & custom) to a single color of customizability.
  • Remove the hard-coded -50 value offset in base colors so that WYSIWYG.
  • Add theme options for edit bone selection colors, instead of hijacking mesh edit theme colors.
  • Versioning: Can map old bone colors to similar colors of the new presets. (Not relevant for Custom Colors.)

I wonder if a new task should be started by the dev(s) who want to tackle these tasks, now that everyone got a chance to make their voices heard and the design seems more or less agreed upon? And then this and the other task could both be closed.

So, AFAIK this task was [discussed](https://devtalk.blender.org/t/2023-10-17-animation-rigging-module-meeting/31647) by the module. It was decided to delay [New Bone Color Presets](https://projects.blender.org/blender/blender/issues/112635) to 4.1 so it can be tackled together with this task. My understanding is also that this would get taken over by the core Anim Module dev team. Rephrasing the meeting notes: - Add a "Colorize Bone Selection" userpref option, off by default, making the proposed unified select/active colors the default behaviour. - Selected/active bones' wire color is no longer affected by bone color, until that option is turned on. - When turned on, use a clever offset to come up with selection/active colors similar to what were in the New Bone Colors Presets proposal. - This allows reducing bone colors (theme & custom) to a single color of customizability. - Remove the hard-coded -50 value offset in base colors so that WYSIWYG. - Add theme options for edit bone selection colors, [instead of hijacking mesh edit theme colors](https://projects.blender.org/blender/blender/issues/110874#issuecomment-1038531). - Versioning: Can map old bone colors to similar colors of the new presets. (Not relevant for Custom Colors.) I wonder if a new task should be started by the dev(s) who want to tackle these tasks, now that everyone got a chance to make their voices heard and the design seems more or less agreed upon? And then this and the other task could both be closed.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
main
brush-assets-project
universal-scene-description
fix-121021
blender-v4.1-release
blender-v3.3-release
blender-v3.6-release
blender-v3.6-temp_wmoss_animrig_public
temp-sculpt-dyntopo
gpencil-next
anim/animation-id-113594
blender-v4.0-release
blender-projects-basics
bridge-curves
sculpt-blender
asset-browser-frontend-split
asset-shelf
tmp-usd-python-mtl
tmp-usd-3.6
blender-v3.5-release
blender-v2.93-release
realtime-clock
sculpt-dev
bevelv2
xr-dev
v4.1.1
v3.6.11
v3.3.18
v4.1.0
v3.3.17
v3.6.10
v3.6.9
v3.3.16
v3.6.8
v3.6.7
v3.3.14
v4.0.2
v4.0.1
v4.0.0
v3.6.5
v3.3.12
v3.6.4
v3.6.3
v3.3.11
v3.6.2
v3.3.10
v3.6.1
v3.3.9
v3.6.0
v3.3.8
v3.3.7
v2.93.18
v3.5.1
v3.3.6
v2.93.17
v3.5.0
v2.93.16
v3.3.5
v3.3.4
v2.93.15
v2.93.14
v3.3.3
v2.93.13
v2.93.12
v3.4.1
v3.3.2
v3.4.0
v3.3.1
v2.93.11
v3.3.0
v3.2.2
v2.93.10
v3.2.1
v3.2.0
v2.83.20
v2.93.9
v3.1.2
v3.1.1
v3.1.0
v2.83.19
v2.93.8
v3.0.1
v2.93.7
v3.0.0
v2.93.6
v2.93.5
v2.83.18
v2.93.4
v2.93.3
v2.83.17
v2.93.2
v2.93.1
v2.83.16
v2.93.0
v2.83.15
v2.83.14
v2.83.13
v2.92.0
v2.83.12
v2.91.2
v2.83.10
v2.91.0
v2.83.9
v2.83.8
v2.83.7
v2.90.1
v2.83.6.1
v2.83.6
v2.90.0
v2.83.5
v2.83.4
v2.83.3
v2.83.2
v2.83.1
v2.83
v2.82a
v2.82
v2.81a
v2.81
v2.80
v2.80-rc3
v2.80-rc2
v2.80-rc1
v2.79b
v2.79a
v2.79
v2.79-rc2
v2.79-rc1
v2.78c
v2.78b
v2.78a
v2.78
v2.78-rc2
v2.78-rc1
v2.77a
v2.77
v2.77-rc2
v2.77-rc1
v2.76b
v2.76a
v2.76
v2.76-rc3
v2.76-rc2
v2.76-rc1
v2.75a
v2.75
v2.75-rc2
v2.75-rc1
v2.74
v2.74-rc4
v2.74-rc3
v2.74-rc2
v2.74-rc1
v2.73a
v2.73
v2.73-rc1
v2.72b
2.72b
v2.72a
v2.72
v2.72-rc1
v2.71
v2.71-rc2
v2.71-rc1
v2.70a
v2.70
v2.70-rc2
v2.70-rc
v2.69
v2.68a
v2.68
v2.67b
v2.67a
v2.67
v2.66a
v2.66
v2.65a
v2.65
v2.64a
v2.64
v2.63a
v2.63
v2.61
v2.60a
v2.60
v2.59
v2.58a
v2.58
v2.57b
v2.57a
v2.57
v2.56a
v2.56
v2.55
v2.54
v2.53
v2.52
v2.51
v2.50
v2.49b
v2.49a
v2.49
v2.48a
v2.48
v2.47
v2.46
v2.45
v2.44
v2.43
v2.42a
v2.42
v2.41
v2.40
v2.37a
v2.37
v2.36
v2.35a
v2.35
v2.34
v2.33a
v2.33
v2.32
v2.31a
v2.31
v2.30
v2.28c
v2.28a
v2.28
v2.27
v2.26
v2.25
Labels
Clear labels   
Interest
Alembic

  
Interest
Animation & Rigging

  
Interest
Asset Browser

  
Interest
Asset Browser Project Overview

  
Interest
Audio

  
Interest
Automated Testing

  
Interest
Blender Asset Bundle

  
Interest
BlendFile

  
Interest
Collada

  
Interest
Compatibility
This issue affects/is about backward or forward compatibility

  
Interest
Compositing

  
Interest
Core

  
Interest
Cycles

  
Interest
Dependency Graph

  
Interest
Development Management

  
Interest
EEVEE

  
Interest
EEVEE & Viewport

  
Interest
Freestyle

  
Interest
Geometry Nodes

  
Interest
Grease Pencil

  
Interest
ID Management

  
Interest
Images & Movies

  
Interest
Import Export

  
Interest
Line Art

  
Interest
Masking

  
Interest
Metal

  
Interest
Modeling

  
Interest
Modifiers

  
Interest
Motion Tracking

  
Interest
Nodes & Physics

  
Interest
OpenGL

  
Interest
Overlay

  
Interest
Overrides

  
Interest
Performance

  
Interest
Physics

  
Interest
Pipeline, Assets & IO

  
Interest
Platforms, Builds & Tests

  
Interest
Python API

  
Interest
Render & Cycles

  
Interest
Render Pipeline

  
Interest
Sculpt, Paint & Texture

  
Interest
Text Editor

  
Interest
Translations

  
Interest
Triaging

  
Interest
Undo

  
Interest
USD

  
Interest
User Interface

  
Interest
UV Editing

  
Interest
VFX & Video

  
Interest
Video Sequencer

  
Interest
Virtual Reality

  
Interest
Vulkan

  
Interest
Wayland
Issues relating to Wayland windowing support.

  
Interest
Workbench

  
Interest: X11

Issues relating to Xorg/X11 support.

  
Legacy
Blender 2.8 Project

  
Legacy
Milestone 1: Basic, Local Asset Browser

  
Legacy
OpenGL Error

  
Meta
Good First Issue

  
Meta
Papercut

  
Meta
Retrospective

  
Meta
Security
Issues relating to security: https://wiki.blender.org/wiki/Process/Vulnerability_Reports

  
Module
Animation & Rigging

  
Module
Core

  
Module
Development Management

  
Module
EEVEE & Viewport

  
Module
Grease Pencil

  
Module
Modeling

  
Module
Nodes & Physics

  
Module
Pipeline, Assets & IO

  
Module
Platforms, Builds & Tests

  
Module
Python API

  
Module
Render & Cycles

  
Module
Sculpt, Paint & Texture

  
Module
Triaging

  
Module
User Interface

  
Module
VFX & Video

  
Platform
FreeBSD

  
Platform
Linux

  
Platform
macOS

  
Platform
Windows

  
Priority
High

  
Priority
Low

  
Priority
Normal

  
Priority
Unbreak Now!

  
Status
Archived

  
Status
Confirmed

  
Status
Duplicate

  
Status
Needs Info from Developers

  
Status
Needs Information from User

  
Status
Needs Triage

  
Status
Resolved

  
Type
Bug

  
Type
Design

  
Type
Known Issue

  
Type
Patch

  
Type
Report

  
Type
To Do

No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Animation & Rigging
Assignees
Clear assignees
No Assignees
6 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#112943
No description provided.
Delete Branch "%!s(<nil>)"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?