Skip to content
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

Added GamepadPose #25

Closed
wants to merge 2 commits into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
86 changes: 86 additions & 0 deletions index.html
Original file line number Diff line number Diff line change
Expand Up @@ -310,6 +310,13 @@ <h2><dfn>Gamepad</dfn> Interface</h2>

</dd>

<dt>readonly attribute GamepadPose? pose</dt>
<dd>
The current pose of the gamepad, if suppoerted by the hardware.
Includes position, orientation, and acceleration. If the hardware
cannot supply any pose values MUST be set to null.
</dd>

</dl>
</section>

Expand Down Expand Up @@ -365,6 +372,85 @@ <h2><dfn>GamepadButton</dfn> Interface</h2>
</dl>
</section>

<section>
<h2><dfn>GamepadPose</dfn> Interface</h2>
<p>
This interface defines the gamepad's position, orientation, and
acceleration.
</p>

<dl title='interface GamepadPose' class='idl'>
<dt>readonly attribute Float32Array? position</dt>
<dd>
Position of the gamepad as a 3D vector. Position is given in meters
from an origin point, which is determined by the gamepad hardware, and
may be the position of the gamepad when first polled if no other
reference point is available. The coordinate system uses these axis
definitions, assuming the user is holding the gamepad in the forward
orientation:

<ul>
<li>Positive X is to the user's right.</li>
<li>Positive Y is up.</li>
<li>Positive Z is behind the user.</li>
</ul>

MUST be null if the gamepad is incapable of providing positional data.
When not null MUST be a three-element array.
</dd>

<dt>readonly attribute Float32Array? linearVelocity</dt>
<dd>
Linear velocity of the gamepad in meters per second. MUST be null if
the sensor is incapable of providing linear velocity. When not null
MUST be a three-element array.
</dd>

<dt>readonly attribute Float32Array? linearAcceleration</dt>
<dd>
Linear acceleration of the gamepad in meters per second. MUST be null
if the sensor is incapable of providing linear acceleration. When not
null MUST be a three-element array.
</dd>

<dt>readonly attribute Float32Array? orientation</dt>
<dd>
Orientation of the gamepad as a quaternion. An orientation of
[0, 0, 0, 1] is considered to be "forward". The forward direction is
determined by the gamepad hardware, and may be the orientation of the
hardware when it was first polled if no other reference orientation is
available. MUST be null if the sensor is incapable of providing
orientation data. When not null MUST be a four-element array.
</dd>

<dt>readonly attribute Float32Array? angularVelocity</dt>
<dd>
Angular velocity of the gamepad in meters per second. MUST be null if
the sensor is incapable of providing angular velocity. When not null
MUST be a three-element array.
</dd>

<dt>readonly attribute Float32Array? angularAcceleration</dt>
<dd>
Angular acceleration of the gamepad in meters per second. MUST be null
if the sensor is incapable of providing angular acceleration. When not
null MUST be a three-element array.
</dd>

<dt>readonly attribute boolean hasPosition</dt>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm comfortable with Gamepad#pose, but this one not so much. can you explain other instances that are not specific to VR when we need capabilities info. that cannot be discerned from the presence of buttons and axes and their values?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I felt this was necessary for the same reason we have the capabilities structure in WebVR: a null pose.position may not actually mean the device is incapable of reporting it, only that it can't report it right now. I do feel it's important to be able to differentiate those two cases.

That said, it probably is a mistake to have it in the same PR as the pose. Two proposals:

  1. I move this to it's own PR so that this one can focus on pose exclusively. (Pose is still usable without the capabilities, just not as developer friendly)
  2. We merge the capability booleans into the pose interface. This would mark another difference from the same interface in WebVR, but I wouldn't object to it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd opt for #1. In a follow-up PR, instead of a GamepadCapabilities that seems specific to VR, can we rename the properties or have a nested object for VR-specific properties?

What about just having GamepadPose#position return undefined if the gamepad does not support positional tracking? Do you think we can perhaps opt for returning undefined, null, and Float32Arrays instead of introducing a new interface? (Or even maybe instead of having a separate GamepadCapabilities interface, could we just make hasPosition, hasOrientation, etc. be part of GamepadPose?

What are your thoughts?

(P.S. Sorry for the delays. Just got back from PTO.)

Copy link
Contributor

@cvan cvan Jul 30, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With that being said, feel free to merge the GamepadPose changes now. And let me know what you think about my suggestions re: hasPosition and hasOrientation.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll merge those properties into the GamepadPose, which allows everything VR-centric to stay in the same object.

Thanks for the vote of confidence, but I can't merge on this repo. It would have to be @luser, @sgraham or another member with write access.

<dd>
The hasPosition attribute MUST return whether the gamepad is capable
of tracking its position.
</dd>

<dt>readonly attribute boolean hasOrientation</dt>
<dd>
The hasOrientation attribute MUST return whether the gamepad is
capable of tracking its orientation.
</dd>
</dl>
</section>

<section>
<h2><dfn>GamepadMappingType</dfn> enum</h2>
<p>
Expand Down