Moving the view

We have seen how to move objects, but how do we allow the user to move and look around?

Introduction
Till now, we have focused on movement of objects in the virtual world. In this session, we will look at moving the user in the world. What the user sees on the screen of their device is their view into the virtual world. This user view is modelled as a camera metaphor. The user’s view depends on the position and orientation of the user in the virtual world. Furthermore, what is visible to the user is limited by bounding parameters like field-of-view (FoV) and near/far clipping. These parameters define a view-volume and anything outside of this view-volume is not visible to the user. When the user moves in the virtual world, objects which were out of sight previously can become visible if they fall within the view-volume.
The user’s representation in the virtual world is mainly through the camera. Thus, the user’s movement is essentially the movement of the camera. Movement of the camera produces movement through the world which is perceived as movement of the user through the virtual world. The movement of the view happens when: a) the user intentionally provides movement input; b) the virtual world reacts to the user and triggers movement. In most situations, the movement should only happen when user provides input. This input can be implicit/sensed (e.g. gyroscope driven) as the user moves their head or explicit/input-driven (e.g. joystick, touchpad).
System driven movement (for e.g. user is moved by entities or rules of the virtual world) should be minimized. Since this movement may not be expected or anticipated, it can trigger discomfort and vection. In general, movement of the user’s view can result in the visual sensation that the user is actually moving in the real world. This will clash with the balance apparatus which won’t sense similar movement and thus create nausea and discomfort.

AFrame Default Camera
In AFrame, you don’t need to specify all the parameters of the camera or even specify the camera itself. AFrame injects a default camera into the main scene placed at a position [0, 1.6, 0] using the following code:

<a-entity camera="active: true" look-controls wasd-controls position="0 1.6 0" 
 data-aframe-default-camera>
</a-entity> 

Here, we assume that one AFrame unit is equal to 1 meter and Y-axis is upright. Thus, the position [0, 1.6, 0] sets up a view for a user who is about 1.6m tall. The two attributes, look-controls and wasd-controls allow the user to control the camera movement using mouse (or touch-screen) and the keyboard respectively. If the user is viewing the virtual world on a smartphone and they enter the VR Mode, then the camera motion control is linked directly to the headset sensors (gyroscope and accelerometer). The sensor feed is provided through the WebXR API of the browser automatically. As the user physically looks around, the camera moves to match this user movement implicitly.

Defined Camera

In certain cases, the designer of the virtual world may want to place the user at a specific location. To do so, the designer has to override the default injected camera by specifying the desired location as follows:

 <a-entity camera look-controls position="0 4.5 0" ></a-entity> 

If more control is required for position and orientation, the recommended approach is to place the camera inside a “rig” and control the rig’s position and orientation. This is achieved by using code similar to that shown below:

<a-entity id="rig" position="25 10 0" rotation="0 90 0" > 
 <a-entity id="camera" camera></a-entity> 
</a-entity> 

Animations attached to the rig entity will result in movement of the camera and thus the user’s view. This still allows AFrame to adapt the view based on the headset’s movement in VR Mode while respecting any programmed updates to overall position and orientation.

If you wish to explore the camera controls in detail, you can refer to the documentation links provided in the ‘See Also’ section below.