Fix Skeleton3D Edit Mode bone buttons have priority over transform gizmo#115608
Fix Skeleton3D Edit Mode bone buttons have priority over transform gizmo#115608Repiteo merged 1 commit intogodotengine:masterfrom
Skeleton3D Edit Mode bone buttons have priority over transform gizmo#115608Conversation
There was a problem hiding this comment.
Seems to be not worked correctly, the free rotation detection seems too strong:
- Joints without a gizmo surface cannot be selected
- The rotation gizmo does not function in Transform mode
This PR:
bug.mp4
4.5 behavior (should be):
4_5.mp4
So I recommend white semi-transparent sphere area visualizer on center of the gizmo must be removed and the priority must be set to the lowest.
I'm mixed on this, I understand that's how it worked in v4.5, but technically it is part of the transform gizmo and an argument can be made that it should also have priority over the bone buttons, especially since there is a dedicated select tool now. What if someone wants to use the trackball feature to manipulate the joints?
Huh weird, I can make it work sometimes. I'll take a further look. |
This operation must be performed when you press a part inside the sphere that does not exist as a joint button. It is selectable in 4.6 stable, but this PR is causing further regressions. |
Isn't that the issue that this PR is trying to fix? IMO the transform gizmo should consistently have priority over the bone buttons. Wouldn't it make sense more to have the trackball an editor setting if this is considered an issue for people who preferred the behavior of being able to select through the gizmo while it's transform/rotation mode? |
|
Since you might be confused, let me clarify the issue. The issue points out that the joint button takes precedence over the green (XZ) plane transform in the video. 4.6: 46.mp44.5: 45.mp4This PR currently treats everything inside the sphere as part of the transform gizmo's detection, but that's the wrong approach. The only necessary fix here is to ensure that items visually positioned higher take priority when clicked. |
This is certainty possible. 😂
I believe I understand this.
Yes, and I am arguing that the approach makes sense. It is part of the transform gizmo and therefore should have priority over the bone buttons as well. This will lead to consistent behavior and makes it impossible to accidentally select a different bone if someone was rapidly trying to rotate the track ball. My alternative suggestion is we make it an editor setting to disable the trackball for those who prefer not to use the dedicated select tool and wish to click through the transform/rotation gizmo. |
That must be a separate proposal. The author who reported the issue apparently hasn't touched anything other than 4.6, so I don't know if they want that, but I'm simply arguing that we need to preserve the 4.5 behavior, so we should only make "fixes" here, not enhancement. As I said initially, whether to add an option to enforce that transform gizmo area requires discussion and demand assessment through a proposal. Personally, I wouldn't strongly oppose it, but it should never be the default (it means that #114749 will recur within Sphere), and I wouldn't promote that adding it (I'll leave that to others' opinion who want to it). |
There was a problem hiding this comment.
I see. So the white area was added in #109976. After this PR change, I confirmed that reverting #109976 results in the same behavior as 4.5.
Therefore, merging this PR for 4.7 and cherry-picking it into 4.6 should be fine. However, I emphasize that a follow-up to make #109976 optional is absolutely necessary. This is because it partially reintroduces #114749.
I will create a PR for it today. |
|
Thanks! |
|
Cherry-picked for 4.6.1. |
Fix `Skeleton3D` Edit Mode bone buttons have priority over transform gizmo
Fixes: #115581
Verified #114749 was not reintroduced.
#114752 added bone selection handling to
forward_3d_gui_input, which runs before transform gizmo input processing. This caused bone buttons to intercept clicks meant for the gizmo. Bone selection is already handled correctly bysubgizmos_intersect_ray, which runs after the transform gizmo check in_sinput, so this redundant.2026-01-29.18-16-54.mp4