Update with support for WebVR "1.1"

[toji]

These changes enable VREffect and VRControls to use the newly recommended WebVR best practices when the updated version of the API is detected.

Also took the opportunity to remove the really old code path because I don't think anyone is actually using it anymore. The browsers that it supported have all been updated to at least the WebVR 1.0 spec.

[mrdoob]

Thanks!

[mrdoob]

Thanks!

[mrdoob]

I guess this file also needs some updating?
https://github.com/mrdoob/three.js/blob/dev/examples/js/WebVR.js

[mrdoob]

I guess this file also needs some updating?
https://github.com/mrdoob/three.js/blob/dev/examples/js/WebVR.js

[toji]

I guess that isLatestAvailable should probably check for something else, like the presence of VRFrameData. We can probably also strip out the checks for the older API.

I can put up another pull request for that tomorrow.

[toji]

I guess that isLatestAvailable should probably check for something else, like the presence of VRFrameData. We can probably also strip out the checks for the older API.

I can put up another pull request for that tomorrow.

[mflux]

Any updates on this? Seems like using the latest THREE.ViveController will give:

Cannot read property 'position' of undefined

upon doing

var pose = gamepad.pose;

[mflux]

Any updates on this? Seems like using the latest THREE.ViveController will give:

Cannot read property 'position' of undefined

upon doing

var pose = gamepad.pose;

[toji]

If you're using Chrome with the WebVR 1.1 builds you'll need to go into about:flags and turn on "Gamepad Extensions".

Yeah, that sucks. Sorry. I'm gonna work out a system where that's not necessary soon. It's just a side effect of trying to upstream everything into Chrome proper. (Though this does make me think that I should simply not expose the Vive wands at all if the flag isn't flipped. Would be less confusing that way.)

[toji]

If you're using Chrome with the WebVR 1.1 builds you'll need to go into about:flags and turn on "Gamepad Extensions".

Yeah, that sucks. Sorry. I'm gonna work out a system where that's not necessary soon. It's just a side effect of trying to upstream everything into Chrome proper. (Though this does make me think that I should simply not expose the Vive wands at all if the flag isn't flipped. Would be less confusing that way.)

[mflux]

Ohhhh that's what that issue was. Right, thanks, I remember reading that in the release docs now.

[mflux]

Ohhhh that's what that issue was. Right, thanks, I remember reading that in the release docs now.

[mflux]

Since this changed, there's an additional issue where THREE.ViveController is checking if gamepad.pose == null when it should be checking against undefined, I'll tag that as an issue.

[mflux]

Since this changed, there's an additional issue where THREE.ViveController is checking if gamepad.pose == null when it should be checking against undefined, I'll tag that as an issue.

[toji]

It should probably just check for if (!gamepad.pose). It'll be undefined if the flag isn't flipped (which should be a temporary thing ultimately) and null if the gamepad has no pose to report.

And no worries about forgetting the flag. I've only done that about 10 times myself, and I'm the one who put the flag in there. :P My goal is to get away from flag flipping as fast as possible.

[toji]

It should probably just check for if (!gamepad.pose). It'll be undefined if the flag isn't flipped (which should be a temporary thing ultimately) and null if the gamepad has no pose to report.

And no worries about forgetting the flag. I've only done that about 10 times myself, and I'm the one who put the flag in there. :P My goal is to get away from flag flipping as fast as possible.

[mflux]

Oh that's a good point. Will update the issue.

[mflux]

Oh that's a good point. Will update the issue.

[mflux]

Strangely, if ( gamepad !== undefined && !gamepad.pose ) doesn't actually work and I've no idea why.

[mflux]

Strangely, if ( gamepad !== undefined && !gamepad.pose ) doesn't actually work and I've no idea why.