Hardware & VR Performance

A desktop view renders the scene once, to one image, typically targeting 60fps - a 16.7ms budget. VR changes three things at once, and they compound. First, it renders the scene twice - a slightly different image for each eye, to produce stereo depth. Second, it targets a higher frame rate - 90fps is the comfortable floor, some headsets 120 - so the budget shrinks to about 11.1ms or less. Third, headset displays are high resolution per eye, and the image is rendered at even higher internal resolution before lens distortion correction, so each of those two images is itself large.

Stack them up and VR is roughly double the desktop cost, or more - two eyes times a shorter budget times a big per-eye resolution. A scene that runs a comfortable 60fps on a monitor will not simply run in VR; it has to run at 90fps twice over. This is why you cannot treat VR as 'the same scene with a headset plugged in', and why the headroom discipline from the whole module matters most here.

The engine fights back with VR-specific tricks. Instanced stereo rendering draws both eyes in a single pass, sharing the CPU work of describing the scene rather than doing it twice - a large saving on the draw thread. Foveated rendering, where the headset supports eye-tracking, renders the centre of your gaze at full resolution and the periphery lower, exploiting the fact that your eye only sees sharp detail where it is pointed. These help materially, but they reduce the multiplier rather than removing it. Plan for VR costing about twice a desktop view and you will not be caught out.

Real-time archviz leans on three parts of the machine, and it helps to know what each does so you upgrade the right one. The GPU (graphics card) draws the pixels - it is the single most important component, and the first thing to upgrade for VR, because VR's doubled pixel load lands squarely on it. For desktop archviz a solid modern gaming GPU is the baseline; for VR you want a distinctly stronger one with headroom to hold 90fps twice over. The CPU runs the game logic, physics, animation and - crucially - the draw thread that issues draw calls; a scene that is CPU-bound on Draw (from the profiling lesson) is limited by the CPU no matter how strong the GPU. A good multi-core CPU keeps the draw thread and game logic fed. VRAM (the memory on the graphics card) holds your textures, meshes and Nanite data; run out and performance falls off a cliff as data thrashes. Texture-heavy interiors and VR are the hungry cases - 8GB is workable but tight, and 12GB or more is comfortable, especially for VR.

There is no single 'required' spec - it scales with scene complexity and target - but the shape is reliable: GPU first for VR and fidelity, a strong multi-core CPU for draw-call-heavy scenes, and enough VRAM to hold your textures without thrashing. When you plan a project, plan it against the hardware it will actually run and be shown on, which is very often not your workstation.

A useful way to think about the upgrade path: for a desktop deliverable you are usually balancing GPU and VRAM against scene richness, and a strong mid-to-high gaming card handles most archviz comfortably. Step up to VR and the same scene suddenly needs meaningful headroom on top - so the GPU is where the money goes first, then VRAM to hold textures for two eyes without thrashing, with the CPU mattering most when your scene is draw-call heavy. Storage matters too but quietly: Nanite and virtual textures stream from disk, so a fast SSD keeps that streaming smooth and prevents hitches as you move. None of this is a fixed shopping list - it is a way to reason about where a given scene will bottleneck so you spend on the part that is actually limiting you rather than the part that is easiest to buy.

Frame rate can be bought two ways: with more hardware or with lower settings. They are two ends of one slider, and skilled delivery is choosing the right point on it for the machine and the deliverable. You cannot always specify the client's computer, but you can almost always tune the experience to run well on it.

The most powerful single dial is resolution scale (screen percentage) - rendering internally at, say, 80% and upscaling. Because cost scales with pixel count, a modest resolution drop buys a large frame-rate gain, often with little perceived quality loss, especially with modern temporal upscalers. Beyond that, the familiar dials: shadow quality and shadow distance, Lumen (global illumination and reflections) quality - which can be softened or, for a lighter scene, swapped for baked or simpler lighting - anti-aliasing and post-processing cost, translucency and reflection quality, and view/cull distances. Unreal's Scalability settings bundle these into Low/Medium/High/Epic tiers you can switch as a starting point, then fine-tune.

The craft is to spend the budget where the viewer looks and cut where they will not notice. In an interior, protect material and light fidelity because that is what sells the room, and claw back frame rate from resolution scale and shadow distance instead. In VR, comfort - a locked frame rate - outranks fidelity every time, so you cut settings harder and without apology, because a smooth slightly-softer scene beats a beautiful one that makes people ill.

All of this converges on one professional obligation: the experience must be smooth on the hardware where it will actually be seen. A stutter-free 60fps desktop walk on the client's laptop, or a locked 90fps in the headset they will wear, is worth more than a spectacular scene that only your workstation can run.

Build that in from the start. Know the target machine early - ask what the client will present on, or decide the minimum spec you will support, before you tune anything. Profile on that machine, or its equivalent, not only on your own - a scene that flies on your rig can crawl on theirs, and stat unit on the target tells the truth. Build in headroom: aim comfortably above the target frame rate so the odd busy view (a wide shot with everything visible) does not drop below it, and in VR treat the 90fps floor as non-negotiable. Choose the delivery format to match: a packaged executable runs at full native performance on a capable machine, while pixel streaming (covered in Module 10) renders in the cloud and streams video, letting a weak client device run a heavy scene at the cost of latency and streaming infrastructure - a genuinely useful escape hatch when the client hardware simply cannot cope.

The throughline of this whole module is now complete: Nanite tames geometry, profiling finds the real bottleneck, the classic levers claw back frame rate, and hardware-aware delivery lands it smoothly where it counts. Optimization is not a grim final chore - it is what turns an impressive scene into a reliable experience, and reliability is what a client remembers. Master this, and you can promise smoothness and keep the promise.