[avaer]

You render twice per frame: half the "screen" rendered with a camera at ([-eyeOffset, 0, 0] * cameraRot) and the other rendered with a camera at ([+eyeOffset, 0, 0] * cameraRot). The main thing is this has some surprising performance implications (such as geometry complexity being more important than shader fillrate).

You also need to keep an untraditionally high frame rate without dropping frames (90 FPS on the desktop headsets), which also has significant performance/app architecture implications.

It's actually not that radically different in terms of graphics; a game programmer should feel right at home.

The harder part is the UX implications when you realize "controlling the camera" is no longer in your hands. That might require fundamentally rethinking how your game and/or app functions.

[jsheard]

There is one major difference in terms of graphics programming - deferred rendering doesn't work well in VR since it's incompatible with proper multisampled antialiasing, and the edge-detect and/or temporal AA methods typically used instead are too blurry when combined with the low perceived resolution of today's VR headsets.

For this reason there's been a trend back towards forward rendering, with some modern twists to efficiently handle many dynamic lights like deferred does. UE4 for example:

https://docs.unrealengine.com/latest/INT/Engine/Performance/... | https://youtu.be/6kfMVxNSowM?t=3046

[sillysaurus3]

In the youtube video, they mention that moving lights can't cast shadows. https://youtu.be/6kfMVxNSowM?t=3276

That's a significant limitation for a modern technique.

Here's the full algorithm for anyone curious:

> The Forward Renderer works by culling lights and Reflection Captures to a frustum-space grid. Each pixel in the forward pass then iterates over the lights and Reflection Captures affecting it, sharing the material with them. Dynamic Shadows for Stationary Lights are computed beforehand and packed into channels of a screen-space shadow mask, leveraging the existing limit of 4 overlapping Stationary Lights.

[jsheard]

That was a limitation of the initial implementation in UE4.14, not the technique itself. They iterated on it in UE4.15: https://www.unrealengine.com/blog/unreal-engine-4-15-release...

> Forward renderer now supports shadowing from movable lights and light functions.

> Only 4 shadow casting movable or stationary lights can overlap at any point in space, otherwise the movable lights will lose their shadows and an on-screen message will be displayed.

[sillysaurus3]

Excellent! Thanks for passing along the technique. This is an interesting evolution.