- From: Rik Cabanier <notifications@github.com>
- Date: Tue, 01 Dec 2020 14:18:08 -0800
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/568/736855664@github.com>
> Regarding naming: I see that the [Unity hand tracking API](https://developer.oculus.com/documentation/unity/unity-handtracking/#understanding-bone-id), for example, doesn't use the medical names for bones. They use a number to indicate the joint number. I agree that the current names are not easily understood, even by native English speakers. Should we rename the joints with simpler names, much like the unity example you listed? > Each of your examples sets up a structure like: >... > ... would it work to have the API expose the hand data via a richer data structure? Actual code wouldn't use those structures. I think @Manishearth provided that to clarify how the mapping is done. > I'm also trying to understand the relationship between `hand` as a member of `XRInputSource`, and the [primary action](https://immersive-web.github.io/webxr/#primary-action) concept. Does hand input provide a way of generating a primary action? The hands API is not involved in this. Each hand will also be a "controller" which has actions associated with it. > Also, can you give some background on how hand tracking works for people who are missing or unable to use one or more fingers on the hand(s) being used for hand tracking - how does this affect the data which is provided to the application? There is an [issue](https://github.com/immersive-web/webxr-hand-input/issues/11) on this. The spec currently defines that the hand will always returns all the joints. > Finally, maybe a silly question - if an application wanted to track both hands, would that be two separate `InputSource`s? Yes :-) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/568#issuecomment-736855664
Received on Tuesday, 1 December 2020 22:18:20 UTC