look-controls no longer manage the camera pose in VR mode (fix #3315 #3118 #3051 #2487)

[dmarcos]

Instead VRManager from THREE does update the pose applying always standing coordinates so a user height is always present in the pose: defaulting to 1.6 in the case of 3DOF headsets.

[ngokevin]

r- as is

This stacks the Vive's absolute pose in the room on top of a defined 1.6m on the camera rig. Resulting in being way too high up.

[dmarcos]

This PR adapts to the changes proposed to the THREE VRManaged in mrdoob/three.js#13158 Tested on:

• Oculus Rift
• Windows MR
• Vive

[ngokevin]

Shouldn't the non-VR mode user offset logic remain? We want a 1.6m (or configurable) user height on 2D mode, but when entering VR, use the headset pose.

See laser-controls is on the ground on desktop:

If we try to add position="0 1.6 0" to the camera rig, then in VR, the height will be too high.

[dmarcos]

@ngokevin It is up to you to put the camera where you want in 2D mode. You can just place the camera where you want. You don't need a camera rig. The default A-Frame camera is placed at 1.6m already for people they don't want to mess with it

[dmarcos]

@ngokevin Look at tracked-controls as an example

[ngokevin]

r+

Can you dump some knowledge here for future reference? Everything about the sitting to standing transform, how the camera is handled internally by three.js, etc.

[dmarcos]

The code is now much simpler than before. The camera pose is managed completely by THREE and you will always have a user scale height: Either the one coming from the VRDevice sensors or a 1.6m default otherwise. The use of sittingToStandingTransform can be safely ignored by A-Frame. All poses coming from VRDevices are normalized to standing mode. In other words, the camera height will always be relative to the ground: measured by the tracking system, inferred by the headset user configuration or default to 1.6m in the case of 3DOF headsets. I updated the commit comment to reflect what this PR ended up doing that it is different that the original camera rig approach. By normalizing to standing position it is still possible to provide a camera rig to move the user around like for instance the teleport component.

[donmccurdy]

Lots of questions about how to use this now. 😅 If camera pose is handled by THREE for 6DOF, I don't see any code here that would set the camera's position back onto the entity ... How do I look up the user's position in the scene? And how would components like teleport-controls move the player from some current position to, say, a target position at a different elevation?

In tracked-controls/index.html example I see:

<a-entity position="0 1.6 2" camera look-controls wasd-controls></a-entity>

Please correct me on any of this that is wrong:

1. For 2D devices, camera height is 1.6 and that's configurable through the position component.
2. For 3DOF devices, camera height is 1.6 and that's not configurable because it's hard coded in WebVRManager.
3. For 6DOF devices, camera position is handled by THREE, and is entirely independent of the starting position placed on the camera entity? Or it reflects initial position.x and .z but not .y?

[dmarcos]

Magic, in 0.8.0 you don't need to do el.setAttribute('position') you can modify directly el.object3D.position.set() and you will get back the correct value when doing el.getAttribute('position'). The same goes for the rotation. THREE updates the pose on the entity.

To move the user around you just create a camera rig that you move around. teleport-controls is moving to a camera rig model already (https://github.com/fernandojsg/aframe-teleport-controls/blob/master/examples/mesh/index.html#L44)

<a-entity id="cameraRig">
  <a-entity camera look-controls></a-entity>
  <a-entity hand-controls="left"></a-entity>
  <a-entity hand-controls="right"></a-entity>
</entity>

To position the camera in 2D mode you just position the camera:

<a-entity position="0 1.6 0"></a-entity>

The position is saved when entering VR mode and restored when exiting. The A-Frame default camera already sets the height to 1.6.

For 3DOF devices the height is 1.6 by default. Not configurable but you can move up and down the user with a camera rig if necessary.

[dmarcos]

Thanks to @arturitu for testing on:

• Chrome on Daydream
• Oculus Browser on GearVR
• Internet Browser on GearVR

[donmccurdy]

Ok, I think this all sounds good but just to clarify....

<a-entity id="cameraRig" position="25 100 25">
  <a-entity id="head" camera position="0 1.6 0" look-controls></a-entity>
  <a-entity teleport-controls="cameraRig: #cameraRig; teleportOrigin: #head;"></a-entity>
  <a-entity teleport-controls="cameraRig: #cameraRig; teleportOrigin: #head;"></a-entity>
</entity>

Means that...

1. The "floor" is essentially at y=100, so if my height is 1.51 meters in a 6DOF device the #cameraRig position will be left alone, but the #head position will change to 0 1.51 0, for a cumulative world position of 25 101.51 25.
2. If I need the position of the player relative to the scene floor (e.g. for nav mesh stuff) I'll use cameraRigEl.object3D.position
3. If I need the position of the player's head, I'd use cameraEl.object3D.getWorldPosition()
4. Teleport controls will move the rig, not the camera, and most community components should do the same.
5. The cameraRig can safely be rotated around the Y axis but probably users shouldn't change pitch/roll.

[dmarcos]

@donmccurdy correct to all of the above 😄

[donmccurdy]

Ok, LGTM. 👍

Other thoughts:

1. wasd-controls should probably either offer a cameraRig or cameraEl property, so that it can move the rig but set direction according to the camera heading.

2. I might delete a lot of the rotation-related stuff from universal-controls, and focus only on components that affect position instead... so for example components like touch- checkpoint- and gamepad-controls will move the rig around but will leave rotation to the look-controls component. That way things are less complicated for everyone and I can focus on things like navmesh traversal rather than these userHeight issues. 😅

[dmarcos]

@donmccurdy Can you file an issue for the wasd-controls property to indicate a camera rig?

Rotation composition is tricky 😄

[dmarcos]

Thanks everybody for your help on this PR. I got stuck for a while unable to make a decision I would feel comfortable with.

[machenmusik]

Nice!

[machenmusik]

I do think that as best practice for 6DOF we could use example that use a player rig and teleport (even if we only do the shoot-the-floor version with laser-controls)

[mattrei]

The gaze cursor is now disappearing when in VR mode on mobile devices. See related issue #3375