Changed default pointer extent to make mouse pointer behavior more intuitive #10075
Conversation
|
/azp run |
|
Azure Pipelines successfully started running 2 pipeline(s). |
|
I've tried to verify this, but I'm seeing quite a strange behavior with the screen space mouse pointer. When interacting with the slider, the slider moves in the proper way, but the mouse cursor itself stays frozen until the slider is released. @RogPodge is this some problem with how I've set up the mouse pointer? I followed the repro instructions as closely as I could in the original issue (#10071 ) |
The behavior of having 2 mouse cursors occurs when you use the MousePointer prefab in the input profile rather than the ScreenSpaceMousePointer
As for why that happens, I think it's because that pointer's cursor behavior is similar to our gaze cursor and far pointer's behavior with the sliders. Once the pointer is "focus locked" with the slider, the cursor becomes rooted in place. |
RogPodge
moved this from Fixed - Needs Release Notes
to Done - July 2021
in [Retired] MRTK Backlog
Overview
Changes the default pointing extent for the screen space mouse pointer to be much smaller, thus making the mouse pointer interactions with the sliders much more natural and intuitive.
The reason for this change is because a mouse pointer's "position" is determined by the following
Camera Position + mouse pointer forward transform * DefaultPointerExtent.
This means that the mouse pointer's position is always DefaultPointerExtent units away from the camera, which makes the mosue pointer's position in world space change pretty drastically. In the current architecture, it's quite a bit more work to make the mouse pointer's position coincide with the position of it's raycast hit target, so this PR alleviates the high variance issue by decreasing DefaultPointerExtent to a more reasonable value of 1.
Old:
New (There are still some distances where the alignment isn't quite right when sliding):
Changes