I searched, but I can't find anything relevant in the archives. Since pointer
lock is now well supported, I think it's time to begin thinking about virtual
reality APIs. Since this is a complex topic I think any spec should start
simple. With that I'm proposing we have a discussion on adding a head tracking.
This should be very generic with just position and orientation information. So
no matter if the data is coming from a webcam, a VR headset, or a pair of
glasses with eye tracking in the future the interface would be the same. This
event would be similar to mouse move with a high sample rate (which is why in
the event the head tracking and eye tracking are in the same event representing
a user's total view).
interface ViewEvent : UIEvent {
readonly attribute float roll; // radians, positive is slanting the head to
the right
readonly attribute float pitch; // radians, positive is looking up
readonly attribute float yaw; // radians, positive is looking to the right
readonly attribute float offsetX; // offset X from the calibrated center 0
in the range -1 to 1
readonly attribute float offsetY; // offset Y from the calibrated center 0
in the range -1 to 1
readonly attribute float offsetZ; // offset Z from the calibrated center 0
in the range -1 to 1, and 0 if not supported
readonly attribute float leftEyeX; // left eye X position in screen
coordinates from -1 to 1 (but not clamped) where 0 is the default if not
supported
readonly attribute float leftEyeY; // left eye Y position in screen
coordinates from -1 to 1 (but not clamped) where 0 is the default if not
supported
readonly attribute float rightEyeX; // right eye X position in screen
coordinates from -1 to 1 (but not clamped) where 0 is the default if not
supported
readonly attribute float rightEyeY; // right eye Y position in screen
coordinates from -1 to 1 (but not clamped) where 0 is the default if not
supported
}
Then like the pointer lock spec the user would be able to request view lock to
begin sampling head tracking data from the selected source. There would thus be
a view lock change event.
(It's not clear how the browser would list which sources to let the user choose
from. So if they had a webcam method that the browser offered and an Oculus
Rift then both would show and the user would need to choose).
Now for discussion. Are there any features missing from the proposed head
tracking API or features that VR headsets offer that need to be included from
the beginning? Also I'm not sure what it should be called. I like "view lock",
but it was my first thought so "head tracking" or something else might fit the
scope of the problem better.
Some justifications. The offset and head orientation are self explanatory and
calibrated by the device. The eye offsets would be more for a UI that selects
or highlights things as the user moves their eyes around. Examples would be a
web enabled HUD on VR glasses and a laptop with a precision webcam. The user
calibrates with their device software which reports the range (-1, -1) to (1,
1) in screen space. The values are not clamped so the user can look beyond the
calibrated ranges. Separate left and right eye values enable precision and
versatility since most hardware supporting eye tracking will have raw values
for each eye.
