Proposal Virtual Reality "View Lock" Spec

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.

Received on Wednesday, 26 March 2014 07:34:49 UTC