A VR productivity tool (ie anything that's for work and not just a game) must be networked between players/users so that experienced people can show new people how to operate the software, since the normal method of the expert looking over the shoulder of the student and pointing things out is not possible.
But before you can network the VR players, you have to have avatars that can copy the motions of a single player's headset and controllers/hands. In some circumstances, hand-tracking could be the dominant form of UI, particularly for AR applications when interaction with the computer is not happening 100% of the time. So, for example, in a FPS game where you are using them all the time controllers are okay, but if the user is intermittently interacting with the computer, such as to change a tab every few minutes, nobody is going to want to have to keep picking them up.
Therefore, if hand-tracking is going to be part of the UI, then it has to be networked so that experts can show novices how to make the gesture-controls. And it adds to the band-width of communication between individuals at no extra cost in hardware (unlike full body tracking at the moment).
The above argument comes from lessons learned from this project: https://sidequestvr.com/app/1630/tunnelvr https://github.com/goatchurchprime/tunnelvr/
Mapping from Oculus Quest (and other VR control systems) to an apparently standardized avatar used my Mozilla Hubs here https://github.com/MozillaReality/hubs-avatar-pipelines/tree/master/Blender/AvatarBot and generated by https://readyplayer.me/
Based on a copy of the OQ_Toolkit directory copied in from here: https://github.com/NeoSpark314/godot_oculus_quest_toolkit/
(It would be preferable to bring in this OQ_Toolkit dependency from the AssetLib rather than include it in this repo, but without it the project cannot be opened because it derives nodes directly from its contents.)
The binary addons vr drivers are not included, so you need to fetch the godot-openvr one from the godot AssetLib and copy the up to date binaries for godot_ovrmobile from the https://github.com/NeoSpark314/godot_oculus_quest_toolkit/tree/master/addons/godot_ovrmobile until the AssetLib one is updated.
Remember when using the OQ_Toolkit you need to set the Autoload to vr = OQ_Toolkit/vr_autoload.gd
The fundamental bone transform equation is:
a * b = Transform(a.basis * b.basis, a.origin + a.basis * b.origin)
The translation happens first, followed by the rotation at each of the pose joints. I believe this explains why there appears to be an extra row of joints in the palm of the hand in the w3c spec: https://www.w3.org/TR/webxr-hand-input-1/#skeleton-joints-section even though there is no bending there -- it's to allow a change of frame before we hit the first row of knuckles. If the bone transforms worked the other way (first rotation, then translation), then you wouldn't need these joints.
The Quest hand model only keeps the extra palm joints for the thumb and the pinky. But since its translation vectors are in a totally different direction to the Hubs avatar hand, and there are fewer bones, it's not easily compatible.
The basic idea of this conversion is that I calculate the absolute positions of all the knuckles in the hands from the Quest api by composing these rotations with the rest bone transforms in the system model. https://developer.oculus.com/documentation/native/android/mobile-hand-tracking/?locale=en_GB Then, after aligning the wrist/palm plane as best I can in the plane defined by the index and pinky knuckles, I fold each of the avatar's bones towards the next knuckle and extend it to meet.
It works as well as I can make it, but it's sometimes horrible in the area between the thumb and index finger. I wouldn't necessarily call it a success. One may simply need to add in the Quest based hands for all avatars (with their hands switched off) and somehow find a way to copy across the skin colour.