Fix Hand_IndexTip bone label mapping for OpenXR hand skeletons in OVRSkeleton

[HUAN2022A]

Summary

OVRSkeleton.BoneId overlays the legacy OVR hand family (Hand_*) and the OpenXR hand family (XRHand_*) in one flat enum whose numeric values fully overlap. BoneLabelFromBoneId dispatches on numeric value only, so legacy Hand_* IDs passed while using SkeletonType.XRHandLeft/XRHandRight resolve to the wrong joint — most visibly, BoneId.Hand_IndexTip (=20) matches case BoneId.XRHand_RingTip: (=20) and returns the ring fingertip transform instead of the index fingertip (see #120).

This PR adds an additive, opt-in helper — OVRSkeletonBoneIdExtensions — in the Movement package:

• ToXRHandBoneId(BoneId): semantic Hand_* → XRHand_* translation following the phalange annotations (Hand_Index1 → XRHand_IndexProximal, Hand_Pinky0 → XRHand_LittleMetacarpal, Hand_ForearmStub → XRHand_Wrist; non-Hand_* IDs pass through unchanged)
• GetFingerTipBoneId(SkeletonType, finger): per-skeleton-type fingertip selection, mirroring the per-type pattern the Meta XR Core SDK itself uses in OVRVirtualKeyboard

Root cause

Verified against the Meta XR Core SDK v81 sources (com.meta.xr.sdk.core, the version the issue was filed against):

• OVRPlugin.BoneId: Hand_MaxSkinnable=19, Hand_ThumbTip=19, Hand_IndexTip=20, Hand_MiddleTip=21, Hand_RingTip=22, Hand_PinkyTip=23
• OpenXR family (spec order Palm=0, Wrist=1, Thumb 2–5, Index 6–10, Middle 11–15, Ring 16–20, Little 21–25): XRHand_IndexTip=10, XRHand_RingTip=20

So Hand_IndexTip and XRHand_RingTip are the same integer. The enum's own doc comment already warns that "some values of this enum overlap each other". Counting on XRHandLeft, 19 of 24 Hand_* IDs are mislabeled by the current dispatch — Hand_IndexTip is just the instance reported in #120.

Note that OVRSkeleton.cs itself ships in com.meta.xr.sdk.core and is not part of this repository, which is why the fix lands here as a translation API rather than an edit to the switch in BoneLabelFromBoneId. Relabeling the shared numeric value 20 inside the SDK enum would rename every OpenXR hand's native ring-tip joint, so the upstream Core SDK likely needs a dispatch fix (or, minimally, a documentation clarification) on its side as well.

Fix

• 1 file changed, 139 insertions: com.meta.xr.sdk.movement/Scripts/Utils/OVRSkeletonBoneIdExtensions.cs
• No existing behavior is modified; callers opt in to the translation explicitly

Verification

Standalone C# replication of OVRPlugin.SkeletonType, all Hand_*/XRHand_* BoneId values (Core SDK v81) and the BoneLabelFromBoneId hand branches:

• 184/184 checks passed — before-fix issue reproduction (Hand_IndexTip → "XRHand_RingTip"), after-fix mapping correctness across all 24 Hand_* IDs on both XRHandLeft and XRHandRight, label integrity for all 26 native OpenXR joints, and legacy OVR hand label self-consistency
• Unity Editor compilation and on-device Quest verification were not run in this environment; all SDK types/members referenced by the new file were checked by name against the extracted v81 package sources

Checklist

• Additive only, no changes to existing public API or behavior
• Reproduction + fix covered by a deterministic table-driven test
• On-device verification (happy to add results if requested)

Fixes #120

[meta-cla]

Hi @HUAN2022A!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!