Fixed Foveated Rendering for Developers

Fixed foveated rendering (FFR) draws the outer parts of each eye's image at a lower resolution and keeps the middle sharp. It does not need eye tracking, which matters because most standalone Quest headsets do not have it. You choose a level, the engine applies it, and the GPU has less work to do on every frame.

This guide covers what the setting costs visually, how to pick a level, and how to test it scene by scene. If you want the wider comparison first, our fixed vs eye-tracked foveated rendering explained guide covers both approaches.

What does fixed foveated rendering actually do?

Each eye's view is split into regions. The centre keeps full detail, and the regions toward the edges are shaded at a lower resolution. Pixel shading and memory bandwidth both drop in the outer regions, so the saving shows up most in games that are limited by how many pixels the GPU has to fill.

"Fixed" means the sharp region stays in the middle of the lens rather than following the player's gaze. Most of the time people look near the centre, so a well tuned level is hard to spot. The loss is still there at the edges, and that is the trade you accept.

Which level should you choose?

Engines and SDKs name the levels differently, so treat this table as a rough guide, not a spec sheet.

Level	What you gain	What players may notice	Good fit for
Low	A small saving	Very little in calm scenes	Detailed scenes where edges matter
Medium	A balanced middle ground	Soft edges and some shimmer on fine patterns	Most scenes
High	The largest saving	Blurry detail near the edges and small text	Heavy combat where frame rate matters most

Start with medium and adjust from there based on what you measure. Do not pick the highest level just because it saves the most work. Edge artefacts can ruin a scene that otherwise runs well.

Where do the trade-offs show up?

Most problems appear in a small set of places, so check these first:

• Text and icons near the edges, such as menus or ammo counters placed far from the centre
• Fine repeating patterns like chain link fences, grates and tiled floors, which can shimmer as you turn
• Thin objects such as cables, antennas and wires, which can break up or flicker
• High contrast edges far from the centre, where aliasing becomes visible
• Fast moving targets at the periphery, which can look soft during a quick turn

The fix is usually layout rather than code. Keep critical UI near the centre, use larger type for anything important, and avoid tiny icons near the edges. Then retest.

How do you test it scene by scene?

A quick check in one room tells you very little, so work through each major scene with the same routine.

On the headset

Test on the lowest headset you support, not on a development PC or a top tier model. Turn your head slowly and then quickly through the scene, and look at edges, HUD text and fine patterns while you do it.

In the profiler

Record the same camera path at each level so you can compare frames side by side. Read frame time from a profiler or the headset's performance overlay, and note where the spikes happen.

With fresh eyes

Ask someone who has not seen the scene to point out anything that looks wrong. They will notice shimmer and blur that you have stopped seeing. Keep the notes next to the build number, and repeat the process after every art pass, because a new texture or a dense prop can change the result.

When do dynamic levels make sense?

Dynamic foveation changes the level based on measured frame time. It helps when a scene has big swings, such as a calm hub that turns into a crowded firefight. Start with a fixed level, and add dynamic control only after profiling shows spikes you cannot fix any other way.

Dynamic levels carry their own risks. If the level changes too often, players see the image pulse at the edges. Use a threshold with some margin so the level does not flip back and forth, change it gradually, and avoid large jumps while the player is reading text.

Hands, UI and the rest of the frame

Foveation only addresses the GPU side. Physics, game logic and audio still run on the CPU, so profile them alongside rendering. Our write-up on physics hands vs fixed hands in VR games explains the player facing trade-offs of each approach, which helps when you decide where to spend frame time.

Also check how your target runtime exposes foveation. Controls often come through vendor extensions rather than one shared switch. The OpenXR guide for indie developers explains the standard and why those extensions matter before you build your settings menu.

Common mistakes to avoid

• Setting one level for the whole game without checking the calm scenes
• Testing only on a development PC instead of the target headset
• Placing menus and small text at the edge of the view
• Forgetting to recheck after new props, particles or shaders go in

Fixed foveated rendering is a cheap win when you tune it per scene. Set a sensible default, test on your weakest supported headset, and keep the important parts of your interface near the centre. That combination gives you frame time back without most players noticing the change.