Back to Blog

Why looks fine on desktop fails in XR

Desktop 3D applications and XR applications have fundamentally different performance requirements. A model that renders acceptably on desktop at 30fps fails in XR where 60-90fps is mandatory. Stereo rendering doubles GPU cost. Viewing distance and field of view expose details invisible on desktop monitors. Assumptions from desktop development do not transfer to XR.

Frame rate requirements are non-negotiable in XR. Desktop applications tolerate 30fps. XR requires 60fps minimum, 90fps preferred. Dropping below 60fps causes motion sickness. Each frame must complete in 11ms for 90fps or 16ms for 60fps. Desktop applications have 33ms per frame at 30fps. XR has half the time budget with twice the rendering cost due to stereo.

Stereo rendering doubles draw calls and fragment shading cost. Each eye requires a separate render pass. A scene with 100 draw calls becomes 200 draw calls in stereo. Fragment shaders execute twice for every pixel. A desktop application rendering 1920x1080 processes 2M pixels per frame. VR at 2880x1600 per eye processes 9.2M pixels per frame. This is 4.6x more fragment shading work.

Viewing distance in XR is closer than desktop. Desktop users sit 50-100cm from monitors. XR users hold objects 20-50cm from their eyes. Details invisible on desktop become obvious in XR. Low-resolution textures, polygon edges, and normal map artifacts are visible. Models that look fine on desktop appear low-quality in XR.

Field of view is wider in XR. Desktop monitors have 60-90 degree FOV. VR headsets have 90-110 degree FOV. This increases the visible portion of the scene. More objects are on-screen simultaneously. Culling and LOD systems designed for desktop FOV fail to reduce load in XR. You must render more geometry per frame.

Texture resolution requirements increase in XR. A 1024x1024 texture looks acceptable on a desktop monitor at 1920x1080. The same texture in VR at 2880x1600 per eye appears blurry. Objects close to the camera need 2048x2048 or 4096x4096 textures. This quadruples texture memory usage. Desktop memory budgets do not apply to mobile XR.

Polygon density requirements differ by viewing distance. Desktop applications use 10k-50k triangles for hero assets viewed from 2-5 meters. XR applications need 30k-100k triangles for objects viewed from 0.5-2 meters. Silhouettes and surface curvature must hold up under close inspection. Desktop LOD systems that switch at 5 meters are too aggressive for XR.

Lighting and shadows are more expensive in XR. Desktop applications render one shadow map per light. XR requires two shadow maps (one per eye) or a single high-resolution map covering both eyes. Real-time shadows at 90fps are prohibitively expensive on mobile XR. Baked lighting and lightmaps are essential. Dynamic shadows must be limited to one or two lights.

Shader complexity limits differ. Desktop GPUs have 10-100x more ALU throughput than mobile GPUs. Complex PBR shaders with multiple texture lookups run fine on desktop but drop frames on mobile XR. Disable features like clearcoat, sheen, and anisotropy on mobile. Use simplified shaders with fewer texture samples and math operations.

Antialiasing requirements increase in XR. Desktop applications use TAA or FXAA at 1920x1080. XR requires MSAA 4x or higher at 2880x1600 per eye. MSAA multiplies fragment shading cost by the sample count. 4x MSAA quadruples fragment shader cost. This is on top of the 4.6x increase from stereo and resolution. Total fragment cost is 18x higher than desktop.

Memory bandwidth is constrained on mobile XR. Desktop GPUs have 200-500 GB/s memory bandwidth. Mobile GPUs have 10-30 GB/s. Texture fetches and framebuffer writes are bandwidth-limited. High-resolution textures and large framebuffers cause memory stalls. Compress textures aggressively. Reduce framebuffer resolution. Use foveated rendering if available.

Thermal throttling affects mobile XR. Desktop GPUs have active cooling and maintain peak performance indefinitely. Mobile GPUs throttle after 5-10 minutes of sustained load. Frame rate drops from 90fps to 60fps or lower. Design experiences to run within thermal budgets. Reduce rendering complexity after initial load. Use lower LODs for extended sessions.

Input latency is critical in XR. Desktop applications tolerate 50-100ms input latency. XR requires under 20ms latency to avoid motion sickness. This includes sensor tracking, rendering, and display refresh. Any delay between head movement and visual update causes discomfort. Optimize rendering to minimize latency. Use predictive tracking to compensate for display lag.

Depth perception changes optimization priorities. Desktop applications optimize for screen-space metrics (pixels, draw calls). XR applications optimize for world-space metrics (viewing distance, object size). A 1-pixel error on desktop is a 1mm error in XR at 50cm viewing distance. Quantization and LOD errors that are invisible on desktop become visible in XR.

Testing on desktop does not predict XR performance. Desktop GPUs are 10-100x faster than mobile XR GPUs. A scene that runs at 60fps on desktop may run at 10fps on mobile XR. Always test on target hardware. Use device profilers to measure frame time. Optimize until the experience runs at 60fps minimum on the lowest-spec device you support.

Avoid common mistakes: do not use desktop performance as a proxy for XR performance, do not assume 30fps is acceptable, do not ignore stereo rendering cost, do not use desktop texture resolutions, do not skip compression, do not use complex shaders, do not rely on dynamic shadows, do not test only on high-end devices. These mistakes cause motion sickness and poor user experience.

The workflow for XR optimization: model on desktop, export at target resolution, compress with OptimiXR, test on actual XR hardware, iterate. Do not optimize prematurely on desktop. Desktop tools and metrics do not reflect XR constraints. Build for XR from the start. Use XR-specific performance budgets. Test early and often on real devices.

Desktop and XR are different platforms with different constraints. Treat them as such. Do not assume desktop best practices apply to XR. Learn XR-specific optimization techniques. Use tools like OptimiXR compress to prepare models for XR deployment. Test on target hardware. The goal is not to make desktop models work in XR but to build models specifically for XR from the beginning.