-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarifying docs on XRInputSource.handedness property #124
Comments
I think it's fine to add some clarification to the explainer. |
Another quick note: Meta's XR emulator does provide |
One of the editors correct me if so am wrong but I’m pretty sure handedness shouldn’t change on the fly and that if an input source needed to change handedness it would be removed and added with the new handedness. |
That is the behaviour on Quest 3 as I believe. |
Yes, the chromium code generates new inputsources each time anything in the inputsource changes. |
I attempted to draw both hands using a custom component in A-Frame by following the structure in the explainer, but this results in rendering the skeleton on one hand: for (const inputSource of inputSources) {
if (inputSource.hand) {
const hand = inputSource.hand;
for (const finger of orderedJoints) {
for (const jointName of finger) {
const joint = hand.get(jointName);
if (joint) {
const jointPose = this.frame.getJointPose(joint, this.referenceSpace);
const position = jointPose.transform.position;
if (!this.spheres[jointName]) {
this.spheres[jointName] = this.drawSphere(jointPose.radius, position);
} else {
this.spheres[jointName].object3D.position.set(position.x, position.y, position.z);
}
}
}
}
}
} Both hands are detected, but the problem is that the spheres are drawn (and overwritten) on the last detected hand when looping through |
Just to clarify, this is not about changing |
You index spheres by joint name: |
I agree Would anyone object to me making a PR for your review? |
No, PRs are always welcome |
The Hand Input Explainer does not explicitly mention the
handedness
attribute, and this causes the code samples provided to not work as expected (you end up with one visible hand when drawing the skeleton).While it's clear in the Device API spec that
handedness
is a property ofXRInputSource
, I feel it should be mentioned in the explainer, perhaps in the Accessing this API or Displaying hand models using this API sections? This would make it clear for developers that ahand
doesn't determinehandedness
, and would also provide the relevant info on how to access thehandedness
attribute if required.I am happy to create a PR to do the following:
Mention
handedness
in the relevant parts of the explainerMention
handedness
in a note in Section 3.1 of the Hand Input Module specAny thoughts? I am away early next week but I would be able to work on this later in the week.
The text was updated successfully, but these errors were encountered: