2.2 沉浸三角：视场角、刷新率与分辨率

2.2 沉浸三角：视场角、刷新率与分辨率

本节摘要：视场角、刷新率、分辨率构成视觉体验的沉浸三角，三者共享同一份带宽与算力，动一个就必须动另外两个。本节给出每个参数的舒适门槛、测量口径与交换规则，并回答一个高频评审问题：当算力不够时，先牺牲哪一个。

承接上一节的硬件盘点：光路与屏幕决定了"能不能"，本节的三角决定"怎么分"。它向下直接喂给第三节——延迟与刷新率本是一体两面，帧率的另一半秘密在时序里。

三个参数各自的舒适门槛

视场角（FOV）决定"窗口"有多大：人眼水平视野超过两百度的双眼合成，主流头显覆盖其中一段。视野越宽临在感越强，但边缘像差、镜片厚度、像素需求同步上涨。对眩晕的影响是双向的：视野窄像戴潜水镜，临在感崩；视野过宽而分辨率跟不上，边缘糊成一片。工程结论：在画质可保的前提下取宽，画质保不住时宁可收窄——用可调光圈把视野物理收缩，是给易感用户的合法选项（第三章的可访问性会用）。

刷新率决定"世界的心跳"。它同时影响流畅度与延迟：刷新率翻倍，帧间隔减半，运动到成像的等待同步缩短。经验门槛是必须显著高于闪烁融合阈值并覆盖头部运动速度，主流设备从低刷新率起步一路爬升，高刷新率档位在强内容下明显更耐久。低光下低占空比驱动造成的闪烁，是暗场不适的另一个来源——别把暗场不适全记在亮度头上。

分辨率决定"纹理"：以每度视角像素数（PPD）为口径才公平，因为两台设备标称像素相近而视场角不同时，清晰度可以差出一段。PPD 不足时文字发虚、远处糊团，用户会不自觉眯眼前倾，视觉疲劳累积。判定口诀：以"最常用观看距离下能否舒适阅读界面最小字号"为分辨率验收线，而不是看渲染分辨率截图。

三角怎么打架：同一份预算的三种花法

带宽与算力是共享预算：像素总量 = 视场角内每度像素数的平方 × 视场面积，刷新率再乘上去，得到每秒要填充与传输的像素量。视场拉宽或 PPD 抬高，每帧成本上涨；刷新率上调，每帧预算直接被砍。所以三角的每一次选择都是交换：宽视野低 PPD（铺量）、窄视野高 PPD（聚焦）、高刷新低特效（流畅优先）。

这张表是评审会上的谈判起点：先定场景属于哪一行，再谈参数——脱离场景谈"哪个参数重要"没有意义。

引擎侧的交换手段

预算不够时，引擎给出三个主要调节阀。动态分辨率：按帧时间反馈实时升降渲染分辨率，守住帧率底线、牺牲瞬时清晰度；注视点渲染：利用人眼中央凹分辨率远高于外围的事实，对注视区全分辨率、外围降采样渲染，节省的像素可观，代价是需要稳定的眼动追踪与延迟容忍（眼动数据晚一帧，降采样区就会错位，反而显糊）；多分辨率着色：不需要眼动硬件的折中，把屏幕分成环带，中心高边缘低，静态但稳健。

// Unity 侧动态分辨率的最小示例：用帧时间闭环守住刷新率底线
using UnityEngine;

public class FrameBudgetKeeper : MonoBehaviour
{
    public float targetFrameMs = 13.5f;   // 留出输出余量，不满打满算
    public float minScale = 0.6f, maxScale = 1.0f;
    public float adjustStep = 0.02f;

    void Update()
    {
        float frameMs = Time.unscaledDeltaTime * 1000f;
        // 用滑动窗口的思路简化为单帧判断，工程上应改为多帧平均
        if (frameMs > targetFrameMs && UniversalAnalyticsScale > minScale)
            UniversalAnalyticsScale -= adjustStep;   // 超支：降渲染比例
        else if (frameMs < targetFrameMs * 0.85f && UniversalAnalyticsScale < maxScale)
            UniversalAnalyticsScale += adjustStep;   // 有盈余：逐步回升
    }

    float UniversalAnalyticsScale
    {
        get => UnityEngine.XR.XRSettings.eyeTextureResolutionScale;
        set => UnityEngine.XR.XRSettings.eyeTextureResolutionScale = value;
    }
}
​

💡 关键直觉：动态分辨率不是"画质自动挡"那么简单，它是三角谈判的仲裁者——刷新率是红线，分辨率是缓冲垫。把哪项设成缓冲、哪项设成红线，是每个项目的舒适策略表态。

演练：给一份参数表做三角体检

拿一份虚构的一体机参数走流程：双目视场约百度的八成、标称高刷新档、渲染分辨率中等。第一步算 PPD：像素数除以视场度数，得出每度像素量级，对照"最小可读字号"验收线。第二步算帧负担：像素总量乘以最高刷新率，与平台像素吞吐上限对比，判断高刷档是否要靠动态分辨率硬撑。第三步看内容匹配：若项目是竞技类，流畅型策略成立；若是社交协作，聚焦型更优，高刷档的预算应转投 PPD。第四步写结论：三角策略一句话 + 每个参数的升降条件，贴进项目工程手册。这套流程的关键产出不是分数，而是让团队对"算力不够先砍谁"达成书面共识。

⚠️ 常见坑：评审时拿单帧渲染截图评画质。三角策略下，一帧的美不等于全程的美——掉帧瞬间的糊与拖影在截图里全部隐形，验收必须录一段带头部运动的实拍。

与延迟的接壤

三角谈完，还剩一个隐藏项：刷新率越高，帧间隔越短，运动到成像的总延迟越低——三角与延迟并非两个话题，而是同一份时序预算的两面。第三节把时间轴拉出来，逐毫秒拆解从转头到出画的整条链路，并请出重投影这件兜底工具。

高频问答：评审席上的三角问题

问：动态分辨率降到多少算过分？答：以 PPD 口径守住"最小字号可读"为底线，跌破即视为功能受损而不是画质让步；底线之上的波动用户基本无感。问：注视点渲染没有眼动硬件能用吗？答：能用头部朝向近似，但省率与稳定性都下降，且扫视跟随无从谈起——把它当"低配版多分辨率着色"用，别按完整注视点渲染验收。问：高刷新率是不是一定更好？答：在渲染跟得上的前提下是；追高刷新导致长期靠动态分辨率硬撑，等于用清晰度买流畅——三角谈判里这笔账通常不划算，除非内容是竞技类。问：视场角能后期靠软件调吗？答：能调的是渲染视场与光圈物理收缩，透镜决定的视野上限是硬件事实——宣传里的"等效视场"要追问换算口径。这四问覆盖了评审席上八成的三角争议，答案的出处都在前文对应小节。

本节回收站

• PPD 是分辨率的唯一公平口径，标称像素数会撒谎。
• 刷新率是三角的红线：它同时定价流畅度与延迟，预算再紧也不该第一个牺牲。
• 动态分辨率、注视点渲染、多分辨率着色是三个调节阀，各有硬件前提与伪影风险。
• 三角体检四步：算 PPD、算帧负担、对内容定策略、写书面共识。
• 验收必须看带头动的实拍录像，单帧截图会隐藏动态缺陷。

参数的账算完了，下一节把镜头对准时间本身：一帧从请求到点亮要经历什么，延迟到底藏在哪里，重投影何时能救场、何时反而帮倒忙。