Asynchronous spacewarp

From XVRWiki
(Redirected from Asynchronous Spacewarp)
Jump to navigation Jump to search
Asw example gif1.gif

Asynchronous spacewarp (ASW) is a graphics rendering technology that applies animation detection, camera translation, and head translation to previous frames in order to predict the next frame. It was made for the Oculus Rift.

As a result of ASW, motion is smoothed and applications can run on lower performance hardware. ASW expends upon asynchronous timewarp (ATW), which only applies to the rotational tracking of the head.

The Rift operates at 90Hz. If an application fails to submit frames at 90Hz, the Rift runtime drops the application down to 45Hz with ASW providing each intermediate frame. Asynchronous SpaceWarp (ASW) enables users to run the Oculus Rift on lower specification hardware than our current recommended specification.

ASW tends to predict linear motion better than non-linear motion. If your application is dropping frames, you can either adjust the resolution or simply allow ASW to take over.

ASW is available with the release of the Oculus 1.10 runtime. It will be enabled across all ranges of hardware and systems that support the feature, and activated for all applications. ASW will automatically engage whenever the application needs extra time for rendering. For developers the Oculus Debug Tool will provide support for controlling ASW for development purposes.

How does it work?[edit]

ASW generates extrapolated frames from previous frames generated by the VR application. On the surface, this sounds quite a bit like ATW, which is capable of extrapolating for only a single thing: the user's head rotation. While this covers many of the hitches, it's not a magic bullet. ASW works in tandem with ATW to cover all visual motion within the virtual reality experience. This includes character movement, camera movement, Touch controller movement, and the player's own positional movement. If the application falls behind the display's frame rate, the experience typically remains smooth and enjoyable.

An example of this extrapolation is shown below. We have a scene in which a held gun which is moving from right to left in frames 0 and 1 (generated 1/45th of a second apart), and we want to generate an extrapolated frame from that movement (1/90th of a second after frame 1). We detect the movement of the gun and generate a new frame which we display on behalf the application.

When it comes to virtual reality, ATW and ASW are siblings and complement each other. Timewarp is great for accommodating head rotation. In fact, it's perfect for static images at a distance. For applications like 360 videos and features on the horizon, Spacewarp is unnecessary. Conversely, Spacewarp is pretty good for animated objects up close but not so great at tracking head rotation.

With ASW, Oculus is building on ATW to produce the best virtual reality experience possible. Effective latency is kept low and head tracking as before is smooth—and now, moving elements within VR are also kept smooth.[1]

Requirements[edit]

ASW requires the following:

  • Oculus Runtime 1.9 or later
  • Windows 8 or later
  • For Nvidia, driver 373.06 or later
  • For AMD, driver 16.40.2311 or later

Until the minimum specification is released, we recommend the following GPUs for ASW testing:

Manufacturer Series Minimum RAM Minimum Model
NVIDIA Pascal 3GB 1060
Maxwell 4GB 960
AMD Polaris 4GB 470

[2]

Testing ASW[edit]

To enable ASW testing:

  1. Open your registry editor.
  2. Navigate to HKLM\Software\Oculus VR, LLC\LibOVR.
  3. Create the DWORD AswEnabled key and set it to 1.

While testing your application with ASW, you can switch between rendering modes:

  • Control-Numpad1: Disables ASW and returns to the standard rendering mode.
  • Control-Numpad2: Forces apps to 45Hz with ASW disabled. Depending on the application, you are likely to experience judder.
  • Control-Numpad3: Forces apps to 45Hz with ASW enabled. Enabling and disabling ASW will help you see the effects of ASW.
  • Control-Numpad4: Enables ASW. ASW automatically turns on and off, depending on whether the app maintains a 90Hz frame rate. This is the default runtime rendering mode.[2]

Downsides[edit]

Just as with ATW, ASW is active and enabled for all applications without any developer effort.

There's no completely free lunch, however. ASW doesn't scale well below half the display's refresh rate. Depending on what's being displayed, there may be visual artifacts present as a result of imperfect extrapolation. Typical examples include:

  1. Rapid brightness changes. Lightning, swinging lights, fades, strobe lights, and other rapid brightness changes are hard to track for ASW. These portions of the scene may waver as ASW attempts to find recognizable blocks. Some kinds of animating translucency can cause a similar effect.
  2. Object disocclusion trails. Disocclusion is a graphics term for an object moving out of the way of another. As an object moves, ASW needs something to fill the space the object leaves behind. ASW doesn't know what's going to be there, so the world behind will be stretched to fill the void. Since things don't typically move very far on the display between 45 fps frames, these trails are generally minimal and hard to spot. As an example, if you look closely at the extrapolated image from the screenshots here you'll see a tiny bit of warping to the right of the revolver.
  3. Repeated patterns with rapid movement of them. An example might be running alongside an iron gate and looking at it. Since parts of the object look similar to others, it may be hard to tell which one moved where. With ASW, these mispredictions should be minimal but occasionally noticeable.
  4. Head-locked elements move too fast to track. Some applications use a head-locked cockpit, HUD, or menu. When applications attempt to do this on their own without the help of a head-locked layer, the result can be judder because the background is moving fast against the head-locked object. Some accommodation can be made with ASW, but users can move their head fast enough that they'll no longer track properly and the result won't be smooth. Using the head-locked layers (ovrLayerFlag_HeadLocked) provided by the Oculus Rift SDK will produce the ideal result.

Outside of point 4, you shouldn't avoid scenarios that produce these artifacts but rather be mindful of their appearance. ASW works well under most, but not all, circumstances to cover sub-90fps rendering. We feel the experience of ASW is a significant improvement to judder and is largely indistinguishable from full-rate rendering in most circumstances.[1]

As a Developer, How to Make ASW Work Well[edit]

ASW enables a class of computers that were previously unable to drive VR. This means on recommended specification systems ASW should rarely be seen, if at all. Developers should maintain 90 fps rendering on recommended spec systems. Without any additional effort from the developer, the experience generally will scale to minimum spec machines and use ASW as needed. This is because apps that run at 90 fps on recommended spec systems can typically run at 45 fps on min spec systems. ASW and VR in general will benefit from the following suggestions:

  1. Use layers for head-locked content, HUDs, and menus. These items are tracked more accurately using layers in the Oculus runtime compositor. Using layers correctly will make these elements appear crisp and track correctly even if ASW is unavailable, and also allow improved image quality and readability for text.
  2. Never assume the display frame time is 1/90th of a second (or any other constant value). Run application simulations including animations and physics based on elapsed real time, not frame counts. There are a number of frame rates found on current VR headsets. The range today is anywhere from 45 fps to 120 fps. Fixing computations to any expected value will guarantee your application runs at the wrong rate on any other hardware. Timing the application to the frame rate will almost certainly result in bugs and poor experiences.
  3. Provide quality settings that are easy for users to understand. Simple Low/Medium/High quality settings allow users to tweak a preferred quality sweet spot. Esoteric or hard to understand settings will result in users poorly tuning their application settings and having a negative experience with your software.[1]

References[edit]