2.83.2 and 2.9.0 problem with bone selection inside another bone #79024

New Issue

Alexander · 2020-07-17T14:31:01+02:00

Alexander commented

2020-07-17 14:31:01 +02:00

System Information
Operating system: Windows-7-6.1.7601-SP1 64 Bits
Graphics card: AMD Radeon HD 6670 ATI Technologies Inc. 4.5.13417 Core Profile Context 15.301.1901.0

Blender Version
Broken: version: 2.83.2, branch: master, commit date: 2020-07-09 05:50, hash: 239fbf7d93
Worked: (in blender 2.80 worked as expected)

Short description of error
Bone selection problem, inside another bone

Exact steps for others to reproduce the error

Blender 2.83.2 and the latest version 2.90 currently have a problem with bone selection in both Edit mode and Pose mode.

If you create a bone and then copy it and scale down. In Edit mode with the OpenGL Depth Picking enabled and xray-mode on, you can only select bone tail inside another bone. If select the bone itself, the outer bone is highlighted.
I tested this with both, my settings and Factory Defaults, the problem occurs in both cases.
Video demonstration: https://youtu.be/NksQCnU6kjs
If you create a bone and then copy it and scale down. In Pose mode with the OpenGL Depth Picking enabled and xray-mode on, you can't select bone tail and bone inside another bone.
I tested this with both, my settings and Factory Defaults, the problem occurs in both cases
If you create a bone and then copy it and scale down. In Pose mode with the OpenGL Depth Picking disabled and xray-mode on, you can select bone tail inside another bone, but you cannot select a bone along its edge inside another bone.
I tested this with both, my settings and Factory Defaults, the problem occurs in both cases.
Video demonstration: https://youtu.be/Su6GZJg_-Ak

version 2.8 does not have this problem

**System Information** Operating system: Windows-7-6.1.7601-SP1 64 Bits Graphics card: AMD Radeon HD 6670 ATI Technologies Inc. 4.5.13417 Core Profile Context 15.301.1901.0 **Blender Version** Broken: version: 2.83.2, branch: master, commit date: 2020-07-09 05:50, hash: `239fbf7d93` Worked: (in blender 2.80 worked as expected) **Short description of error** Bone selection problem, inside another bone **Exact steps for others to reproduce the error** Blender 2.83.2 and the latest version 2.90 currently have a problem with bone selection in both Edit mode and Pose mode. 1. If you create a bone and then copy it and scale down. In Edit mode with the OpenGL Depth Picking enabled and xray-mode on, you can only select bone tail inside another bone. If select the bone itself, the outer bone is highlighted. I tested this with both, my settings and Factory Defaults, the problem occurs in both cases. Video demonstration: https://youtu.be/NksQCnU6kjs 2. If you create a bone and then copy it and scale down. In Pose mode with the OpenGL Depth Picking enabled and xray-mode on, you can't select bone tail and bone inside another bone. I tested this with both, my settings and Factory Defaults, the problem occurs in both cases 3. If you create a bone and then copy it and scale down. In Pose mode with the OpenGL Depth Picking disabled and xray-mode on, you can select bone tail inside another bone, but you cannot select a bone along its edge inside another bone. I tested this with both, my settings and Factory Defaults, the problem occurs in both cases. Video demonstration: https://youtu.be/Su6GZJg_-Ak version 2.8 does not have this problem

👀 1

Alexander commented

2020-07-17 14:31:01 +02:00

Added subscriber: @LDsanya

blender-admin commented

2020-07-17 14:31:01 +02:00

#83534 was marked as duplicate of this issue

Germano Cavalcante commented

2020-07-17 16:30:52 +02:00

Added subscriber: @mano-wii

Germano Cavalcante commented

2020-07-17 16:30:52 +02:00

Same as #75425 which was closed as resolved.

Richard Antalik commented

2020-07-22 03:14:31 +02:00

Closed as duplicate of #75425

Richard Antalik closed this issue

2020-07-22 03:14:31 +02:00

Campbell Barton commented

2020-07-22 04:27:06 +02:00

Added subscriber: @ideasman42

Campbell Barton commented

2020-07-22 04:27:06 +02:00

Changed status from 'Duplicate' to: 'Confirmed'

Campbell Barton reopened this issue

2020-07-22 04:27:06 +02:00

Campbell Barton commented

2020-07-22 04:27:06 +02:00

Re-opening as #75425 was mixing multiple issues, the main issue was that it wasn't possible to select certain bones, although it mentions this issue too.

Campbell Barton commented

2020-07-22 04:34:18 +02:00

Setting this as a papercut since it's not a mistake in the code.

The current method uses depth even with wireframe selection, so small bones that are behind bigger bones are selected last.

Reversing the order of selection would solve simple cases but means distant bones would also be selected first.

We could try:

Flipping the normals so smaller bones would be in front of the larger bones back-facing depth.
Ordering bones using screen-space size.
Selecting bones using their wire. (we probably don't want to do this, just noting that it could work, perhaps wire as a first pass, then depth as a second pass if the first pass fails)

Setting this as a papercut since it's not a mistake in the code. The current method uses depth even with wireframe selection, so small bones that are behind bigger bones are selected last. Reversing the order of selection would solve simple cases but means distant bones would also be selected first. We could try: - Flipping the normals so smaller bones would be in front of the larger bones back-facing depth. - Ordering bones using screen-space size. - Selecting bones using their wire. *(we probably don't want to do this, just noting that it could work, perhaps wire as a first pass, then depth as a second pass if the first pass fails)*

SecuoyaEx commented

2020-07-22 10:41:25 +02:00

Added subscriber: @SecuoyaEx

SecuoyaEx commented

2020-07-22 10:41:25 +02:00

Selecting bones using their wire. (we probably don't want to do this, just noting that it could work, perhaps wire as a first pass, then depth as a second pass if the first pass fails)

I'm curious, why wouldn't we want this? what would be wrong with this approach compared to mesh objects doing the same? Also, can't both methods exist together depending of the shading mode?

> Selecting bones using their wire. (we probably don't want to do this, just noting that it could work, perhaps wire as a first pass, then depth as a second pass if the first pass fails) I'm curious, why wouldn't we want this? what would be wrong with this approach compared to mesh objects doing the same? Also, can't both methods exist together depending of the shading mode?

Campbell Barton commented

2020-07-22 10:50:29 +02:00

It would mean selecting in the middle of the bone could miss the bone - if it's large as the area inside it doesn't have wire, although as mentioned, this could be handled using a second solid pass as a fallback.

SecuoyaEx commented

2020-07-24 21:07:14 +02:00

It would mean selecting in the middle of the bone could miss the bone

Which is already the case with meshes in object mode, which is the expected behavior honestly, nothing wrong with that. There's always solid view to do solid selections

Edit: I just don't understand why it needs to be different or special from what Object mode already does in wireframe. But if it is because in pose and edit mode, bones are drawn with solid semitransparent filling and it might confuse the users, then let's not! Let bones be unfilled in wireframe view. Again, solid view is already there

> It would mean selecting in the middle of the bone could miss the bone Which is already the case with meshes in object mode, which is the expected behavior honestly, nothing wrong with that. There's always solid view to do solid selections Edit: I just don't understand why it needs to be different or special from what Object mode already does in wireframe. But if it is because in pose and edit mode, bones are drawn with solid semitransparent filling and it might confuse the users, then let's not! Let bones be unfilled in wireframe view. Again, solid view is already there

Germano Cavalcante commented

2020-12-10 03:50:16 +01:00

Added subscriber: @jwvdronkelaar

Jan-Willem van Dronkelaar commented

2020-12-12 11:53:21 +01:00

I would like to request this gets assigned to the "Rigging and Animation" project instead of "Modeling". This will make sure it appears on the work board for "Animation 2020" and is looked at by the correct people.

In #79024#983194, @ideasman42 wrote:
Setting this as a papercut since it's not a mistake in the code.

I take issue with this classification.

We had a user story where people go into wireframe mode to select objects behind or inside other objects. This user story broke; we have a clear working and non working version as stated in the report. "Its not a mistake in the code" is a meaningless statement in this context.

Unless I have to explain this as a design choice where the user story got changed and Wireframe mode is now only for visual splendor without affecting actual selection? The fact this report is marked as TODO indicates to me that no such decision was made and the initial user story is still valid.

Selecting bones inside bones is not an obscure workflow, its a common occurrence during rigging.

In my opinion this should really be classified as a bug. Please take a second look at its classification. Thank you.

I would like to request this gets assigned to the "Rigging and Animation" project instead of "Modeling". This will make sure it appears on the work board for "Animation 2020" and is looked at by the correct people. > In #79024#983194, @ideasman42 wrote: > Setting this as a papercut since it's not a mistake in the code. I take issue with this classification. We had a user story where people go into wireframe mode to select objects behind or inside other objects. This user story broke; we have a clear working and non working version as stated in the report. "Its not a mistake in the code" is a meaningless statement in this context. Unless I have to explain this as a design choice where the user story got changed and Wireframe mode is now only for visual splendor without affecting actual selection? The fact this report is marked as TODO indicates to me that no such decision was made and the initial user story is still valid. Selecting bones inside bones is not an obscure workflow, its a common occurrence during rigging. In my opinion this should really be classified as a bug. Please take a second look at its classification. Thank you.

Luciano Muñoz Sessarego commented

2020-12-13 16:08:30 +01:00

Added subscriber: @LucianoMunoz

Jan-Willem van Dronkelaar commented

2020-12-19 16:00:20 +01:00

Added subscriber: @dr.sybren

Jan-Willem van Dronkelaar commented

2020-12-19 16:00:20 +01:00

As requested by @dr.sybren here is the specific version where it broke:

Worked last: 2.81 (sub 16), branch: master, commit date: 2019-12-04 11:32, hash: f1aa4d18d4

Broke first: version: 2.82 (sub 7), branch: master, commit date: 2020-02-12 16:20, hash: 77d23b0bd7

I used the bug report functionality to easily access the version information. Strangely it marks the last worked at 2.81 without the letter. It is actually 2.81a

As requested by @dr.sybren here is the specific version where it broke: Worked last: 2.81 (sub 16), branch: master, commit date: 2019-12-04 11:32, hash: `f1aa4d18d4` Broke first: version: 2.82 (sub 7), branch: master, commit date: 2020-02-12 16:20, hash: `77d23b0bd7` I used the bug report functionality to easily access the version information. Strangely it marks the last worked at 2.81 without the letter. It is actually **2.81a**

Sybren A. Stüvel commented

2021-06-04 13:07:33 +02:00

Since Blender 2.93 (release notes) it is possible to alt-click and get a drop-down of available bones (just like alt-click to select objects). Would that be a good enough resolution for this issue? Or should the depth picking still be improved?

Since Blender 2.93 ([release notes](https://wiki.blender.org/wiki/Reference/Release_Notes/2.93/Animation-Rigging)) it is possible to alt-click and get a drop-down of available bones (just like alt-click to select objects). Would that be a good enough resolution for this issue? Or should the depth picking still be improved?

Alexander commented

2021-06-11 10:27:09 +02:00

In #79024#1170825, @dr.sybren wrote:
Since Blender 2.93 (release notes) it is possible to alt-click and get a drop-down of available bones (just like alt-click to select objects). Would that be a good enough resolution for this issue? Or should the depth picking still be improved?

Quite a good solution, I liked it!

> In #79024#1170825, @dr.sybren wrote: > Since Blender 2.93 ([release notes](https://wiki.blender.org/wiki/Reference/Release_Notes/2.93/Animation-Rigging)) it is possible to alt-click and get a drop-down of available bones (just like alt-click to select objects). Would that be a good enough resolution for this issue? Or should the depth picking still be improved? Quite a good solution, I liked it!

Sybren A. Stüvel commented

2021-06-11 14:33:48 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Sybren A. Stüvel closed this issue

2021-06-11 14:33:48 +02:00

Sybren A. Stüvel self-assigned this 2021-06-11 14:33:48 +02:00

Sybren A. Stüvel commented

2021-06-11 14:33:48 +02:00

In that case, I'll consider this task resolved :)

Jan-Willem van Dronkelaar commented

2021-07-18 10:07:25 +02:00

I am really disappointed to see this report marked as resolved @dr.sybren

Its obvious it has not been resolved. A different workflow has been added, which is great (the alt menu missing for bones was a notable shortcoming), but the original issue still stands.

We talked about this a couple of months ago and per your request I went back blender versions to prove it was a regression and provide a specific version number. This so it would be assigned the proper classification (bug) and possibly be moved to the animation module for fixing at one point in the future.

I can understand why this is not fixed yet, setting priorities are up to the blender foundation and I respect and understand that. But by marking this as resolved you have essentially made it so this bug will never be fixed.

This is a notable regression. This is a bug. It should be marked as such and left open so somewhere in the future there is a chance this will get fixed when priorities allow for it.

And for added clarity, layered hierarchies are extremely common in rigging. There is a reason people use scale to differentiate bones on top of each other. Its extremely quick to set up parenting and constraints this way. There is still a use case for this, even with the alt menu in place.

I am quite miffed I have to even argue the use case for it because the fact this is a regression really should be enough reason to mark it as a bug and leave it open. It genuinely feels like a double standard at work here. Users reporting have strict rules to abide by (what is a bug, a feature request, a known shortcoming etc) but apparently developers can just decide that a regression isn't really a bug and mark it as solved when they feel there are other workflows that fit the "use case" well enough.

I wish I was here to "protest" at june 4th but life happened and Phabricator had an old email (which i've fixed after seeing this happened without me know about it) so I missed it.

I am really disappointed to see this report marked as resolved @dr.sybren Its obvious it has not been resolved. A different workflow has been added, which is great (the alt menu missing for bones was a notable shortcoming), but the original issue still stands. We talked about this a couple of months ago and per your request I went back blender versions to prove it was a regression and provide a specific version number. This so it would be assigned the proper classification (bug) and possibly be moved to the animation module for fixing at one point in the future. I can understand why this is not fixed yet, setting priorities are up to the blender foundation and I respect and understand that. But by marking this as resolved you have essentially made it so this bug will never be fixed. This is a notable regression. This is a bug. It should be marked as such and left open so somewhere in the future there is a chance this will get fixed when priorities allow for it. And for added clarity, layered hierarchies are extremely common in rigging. There is a reason people use scale to differentiate bones on top of each other. Its extremely quick to set up parenting and constraints this way. There is still a use case for this, even with the alt menu in place. I am quite miffed I have to even argue the use case for it because the fact this is a regression really should be enough reason to mark it as a bug and leave it open. It genuinely feels like a double standard at work here. Users reporting have strict rules to abide by (what is a bug, a feature request, a known shortcoming etc) but apparently developers can just decide that a regression isn't really a bug and mark it as solved when they feel there are other workflows that fit the "use case" well enough. I wish I was here to "protest" at june 4th but life happened and Phabricator had an old email (which i've fixed after seeing this happened without me know about it) so I missed it.

SecuoyaEx commented

2021-07-18 12:56:07 +02:00

I concur. Not only is it a regression, it's hard to understand what is so conflicting, design wise, about the solution: Adding a proper wireframe display mode to bones, and making them selectable by the closest wire when said display mode is in use

Campbell Barton commented

2021-07-19 04:10:31 +02:00

If the behavior from 2.80x is still preferred, then I think this should be kept open as a paper cut since selection isn't working as well as it should and we have a documented / agreed on improvement to it's behavior.

I'd be interested if P2262 is an improvement from a user-perspective (only works edit-mode). It works by ordering bones by their screen-space triangle area with the head, tail and mouse location.

If the behavior from 2.80x is still preferred, then I think this should be kept open as a paper cut since selection isn't working as well as it should and we have a documented / agreed on improvement to it's behavior. ---- I'd be interested if [P2262](https://archive.blender.org/developer/P2262.txt) is an improvement from a user-perspective (only works edit-mode). It works by ordering bones by their screen-space triangle area with the head, tail and mouse location.

Jan-Willem van Dronkelaar commented

2021-07-19 14:21:47 +02:00

@ideasman42 the proposal you linked to does not sound like an improvement. Why would I want to have a selection order forced upon me when I should be able to select the bone I want directly. This is just adding more complexity without any benefit. It also gives me the feeling you do not understand the reach of this selection issue. Why do you assume this is an issue that only effects edit mode and not pose mode?

Implementing https://developer.blender.org/P2262 also wouldn't solve anything. In my original report on this issue which was closed as a duplicate I linked two short clips showing old and new behavior. It showed the use case of wanting to assign a constraint with a target (so pose mode and not edit mode). So its important to be able to select just two bones and have one as active since that dictates on which bone the constraint is placed and which bone is the target. As you would expect it has bones inside bones with a slight size difference so it should be easy to pick them apart.

Here is my report with the clips: https://developer.blender.org/T83534

As you can see, a toggling behavior for bones behind/inside bones is already present and fails in this scenario. I could not get a valid selection to assign my constraint properly. So implementing some other toggling behavior instead of allowing me to pick a bone directly is not a solution. And even if it were, it would be the long way around (just like the alt menu) compared to being able to pick the bone directly.

A few posts up I posted the user story:

We had a user story where people go into wireframe mode to select objects behind or inside other objects. This user story broke; we have a clear working and non working version as stated in the report.

I got no feedback on this user story no longer being valid and wireframe just being for show instead of actually allowing you to select bones inside or behind other bones. Not only did it used to work this way, it was also consistent with behavior in object mode:

proper_wireframe_selection.mp4

So please, mark this regression as a bug and set it to open so that it can be fixed at some point in the future and we can finally select bones properly in wireframe mode again.

@ideasman42 the proposal you linked to does not sound like an improvement. Why would I want to have a selection order forced upon me when I should be able to select the bone I want **directly**. This is just adding more complexity without any benefit. It also gives me the feeling you do not understand the reach of this selection issue. Why do you assume this is an issue that only effects edit mode and not pose mode? Implementing https://developer.blender.org/P2262 also wouldn't solve anything. In my original report on this issue which was closed as a duplicate I linked two short clips showing old and new behavior. It showed the use case of wanting to assign a constraint with a target (so pose mode and not edit mode). So its important to be able to select just two bones and have one as active since that dictates on which bone the constraint is placed and which bone is the target. As you would expect it has bones inside bones with a slight size difference so it should be easy to pick them apart. Here is my report with the clips: https://developer.blender.org/T83534 As you can see, a toggling behavior for bones behind/inside bones is already present and fails in this scenario. I could not get a valid selection to assign my constraint properly. So implementing some other toggling behavior instead of allowing me to pick a bone directly is not a solution. And even if it were, it would be the long way around (just like the alt menu) compared to being able to pick the bone directly. A few posts up I posted the user story: > We had a user story where people go into wireframe mode to select objects behind or inside other objects. This user story broke; we have a clear working and non working version as stated in the report. I got no feedback on this user story no longer being valid and wireframe just being for show instead of actually allowing you to select bones inside or behind other bones. Not only did it used to work this way, it was also consistent with behavior in object mode: [proper_wireframe_selection.mp4](https://archive.blender.org/developer/F10228025/proper_wireframe_selection.mp4) So please, mark this regression as a bug and set it to open so that it can be fixed at some point in the future and we can finally select bones properly in wireframe mode again.

Campbell Barton commented

2021-07-20 06:59:02 +02:00

@jwvdronkelaar I wasn't as clear as I could have been.

The order is also used for the first bone that's selected.
It only works in edit-mode because it is not yet implemented in pose mode (since it's a proof of concept), it can be made to work in pose mode too.

This video shows the difference: out.ogv

@jwvdronkelaar I wasn't as clear as I could have been. - The order is also used for the first bone that's selected. - It only works in edit-mode because it is not yet implemented in pose mode (since it's a proof of concept), it can be made to work in pose mode too. This video shows the difference: [out.ogv](https://archive.blender.org/developer/F10228798/out.ogv)

Jan-Willem van Dronkelaar commented

2021-07-20 12:37:03 +02:00

@ideasman42 For a while now I've felt I've been missing something when I look at the convo in this report. I always try to find the perspective from the person on the "other side" and I had trouble to explain to myself why you seemed so reluctant to accept my suggested solution or, in fact, even assign it as a bug.

Then I realized that with 2.8 this weird exception was introduced for wireframe for bones in edit and pose mode. Instead of giving the user what he chose,; a wireframe view, the user was now forced (whether he wanted or not) into solid mode with x-ray forced on. Ironically I imagine this was done to make selecting bones "easier" in the most plain of scenarios? Personally I see little to no value in this addition, especially since I used to be able to chose myself whether I wanted to work into solid or wire and this choice was taken away from me. Nevertheless its what we got; so done deal for now.

Right now I'm guessing our perspectives differ in the following matter. I still consider wireframe mode, wireframe mode. The visual garb that was added on top does not change my purpose for going into wireframe mode.

I want to see everything and be able to select everything. This includes me being able to make selections "wireframe style".

I think that you actually don't see wireframe mode for bones in edit and pose mode as wireframe. Visually it looks like solid mode despite us being in wireframe mode and I think you take that as the main factor for how the selection should behave. This would explain our seemingly opposing viewpoints. I'd love to know if this is how you see it or whether I am completely missing the mark

With that out of the way lets get onto more constructive matters. Let me start by saying the video looks great. I am hesitant about this approach working in all cases though. What about b-bones with different diameters for example? I think its pretty tough to make this as solid and reliable as wireframe style selection.

With that said, this looks like it allows me to make the selections directly that I'm currently unable to in 2.93 I don't know enough about coding to judge the functionality by the code alone. I'd love to test this in a few different scenarios (I see no selecting of bone heads in the video for example).

If this ends up working reliably in all cases it looks like this would solve my issue. :)

@ideasman42 For a while now I've felt I've been missing something when I look at the convo in this report. I always try to find the perspective from the person on the "other side" and I had trouble to explain to myself why you seemed so reluctant to accept my suggested solution or, in fact, even assign it as a bug. Then I realized that with 2.8 this weird exception was introduced for wireframe for bones in edit and pose mode. Instead of giving the user what he chose,; a wireframe view, the user was now forced (whether he wanted or not) into solid mode with x-ray forced on. Ironically I imagine this was done to make selecting bones "easier" in the most plain of scenarios? Personally I see little to no value in this addition, especially since I used to be able to chose myself whether I wanted to work into solid or wire and this choice was taken away from me. Nevertheless its what we got; so done deal for now. Right now I'm guessing our perspectives differ in the following matter. I still consider wireframe mode, wireframe mode. The visual garb that was added on top does not change my purpose for going into wireframe mode. I want to see everything and be able to select everything. This includes me being able to make selections "wireframe style". I think that you actually **don't** see wireframe mode for bones in edit and pose mode as wireframe. Visually it looks like solid mode despite us being in wireframe mode and I think you take that as the main factor for how the selection should behave. This would explain our seemingly opposing viewpoints. I'd love to know if this is how you see it or whether I am completely missing the mark ----------------------------------- With that out of the way lets get onto more constructive matters. Let me start by saying the video looks great. I am hesitant about this approach working in all cases though. What about b-bones with different diameters for example? I think its pretty tough to make this as solid and reliable as wireframe style selection. With that said, this looks like it allows me to make the selections directly that I'm currently unable to in 2.93 I don't know enough about coding to judge the functionality by the code alone. I'd love to test this in a few different scenarios (I see no selecting of bone heads in the video for example). If this ends up working reliably in all cases it looks like this would solve my issue. :)

Campbell Barton commented

2021-07-20 16:23:34 +02:00

@jwvdronkelaar thanks for the feedback.

Note that I personally don't have a strong opinion about this design decision.

They would certainly be some advantages with your suggestion of reinstating real wire drawing.
It's not that I'm pushing back against that, just that it's a much bigger decision & change to make.

That the problem of selecting a bone inside another bone is the main annoyance with the current selection behavior - makes me think a smaller change might be sufficient.

As for your feedback on my patch, yes you're right to be concerned about different bone drawing styles etc.

B-Bones can be supported (it's possible to calculate distance to a b-bone segment). My main concern is pose-mode custom-object display, in practice it might end up being OK to use the same logic as regular bones, seeing as that only changes the order of selection - the pose-bones display-object still needs to be under the cursor to be selected.

This bone selection behavior could be tested as an experimental feature to get feedback from animators.

@jwvdronkelaar thanks for the feedback. Note that I personally don't have a strong opinion about this design decision. They would certainly be some advantages with your suggestion of reinstating real wire drawing. It's not that I'm pushing back against that, just that it's a much bigger decision & change to make. That the problem of selecting a bone inside another bone is the main annoyance with the current selection behavior - makes me think a smaller change might be sufficient. ---- As for your feedback on my patch, yes you're right to be concerned about different bone drawing styles etc. B-Bones can be supported (it's possible to calculate distance to a b-bone segment). My main concern is pose-mode custom-object display, in practice it might end up being OK to use the same logic as regular bones, seeing as that only changes the order of selection - the pose-bones display-object still needs to be under the cursor to be selected. This bone selection behavior could be tested as an experimental feature to get feedback from animators.

Sybren A. Stüvel commented

2021-07-20 17:46:22 +02:00

Changed status from 'Resolved' to: 'Confirmed'

Sybren A. Stüvel reopened this issue

2021-07-20 17:46:22 +02:00

Sybren A. Stüvel removed their assignment 2021-07-20 17:46:22 +02:00

Sybren A. Stüvel commented

2021-07-20 17:46:22 +02:00

In #79024#1193086, @jwvdronkelaar wrote:
So please, mark this regression as a bug and set it to open so that it can be fixed at some point in the future and we can finally select bones properly in wireframe mode again.

With such a passionate plea (I'm quoting one line here, but I'm referring to your multiple comments on this task), how can I do otherwise but listen and agree?

> In #79024#1193086, @jwvdronkelaar wrote: > So please, mark this regression as a bug and set it to open so that it can be fixed at some point in the future and we can finally select bones properly in wireframe mode again. With such a passionate plea (I'm quoting one line here, but I'm referring to your multiple comments on this task), how can I do otherwise but listen and agree?

Jan-Willem van Dronkelaar commented

2021-07-20 19:27:25 +02:00

@ideasman42 After you validating my concern on how well this approach will work with different bone drawing styles and custom bones shapes, I just can't help but feel that my my original suggestion to go back to a proper "wireframe selection" is still the best way to go.

I will say its quite disheartening to read that your proposal can't be fleshed out into a proper solution but I guess I should have just seen it as a thought experiment? I understand this report is just one of many for you but please also understand that to me as a user I'd really love to see it solved. I am not having this discussion because its my favorite pastime.

I consider it a genuine possibility that this just does not get properly resolved and as users we lose the very basic functionality of efficiently and directly making selections in armature edit and pose mode. This report is still, at the time of writing, (incorrectly) marked as closed after all.

That the problem of selecting a bone inside another bone is the main annoyance with the current selection behavior - makes me think a smaller change might be sufficient.

I have no idea what that line infers. You have a new proposal?

@ideasman42 After you validating my concern on how well this approach will work with different bone drawing styles and custom bones shapes, I just can't help but feel that my my original suggestion to go back to a proper "wireframe selection" is still the best way to go. I will say its quite disheartening to read that your proposal can't be fleshed out into a proper solution but I guess I should have just seen it as a thought experiment? I understand this report is just one of many for you but please also understand that to me as a user I'd really love to see it solved. I am not having this discussion because its my favorite pastime. I consider it a genuine possibility that this just does not get properly resolved and as users we lose the very basic functionality of efficiently and directly making selections in armature edit and pose mode. This report is still, at the time of writing, (incorrectly) marked as closed after all. > That the problem of selecting a bone inside another bone is the main annoyance with the current selection behavior - makes me think a smaller change might be sufficient. I have no idea what that line infers. You have a new proposal?

Jan-Willem van Dronkelaar commented

2021-07-20 19:40:10 +02:00

In #79024#1193835, @dr.sybren wrote:

In #79024#1193086, @jwvdronkelaar wrote:
So please, mark this regression as a bug and set it to open so that it can be fixed at some point in the future and we can finally select bones properly in wireframe mode again.

With such a passionate plea (I'm quoting one line here, but I'm referring to your multiple comments on this task), how can I do otherwise but listen and agree?

I love your sense of humor about this. So allow me to, in the same lighthearted manner, point out that you actually did not listen and agree. Because its still not marked as a bug but instead as a papercut? :)

Since you also mention my multiple comments on this task I'd like to point out the one where I mention in what version it broke, so its clear this is a regression and qualifies as a bug.

https://developer.blender.org/T79024#1078729

With that said, I do feel its time for this:

> In #79024#1193835, @dr.sybren wrote: >> In #79024#1193086, @jwvdronkelaar wrote: >> So please, mark this regression as a bug and set it to open so that it can be fixed at some point in the future and we can finally select bones properly in wireframe mode again. > > With such a passionate plea (I'm quoting one line here, but I'm referring to your multiple comments on this task), how can I do otherwise but listen and agree? I love your sense of humor about this. So allow me to, in the same lighthearted manner, point out that you actually did not listen and agree. Because its still not marked as a bug but instead as a papercut? :) Since you also mention my multiple comments on this task I'd like to point out the one where I mention in what version it broke, so its clear this is a regression and qualifies as a bug. https://developer.blender.org/T79024#1078729 With that said, I do feel its time for this: ![image.png](https://archive.blender.org/developer/F10230216/image.png)

Campbell Barton commented

2021-07-21 03:25:22 +02:00

In #79024#1193850, @jwvdronkelaar wrote:
@ideasman42 After you validating my concern on how well this approach will work with different bone drawing styles and custom bones shapes, I just can't help but feel that my my original suggestion to go back to a proper "wireframe selection" is still the best way to go.

Suggesting two options that use real-wire selection with some tweaks to work with the 2.81+ style of drawing:

Wire selection w/ solid fallback.


If there are no hits then solid-selection would be used as a fallback.

The fallback is important since wire selection without changing the draw-style would introduce a problem that interior wire could be used for selection but be invisible (since the interior wire is masked and only the silhouette is shown).

Wire selection w/ outline only.

Wire selection that ignores interior wire (select based on the bones outline - silhouette).

This means selecting in the middle of a bone (when zoomed in enough) would not select it.

In principle this isn't so complicated although I'd need to check on how this can be done with the current shaders / drawing system.

Or, implement real wire-selection:

Add back real wire selection exactly as 2.80 and older, with only a minor tweak to drawing so interior wires are shown as well as the outline (when in wire-frame display mode).

They could be drawn with thin lines than the silhouette so the overall impact isn't a significant change to the current display style.

I will say its quite disheartening to read that your proposal can't be fleshed out into a proper solution but I guess I should have just seen it as a thought experiment?

It would be good to have the patch tested. It can be made to work for pose-bones and b-bones - etc. OTOH, I'm not pushing for this, just noting it as an option.

I understand this report is just one of many for you but please also understand that to me as a user I'd really love to see it solved. I am not having this discussion because its my favorite pastime.

I consider it a genuine possibility that this just does not get properly resolved and as users we lose the very basic functionality of efficiently and directly making selections in armature edit and pose mode. This report is still, at the time of writing, (incorrectly) marked as closed after all.

That the problem of selecting a bone inside another bone is the main annoyance with the current selection behavior - makes me think a smaller change might be sufficient.

I have no idea what that line infers. You have a new proposal?

There are typically multiple solutions to these kind of problems, noted some alternatives above.

I'll check with others, nevertheless, it would be interesting to get some feedback on the patch I posted to know if it works well in practice, even knowing problems that make it unworkable can help guide new solutions.

> In #79024#1193850, @jwvdronkelaar wrote: > @ideasman42 After you validating my concern on how well this approach will work with different bone drawing styles and custom bones shapes, I just can't help but feel that my my original suggestion to go back to a proper "wireframe selection" is still the best way to go. Suggesting two options that use real-wire selection with some tweaks to work with the 2.81+ style of drawing: - Wire selection w/ solid fallback. ``` If there are no hits then solid-selection would be used as a fallback. ``` ``` The fallback is important since wire selection without changing the draw-style would introduce a problem that interior wire could be used for selection but be invisible (since the interior wire is masked and only the silhouette is shown). ``` - Wire selection w/ outline only. ``` Wire selection that ignores interior wire (select based on the bones outline - silhouette). ``` ``` This means selecting in the middle of a bone (when zoomed in enough) would not select it. ``` ``` In principle this isn't so complicated although I'd need to check on how this can be done with the current shaders / drawing system. ``` Or, implement real wire-selection: - Add back real wire selection exactly as 2.80 and older, with only a minor tweak to drawing so interior wires are shown as well as the outline (when in wire-frame display mode). ``` They could be drawn with thin lines than the silhouette so the overall impact isn't a significant change to the current display style. ``` ---- > I will say its quite disheartening to read that your proposal can't be fleshed out into a proper solution but I guess I should have just seen it as a thought experiment? It would be good to have the patch tested. It can be made to work for pose-bones and b-bones - etc. OTOH, I'm not pushing for this, just noting it as an option. > I understand this report is just one of many for you but please also understand that to me as a user I'd really love to see it solved. I am not having this discussion because its my favorite pastime. > > I consider it a genuine possibility that this just does not get properly resolved and as users we lose the very basic functionality of efficiently and directly making selections in armature edit and pose mode. This report is still, at the time of writing, (incorrectly) marked as closed after all. > >> That the problem of selecting a bone inside another bone is the main annoyance with the current selection behavior - makes me think a smaller change might be sufficient. > > I have no idea what that line infers. You have a new proposal? There are typically multiple solutions to these kind of problems, noted some alternatives above. I'll check with others, nevertheless, it would be interesting to get some feedback on the patch I posted to know if it works well in practice, even knowing problems that make it unworkable can help guide new solutions.

Jan-Willem van Dronkelaar commented

2021-07-21 10:08:09 +02:00

In #79024#1193985, @ideasman42 wrote:

Wire selection w/ solid fallback.

If there are no hits then solid-selection would be used as a fallback.

The fallback is important since wire selection without changing the draw-style would introduce a problem that interior wire could be used for selection but be invisible (since the interior wire is masked and only the silhouette is shown).

If I'm reading this correctly this means that the current selection method will be mostly kept intact where you can select bones by clicking "inside" their shaded area. In addition however you can click on the wire and if you do that, that will take precedence over the solid shading allowing you to select bones directly regardless of them being inside other bones. This sounds like it would introduce minimal change while still solving the issue at hand here.

When I am honest I would prefer the third option. However assuming this current visual "style" serves a purpose and other people see value in it I can understand the will to keep it. I'd also really like to avoid this turning into a design task. So with that taken into account I'd say option 1 would be the best way to move forward.

I will admit its not as elegant as the solution your code snippet is the start of. It essentially allows for solid shading selection to work properly with x-ray which is essentially what wireframe mode for pose and edit mode for armatures has turned into.

However I feel its unwise to pursue a solution that would be overly complex to implement in a manner where its reliable in all cases. To me at this point its just creating extra work, allowing room for errors which in the worst case will result in reverted commits after users start testing it and then being back at square one with this task.

Another argument against it is that from a consistency pov it would make sense to allow users to select by clicking on the wireframe in wireframe mode. Regardless of how its dressed up.

So lets not make this task any more complex then it needs to be, I think option 1 is much more practical.

> In #79024#1193985, @ideasman42 wrote: > - Wire selection w/ solid fallback. > > If there are no hits then solid-selection would be used as a fallback. > > The fallback is important since wire selection without changing the draw-style would introduce a problem that interior wire could be used for selection but be invisible (since the interior wire is masked and only the silhouette is shown). If I'm reading this correctly this means that the current selection method will be mostly kept intact where you can select bones by clicking "inside" their shaded area. In addition however you can click on the wire and if you do that, that will take precedence over the solid shading allowing you to select bones directly regardless of them being inside other bones. This sounds like it would introduce minimal change while still solving the issue at hand here. When I am honest I would prefer the third option. However assuming this current visual "style" serves a purpose and other people see value in it I can understand the will to keep it. I'd also **really** like to avoid this turning into a design task. So with that taken into account I'd say option 1 would be the best way to move forward. -------- I will admit its not as elegant as the solution your code snippet is the start of. It essentially allows for solid shading selection to work properly with x-ray which is essentially what wireframe mode for pose and edit mode for armatures has turned into. However I feel its unwise to pursue a solution that would be overly complex to implement in a manner where its reliable in all cases. To me at this point its just creating extra work, allowing room for errors which in the worst case will result in reverted commits after users start testing it and then being back at square one with this task. Another argument against it is that from a consistency pov it would make sense to allow users to select by clicking on the wireframe in wireframe mode. Regardless of how its dressed up. So lets not make this task any more complex then it needs to be, I think option 1 is much more practical.

Jan-Willem van Dronkelaar commented

2021-08-19 14:08:46 +02:00

In #79024#1193985, @ideasman42 wrote:
I'll check with others, nevertheless, it would be interesting to get some feedback on the patch I posted to know if it works well in practice, even knowing problems that make it unworkable can help guide new solutions.

Since there has been no reply on my previous comment I assume this is the manner in which you wish to proceed. Have you shared your proposal with others (whoever that may be)? Do you have an idea what your next step will be based on the feedback you received?

I recently rigged a character for someone and this selection issue is still something that hinders my workflow. I can hide bones temporarily (in certain cases) or use the alt menu but this is still a regression compared to how things used to be.

As a user is there any way I can help to move this task forward?

It would make me quite sad to see 3.0 released later this year and this regression still being present.

> In #79024#1193985, @ideasman42 wrote: > I'll check with others, nevertheless, it would be interesting to get some feedback on the patch I posted to know if it works well in practice, even knowing problems that make it unworkable can help guide new solutions. Since there has been no reply on my previous comment I assume this is the manner in which you wish to proceed. Have you shared your proposal with others (whoever that may be)? Do you have an idea what your next step will be based on the feedback you received? I recently rigged a character for someone and this selection issue is still something that hinders my workflow. I can hide bones temporarily (in certain cases) or use the alt menu but this is still a regression compared to how things used to be. As a user is there any way I can help to move this task forward? It would make me quite sad to see 3.0 released later this year and this regression still being present.

Campbell Barton commented

2021-08-20 04:58:48 +02:00

In #79024#1194114, @jwvdronkelaar wrote:

In #79024#1193985, @ideasman42 wrote:

Wire selection w/ solid fallback.

If there are no hits then solid-selection would be used as a fallback.

The fallback is important since wire selection without changing the draw-style would introduce a problem that interior wire could be used for selection but be invisible (since the interior wire is masked and only the silhouette is shown).

If I'm reading this correctly this means that the current selection method will be mostly kept intact where you can select bones by clicking "inside" their shaded area. In addition however you can click on the wire and if you do that, that will take precedence over the solid shading allowing you to select bones directly regardless of them being inside other bones. This sounds like it would introduce minimal change while still solving the issue at hand here.

Right, the reason for this is bones are drawing solid even in wire mode, so it makes some sense to be able to select them when clicking in the middle of a bone for example.

When I am honest I would prefer the third option. However assuming this current visual "style" serves a purpose and other people see value in it I can understand the will to keep it. I'd also really like to avoid this turning into a design task. So with that taken into account I'd say option 1 would be the best way to move forward.

I will admit its not as elegant as the solution your code snippet is the start of. It essentially allows for solid shading selection to work properly with x-ray which is essentially what wireframe mode for pose and edit mode for armatures has turned into.

If wire selection is added back - the exact behavior is simple to tweak to make it work either way.

However I feel its unwise to pursue a solution that would be overly complex to implement in a manner where its reliable in all cases. To me at this point its just creating extra work, allowing room for errors which in the worst case will result in reverted commits after users start testing it and then being back at square one with this task.

Another argument against it is that from a consistency pov it would make sense to allow users to select by clicking on the wireframe in wireframe mode. Regardless of how its dressed up.

I see your point, personally I don't have a strong opinion either way and would go with the preference of users involved in the animation module.

So lets not make this task any more complex then it needs to be, I think option 1 is much more practical.

For now this is waiting for a developer to work on it. I'll see if anyone is available to look into this further.

> In #79024#1194114, @jwvdronkelaar wrote: >> In #79024#1193985, @ideasman42 wrote: >> - Wire selection w/ solid fallback. >> >> If there are no hits then solid-selection would be used as a fallback. >> >> The fallback is important since wire selection without changing the draw-style would introduce a problem that interior wire could be used for selection but be invisible (since the interior wire is masked and only the silhouette is shown). > > If I'm reading this correctly this means that the current selection method will be mostly kept intact where you can select bones by clicking "inside" their shaded area. In addition however you can click on the wire and if you do that, that will take precedence over the solid shading allowing you to select bones directly regardless of them being inside other bones. This sounds like it would introduce minimal change while still solving the issue at hand here. Right, the reason for this is bones are drawing solid even in wire mode, so it makes some sense to be able to select them when clicking in the middle of a bone for example. > When I am honest I would prefer the third option. However assuming this current visual "style" serves a purpose and other people see value in it I can understand the will to keep it. I'd also **really** like to avoid this turning into a design task. So with that taken into account I'd say option 1 would be the best way to move forward. > > -------- > > I will admit its not as elegant as the solution your code snippet is the start of. It essentially allows for solid shading selection to work properly with x-ray which is essentially what wireframe mode for pose and edit mode for armatures has turned into. If wire selection is added back - the exact behavior is simple to tweak to make it work either way. > However I feel its unwise to pursue a solution that would be overly complex to implement in a manner where its reliable in all cases. To me at this point its just creating extra work, allowing room for errors which in the worst case will result in reverted commits after users start testing it and then being back at square one with this task. > > Another argument against it is that from a consistency pov it would make sense to allow users to select by clicking on the wireframe in wireframe mode. Regardless of how its dressed up. I see your point, personally I don't have a strong opinion either way and would go with the preference of users involved in the animation module. > So lets not make this task any more complex then it needs to be, I think option 1 is much more practical. For now this is waiting for a developer to work on it. I'll see if anyone is available to look into this further.

Jan-Willem van Dronkelaar commented

2021-08-22 21:10:39 +02:00

In #79024#1208698, @ideasman42 wrote:

For now this is waiting for a developer to work on it. I'll see if anyone is available to look into this further.

Thanks for the status update. Good to know it still has your attention. :)

> In #79024#1208698, @ideasman42 wrote: > > For now this is waiting for a developer to work on it. I'll see if anyone is available to look into this further. Thanks for the status update. Good to know it still has your attention. :)

Jan-Willem van Dronkelaar commented

2021-09-29 14:41:10 +02:00

It seems highly unlikely this will be fixed for 3.0 at this point. I hope its not relegated to a known issue now just because it has been ignored for so long.

In my opinion this should, still, be marked as a bug since it checks all the criteria. The fact this is marked as a "modelling papercut" despite my repeated attempts to have this changed is hard to interpret as anything other then a deliberate attempt to keep this report from getting the priority it deserves and actually being fixed.

I fully understand that the developers focus is elsewhere right now with the 3.0 release but this report is from July last year. There have been other moments that could have been used to resolve this bug even taking into account it took months before the conversation became constructive and the fact there was a regression in functionality was acknowledged.

At this point I find it quite hard to believe this will ever get fixed. "Waiting for a developer to work on it" is quite meaningless if the report is marked as a papercut.

It seems highly unlikely this will be fixed for 3.0 at this point. I hope its not relegated to a known issue now just because it has been ignored for so long. In my opinion this should, still, be marked as a bug since it checks all the criteria. The fact this is marked as a "modelling papercut" despite my repeated attempts to have this changed is hard to interpret as anything other then a deliberate attempt to keep this report from getting the priority it deserves and actually being fixed. I fully understand that the developers focus is elsewhere right now with the 3.0 release but this report is from July last year. There have been other moments that could have been used to resolve this bug even taking into account it took months before the conversation became constructive and the fact there was a regression in functionality was acknowledged. At this point I find it quite hard to believe this will ever get fixed. "Waiting for a developer to work on it" is quite meaningless if the report is marked as a papercut.

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

2.83.2 and 2.9.0 problem with bone selection inside another bone #79024