OS Level change DESTROYS quality of pointer functionality.
After a discussion with tech support, we've established that the Oculus organization is convinced it has done this, relative to hand pointer action in Unity with the All-In-One SDK:
"Hand tracking updates
We’ve made hand tracking more stable and responsive when navigating the universal menu and in apps, making it easier to interact with your hands in mixed reality. The cursor is now stabilized as you pinch your fingers together, so making selections should be more accurate. We also improved the responsiveness and stability of drag-and-drop interactions like dragging a Browser tab into a new window. The cursor should also perform more predictably and naturally when your hands are close to your body. Finally, new cursor visuals should help locating and targeting elements with your hands."
In reality, this is not what you have done. What you've actually done, in Unity, is prioritize a limited 2-dimensional panel use case on hand pointer function that requires your interface is in the upper quadrant of your field of view and is set about 18 inches from the user. If you have that, then you still have some level of accuracy with your hand pointers anchored in the new location you've elected to anchor them; the wrists.
However, this is ABSOLUTELY NOT what everyone is doing with hand pointers. The prior design anchored the hand pointer to the forearm. This was a key insight of the Leap Motion team, who were added to the oculus team about 5 years ago. With forearm anchoring, the user has the physical strength to aim the hand pointer carefully all over the virtual space--above, below, around a full 360 degrees, allowing them to explore a full virtual space and pick up 3 dimensional objects and relocate them, with good control out to at least 4 meters. The hand pointers worked great for that use case, previously. That use case, is a use-case you've single handedly destroyed with this change of anchoring. The new system accuracy for that use case is absolute garbage now.
With a wrist anchored hand pointer, you have extremely noisy aiming which limits range from the previous range of approximately 4 meters, down to about 18 inches. With the wrist anchored hand pointers, if you aim downwards in your space, you find random noise injected by AI approximation on hand pointer aiming that actually oscillates around on its on without any extra hand input signal. This is enough to make hand pointers unusable for anything but that highly restricted use case you guys seem to think is most important. You guys made a really poor decision here and from your press releases you seem to be proud of this awful, inexperienced and uninformed change.
People have been working with this system the way it was for years, and you've just broken the software relative to all that effort.
What you've done is forget the institutional memory that understood how to manage hand pointers, and you've replaced it with a naive, and short-sighted interpretation of hand pointer operation. If you MUST support 2D panels in the upper quadrant at 18 inches away, fine, provide the new anchor point as an option, but PLEASE, DO NOT DESTROY the previous function which ALL DEVS WHO USE HAND POINTERS would have been relying upon.
Please put a switch in the software to allow continued support of the hand pointer function you've had for at least the last 5 years. This small change you've forced upon your users is enough to destroy entire user interface designs. All the user to select which anchor point you set for the hand pointers. The way it is now is just plain old bad, and not the improvement you seem to think it is. You could fix what you've done by adding a check box change which switches between the two competing geometries for hand pointer anchoring.
The hand pointer was fine in version 74 of the OS. It is version 77 that breaks it, and with tech support, we proved that the change is a feature of the operating systems, not of end user code. I'm opening up discussion about this with this post. I invite any other developers having the same problem to add to the discussion and I myself am prepared to argue for and lobby the organization to restore the prior function so the years of work I've put into my software isn't wreaked by short sighted decisions in your organization.
Thank you, in advance, for correcting this mistake, please.