Re: Proposal Virtual Reality "View Lock" Spec

On 26 Mar 2014 08:37, "Brandon Andrews" <warcraftthreeft@sbcglobal.net>
wrote:
>
> 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.
>

Hi,

I published an article today that explains how we can build VR experiences
in today's web browsers on top of the deviceorientation event:

http://dev.opera.com/articles/view/w3c-device-orientation-usage/

There's also a simple VR demo available @
http://people.opera.com/richt/release/demos/orientation/virtualreality/.

Let me know if you see anything missing from there. A lot of what you are
requesting may be best left up to fully-featured 3D frameworks.

- Rich