VR is the most demanding real-time target in common use, for reasons that compound.
The frame rate is not negotiable
Ninety frames per second is a typical minimum, and missing it is not a quality issue — it causes discomfort. A game that drops frames on a monitor is annoying; one that drops frames in a headset makes people ill.
That converts performance from a polish concern into a design constraint.
Two eyes
The scene renders twice, from slightly different positions. Some cost is shared through single-pass stereo techniques, and much is not. Plan on substantially more than one render's cost.
Standalone headsets are mobile hardware
The most common VR devices are mobile chipsets in a headset. So mobile constraints apply — tile-based rendering, tight draw call budgets, thermal throttling — at ninety frames per second and double the rendering.
What that means practically
- Draw calls are the first ceiling. Aggressive batching and instancing are mandatory rather than advisable.
- Overdraw is punishing. Transparency budgets are very small.
- Post-processing is expensive at these resolutions and often skipped entirely.
- Dynamic lighting is limited; baked lighting remains standard.
- Polygon budgets are far below desktop equivalents.
What VR adds that screens do not
- Stereo disparity reveals flatness. Normal-mapped detail that convinces on a monitor reads as flat when each eye sees a slightly different angle. Silhouette and real geometry matter more.
- Scale is felt. Objects at the wrong size are obvious in a way they are not on screen.
- The user can look anywhere. Nothing can be faked from a fixed angle.
Generated assets for VR
Everything above argues for retopology to a low budget, texture consolidation, and a scene built from few unique materials. Generated content used at volume is exactly the wrong shape for VR unless it is consolidated first.