Don't activate pointer lock if headset is connected and/or in VR mode

[ngokevin]

Description:

[dmarcos]

I'm still skeptical about pointer lock by default. With pointer lock you need content to provide gaze based or alternative selection mechanisms while a cursor based raycaster is probably the best solution and not compatible with pointer lock. With respect to my personal workflow. Developing and testing is a worse experience than before since I have to hit Esc continuously to unlock my cursor.

[ngokevin]

I would disable the pointer lock for development purposes.

In production, I think providing a reticle-based raycaster is best, how most games do it. Before, mouse drag and mouse-based raycaster was conflated, sometimes you'd want to drag the camera, but accidentally interact with the scene.

[dmarcos]

The mindset you approach a game is totally different than the expectations when you are browsing the Web. The screen real estate is shared with other elements like 2D elements in the Web site or the browser URL or tab bars that pointer lock makes harder to interact with. When you launch a game you are fully committed to it and are not expected to multitask in the same way you do when browsing the Web. The conflation between drag and mouse based raycaster could be solvable by delaying a bit the clicks to see if they are followed by a drag movement. Ultimately, A-Frame is focused in VR and the 2D mode is not the expected primary mode of interaction with content. It is more like a preview mode.

Pointer lock makes development and casual Web browsing more tedious. It optimizes for exclusive long sessions interacting with a specific piece that I do not think it will be the general case in the Web as it is in more traditional games.

[dmarcos]

For development purposes I do not always have control of the different experiences I have to debug / test or QA. The fact that pointer lock will be the default makes it harder.

[arpu]

After pointer lock reached master, i do some testing, it "feels" not good for me, so i revert back to mouse drag ( maybe its only for me because i working a lot with 360 videos)

[dmarcos]

I agree, I don't think pointer lock improves the experience when viewing panoramas or 360 videos.

[machenmusik]

Another vote against pointer lock being on by default, it breaks basic functions like click to play... https://aframevr.slack.com/archives/C0GG937RN/p1516719309000891?thread_ts=1516719309.000891&cid=C0GG937RN

[machenmusik]

The standard way to distinguish between click and drag is to capture position on down, and check to see whether position has changed beyond tolerance on move and/or up... if yes then it's drag, if always no then it's click. Not sure why that should be any different here?

[donmccurdy]

The mindset you approach a game is totally different than the expectations when you are browsing the Web. The screen real estate is shared with other elements like 2D elements in the Web site or the browser URL or tab bars that pointer lock makes harder to interact with.

Ultimately, A-Frame is focused in VR and the 2D mode is not the expected primary mode of interaction with content. It is more like a preview mode.

I think the fact that A-Frame is focused on immersive VR means that sharing screen real estate with other 2D elements is not a primary use case, and so the fact that tab bars are harder to interact with isn't high-priority. I also agree that pointerlock is not preferable for panoramas or 360º videos. But for example in an immersive social VR experience where users on desktop 2D want to look around and feel present alongside users in VR, I think that pointerlock is a good improvement, more like a traditional video game experience.

But yeah I'm completely fine with setting pointerLockEnabled=false by default, as long as the option is there and we don't have to tell users to re-implement look-controls I'm happy. :)

[dmarcos]

@donmccurdy Yeah, I'm happy with keeping the code. The controversy is only on which mode should be the default.

[arturitu]

I prefer 'false' by default because with Edge on Mixed Reality portal, when you are in 2D mode (into a 6DoF room but showing your webVR content on a 2D floating window on Edge) if the webpage is trying to lock the cursor, a confirm dialog appears to allow or not to hide the pointer, and if you click Yes, the controllers disappear and is hard to know where are you pointing.

[donmccurdy]

Ok, let's set pointerLockEnabled to false by default.

When pointerLockEnabled is manually turned on, should we also ignore the setting if utils.device.checkHeadsetConnected() returns true? Can't use sceneEl.is('vr-mode') since that also fires in fullscreen mode... Any better indicators?

[ngokevin]

Yeah I have a branch with that. I'm OK with it false by default.

[ngokevin]

Well all I have is:

+    if (this.data.pointerLockEnabled && !this.pointerLocked &&
+        !(this.el.sceneEl.is('vr-mode') && utils.device.checkHeadsetConnected())) {

Have not written tests yet

[donmccurdy]

Looks about right 👍

[dmarcos]

@ngokevin any pending work here?