Proposal: New Bone Color Presets #112635

New Issue

Closed

opened 2023-09-20 19:07:07 +02:00 by Demeter Dzadik · 25 comments

Demeter Dzadik commented 2023-09-20 19:07:07 +02:00

Member

Copy Link

Comparisons

	Edge Shapes Deselected	Edge Shapes Selected	Polygon Shapes Deselected	Polygon Shapes Selected	Theme UI
Old
New v2
New v3

Test it out!

You can simply download and open this file to test out the proposed presets.

Intro

Most rigs are forced to use Custom Colors very often, because not enough of the preset colors feel nice to use. This is a shame, because Custom Colors cannot be customized on a user-level, via the theme settings. I think if the Preset Colors were better, Custom Colors wouldn't even be necessary; The 20 slots that we have are plenty enough to cover the entire color wheel with distinct enough colors. At that point, even if you wanted to add a custom color, you'd be hard pressed to find a color that isn't very similar to one of the presets.

Issues with current bone color presets:

• Slots 16-20 are blank, immediately not useful.
• Most colors are too dark, and do not contrast well against Blender's default viewport background color, which is a dark gray in the case of all shipped themes.

The colors in this proposal:

• Base colors are much brighter.
• Base colors were eyeballed to feel equally bright, and equally contrasting against the default viewport background color.
• Selected color was calculated as a luma offset using fancy maths, then manually adjusted here and there to again, feel like they all have the same brightness.
• Active color was done in a really dumb way by just setting the saturation to 0.1. I think this works really well tbh. If it's stupid and it works, it ain't stupid!
• Colors are spread out fairly evenly across the color wheel, while giving maximum effort to make neighbouring colors as distinct as possible.
• Themes tend to deviate very little in their 3D view background color, and if they do, they are darker, which is even better. For that reason, these colors work fine for all themes.
• Presets have been sorted by hue. This may make old rigs that used presets look quite different than they used to. This was agreed upon without objections at this module meeting, since not many rigs today use the existing presets anyways, as mentioned in the intro. The benefit of sorting them by hue is that users don't get caught off guard when assigning 2 presets far from each other in the list, only to find that they are not that distinct from each other.

Base PR
Add-ons repo PR

## Comparisons | | Edge Shapes Deselected | Edge Shapes Selected | Polygon Shapes Deselected| Polygon Shapes Selected | Theme UI | |---|---|---|---|---|---| | Old |  |  |  |  |  | | New v2 |  |  |  |  |  | | New v3 |  |  |  |  |  | ## Test it out! You can simply download and open [this file](/attachments/f4be24e7-4067-4c79-a209-3aba28a4752e) to test out the proposed presets. ### Intro Most rigs are forced to use Custom Colors very often, because not enough of the preset colors feel nice to use. This is a shame, because Custom Colors cannot be customized on a user-level, via the theme settings. I think if the Preset Colors were better, Custom Colors wouldn't even be necessary; The 20 slots that we have are plenty enough to cover the entire color wheel with distinct enough colors. At that point, even if you wanted to add a custom color, you'd be hard pressed to find a color that isn't very similar to one of the presets. ### Issues with current bone color presets: - Slots 16-20 are blank, immediately not useful. - Most colors are too dark, and do not contrast well against Blender's default viewport background color, which is a dark gray in the case of all shipped themes. ### The colors in this proposal: - Base colors are much brighter. - Base colors were eyeballed to feel equally bright, and equally contrasting against the default viewport background color. - Selected color was calculated as a luma offset using fancy maths, then manually adjusted here and there to again, feel like they all have the same brightness. - Active color was done in a really dumb way by just setting the saturation to 0.1. I think this works really well tbh. If it's stupid and it works, it ain't stupid! - Colors are spread out fairly evenly across the color wheel, while giving maximum effort to make neighbouring colors as distinct as possible. - Themes tend to deviate very little in their 3D view background color, and if they do, they are darker, which is even better. For that reason, these colors work fine for all themes. - Presets have been sorted by hue. This may make old rigs that used presets look quite different than they used to. This was agreed upon without objections at [this module meeting](https://devtalk.blender.org/t/2023-10-05-animation-rigging-module-meeting/31420), since not many rigs today use the existing presets anyways, as mentioned in the intro. The benefit of sorting them by hue is that users don't get caught off guard when assigning 2 presets far from each other in the list, only to find that they are not that distinct from each other. [Base PR](https://projects.blender.org/blender/blender/pulls/112639) [Add-ons repo PR](https://projects.blender.org/blender/blender-addons/pulls/104905)

image.png

201 KiB

image.png

185 KiB

image.png

182 KiB

image.png

665 KiB

image.png

226 KiB

new_bone_colors_v3.blend

879 KiB

new_bone_colors_v2.blend

825 KiB

image.png

227 KiB

image.png

202 KiB

image.png

233 KiB

image.png

213 KiB

image.png

232 KiB

image.png

667 KiB

image.png

442 KiB

image.png

208 KiB

image.png

203 KiB

image.png

202 KiB

image.png

234 KiB

image.png

212 KiB

image.png

240 KiB

image.png

644 KiB

image.png

232 KiB

image.png

239 KiB

image.png

206 KiB

image.png

646 KiB

❤️ 1

Demeter Dzadik added the

Type

Design

label 2023-09-20 19:07:07 +02:00

Demeter Dzadik added this to the Animation & Rigging project 2023-09-20 19:07:13 +02:00

Demeter Dzadik added the

Interest

Animation & Rigging

label 2023-09-20 19:07:23 +02:00

Demeter Dzadik referenced this issue from a commit 2023-09-20 20:35:26 +02:00

New bone color presets

Demeter Dzadik referenced this issue 2023-09-20 20:36:44 +02:00

New bone color presets #112639

Nathan Vegdahl commented 2023-09-21 11:06:14 +02:00

Member

Copy Link

This definitely looks better! We also recently discussed the visual confusion of custom bone colors at a recent module meeting:
https://devtalk.blender.org/t/2023-08-31-animation-rigging-module-meeting/30914#patch-review-decision-time-5 (see the second top-level bullet under the linked section)

Ivan proposed only customizing the unselected color, while leaving the selected and active colors as default, to make those states always unambiguous. We agreed at the meeting that this is probably a good idea, and Ivan is working on a fuller proposal.

There was also some discussion about solid-shaded rig controls, which apparently introduce their own confusion.

Regardless, I think your work here is still relevant, because even the unselected colors were a mess, and this is a big improvement.

Something else I think we should explore is optimizing the order of the color presets, to put the most mutually-distinct presets first. For example, right now the first two presets are red and orange, which isn't optimal. Whereas if we order them for distinctness, then users can relatively mindlessly just start at the beginning of the list, and regardless of how many presets they use they can be confident they have the most distinct presets at that count.

This definitely looks better! We also recently discussed the visual confusion of custom bone colors at a recent module meeting: https://devtalk.blender.org/t/2023-08-31-animation-rigging-module-meeting/30914#patch-review-decision-time-5 (see the second top-level bullet under the linked section) Ivan proposed only customizing the *unselected* color, while leaving the selected and active colors as default, to make those states always unambiguous. We agreed at the meeting that this is probably a good idea, and Ivan is working on a fuller proposal. There was also some discussion about solid-shaded rig controls, which apparently introduce their own confusion. Regardless, I think your work here is still relevant, because even the unselected colors were a mess, and this is a big improvement. Something else I think we should explore is optimizing the *order* of the color presets, to put the most mutually-distinct presets first. For example, right now the first two presets are red and orange, which isn't optimal. Whereas if we order them for distinctness, then users can relatively mindlessly just start at the beginning of the list, and regardless of how many presets they use they can be confident they have the most distinct presets at that count.

Sybren A. Stüvel commented 2023-09-21 11:49:26 +02:00

Member

Copy Link

With regards to the proposal of @icappiello, it's clear from @Mets 's proposal:

that the relationship between "regular" and "selected"/"active" can differ quite wildly. Especially when the "regular" colour is very dark (which can be super useful for certain "don't touch these" bones), they should still stand out while selected. This seems to suggest that the "selected" and "active" brightnesses should be somewhat fixed values, while the hue & saturation can change. I'm curious what you come up with, Ivan!

With regards to the proposal of @icappiello, it's clear from @Mets 's proposal:  that the relationship between "regular" and "selected"/"active" can differ quite wildly. Especially when the "regular" colour is very dark (which can be super useful for certain "don't touch these" bones), they should still stand out while selected. This seems to suggest that the "selected" and "active" brightnesses should be somewhat fixed values, while the hue & saturation can change. I'm curious what you come up with, Ivan!

Ivan Cappiello commented 2023-09-21 12:23:55 +02:00

Member

Copy Link

@dr.sybren, @Mets proposal lgtm. To be clear i am working on a different thing as long as i can see.
I were suggesting to change the actual behavuour of active/selected by unifying those in the preferences instead of having to explicitly choose one for each theme.
The customization of selected/active per theme should instead be explicitly enabled by the user in the bone groups ui panel.
Menaning reversing what rigify bone groups do right now (setting an unified color for active/selected picking it from blender general ui theme setting)

@dr.sybren, @Mets proposal lgtm. To be clear i am working on a different thing as long as i can see. I were suggesting to change the actual behavuour of active/selected by unifying those in the preferences instead of having to explicitly choose one for each theme. The customization of selected/active per theme should instead be explicitly enabled by the user in the bone groups ui panel. Menaning reversing what rigify bone groups do right now (setting an unified color for active/selected picking it from blender general ui theme setting)

Demeter Dzadik commented 2023-09-21 15:24:45 +02:00

Author

Member

Copy Link

While unifying selected/active colors across all presets would make things a lot easier, I actually don't like it. I think it's because I'm lazy and my rigs' bone shapes are not very distinct, so I rely on colors more to visually categorize bones. Therefore, if those colors disappear when many bones are selected, I'm not happy.
But to have an option for that makes perfect sense, and I don't even mind if it's on by default. I would just turn it off for myself, I won't cry about it.

optimizing the order of the color presets, to put the most mutually-distinct presets first

This has the downside where you might apply preset 03 and 12 to some bones because they look pretty distinct in this list of colors where the hue is jumping all over the place, but when put next to each other, they are actually quite similar, so you might end up assigning similar colors to two sets of bones unintentionally. So, if we were to sort, I would actually sort by hue.

But the issue with any kind of sorting is that any old rigs that used the presets would look completely different then. With the current proposal, they would only look... a lot brighter. :D

Still, I do think if we're willing to piss off a few people, hue sorting would be better UX long-term.

While unifying selected/active colors across all presets would make things a lot easier, I actually don't like it. I think it's because I'm lazy and my rigs' bone shapes are not very distinct, so I rely on colors more to visually categorize bones. Therefore, if those colors disappear when many bones are selected, I'm not happy. But to have an option for that makes perfect sense, and I don't even mind if it's on by default. I would just turn it off for myself, I won't cry about it. > optimizing the order of the color presets, to put the most mutually-distinct presets first This has the downside where you might apply preset 03 and 12 to some bones because they look pretty distinct in this list of colors where the hue is jumping all over the place, but when put next to each other, they are actually quite similar, so you might end up assigning similar colors to two sets of bones unintentionally. So, if we were to sort, I would actually sort by hue. But the issue with any kind of sorting is that any old rigs that used the presets would look completely different then. With the current proposal, they would only look... a lot brighter. :D Still, I do think if we're willing to piss off a few people, hue sorting would be better UX long-term.

Ivan Cappiello referenced this issue 2023-09-27 09:58:05 +02:00

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

Alexander Gavrilov commented 2023-09-27 12:13:34 +02:00

Member

Copy Link

Regarding the use of brightness for selection: is it possible to ensure the colors have exactly the same visual brightness? And not in just the max channel values, but what you actually see on the screen, i.e. compensate for any effects where certain colors appear brighter than the others.

Regarding the use of brightness for selection: is it possible to ensure the colors have exactly the same visual brightness? And not in just the max channel values, but what you actually see on the screen, i.e. compensate for any effects where certain colors appear brighter than the others.

Ivan Cappiello commented 2023-09-27 12:30:23 +02:00

Member

Copy Link

Regarding the use of brightness for selection: is it possible to ensure the colors have exactly the same visual brightness? And not in just the max channel values, but what you actually see on the screen, i.e. compensate for any effects where certain colors appear brighter than the others.

this would be a nice improvement, but do you already know how to do it?

> Regarding the use of brightness for selection: is it possible to ensure the colors have exactly the same visual brightness? And not in just the max channel values, but what you actually see on the screen, i.e. compensate for any effects where certain colors appear brighter than the others. this would be a nice improvement, but do you already know how to do it?

Alexander Gavrilov commented 2023-09-27 15:35:02 +02:00

Member

Copy Link

this would be a nice improvement, but do you already know how to do it?

Well, I expect you need to adjust the color to target a specific luminance without affecting hue, and minimally affecting saturation (unlike value, increasing luminance past a certain point requires desaturation, e.g. luminance 1 is only achievable with pure white). The questions would be:

• Where to get the target luminance (use the 'default' selected and active colors maybe?)
• What specifically to do with saturation if decreasing luminance - should it increase saturation in any circumstances, or preserve existing?

> this would be a nice improvement, but do you already know how to do it? Well, I expect you need to adjust the color to target a specific luminance without affecting hue, and minimally affecting saturation (unlike value, increasing luminance past a certain point requires desaturation, e.g. luminance 1 is only achievable with pure white). The questions would be: * Where to get the target luminance (use the 'default' selected and active colors maybe?) * What specifically to do with saturation if decreasing luminance - should it increase saturation in any circumstances, or preserve existing?

Demeter Dzadik commented 2023-09-27 17:06:48 +02:00

Author

Member

Copy Link

I don't think reducing saturation for the selected/active colors is a problem. Maybe using a luminance offset for selection states would work, but do note that in order to find 20 unique enough base colors, some of those base colors might be desaturated in the first place, or even be black and white.

In any case, there's a handy .blend file attached in the post where you can try to experiment with stuff by looping over the theme preset colors and applying some maths based on to the base color of each preset. I'm not sure if there are native functions for setting luminance, but maybe. There's also the PR, which if you apply and then reload factory settings, you'll get the colors that I came up with, if you want to use that as a starting poing.

I don't think reducing saturation for the selected/active colors is a problem. Maybe using a luminance offset for selection states would work, but do note that in order to find 20 unique enough base colors, some of those base colors might be desaturated in the first place, or even be black and white. In any case, there's a handy .blend file attached in the post where you can try to experiment with stuff by looping over the theme preset colors and applying some maths based on to the base color of each preset. I'm not sure if there are native functions for setting luminance, but maybe. There's also the PR, which if you apply and then reload factory settings, you'll get the colors that I came up with, if you want to use that as a starting poing.

Alexander Gavrilov commented 2023-09-27 18:27:15 +02:00

Member

Copy Link

In any case, there's a handy .blend file attached in the post where you can try to experiment with stuff by looping over the theme preset colors and applying some maths based on to the base color of each preset.

Well, here is a file where I added luminance unification to your script, using the default selected and active colors as the reference. It basically scales the color until any component reaches 1, and then mixes in white (desaturates) if that was not enough to reach the goal.

P.S. I also noticed that when the bones are drawn, 50 is subtracted from the Normal color, so the color in the settings does not reflect the actual appearance...

> In any case, there's a handy .blend file attached in the post where you can try to experiment with stuff by looping over the theme preset colors and applying some maths based on to the base color of each preset. Well, here is a file where I added luminance unification to your script, using the default selected and active colors as the reference. It basically scales the color until any component reaches 1, and then mixes in white (desaturates) if that was not enough to reach the goal. P.S. I also noticed that when the bones are drawn, 50 is subtracted from the Normal color, so the color in the settings does not reflect the actual appearance...

bone_colors1.blend

875 KiB

Sybren A. Stüvel commented 2023-09-28 14:48:47 +02:00

Member

Copy Link

Well, here is a file where I added luminance unification to your script, using the default selected and active colors as the reference. It basically scales the color until any component reaches 1, and then mixes in white (desaturates) if that was not enough to reach the goal.

With so much color science going on, I feel that this is not something that should be addressed/implemented for bone colors alone. If we want to have some calculation of the preceived brighness of a color, and a function to scale to a given brightness, I'm sure there are papers that talk about this. It's not going to be easy though, because "perceived brightness" is heavily influenced by the surrounding colors. But I'm sure that there's something out there that can at least normalise a color based on the average sensitivity of the eye.

> Well, here is a file where I added luminance unification to your script, using the default selected and active colors as the reference. It basically scales the color until any component reaches 1, and then mixes in white (desaturates) if that was not enough to reach the goal. With *so* much color science going on, I feel that this is not something that should be addressed/implemented for bone colors alone. If we want to have some calculation of the preceived brighness of a color, and a function to scale to a given brightness, I'm sure there are papers that talk about this. It's not going to be easy though, because "perceived brightness" is heavily influenced by the surrounding colors. But I'm sure that there's something out there that can at least normalise a color based on the average sensitivity of the eye.

Demeter Dzadik commented 2023-09-28 15:49:10 +02:00

Author

Member

Copy Link

I also noticed that when the bones are drawn, 50 is subtracted from the Normal color, so the color in the settings does not reflect the actual appearance

Holy shit, you're right. This is huge, and it's weird! This means that the selected and normal colors of the presets can be set to the same colors, and this hard-coded value reduction in the normal color will still allow the selection state to be very clear. Wow, that is such a strange decision in the code... I'm surprised I didn't catch that, but I'm glad you did!

luminance unification

I think it's working pretty well! I could see this being a viable way to go for cutting down bone color settings from 3 to 1!

What I think would be great at some point in the future then, is to remove that hard-coded value reduction from the base color, implement your luminosity based selection state indication, and provide 20 nice and distinct presets for the just the base color, while removing the customization of selected and active colors.

But I'm afraid this might be a bit too much for me and my coding skills, so what I will probably do that is within my power, is to update the proposal and the PRs to just use your luminosity-based color logic with the existing 3-color system that we have. And then that can still be the baseline for further development, if somebody more skilled wants to tackle that in future.

> I also noticed that when the bones are drawn, 50 is subtracted from the Normal color, so the color in the settings does not reflect the actual appearance Holy shit, you're right. This is huge, and it's weird! This means that the selected and normal colors of the presets can be set to the same colors, and this hard-coded value reduction in the normal color will still allow the selection state to be very clear. Wow, that is such a strange decision in the code... I'm surprised I didn't catch that, but I'm glad you did! > luminance unification I think it's working pretty well! I could see this being a viable way to go for cutting down bone color settings from 3 to 1! What I think would be great at some point in the future then, is to remove that hard-coded value reduction from the base color, implement your luminosity based selection state indication, and provide 20 nice and distinct presets for the just the base color, while removing the customization of selected and active colors. But I'm afraid this might be a bit too much for me and my coding skills, so what I will probably do that is within my power, is to update the proposal and the PRs to just use your luminosity-based color logic with the existing 3-color system that we have. And then that can still be the baseline for further development, if somebody more skilled wants to tackle that in future.

Alexander Gavrilov commented 2023-09-28 17:59:39 +02:00

Member

Copy Link

With so much color science going on, I feel that this is not something that should be addressed/implemented for bone colors alone. If we want to have some calculation of the preceived brighness of a color, and a function to scale to a given brightness, I'm sure there are papers that talk about this. It's not going to be easy though, because "perceived brightness" is heavily influenced by the surrounding colors. But I'm sure that there's something out there that can at least normalise a color based on the average sensitivity of the eye.

I used luminance, which is a standard thing and computed as basically a weighted average of the channel values based on perceptual statistics. The only trick I figured out myself (by looking at how HSV works) is how to adjust the luminance of a color without changing its hue.

> With *so* much color science going on, I feel that this is not something that should be addressed/implemented for bone colors alone. If we want to have some calculation of the preceived brighness of a color, and a function to scale to a given brightness, I'm sure there are papers that talk about this. It's not going to be easy though, because "perceived brightness" is heavily influenced by the surrounding colors. But I'm sure that there's something out there that can at least normalise a color based on the average sensitivity of the eye. I used luminance, which is a standard thing and computed as basically a weighted average of the channel values based on perceptual statistics. The only trick I figured out myself (by looking at how HSV works) is how to adjust the luminance of a color without changing its hue.

Demeter Dzadik referenced this issue 2023-10-04 12:13:56 +02:00

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

Demeter Dzadik commented 2023-10-04 13:12:43 +02:00

Author

Member

Copy Link

The proposal now uses Alexander's luminance math!

I updated the screenshots, added a note about and a link to the "Unify Selected/Active" behaviour task.

Most importantly, I updated the .blend file such that anybody can just download and open it to see the proposed colors on their end.

The proposal now uses Alexander's luminance math! I updated the screenshots, added a note about and a link to the "Unify Selected/Active" behaviour task. Most importantly, I updated the .blend file such that anybody can just download and open it to see the proposed colors on their end.

Nathan Vegdahl commented 2023-10-05 11:27:00 +02:00

Member

Copy Link

I played around with the new blend file, and to my eye it's still not clear what is and isn't selected if I don't already know.

I agree with the general idea of using perceived luminance to distinguish states here. But for that to work, I think we need to make the bone colors for each state the same perceived luminance (e.g. all unselected colors have the same perceived luminance, all selected colors have the same perceived luminance, etc.). Which currently isn't the case, particularly for unselected.

Additionally, human color perception is weird, and a simple weighted average of the RGB channels doesn't actually cut it for highly saturated colors. If we're going to do this algorithmically rather than by hand, I recommend we do the computations in a more perceptually uniform color space, like OkLab.

I played around with the new blend file, and to my eye it's still not clear what is and isn't selected if I don't already know. I agree with the general idea of using perceived luminance to distinguish states here. But for that to work, I think we need to make the bone colors for each state the same perceived luminance (e.g. all unselected colors have the same perceived luminance, all selected colors have the same perceived luminance, etc.). Which currently isn't the case, particularly for unselected. Additionally, human color perception is weird, and a simple weighted average of the RGB channels doesn't actually cut it for highly saturated colors. If we're going to do this algorithmically rather than by hand, I recommend we do the computations in a more perceptually uniform color space, like [OkLab](https://bottosson.github.io/posts/oklab/).

Alexander Gavrilov commented 2023-10-05 11:37:33 +02:00

Member

Copy Link

Additionally, human color perception is weird, and a simple weighted average of the RGB channels doesn't actually cut it for highly saturated colors. If we're going to do this algorithmically rather than by hand, I recommend we do the computations in a more perceptually uniform color space, like OkLab.

I agree, but simple luminance is about the limit of my own understanding of the color stuff :)

> Additionally, human color perception is weird, and a simple weighted average of the RGB channels doesn't actually cut it for highly saturated colors. If we're going to do this algorithmically rather than by hand, I recommend we do the computations in a more perceptually uniform color space, like [OkLab](https://bottosson.github.io/posts/oklab/). I agree, but simple luminance is about the limit of my own understanding of the color stuff :)

❤️ 1

Alexander Gavrilov commented 2023-10-05 11:42:00 +02:00

Member

Copy Link

That OkLab page contains some code, so it may be easy to try it.

Actually, now I wonder if the luminance should actually have been computed in linear space rather than gamma, and whether these color theme values are linear or gamma corrected. Any ideas?

That OkLab page contains some code, so it may be easy to try it. Actually, now I wonder if the luminance should actually have been computed in linear space rather than gamma, and whether these color theme values are linear or gamma corrected. Any ideas?

Nathan Vegdahl commented 2023-10-05 12:00:39 +02:00

Member

Copy Link

That OkLab page contains some code, so it may be easy to try it.

Yeah. Even further, in another post he derives an OkHSL space that might be easier to work with for this. The code is a little more involved, but he does provide code and it should be straightforward to copy/paste and translate to Python or whatnot.

Actually, now I wonder if the luminance should actually have been computed in linear space rather than gamma, and whether these color theme values are linear or gamma corrected. Any ideas?

Luminance (following the technical definition) should always be computed in linear space. And the weighted channel average is actually correct for that. But luminance (again, by technical definition) doesn't actually correspond precisely to perceived brightness. This is particularly true for highly saturated blues.

Computing perceived brightness consistently is tricky (e.g. OkLab also doesn't fully succeed, it just gets a lot closer), but it definitely involves nonlinearity in the computations.

As for whether the bone color RGB values are interpreted linearly or not... that's a great question. I did a quick test, and the results strongly suggest it's non-linear sRGB. But it might be worth checking Blender's source to be sure.

> That OkLab page contains some code, so it may be easy to try it. Yeah. Even further, in another post he derives an [OkHSL](https://bottosson.github.io/posts/colorpicker/) space that might be easier to work with for this. The code is a little more involved, but he does provide code and it should be straightforward to copy/paste and translate to Python or whatnot. > Actually, now I wonder if the luminance should actually have been computed in linear space rather than gamma, and whether these color theme values are linear or gamma corrected. Any ideas? Luminance (following the technical definition) should always be computed in linear space. And the weighted channel average is actually correct for that. But luminance (again, by technical definition) doesn't actually correspond precisely to *perceived brightness*. This is particularly true for highly saturated blues. Computing perceived brightness consistently is tricky (e.g. OkLab also doesn't fully succeed, it just gets a lot closer), but it definitely involves nonlinearity in the computations. As for whether the bone color RGB values are interpreted linearly or not... that's a great question. I did a quick test, and the results strongly suggest it's non-linear sRGB. But it might be worth checking Blender's source to be sure.

Sybren A. Stüvel referenced this issue 2023-10-05 12:37:16 +02:00

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

Sybren A. Stüvel commented 2023-10-05 12:46:18 +02:00

Member

Copy Link

As for whether the bone color RGB values are interpreted linearly or not... that's a great question. I did a quick test, and the results strongly suggest it's non-linear sRGB. But it might be worth checking Blender's source to be sure.

It's sRGB, see use_bone_color() in source/blender/draw/engines/overlay/overlay_armature.cc. It calls srgb_to_linearrgb_v4() to convert to linear for passing onto the next overlay drawing stage.

> As for whether the bone color RGB values are interpreted linearly or not... that's a great question. I did a quick test, and the results strongly suggest it's non-linear sRGB. But it might be worth checking Blender's source to be sure. It's sRGB, see `use_bone_color()` in `source/blender/draw/engines/overlay/overlay_armature.cc`. It calls `srgb_to_linearrgb_v4()` to convert to linear for passing onto the next overlay drawing stage.

👍 1

Sybren A. Stüvel referenced this issue 2023-10-05 14:20:47 +02:00

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

Demeter Dzadik commented 2023-10-05 19:05:52 +02:00

Author

Member

Copy Link

This proposal has been discussed in today's Animation Module Meeting.

Following decisions were made, unless I missed any:

• Sort the presets by Hue, so that users don't get caught off guard when assigning 2 presets far from each other in the list, only to find that they are not that distinct from each other.
• Let's use the OKLab way of calculating luminance values that Nathan suggested, and then pick a luminance value for unselected, selected, and active, and then pick some nice base colors.
• A button to expose this functionality to automatically derive selected/active colors could be added for convenience, but considering good presets should minimize the demand for customizing the colors in the first place, this is rather low priority.
• Let's push this to 4.0 since it's not a new feature.

I will update the proposal text as well as the PRs accordingly, soon.

This proposal has been discussed in [today's Animation Module Meeting](https://devtalk.blender.org/t/2023-10-05-animation-rigging-module-meeting-upcoming/31420). Following decisions were made, unless I missed any: - Sort the presets by Hue, so that users don't get caught off guard when assigning 2 presets far from each other in the list, only to find that they are not that distinct from each other. - Let's use the OKLab way of calculating luminance values that Nathan suggested, and then pick a luminance value for unselected, selected, and active, and then pick some nice base colors. - A button to expose this functionality to automatically derive selected/active colors could be added for convenience, but considering good presets should minimize the demand for customizing the colors in the first place, this is rather low priority. - Let's push this to 4.0 since it's not a new feature. I will update the proposal text as well as the PRs accordingly, soon.

Christoph Lendenfeld referenced this issue 2023-10-06 09:32:03 +02:00

Anim: Theme confusion with 'Pose Bone' label #110874

Nathan Vegdahl commented 2023-10-06 12:33:03 +02:00

Member

Copy Link

@Mets
Here's a Python implementation of OkHSL: okhsl.py
(It's a fair bit of code, but is just a straightforward translation of the C code to Python.)

The main function you'll probably want to use is okhsl_to_srgb(). It just takes a Hue-Saturation-Lightness color and converts it to non-linear sRGB, which can be plugged straight into the bone colors.

For example, this prints a list of sRGB colors with 20 different hues, 90% saturation, and 30% lightness:

for h in range(20):
    hsl = HSL(h / 20.0, 0.9, 0.3)
    print(okhsl_to_srgb(hsl))

@Mets Here's a Python implementation of OkHSL: [okhsl.py](/attachments/c7d83ca5-ec9c-4235-9fa9-3a67710b85b8) (It's a fair bit of code, but is just a straightforward translation of the C code to Python.) The main function you'll probably want to use is `okhsl_to_srgb()`. It just takes a Hue-Saturation-Lightness color and converts it to non-linear sRGB, which can be plugged straight into the bone colors. For example, this prints a list of sRGB colors with 20 different hues, 90% saturation, and 30% lightness: ```python for h in range(20): hsl = HSL(h / 20.0, 0.9, 0.3) print(okhsl_to_srgb(hsl)) ```

okhsl.py

12 KiB

Alexander Gavrilov commented 2023-10-09 13:34:27 +02:00

Member

Copy Link

The main function you'll probably want to use is okhsl_to_srgb(). It just takes a Hue-Saturation-Lightness color and converts it to non-linear sRGB, which can be plugged straight into the bone colors.

Note that because of the offset applied to wire color, you need to add 50/255 to the 'normal' color rgb channels after okhsl_to_srgb if you want the actual color lightness unification to target the wire color rather than the solid fill.

This isn't the case for the active and selected colors, so for those okhsl_to_srgb can be used directly.

> The main function you'll probably want to use is `okhsl_to_srgb()`. It just takes a Hue-Saturation-Lightness color and converts it to non-linear sRGB, which can be plugged straight into the bone colors. Note that because of the offset applied to wire color, you need to add 50/255 to the 'normal' color rgb channels after `okhsl_to_srgb` if you want the actual color lightness unification to target the wire color rather than the solid fill. This isn't the case for the active and selected colors, so for those `okhsl_to_srgb` can be used directly.

👍 1

Nathan Vegdahl commented 2023-10-09 17:14:11 +02:00

Member

Copy Link

@Mets and I had a bit of a powow together, trying to get the OkLab stuff working. And the bottom line is that when using any reasonably simple model (like weighted RGB averages, OkLab, etc.), generating consistently good results automatically is going to be challenging. And I don't think this is something we can tackle before 4.0.

So for now @Mets is going use OkLab as a tool, but hand-tweak the colors as best he can to have uniform perceived luminance.

Automating the creation of the colors (e.g. based on user-specified hues) may still be worth investigating in the future. But doing it well will likely be challenging.

@Mets and I had a bit of a powow together, trying to get the OkLab stuff working. And the bottom line is that when using any reasonably simple model (like weighted RGB averages, OkLab, etc.), generating consistently good results automatically is going to be challenging. And I don't think this is something we can tackle before 4.0. So for now @Mets is going use OkLab as a tool, but hand-tweak the colors as best he can to have uniform perceived luminance. Automating the creation of the colors (e.g. based on user-specified hues) may still be worth investigating in the future. But doing it well will likely be challenging.

Demeter Dzadik referenced this issue from a commit 2023-10-09 19:17:12 +02:00

New bone color presets

Demeter Dzadik referenced this issue from a commit 2023-10-09 19:21:19 +02:00

New bone color presets

Sybren A. Stüvel referenced this issue from a commit 2023-10-10 10:47:47 +02:00

New bone color presets

Demeter Dzadik referenced this issue 2023-10-19 15:55:25 +02:00

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

Demeter Dzadik commented 2023-10-19 15:55:30 +02:00

Author

Member

Copy Link

As per the last module meeting, it seems this task will be tackled along with Unified Active/Selected colors, among other issues related to bone colors and theme customization, targetting 4.1 instead of 4.0.

I think this task will be dormant now, but I'll leave it open until a new parent task is created.

As per the [last module meeting](https://devtalk.blender.org/t/2023-10-17-animation-rigging-module-meeting/31647), it seems this task will be tackled along with [Unified Active/Selected colors](https://projects.blender.org/blender/blender/issues/112943), among other issues related to bone colors and theme customization, targetting 4.1 instead of 4.0. I think this task will be dormant now, but I'll leave it open until a new parent task is created.

Sybren A. Stüvel referenced this issue 2023-10-19 16:38:07 +02:00

Anim: rework bone colors #113941

Demeter Dzadik commented 2023-10-19 17:16:01 +02:00

Author

Member

Copy Link

I think it makes sense to close this now, as this can be considered a design task with a finished design, which now constitutes one part this new, bigger rework: #113941.

I think it makes sense to close this now, as this can be considered a design task with a finished design, which now constitutes one part this new, bigger rework: https://projects.blender.org/blender/blender/issues/113941.

Demeter Dzadik closed this issue 2023-10-19 17:16:03 +02:00

Blender Bot added the

Status

Archived

label 2023-10-19 17:16:04 +02:00

Demeter Dzadik commented 2024-02-26 16:16:54 +01:00

Author

Member

Copy Link

For the record, I've been using my final set of custom colors ever since, and just told my rig generation system to set the bone's custom colors to my theme colors. That means my colors are currently propagating to my animators, so for now they can't customize it. They don't want to, so that's no big deal.

My experience with them has been as expected: Instead of having 3 fantastically popping colors, I have 20 super good enough colors.

Sure, the red and the blue don't pop as crazily as they used to, since they had to be toned down so their perceived lightness is similar to that of other hues when deselected. For me, totally worth it for the ability to have all kinds of colors that look super good enough mixed together in all selection states.

For the record, I've been using my final set of custom colors ever since, and just told my rig generation system to set the bone's custom colors to my theme colors. That means my colors are currently propagating to my animators, so for now they can't customize it. They don't want to, so that's no big deal. My experience with them has been as expected: Instead of having 3 fantastically popping colors, I have 20 super good enough colors. Sure, the red and the blue don't pop as crazily as they used to, since they had to be toned down so their perceived lightness is similar to that of other hues when deselected. For me, totally worth it for the ability to have all kinds of colors that look super good enough mixed together in all selection states.

Sybren A. Stüvel referenced this issue 2024-03-01 14:22:44 +01:00

Bone Collections & Bone Colors polish #118743

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

brush-assets-project

blender-v3.3-release

partial-write-refactor

universal-scene-description

fix-121021

blender-v4.1-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

5 Participants

Notifications

Subscribe

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#112635

No description provided.