In general, Oculus discourages the use of traditional HUDs. Instead, we encourage developers to embed that information into the environment. Although certain old conventions can work with thoughtful re-design that is mindful of the demands of stereoscopic vision (see: reticle example below), simply porting over the HUD from a non-VR game into VR content introduces new issues that make them impractical or even discomforting.
First, HUDs occlude (appear in front of) everything in the 3D scene. This isn’t a problem in non-stereoscopic games, because the user can easily assume that the HUD actually is in front of everything else. Unfortunately, adding binocular disparity (the slight differences between the images projected to each eye) as a depth cue can create a contradiction if a scene element comes closer to the user than the depth plane of the HUD: based on occlusion, the HUD is perceived as closer than the scene element because it covers everything behind it, yet binocular disparity indicates that the HUD is farther away than the scene element it occludes. This can lead to difficulty and/or discomfort when trying to fuse the images for either the HUD or the environment.
Although moving the HUD closer to the user might prevent visual contradictions of occlusion and disparity, the proximity necessary to prevent problems will most likely bring the interface closer than the recommended minimum comfortable distance, 75 cm. Setting the player’s clipping boundary at the depth of the HUD similarly introduces issues, as users will feel artificially distanced from objects in the environment. Although they might work within particular contexts that can circumvent these issues, HUDs can quickly feel like a clunky relic in VR and generally should be deprecated in favor of more user-friendly options.
Instead, consider building informational devices into the environment itself. Remember that users can move their heads to glean information in a natural and intuitive way that might not work in traditional video games. For instance, rather than a mini map and compass in a HUD, the player might get their bearings by glancing down at an actual map and compass in their avatar’s hands or cockpit. This is not to say realism is necessary; enemy health gauges might float magically over their heads. What’s important is presenting information in a clear and comfortable way that does not interfere with the player’s ability to perceive a clear, single image of the environment or the information they are trying to gather.
Targeting reticles are an excellent illustration of adapting old paradigms to VR. While a reticle is critical for accurate aiming, simply pasting it over the scene at a fixed depth plane will not yield the reticle behavior players expect in a game. If the reticle appears at a depth plane different from where the eyes are converged, it is perceived as a double image. In order for the targeting reticle to work the same way it does in traditional video games, it must be drawn directly onto the object it is targeting on screen, presumably where the user’s eyes are converged when aiming. The reticle itself can be a fixed size that appears bigger or smaller with distance, or you can program it to maintain an absolute size to the user; this is largely an aesthetic decision for the designer. This simply goes to show that some old paradigms can be ported over to VR, but not without careful modification and design for the demands of the new medium.
An avatar is a visible representation of a user’s body in a virtual world that typically corresponds to the user’s position, movement and gestures. The user can see their own virtual body and observe how other users see and interact with them. Since VR is often a first person experience, many VR applications dispense with any representation of the user whatsoever, and therefore the user is simply disembodied in virtual space.
Avatars have pros and cons. On the one hand, an avatar can give users a strong sense of scale and of their body’s volume in the virtual world. On the other hand, presenting a realistic avatar body that contradicts the user’s proprioception (e.g., a walking body while they are seated) can feel peculiar. At public demonstrations with the Rift, users generally react positively to being able to see their virtual bodies, and so avatars can serve as a means of eliciting an aesthetic response. Like anything else in this young medium, user testing and evaluation are necessary to see what works best for your experience.
In first person shooters, weapons typically appear towards the bottom of the screen, positioned as though the user is holding and aiming them. Spatially, this means that the weapon is much closer than anything else in the scene. In a typical non-stereoscopic game, this doesn’t create any special problems, and we accept that we are seeing a big, close-up object superimposed over a scene at a normal distance.
However, when this is translated into a stereoscopic implementation, things get a little more complicated. Rendering weapons and tools so close to the camera requires the user to make large changes in eye convergence when looking between the weapon to the rest of the scene. Also, because the weapon is so close to the viewer, the left and right views can be significantly different and difficult to resolve into a single three-dimensional view.
The approach we find most comfortable is to position the cameras just above the neck of a headless, full-body avatar, as described above. Weapons and tools are rendered as part of the user avatar, which can hold them up during use, but otherwise drop them out of view.
There are some possible “cheats” to rendering weapons and tools in the player’s view, and although we do not endorse them, your content might require or be suited to some variation on them. One possibility is to render weapons in 2D, behind your HUD if you have one. This takes care of some of the convergence and fusion problems at the expense of making the weapon look flat and artificial.
Another possible approach is to employ multi-rigging, so that close-up objects (e.g., cockpit, helmet, gun) are separate from the main world and independently employ a different camera separation from the environment. This method runs the risk of creating visual flaws, such as foreground objects appearing stereoscopically further away than the background behind them, and are discouraged.
Iterative experimentation and user testing might reveal an optimal solution for your content that differs from anything here, but our current recommendation is to implement weapons and tools as a component of the user’s avatar.