In a recent blog post the Amazon developer team discussed the upcoming support for VR devices in Lumberyard 1.3. This support comes in two forms, supporting actual VR devices in your game and using VR to develop your game. Both are being provided in the form of “Gems”, which is basically Amazon’s way of saying plugin. To add support for a new VR device, you create a gem that implements the IHMDDevice interface, acting as a bridge between Lumberyard and the device’s SDK.
Utilizing Gems, small chunks of code can be created that interact with the engine but don’t require editing the engine code itself. This means that developers can add support for any VR device without having to delve into the engine source. As long as a new VR device conforms to the public interfaces that Lumberyard has defined, the engine will automatically use it. Developers can create their own integrations for additional devices without having to wait for an official Lumberyard update, as they would in other engines. With so many new VR devices coming out soon, we wanted to provide a way for customers to make their own support decisions. Additionally, developers can easily override existing device support to add any experimental features that may be important for their gameplay. Below is a high-level diagram of the way this works inside the engine.
The HMDManager contains an IHMDDevice, which is then implemented by a device-specific Gem. The manager takes care of device initialization and device-abstracted head-mounted display (HMDs) interaction with the rest of the system. On the rendering side, Lumberyard’s stereo renderer makes use of the D3DHMDRender object, which takes care of creating graphics-API-specific render targets, social screen rendering, and frame submission to the VR device. To add support for any new VR devices, you simply wrap the vendor-specific SDK in a Gem as defined by IHMDDevice. That’s it! There’s no need to edit Lumberyard’s underlying HMD code, which is represented by the Lumberyard Engine section of the diagram.
On engine startup, the selected HMDs are scanned for connectivity and selected for use. If you want to support both the Rift and the Vive, for example, simply go into the Project Configurator, enable both Gems, and the engine will pick which one to use at runtime based on which device is plugged in.
They also go on to describe the new VR developer functionality that will be part of Lumberyard 1.3:
Developing in VR
Game developers need to be able to see what they’re doing in the editor at all times. Without a way to see VR in the editor, developers would have to export a level, load it into the launcher, enable VR, and take a look around. This is obviously inefficient. The Lumberyard Beta 1.3 editor will have full VR Preview support built in. VR Preview utilizes the same Gems system as the engine runtime, and it works in a similar fashion. We’ve added the “VR Preview” button to the editor, which you can click to see in VR right away. This allows developers to make VR-specific adjustments to their level designs right in the editor, which reduces iteration time. Flow Graph nodes are an important part of developing in Lumberyard, but they can only be debugged in the editor. With VR Preview, users can debug their VR Flow Graph nodes and see what they’re doing.
The cool part of their implementation is there is no performance penalty for enabling VR if VR functionality isn’t used, making this functionality “free” from a processing perspective.
So, what devices are supported? Well until 1.3 ships the answer is unknown. They address it with this comment:
Rift and HTC Vive support were top requests (our demo was presented on the Rift), but many developers were just as interested in other devices, like the Samsung GearVR, PSVR, and OSVR.
But never actually state what gems will ship with the 1.3 release, meaning it might be left to developers to implement the various VR headset SDKs.