企业官网建设流程全解析

2. 从光学设计到 Unity 呈现：为什么“无畸变”这么重要

先说结论：所谓“无畸变目镜”，并不是真的让镜头畸变为零，而是在虚拟现实和增强现实的光学系统中，通过“预畸变”或“逆向校正”的方式，让最终人眼看到的画面保持横平竖直。这个方案在 VirtualLab 里做光学仿真验证，再通过 Unity 完成实时渲染和交互呈现，是目前做 VR 头显、AR 眼镜、以及各类近眼显示原型时非常常见的一条技术链路。

我最早接触这个课题，是在做一款轻量级 VR 头显的显示模组评估。当时团队拿到一个现成的目镜光学系统，MTF 曲线和畸变数据都挺好看，但一旦接入 Unity 渲染的画面，测试者普遍反馈“画面边缘变形严重”“直线变弯了”“转头时画面像在水里晃动”。后来才意识到，问题不是渲染引擎不行，而是显示面板上的画面根本没有针对目镜光学系统做预处理。简单说，光学系统本身有畸变，人眼透过它看到的就是畸变后的画面；如果我们在图像源上提前做一个反向畸变，两者叠加，最终人眼看到的就能接近无畸变效果。

这也是为什么 VirtualLab 和 Unity 会出现在同一个项目里：VirtualLab 负责把光学系统的畸变场精确测量和建模出来，Unity 负责把畸变校正后的图像实时渲染并输出到微显示屏上。这个组合在工程上非常实用，而且能覆盖从光学仿真到交互验证的完整闭环。

这篇文章重点围绕“VirtualLab Unity 应用：无畸变目镜”展开，我会把整条链路拆开讲清楚：如何用 VirtualLab 获取畸变数据、如何在 Unity 里实现网格畸变校正、怎样保证实时性能、以及我在实际项目中踩过哪些坑。适合正在做 VR/AR 近眼显示、数字孪生可视化、以及需要把光学仿真和 Unity 渲染结合起来的朋友参考。

2. 内容整体设计与思路拆解

2.1 为什么选择 VirtualLab 做光学仿真

VirtualLab 是一款基于场追迹（Field Tracing）的光学仿真软件，它的核心优势在于把几何光学和物理光学统一在同一个框架下处理。对于目镜这种既有大视场角、又有明显像差的系统，普通光线追迹软件也能给出畸变数据，但 VirtualLab 能更进一步：直接输出完整的位相分布、场分布、以及任意像面上的畸变网格。这意味着我们不仅能拿到“畸变多少”，还能拿到“每个视场点对应的精确像点位置”，而这正是后续做 Unity 校正网格时最需要的信息。

具体到目镜设计，VirtualLab 特别适合处理以下几个问题：

• 大视场目镜的畸变场计算，包括径向畸变和切向畸变；
• 出瞳位置的场分布分析，判断边缘视场的光线是否被拦光；
• 微显示屏到目镜之间的照明均匀性；
• 非球面、自由曲面目镜的建模与公差分析。

我们在项目里用的方案是：先在 CAD 里建好目镜的机械结构和镜片模型，导入 VirtualLab，设置好光源波长（常用绿光 550nm，或者 RGB 三色）、视场角范围、入瞳直径，然后跑一次场追迹。VirtualLab 会输出一个像面网格，每个网格点对应一个视场角下的像点实际位置。这个网格就是后续畸变校正的核心输入。

2.2 在 Unity 中呈现的光学逻辑：预畸变与后校正

Unity 本身不会“自动理解”光学系统的畸变。它只负责把相机渲染出的图像输出到显示设备。换句话说，Unity 输出的是理想的无畸变画面，但一旦经过目镜光学系统，画面就变成了带畸变的画面。所以我们需要在 Unity 的渲染管线中插入一道“预畸变”处理，让最终光学输出端的画面是正常的。

打个比方：目镜像一面哈哈镜，你看到的是被扭曲的世界。要让他看起来正常，就得在源头给一幅“反着扭曲”的画面，两者一抵消，正好正常。这就像用一个反向滤镜去中和镜头本身的畸变，本质上是“预补偿”而不是“事后修复”。

在 Unity 中做预畸变，常用方案是后处理：先用一个 Render Texture 拿到主相机渲染的画面，然后通过一个畸变校正 Shader 对画面做 UV 重映射，再把处理后的结果输出到显示面板。这个方案的优点是灵活，畸变参数可以实时调节；缺点是多了一次全屏后处理，对性能有一定要求。针对移动端 VR 或一体机（比如 Pico 4）的场景，优化空间非常大，后面我会详细讲。

2.3 从 VirtualLab 数据到 Unity 校正网格：一次关键转换

VirtualLab 输出的是光学像面上的畸变网格，Unity 需要的是 UV 坐标偏移。两者之间的转换是整个链路中最容易出错、也最值得花时间的地方。

我在项目中的做法是：将 VirtualLab 导出的畸变网格数据按视场排列，从极坐标或归一化坐标转换到 UV 空间，然后生成一个与渲染分辨率匹配的偏移纹理。这个偏移纹理可以提前生成好，运行时直接交给 Shader 采样，省去实时计算的负担。

需要特别注意：VirtualLab 的坐标系和 Unity 的屏幕坐标系有差异。VirtualLab 默认的像面坐标可能是毫米为单位、以光轴为原点；Unity 的 UV 坐标系是以左下角为原点、归一化到 0~1。如果直接拿过来用，画面大概率会反或者偏移。我习惯在第一版就把坐标转换写成独立脚本，统一输出格式，方便后续校准。

3. 核心细节解析与实操要点

3.1 VirtualLab 中的建模与仿真设置

先说建模阶段。目镜光学系统通常由多片镜片组成，在 VirtualLab 中可以直接导入镜片面型参数，也可以自己定义。建议从光学设计软件（比如 Zemax 或 CodeV）导出镜片的曲率半径、厚度、材料折射率，再在 VirtualLab 中重建。这样能让两个软件的模型保持一致，避免在传递过程中引入不必要的误差。

光源设置方面，如果目标是评估中心视场，可以直接用平面波或者点光源。但如果要模拟真实人眼观察效果，最好用“人眼模型+场追迹”的方式。VirtualLab 自带一些经典人眼模型，可以在出瞳位置设置一个接收面，观察不同视场角的光线是否全部通过入瞳。这一步对目镜非常重要，因为目镜的入瞳和出瞳位置通常不一致，实际使用中眼睛位置也会有小范围移动，也就是眼盒（eye box）问题。

网格设置：我建议采样精度先粗后细。第一轮先用 32x32 的网格跑通整个流程，确认畸变趋势正确；第二轮再把网格细化到 128x128，获得更准确的畸变场数据。有些同事一上来就用 512x512，结果仿真耗时巨大，数据量大到 Unity 端处理也吃力，完全没有必要。

仿真完成后，导出像面网格时，我一般会同时导出两种数据：畸变网格点坐标和对应的视场角坐标。前者用于生成校正纹理，后者用于排错和可视化。两者缺一不可。

3.2 Unity 侧关键参数与脚本设计

Unity 侧的脚本核心就两个：生成偏移纹理的工具脚本，和运行时后处理 Shader。

生成偏移纹理的思路是：读取 VirtualLab 导出的网格数据，把它插值到目标分辨率（例如 1920x1080），计算每个像素在畸变前后的 UV 偏移量，然后写入一张 RG 纹理。R 通道存 U 的偏移量，G 通道存 V 的偏移量，B 通道可以留作后续做双目视差或者边缘融合。

Shader 的核心逻辑非常简单：

fixed4 frag (v2f i) : SV_Target { float2 offset = tex2D(_DistortionTex, i.uv).rg; float2 uv = i.uv + offset; return tex2D(_MainTex, uv); }

就这么几行代码，原理不复杂，但实际操作中容易遇到几个问题：

• 偏移量方向搞反：导致画面越来越弯，而不是被拉直；
• 纹理采样边缘溢出：UV 超出 0~1 范围后出现拉伸色块；
• 偏移纹理分辨率不够：校正画面出现马赛克感；
• 后处理执行时机不对：导致 UI 也被畸变，交互时点不到按钮。

这些我都会在后面的问题排查部分具体展开，先记住一点：第 4 个问题非常隐蔽，处理不当会影响整个 VR 应用的可用性。

3.3 传统参数法 vs 网格校正法：两种方案怎么选

在 Unity 中做畸变校正，除了网格法，还有一种常见的参数法：用一个多项式模型描述畸变场，然后在 Shader 里实时计算偏移量。经典模型包括 Brown-Conrady 模型和除法模型，前者适合描述鱼眼镜头的畸变，后者在低成本设备里用得更多。

我整理了一下两者在实际工程中的对比：

就目镜系统而言，尤其是现在大量使用自由曲面和离轴光学方案，畸变场往往不是标准的桶形或枕形，而是非常不规则的。这种情况下参数法很难拟合到位，网格法几乎是唯一可靠的选择。而且 VirtualLab 导出的数据天然就是离散网格，直接拿来用很顺。

如果你的项目对实时性能要求极其苛刻，可以折中：先用网格法生成一个低分辨率的偏移纹理，再在 Shader 里双线性插值。这样既保留了网格法的精度，又能把显存和带宽占用压到很低。

4. 实操过程与核心环节实现

4.1 从 VirtualLab 到 Unity 的完整数据流

我这边走通的一条完整数据流是这样的：

1. 在 VirtualLab 中建立目镜光学模型；
2. 设置视场角范围和采样网格；
3. 运行场追迹仿真；
4. 导出畸变网格数据为 CSV 或文本文件；
5. 编写 Python 脚本解析数据并转换为 Unity 可读的偏移纹理；
6. 在 Unity 中编写编辑器工具，导入偏移纹理并生成材质；
7. 写后处理脚本，把畸变校正材质挂到主相机上；
8. 运行 Unity，通过对比“开/关校正”验证效果；
9. 接入头显或模拟器，进行实机主观测试。

这套流程里，第 5 步看起来不起眼，但其实是整个链路的“翻译官”。我贴一段简化的 Python 脚本作为参考，它的作用是读取 VirtualLab 导出的网格数据，生成一张偏移纹理 PNG。

import numpy as np from PIL import Image # 假设数据格式为: [视场角_x, 视场角_y, 像面_x, 像面_y] data = np.loadtxt("distortion_grid.csv", delimiter=",") width, height = 1920, 1080 # 初始化偏移图 offset_map = np.zeros((height, width, 2), dtype=np.float32) # 这里做插值，实际项目中可用 scipy.interpolate.griddata # 简化为逐点写入 for row in data: # 归一化坐标 u = (row[2] - x_min) / (x_max - x_min) v = (row[3] - y_min) / (y_max - y_min) # 理想坐标 ideal_u = (row[0] - fx_min) / (fx_max - fx_min) ideal_v = (row[1] - fy_min) / (fy_max - fy_min) # 计算偏移 offset_u = ideal_u - u offset_v = ideal_v - v # 写入像素 px = int(u * width) py = int(v * height) if 0 <= px < width and 0 <= py < height: offset_map[py, px] = (offset_u, offset_v) # 保存为纹理，R通道为U偏移，G通道为V偏移 out = np.zeros((height, width, 3), dtype=np.uint8) out[:, :, 0] = np.clip((offset_map[:, :, 0] * 0.5 + 0.5) * 255, 0, 255) out[:, :, 1] = np.clip((offset_map[:, :, 1] * 0.5 + 0.5) * 255, 0, 255) Image.fromarray(out).save("distortion_offset.png")

这个脚本是最小可运行版本，实际项目里需要处理网格点不覆盖全部像素的情况，空白的像素要靠插值填充。我在项目里用的是 scipy 的griddata做双立方插值，效果比线性插值平滑很多，尤其在高频纹理区域不容易出现锯齿。当然，双立方插值的计算量大不少，如果数据规模过大，建议先生成低分辨率偏移场，再在 Unity 里用纹理滤波放大。

4.2 Unity 后处理脚本的完整写法

Unity 后处理有两种常见实现：一种基于OnRenderImage，适合 Unity 内置渲染管线；另一种基于 Scriptable Render Pipeline 的 Render Feature，适合 URP。考虑到很多项目已经在用 URP，我两种都试过，这里给一个基于 URP Renderer Feature 的方案，通用性和性能都更好。

需要先明确一点：如果项目还在用内置渲染管线，OnRenderImage最省事；如果项目是 URP，就不能直接用OnRenderImage，必须通过 Render Feature 在特定的 Pass 插入后处理。下面我以 URP 为例说明步骤。

第一步，在工程中创建一个DistortionRenderFeature.cs：

using UnityEngine; using UnityEngine.Rendering; using UnityEngine.Rendering.Universal; public class DistortionRenderFeature : ScriptableRendererFeature { [System.Serializable] public class Settings { public Material distortionMaterial; public RenderPassEvent renderPassEvent = RenderPassEvent.AfterRenderingTransparents; } public Settings settings = new Settings(); private DistortionPass distortionPass; public override void Create() { distortionPass = new DistortionPass(settings.distortionMaterial, settings.renderPassEvent); } public override void AddRenderPasses(ScriptableRenderer renderer, ref RenderingData renderingData) { if (settings.distortionMaterial != null) { renderer.EnqueuePass(distortionPass); } } }

第二步，实现DistortionPass：

public class DistortionPass : ScriptableRenderPass { private Material material; private RenderTargetIdentifier source; private RenderTargetHandle tempTexture; public DistortionPass(Material mat, RenderPassEvent evt) { material = mat; renderPassEvent = evt; tempTexture.Init("_TempDistortionTex"); } public override void OnCameraSetup(CommandBuffer cmd, ref RenderingData renderingData) { source = renderingData.cameraData.renderer.cameraColorTarget; } public override void Execute(ScriptableRenderContext context, ref RenderingData renderingData) { if (material == null) return; CommandBuffer cmd = CommandBufferPool.Get("DistortionCorrection"); RenderTextureDescriptor desc = renderingData.cameraData.cameraTargetDescriptor; cmd.GetTemporaryRT(tempTexture.id, desc); cmd.Blit(source, tempTexture.id); cmd.Blit(tempTexture.id, source, material, 0); cmd.ReleaseTemporaryRT(tempTexture.id); context.ExecuteCommandBuffer(cmd); CommandBufferPool.Release(cmd); } }

第三步，在 Shader 里完成采样偏移：

Shader "Custom/DistortionCorrection" { Properties { _MainTex ("Source Texture", 2D) = "white" {} _DistortionTex ("Distortion Offset Map", 2D) = "black" {} } SubShader { Tags { "RenderType"="Opaque" } Pass { HLSLPROGRAM #pragma vertex vert #pragma fragment frag #include "Packages/com.unity.render-pipelines.universal/ShaderLibrary/Core.hlsl" struct Attributes { float4 positionOS : POSITION; float2 uv : TEXCOORD0; }; struct Varyings { float4 positionHCS : SV_POSITION; float2 uv : TEXCOORD0; }; TEXTURE2D(_MainTex); SAMPLER(sampler_MainTex); TEXTURE2D(_DistortionTex); SAMPLER(sampler_DistortionTex); CBUFFER_START(UnityPerMaterial) float4 _MainTex_TexelSize; CBUFFER_END Varyings vert (Attributes input) { Varyings output; output.positionHCS = TransformObjectToHClip(input.positionOS.xyz); output.uv = input.uv; return output; } half4 frag (Varyings input) : SV_Target { float2 offset = SAMPLE_TEXTURE2D(_DistortionTex, sampler_DistortionTex, input.uv).rg; offset = offset * 2.0 - 1.0; float2 uv = input.uv + offset; return SAMPLE_TEXTURE2D(_MainTex, sampler_MainTex, uv); } ENDHLSL } } }

代码里的offset = offset * 2.0 - 1.0是把纹理里存储的归一化偏移还原到 -1~1 范围。这个细节很容易被忽略，如果漏掉，校正效果会明显不足或者过度。

最后，在场景中把DistortionRenderFeature挂到 Forward Renderer 上，把材质赋给 Feature 的distortionMaterial字段，运行就可以看到效果。

4.3 参数调节与效果验证：怎么判断校正成功

很多人以为畸变校正是“一键搞定”的，实际并不是。校正完的效果到底好不好，必须通过几个维度判断：

• 用一张网格图作为测试画面，观察横线和竖线是否在画面各个位置都保持平直；
• 观察画面边缘是否存在明显的拉伸或压缩；
• 在 VR 头显里观测时，转头时画面是否稳定，有没有“呼吸感”；
• 检查 UI 元素是否对准，尤其是注视点附近的区域。

这里说个小技巧：在验证畸变校正时，不要在 Unity 默认的 Game 窗口里直接看，因为默认相机没有模拟目镜效果。我一般会把一个“模拟目镜效果”的材质也做到工程里，它负责把校正后的画面再“还原”成带畸变的画面，用于调试对比。这样可以在编辑器里就大致判断出校正强度是否合适，省去反复摘戴头显的麻烦。

4.4 Pico 4 开发适配：移动端性能要注意什么

项目里如果用 Pico 4 这类移动 VR 一体机做验证，Unity 端的畸变校正做得再好，如果性能跟不上，体验也是白搭。移动端 GPU 的带宽和填充率比 PC 端小很多，所以后处理要格外克制。

我的几个实测经验：

• 偏移纹理的分辨率没必要和渲染分辨率一致，一般用渲染分辨率的 1/4 或 1/8 就足够，配合双线性采样，画质损失人眼几乎感知不到；
• 能不实时计算的偏移就不要实时计算，全部提前烘焙到纹理里；
• 后处理 Pass 要尽量简短，不要在 Shader 里做太多次纹理采样；
• 如果项目用了 MSAA，后处理采样的目标纹理需要特别注意分辨率匹配，否则会出现偏移量不准确的问题；
• 多分辨率渲染（Single Pass Instanced）模式下，偏移纹理必须保持双目一致，不能因为不同眼位产生尺寸差异。

还有一点：Pico 4 这类一体机的系统本身已经做了一次畸变校正，对应的是它自家光学系统的预畸变。我们为什么要再做一层？因为在开发阶段，我们往往需要自定义目镜光学系统，这时候系统的原生校正就不适用了。一个比较典型的开发路径是：先用系统默认的校正跑通功能，等光学件定版后，再用 VirtualLab 的数据替换成自己的校正纹理。

5. 常见问题与排查技巧实录

5.1 画面反而更弯了：偏移方向的处理

这个问题几乎每个第一次做畸变校正的人都会遇到。我也一样，第一版测试时网格线不但没有变直，反而弯得更夸张。原因就是偏移方向反了。

在 Unity 的屏幕坐标里，UV 原点在左下角，U 向右增大，V 向上增大。VirtualLab 的像面坐标通常以光轴为原点，X 向右为正，Y 向上为正。但有些导出脚本会把像面坐标按工程图纸习惯定义成 Y 向下为正，这就导致 V 方向出现翻转。

排查技巧：找一个畸变明显的特征点，比如画面中心偏右上区域的一个点，记录它的理想位置和实际位置，然后手动计算偏移向量，再和 Shader 里实际采样的偏移方向对比。通常方向错误的修正很简单：要么在 Python 导出时把 V 分量取反，要么在 Shader 里对偏移量取负。我习惯在数据导出阶段就统一坐标系，这样 Shader 逻辑永远是单纯的“加偏移”，不容易出错。

还有一个小细节：偏移纹理如果直接从 PNG 导入 Unity，会默认按 sRGB 处理，导致采样到的数值不是 0~1 线性值，而是伽马空间的值。这种情况偏移量会出现非线性失真。解决办法是在导入设置里把纹理的 sRGB 选项关掉，或者在 Python 导出时直接把 PNG 保存为线性数据。我踩过这个坑，当时校正量总是差一截，排查了好几个小时才发现是纹理颜色空间的问题。

5.2 边缘出现拉伸色块：UV 越界处理

网格校正在画面边缘很容易出现 UV 越界问题，因为畸变校正后，边缘像素要采样的位置可能跑到 0~1 之外。如果 Shader 不做处理，边缘就会出现拉伸、重复或黑边，观感非常差。

处理方案有三种：

• 最常用的是 clamp 采样，让边缘像素重复，视觉上虽然会有轻微拉伸，但比黑边好得多；
• 更精细一点的，在生成偏移纹理时就把边缘外区域的偏移量设为一个“安全值”，强制拉到最近的有效像素上；
• 有条件的话，渲染时把主画面的边缘多渲染一圈，给后处理流出足够的有效像素。

我自己的偏好是第二种：在 Python 生成偏移纹理时，对边界外的区域做膨胀处理，填充最近有效像素的偏移量。这样在 Shader 端就不必担心越界问题，而且边界过渡更自然。这个方法在 N 卡和移动端 GPU 上实测都稳定。

记得在 Shader 里也写一个防御性的判断：

uv = clamp(uv, 0.001, 0.999);

这样即便偏移纹理有零星空洞，也不会出现整片闪烁。

5.3 UI 元素也跟着畸变了怎么办

这是另一个高频问题。畸变校正是对整幅画面生效的，所以 UI 如果没有单独处理，会被跟着一起扭曲，结果就是视线看着弯按钮在正确位置，但用手柄点击时会发现 UI 实际位置偏了。

处理思路非常简单：UI 不参与畸变校正。具体做法是：把 UI 相机单独渲染到一个独立的 Render Texture，然后再叠加到最终画面上，这样 UI 始终是屏幕空间的直线布局，不受光学畸变影响。

另一个替代方案是：把 UI 放在世界空间，并且让 UI 的摆放位置按照畸变反向偏移，使得透过目镜观察到时，UI 呈现在正确的视觉位置。这个方法在需要 UI 与虚拟世界物体对齐时更实用，但实现难度更高。

我在多数项目里直接用分离相机方案，简单、可靠、对美术组友好。毕竟畸变校正应该只作用于场景画面，UI 是功能层，不应该被“无畸变”这个目标影响。

5.4 VirtualLab 导出数据量过大：如何瘦身

有些朋友从 VirtualLab 导出网格数据时，为了追求精度，直接导出了 1024x1024 的网格点，结果生成偏移纹理时电脑内存直接爆了，或者 Unity 加载时卡死。其实完全没必要。

目镜畸变场的空间频率通常很低，也就是说畸变量在相邻像素之间变化非常平缓。我用 64x64 的网格和 512x512 的网格做过对比，最终校正效果肉眼几乎看不出差异。所以建议第一版先用 64x64 或 128x128，确认效果后再决定要不要加密。

另外，VirtualLab 导出的网格数据格式可能是科学计数法，Python 解析时注意数据列之间的分隔符可能是逗号或制表符，甚至可能是空格。我建议第一步先用pandas.read_csv配合sep=None自动检测分隔符，省去不少麻烦。

5.5 双目画面不一致：左右眼偏移量如何统一

双目 VR 显示里，左右眼各有一套畸变场，严格来说应该有各自的偏移纹理。但如果两套纹理差异很小，为了性能也可以共用一套。

关键问题是：左右眼的画面对应的是两个不同的相机视角，如果直接共用一套偏移纹理，画面边缘可能会出现细微的不对称，让人眼感觉不自然。我建议光学系统设计时，尽量让左右眼的光学参数保持一致，这样就能安全地共用一套纹理。

如果你的光学系统因为制造公差导致左右眼畸变明显不同，那就必须分别导出偏移纹理，并在后处理时根据相机是左眼还是右眼切换纹理。注意这里有个坑：双目标注的渲染视图要正确区分 Source 和 Target，否则左右眼会把对方的偏移量套在自己身上。

6. 踩坑记录与实际调试心得

6.1 从“仿真准确”到“实机正确”之间隔着一道校准

我一开始天真地以为，VirtualLab 仿真数据足够精确，直接用于 Unity 就能一劳永逸。事实上，仿真模型和实际光学系统之间存在差异，包括镜片加工误差、装配公差、显示面板的像素排列、以及人眼瞳距和瞳高的个体差异。这些因素叠加起来，会让实机效果和仿真效果出现不小的偏差。

所以我的建议是：把 VirtualLab 的数据作为初值，实机调试时保留手动微调的能力。工程上我通常会写一个简单的调试面板，允许在运行时调整偏移量的整体缩放系数和旋转角度，方便现场快速校准，测试通过后再把参数固化到配置文件中。

这个调试面板听起来很简单，但对整个开发效率的提升非常明显。有一次我们在光学实验室里，用这个面板边看测试图卡边调参数，十分钟就把畸变校正调到了可接受范围，而如果走“重新仿真-导出-重测”的流程，至少需要半天。

6.2 不要让渲染分辨率成为校正精度的瓶颈

Unity 中的畸变校正是基于最终渲染画面的，如果项目里为了性能把渲染分辨率调得很低（比如动态分辨率降到 60%），画面本身就会产生严重的像素化和边缘锯齿，这时候畸变校正做得再准，人眼看到的边缘还是模糊的。

更好的做法是：保持一个固定的内部分辨率用于后处理和畸变校正，再通过最终的显示输出去适配硬件。换句话说，畸变校正应该在分辨率变化之后做，而不是在低分辨率阶段做。如果项目用了动态分辨率缩放，建议把畸变校正 Pass 放在缩放之后，确保校正精度不受影响。

我第一次在 Pico 4 上做动态分辨率测试时，发现畸变校正的精度在低分辨率下明显变差，后来就是把校正 Pass 的执行顺序调整到最终输出之前，问题才解决。

6.3 关于性能优化：能离线就别实时

最后聊一个很实际的问题：畸变校正到底应该多耗性能？

我见过一些项目把畸变模型写成复杂的高阶多项式，在 Shader 里做大量数学运算，结果性能开销很大，效果还不一定好。其实对于目镜这类畸变场，完全可以在离线阶段把所有计算做完，生成一张偏移纹理，运行时只做一次纹理采样和一次 UV 偏移，开销非常小。

以 Quest 或 Pico 这类移动平台为例，一张 1/4 分辨率偏移纹理的采样开销几乎可以忽略不计。真正的性能消耗可能来自后处理 Pass 中的多重采样和纹理切换，而不是畸变校正本身。所以优化思路应该是：减少后处理 Pass 次数、降低偏移纹理分辨率、避免不必要的纹理切换。

如果做 PC 端 VR，还可以考虑用 Compute Shader 做更精细的校正，但对绝大多数项目来说，普通的后处理已经足够。

6.4 一个容易忽略的坐标陷阱：纹理 V 方向

再多说一句坐标问题。Unity 的纹理坐标 V 方向是从下到上，但很多外部工具导出的图片是按从上到下存储的。这就导致偏移纹理在导入 Unity 后，V 方向的偏移量镜像了。

遇到这种情况，我的处理方式是：在 Shader 里采样的偏移量上手动翻转 V 分量：

offset.y = -offset.y;

这个方法简单粗暴，但很有效。更稳妥的做法是在 Python 导出时就生成 Unity 原生格式的偏移纹理，不过那样会引入对 Unity 二进制格式的依赖，维护成本高。所以我实际项目里用了第二种方案：保留 PNG 导出，Shader 里统一做方向修正，并在代码注释里说明这个修正的来龙去脉，防止后人接手时踩坑。

7. 后续优化空间与实际扩展方向

做完整套流程后，我最大的感受是：VirtualLab 加 Unity 的组合，确实能在光学仿真和实时渲染之间搭起一座桥。但这只是第一步，后面还有很多可以深挖的方向，这里简单提几个。

一个是眼动追踪与动态畸变校正的结合。如果头显里装了眼动追踪，理论上可以针对用户当前注视点微调畸变校正参数，让边缘畸变更不明显。这个方向对算力要求高，但在高端 MR 设备上非常有价值。

另一个是多焦面光学系统。目前的目镜大多是单焦面，画面和人眼的调焦距离固定。未来的 MR 头显会用衍射光波导或全息光学元件实现多焦面显示，那时候畸变场会更复杂，仅仅依靠 Unity 后处理可能不够，需要直接在渲染阶段考虑光学传递函数。

还有一个很实际的方向：把 VirtualLab 的仿真结果和 Unity 的实时可视化结合，做一个光学仿真沙盒。在 Unity 里实时显示不同视场角下的畸变场分布、MTF 曲线、以及对应的校正效果，这样光学工程师和渲染工程师可以共用一套工具，效率和决策质量都会有质的提升。

我在项目中已经开始尝试把虚拟网格和实际相机画面叠加显示，用于标定头的自动校准时，反馈非常好。后续如果把这个能力做成通用工具，应该能帮团队省下不少沟通成本。

根据我个人的经验，从 VirtualLab 到 Unity 的整个链路，真正难的不是单点技术，而是如何让光学仿真数据准确、稳定、可调试地流通到渲染引擎里。只要把数据格式、坐标系、纹理空间和性能预算这四件事想清楚，剩下的就只是按部就班的工程实现了。希望这次分享对正在折腾无畸变目镜、或者准备在 Unity 里做光学相关预处理的你有帮助。