Closed m-alkalbani closed 5 months ago
I think it's fine to add some clarification to the explainer. Can you explain why only 1 hand is visible?
Another quick note: Meta's XR emulator does provide handedness
, but not at the moment of input source creation. While the real device (e.g. Quest 3), provides a specific handedness
at the moment the XRInputSource became available. Which makes it slightly better to work with.
Specs do not mention this, and it is assumed that handedness
can change for an input source at any point.
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.
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. But not in the emulator 😕
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.
Yes, the chromium code generates new inputsources each time anything in the inputsource changes.
I think it's fine to add some clarification to the explainer. Can you explain why only 1 hand is visible?
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 inputSources
. I am able to work around this if I refer to handedness
, but this took some effort to figure out as it is not mentioned in the relevant docs (explainer/spec/other as above). It's currently not obvious for developers how to use handedness if they need it.
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.
Just to clarify, this is not about changing handedness
during runtime, but mainly about clarifying in the docs that handedness
is a property of XRInputSource
. This would make it easier for developers to find and use handedness
if needed (for example recognising a bimanual gesture where the left fist is closed and the right one is open).
I think it's fine to add some clarification to the explainer. Can you explain why only 1 hand is visible?
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
inputSources
. I am able to work around this if I refer tohandedness
, but this took some effort to figure out as it is not mentioned in the relevant docs (explainer/spec/other as above). It's currently not obvious for developers how to use handedness if they need it.
You index spheres by joint name: this.spheres[jointName]
, so you get an override because left hand and right hand have joints that share same names. This is your application logic issue, handedness on input sources work as intended.
handedness on input sources work as intended.
I agree handedness
on input sources works as intended. The problem is that handedness
is not mentioned in the explainer, nor the hand input spec. For new developers using the explainer as a guide, it would be helpful for us to point out that handedness
exists, and is present on XRInputSource
.
Would anyone object to me making a PR for your review?
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.