Comments Locked

8 Comments

Back to Article

  • edzieba - Thursday, August 6, 2015 - link

    Cryengine seems a very odd choice for a VR benchmark. Cryengine has been left WELL in the dust by Unreal and Unity when it comes to VR support. Both have official support for both the Oculus Rift and HTC Vive, but thus far the only game using Cryengine with VR is Star Citizen; and that's a highly customised Cryengine variant whose VR support is at this stage only a technicality (the implementation is old and was unacceptably poorly performing back then).
  • nathanddrews - Thursday, August 6, 2015 - link

    I know that 90fps is regarded as a minimum target (ideal target) for immersion/persistence, and ideally it would be a constant 90fps locked to the refresh of the headset, but has there been any rumbling about utilizing Adaptive Sync (or G-Sync or FreeSync) for VR? If they (Oculus, Sony, Samsung, HTC, Valve, etc.) have looked into it, is there any documentation I could read? I'm guessing a constant frame rate is preferred to a fluctuating one, but since OLED displays are capable of ridiculous refresh speeds and computers are still struggling with 4K, let alone dual 1080p90 ultra streams for VR, it seems like a logical course of action. I know that John Carmack and Michael Abrash have both talked about frame rates and refresh rates around 1,000 being the "end game".
  • edzieba - Thursday, August 6, 2015 - link

    "has there been any rumbling about utilizing Adaptive Sync (or G-Sync or FreeSync) for VR?"

    Yes. It is incompatible with low persistance display driving.

    By varying the time between display updates, you vary the time between display illumination periods. This varies the perceived brightness of the display: Not Good. Worse, in order to adaptively vary the brightness of each display 'pulse' in order to maintain a perceptually steady brightness, you'd need to predict IN ADVANCE what times the next few frames will be delivered. And because VR relies on as little latency as possible, you can't just buffer frames before delivery.
  • nathanddrews - Thursday, August 6, 2015 - link

    Then wouldn't that justify a system like G-Sync to duplicate minimum frames (double/triple/etc.) to a higher refresh rate to maintain that persistence (45fps doubled to 90Hz, 30fps tripled to 90Hz)? I'm only referring to non-ideal situations where you can't maintain a perfect 90fps - what workaround do they have to mitigate these situations?

    Or are they just approaching this from the perspective of "if you can't have a perfect 90fps, then don't use VR"?
  • zepi - Thursday, August 6, 2015 - link

    VR systems actually something like this in development.

    If a new frame doesn't arrive in time to be displayed on the next display out (fixed framerate) it is possible to use the framebuffer of last frame, run the head positioning correction again using that old frame and send that to the screen. This way at least head motion doesn't stop, even though world doesn't move around you and can seem jerky.
  • edzieba - Thursday, August 6, 2015 - link

    "what workaround do they have to mitigate these situations?"

    Asynchronous TimeWarp - synthesising frames from the previous frame + the latest update from the IMU (+ fused position tracking). Previous timewarp implementations only updated the rotation matrix (slide the previous image across the view pre-warp), but the latest Rift SDK releases have added positional timewarp using the depth buffer to synthesise pixels for displaced edges.
  • nathanddrews - Thursday, August 6, 2015 - link

    Interesting, I can't wait to see it in action. Thanks!
  • jkostans - Thursday, August 6, 2015 - link

    You can see it right now: http://www.gfycat.com/Whalefreezer/oculus_060

Log in

Don't have an account? Sign up now