从VirtualLab到Unity：光学仿真驱动的真实鱼眼镜头后处理实现

很多人第一次在Unity里做广角鱼眼模拟时，第一反应就是把Camera组件的Field of View拉到120°甚至150°，然后看着画面边缘被拉伸得面目全非，心里还安慰自己"鱼眼镜头不就是这个效果"。我最早也这么干过，直到我把VirtualLab里追迹出来的真实鱼眼镜头成像数据丢进Unity一对比，才发现两者的差距根本不是"畸变大一点"这么简单——Unity的透视投影和真实鱼眼镜头的等距投影，在物像关系上是两条完全不同的曲线，拉FOV只是在硬凑，凑出来的是桶形夸张变形的假广角，不是物理上真实的鱼眼画面。

这篇博文就记录一下我最近做的VirtualLab + Unity鱼眼镜头应用项目：从VirtualLab里建立鱼眼镜头成像链路、追迹得到实际像高/PSF/相对照度数据，到把这些数据加工成Unity可用的畸变查找表、清晰度掩码和渐晕贴图，最后在URP管线下写后处理Shader还原真实鱼眼成像效果，再接到Pico 4上做XR验证的完整过程。整套链路适合两类人看：一类是光学工程师，手里有VirtualLab仿真数据但不知道怎么在Unity里做交互展示；另一类是Unity开发者，要在数字孪生、车载环视、安防监控这类场景里做高保真鱼眼相机模拟，而不是靠美术参数硬演。

1. 为什么说"拉大FOV≠鱼眼镜头"——先把投影模型这件事掰扯清楚

1.1 Unity默认摄像机模型和真实广角镜头之间差了条什么曲线

Unity的Camera本质上是一个标准的透视投影相机，它的成像关系是严格遵循

r = f·tanθ

其中r是像高（感光面上像点离中心的距离），f是焦距，θ是入射视场角。这个公式的意思是：视场角每增加一度，像高增量不是线性的，而是越往边缘增长越快。当θ逼近90°时，tanθ趋近无穷大，所以透视投影的FOV在数学上就不可能超过180°，拉到120°以后画面边缘其实是在做一种"暴力外扩"，像素密度急剧下降，画面畸变得非常生硬。

而真实鱼眼镜头走的是另一套物像关系。鱼眼镜头的设计目标，就是把超过180°的物方视场角"压"到一个有限的像面上来。这个压缩过程不是随便压的，每种鱼眼镜头都对应一条明确的投影曲线，比如最常见的等距投影

r = f·θ

这里的θ要用弧度制。可以看到，等距投影下像高和视场角成正比，90°视场角对应的像高是f×1.5708，而透视投影下同视角的像高是f×tan45°=f，再看远一点，120°视场角等距投影像高是f×2.094，透视投影是f×1.732。鱼眼镜头把原本在透视画面边缘的信息"压缩"到了更靠中心的位置，所以正前方物体的比例在鱼眼画面里会显得比透视画面小一些，但换来的是极其宽阔的视野。

1.2 鱼眼镜头的几类投影模型，做模拟前得先选定一条基准曲线

鱼眼镜头的投影模型不止一种，工程上常见的有这么几类：

这五条曲线对应的像高随视场角变化的趋势差异非常明显。在θ比较小的时候，sinθ、tanθ、θ这几个函数的值差不了太多，所以镜头中心和普通镜头成像接近；一旦θ超过40°，各条曲线的分化就非常明显了。这就是为什么同一个场景，你用不同投影模型的鱼眼镜头拍出来，边缘物体的形变程度和"压缩感"会差很多。

我这次在项目里选的是等距投影作为理想基准。原因很实在：实验室里做鱼眼标定时，等距模型是最常用的初值模型，OpenCV的fisheye标定也是在这个基础上做的，后续拿实际像高和理想像高一对比，得到的径向畸变曲线可以直接套用成熟的标定误差模型来分析。如果选等立体角投影，虽然更接近某些运动相机，但处理数据时还要多做一层换算。

1.3 那这条"基准曲线"在项目里到底起什么作用

理清投影模型后，整个项目的目标就变得非常清晰了：我在VirtualLab里建一个真实的鱼眼镜头光学系统，追迹出它在各个视场角下的实际像高r_real(θ)，然后把r_real(θ)和理想等距投影的r_ideal(θ)=f·θ做对比，两者的差值就是实际镜头的畸变曲线。把这条曲线变成一张查找表带到Unity里，后处理Shader按照这个查找表对画面做UV重映射——这就不是"拉大FOV硬演"，而是真正由光学仿真数据驱动的鱼眼成像效果。

同时，VirtualLab还能给出每个视场角的PSF（点扩散函数）和相对照度。PSF决定了画面边缘有多"肉"，相对照度决定了边缘有多"暗"。这两样东西直接对应真实鱼眼镜头那种"边缘分辨率崩坏+周围一圈压暗"的质感，是纯美术调参几乎不可能调准的细节。

2. 在VirtualLab里搭建鱼眼成像链路：参数、追迹与数据提取

2.1 镜头参数与光源视场配置：先把"物方哪些方向的光会进到探测器"说清楚

先说清楚一点：VirtualLab不是一个从零设计镜头结构的软件，它更擅长的是做系统级光学仿真验证。我的项目也不是要拿它去设计一套全新的鱼眼镜头，而是把一款已有的鱼眼镜头设计数据（面型、曲率、玻璃材料）导入VirtualLab，搭一套完整的成像链路，追迹验证它的成像质量，并导出Unity端需要的数据。这也是VirtualLab在实际工程里最常见的用法——设计交给专业镜头设计工具，VirtualLab负责系统级分析。

我这套系统的目标参数是这样的：

这里有个参数我是特意算过的：1/2.5"传感器的半对角线是3.2mm，等距投影下180°视场角对应的理想像高是

r = f × (π/2) = 2.1 × 1.5708 ≈ 3.3mm

略大于3.2mm的半对角线，意味着边缘视场的光线会稍微超出传感器边缘，形成一个很轻微的实际截幅。这个"轻微超出"在真实鱼眼镜头里很常见，它能让边缘的畸变过渡更自然，不会出现那种像高正好卡在传感器边界导致的突兀裁切。如果选的焦距太长，边缘视场的像高超出传感器太多，画面边缘会出现大面积的暗角和模糊区；焦距太短，则中心视场的有效像素密度太低，浪费传感器分辨率。2.1mm这个值是我扫了一轮参数后的折中选择。

光源设置上，我在VirtualLab里配置了一组平行光光源阵列，覆盖0°到90°的半视场角，间隔2°取一个采样点，边缘视场加密到1°。为什么边缘要加密？因为鱼眼镜头在边缘视场的像差变化非常剧烈——轴外像差像场弯曲、像散、畸变都是随视场角的高次方增长的，你如果只在0°、30°、60°、90°四个点采样，中间那些角度对应的像质变化会被完全漏掉，生成的查找表会在某些半径位置出现莫名其妙的跳变。采样点间隔定在1°到2°，既保证了精度，又不会让追迹时间爆炸。

2.2 追迹方式的选择：几何光线追迹和场追迹怎么权衡

VirtualLab有两套追迹思路：一套是几何光学追迹（Geometric Optics Tracing），把光当成光线来处理，追迹速度快；另一套是场追迹（Field Tracing），把光当成电磁场来传播，能精确分析衍射、干涉效应，但计算量也大得多。

鱼眼镜头这种超大视场、超大像差的系统，在追迹方式选择上我的建议很明确：用几何光线追迹。原因是鱼眼镜头的PSF主要由几何像差决定，衍射效应在大视场、大像差条件下被严重压制，你再怎么精打细算衍射贡献，对最终成像结果的影响也微乎其微。这时候用场追迹，要去处理超大视场下的海量谐波场分量，计算量涨好几倍，得到的精度提升却完全可以忽略，属于典型的花钱不讨好。

在VirtualLab的操作上，我在光学系统面板里把光线追迹器切成几何追迹模式，设置了追迹光线条数和最大反射次数。鱼眼镜头内部有一些接近全反射传播的大角度光线，反射次数限制设太低会把本该到达像面的光线拦掉，设太高又会拖慢追迹速度，我最后用的是最大反射次数8次，光线数从中心视场的几百条到边缘视场的几千条逐级加密。

2.3 探测器布局与数据提取：像高、PSF、相对照度一个都不能少

探测器放在像面位置，我用的是一个Image Detector。在探测器上同时打开场数据统计功能，追迹完成后可以导出三样关键数据：

第一，各视场角下主光线的像面交点坐标。把这些坐标换算成半径，就得到了实际像高曲线r_real(θ)。这个数据是畸变查找表的核心输入。

第二，各视场角下的PSF形态。做法是把光源切换成单点源，在探测器上记录入射光斑的能量分布，得到的就是该视场的PSF。注意鱼眼镜头边缘视场的PSF通常不是一个对称的小圆斑，而是带着明显彗差形态的"水滴状"，所以不能只记录光斑半径，最好把整个PSF的二维强度分布导出成图像或矩阵。

第三，相对照度曲线。鱼眼镜头因为边缘视场的有效入瞳面积收缩、入射角增大，边缘照度会自然下降。VirtualLab可以直接给出相对照度随视场角的变化曲线。我这套系统的边缘相对照度算出来大约是62%左右，意味着画面最边缘比中心暗了将近三分之一，这个数值在真实广角镜头里很典型。

数据导出格式我用的是CSV和灰度图。像高曲线和照度曲线存CSV，PSF存成多页灰度图或者一个多维矩阵文件。到这一步，VirtualLab这边的活儿就干完了——后面就是数据搬运工的环节。

3. 把VirtualLab结果变成Unity资源：畸变查找表的生成逻辑

3.1 从"实际像高-视场角"数据到二维UV偏移，方向和符号最容易翻车

VirtualLab导出的是一串(θ, r_real)的数据点，要变成Unity用的查找表，得先做一步插值，把离散采样点重采样成连续曲线。我用的是三次样条插值，避免线性插值在采样点之间造成的折线痕迹。插值完成后，对任意一个屏幕像素的归一化半径ρ_screen，都能反查出它对应的物方视场角θ(ρ_screen)，再算出理想像高ρ_ideal = f·θ(ρ_screen)/r_max。

这里的关键逻辑是：屏幕像素在鱼眼像面上的实际位置是ρ_screen，它拍到的物方方向是θ；如果把这个方向用理想等距投影重新画到像面上，它应该出现在ρ_ideal处。所以后处理Shader里，采样源纹理时应该去取半径ρ_ideal处的像素。当实际镜头在某段半径上比理想等距投影压缩得更狠（比如r_real < r_ideal），表现在查找表里就是ρ_ideal > ρ_screen，采样点往外走——画面的边缘信息被"拉伸"出去，形成鱼眼特有的包裹感。

这一段的符号方向必须要翻来覆去验证三遍。我第一版生成查找表时就吃过这个亏：方向弄反之后画面边缘变成向内卷的漩涡状，整个画面像溶化了一样。排查了半天才发现是VirtualLab里像面坐标系的Y轴方向和Unity的UV坐标Y轴方向没有对齐，导致径向对称的畸变叠加了一个假性的切向分量。解决方法是写一个最小验证用例：在VirtualLab里追迹一组十字网格，导出网格点在像面上的实际位置，在Unity里用同一张查找表对一张网格纹理做重映射，对比两者的网格形态是否一致。这个对比通过之前，不要往Shader走。

查找表的纹理分辨率我建议用256×256就足够了。畸变曲线是缓变的径向函数，256分辨率下每个纹素对应的半径增量不到0.4%，远小于镜头本身畸变的梯度；做太高分辨率纯属浪费带宽，而且高分辨率纹理在GPU上做双线性过滤时，边缘的浮点采样误差反而更容易被放大。

3.2 像质损失量化：把PSF半高宽转成清晰度掩码

鱼眼镜头中心画质不错，边缘却往往很"肉"，这是所有广角系统的通病。要还原这个特点，我用VirtualLab追迹得到的各视场PSF来生成一张"清晰度掩码"——其实就是一张模糊权重图。

具体做法是：对每个视场角的PSF计算半高宽（FWHM），得到一个r_FWHM(θ)曲线。然后以画面中心为原点，把这条曲线按半径方向展开成一张径向渐变纹理：中心区域模糊权重接近0，越往边缘模糊权重越大。在Sprite/UI层面这是一张128×128的R8纹理，存储的就是每个UV位置的模糊权重值。

为什么不用全分辨率的高斯模糊核做完整空间变化卷积？因为鱼眼图像本身的边缘视场分辨率已经低到一定程度了，再叠加一个半径精确等于PSF半高宽的卷积核，视觉效果差异肉眼几乎分辨不出来。工程上用一个固定半径的两级模糊，再按模糊权重图做插值，就能以极低的性能开销获得足够真实的边缘画质衰减。这属于视觉心理学的范畴——人对边缘模糊的感知是相对的，只要模糊过渡趋势正确，大脑就会自动补全"这个镜头边缘就是这个素质"的认知。

3.3 相对照度与色差数据：鱼眼真实感里被忽略的"暗角"来源

相对照度曲线我直接转成了一张一维径向渐变纹理，R通道存的就是该半径位置的亮度衰减系数。在Shader里采样这张纹理，乘到最终输出上，画面边缘就会自然压暗。

镜头色差这块，VirtualLab能给出各个波长（R/G/B三个通道的代表波长）分别的实际像高曲线。严格的做法是为R、G、B三个通道各生成一张畸变查找表，在Shader里分别采样、分别偏移，这样画面边缘会出现红蓝边（倍率色差）。实际项目里我做了这个功能，但默认不开启——因为Pico 4这种移动端设备上，三通道分离采样的纹理读取开销实在不小，而画面边缘被模糊权重一盖，色差几乎看不见。最后我给这个功能加了个开关，真机上默认关。如果是在PC端做高保真汽车环视或安防监控模拟，这个开关打开后的效果提升还是很明显的。

4. Unity端还原：基于URP RenderFeature的后处理畸变Shader

4.1 环境与管线：Unity 2022 LTS + URP下自定义后处理的正确姿势

Unity端我的环境是Unity 2022.3 LTS加URP 14。传统的内置渲染管线里写后处理，大家习惯用OnRenderImage那个套路，但在URP里这套已经废了，正确做法是实现一个ScriptableRendererFeature，在它的RenderPass里插入一个自定义绘制调用。

Feature的骨架代码很简单：

public class FisheyeDistortionFeature : ScriptableRendererFeature { public Material fisheyeMaterial; public RenderPassEvent injectionPoint = RenderPassEvent.BeforeRenderingPostProcessing; private FisheyeRenderPass renderPass; public override void Create() { renderPass = new FisheyeRenderPass(fisheyeMaterial, injectionPoint); } public override void AddRenderPasses(ScriptableRenderer renderer, ref RenderingData renderingData) { if (fisheyeMaterial == null) return; renderer.EnqueuePass(renderPass); } }

RenderPass部分，最关键的是要正确处理源纹理和目标纹理的Blit关系。URP里不能用老的Graphics.Blit直接往相机目标纹理上反复倒腾，得用CommandBuffer的GetTemporaryRT申请一块临时纹理，把当前相机画面Blit进去，做完畸变重映射后再Blit回来。我把我实际可用的Pass核心代码贴一下（完整工程太大，这里只保留主干）：

public class FisheyeRenderPass : ScriptableRenderPass { private Material material; private RenderTargetIdentifier source; private RenderTargetHandle tempRT; public FisheyeRenderPass(Material mat, RenderPassEvent evt) { material = mat; renderPassEvent = evt; tempRT.Init("_FisheyeTempRT"); } public override void Execute(ScriptableRenderContext context, ref RenderingData renderingData) { CommandBuffer cmd = CommandBufferPool.Get("FisheyeDistortion"); RenderTextureDescriptor desc = renderingData.cameraData.cameraTargetDescriptor; desc.msaa = 1; cmd.GetTemporaryRT(tempRT.id, desc); cmd.Blit(source, tempRT.id, material, 0); cmd.Blit(tempRT.id, source); context.ExecuteCommandBuffer(cmd); CommandBufferPool.Release(cmd); } }

注意那个desc.msaa = 1，这是一个非常容易踩的坑。如果相机开了MSAA，而我们的临时纹理没有关闭多重采样，边缘的UV重映射结果会被硬件抗锯齿在时序上"抹"掉，后处理完的画面边缘会有一种诡异的模糊残影。强制把临时纹理的MSAA关掉，后处理后的图像再用FXAA或TAA这类后处理级抗锯齿去平滑，效果才正常。

4.2 核心Shader逻辑：从UV重映射到画面输出的完整链路

后处理Shader的核心是拿到当前屏幕UV，经查找表重映射，再对源纹理采样。同时叠加模糊权重和渐晕。

half4 FragFisheye(Varyings input) : SV_Target { float2 uv = input.uv; // 1. 从VirtualLab查找表拿到目标采样UV // 查找表纹理的R/G通道存的是目标UV的偏移量 float2 offset = SAMPLE_TEXTURE2D(_DistortionMap, sampler_DistortionMap, uv).xy; float2 targetUV = uv + offset; // 2. 源画面采样 half3 color = SAMPLE_TEXTURE2D(_MainTex, sampler_MainTex, targetUV).rgb; // 3. 边缘模糊：按清晰度掩码混合一档模糊结果 float blurWeight = SAMPLE_TEXTURE2D(_BlurMap, sampler_BlurMap, uv).r; half3 blurred = SAMPLE_TEXTURE2D(_MainTex, sampler_MainTex, targetUV - _BlurDir0).rgb + SAMPLE_TEXTURE2D(_MainTex, sampler_MainTex, targetUV + _BlurDir0).rgb + SAMPLE_TEXTURE2D(_MainTex, sampler_MainTex, targetUV - _BlurDir1).rgb + SAMPLE_TEXTURE2D(_MainTex, sampler_MainTex, targetUV + _BlurDir1).rgb; blurred *= 0.25; color = lerp(color, blurred, blurWeight * _BlurIntensity); // 4. 相对照度渐晕 float vignette = SAMPLE_TEXTURE2D(_VignetteMap, sampler_VignetteMap, uv).r; color *= vignette * _VignetteStrength; return half4(color, 1.0); }

模糊那步用的是二方向四tap的小型模糊核，也就是水平+垂直两个方向各取两个点做均值。因为后面的模糊权重图是缓变的，四tap模糊和九tap高斯模糊在视觉上几乎没有差别，但开销差了近一半。如果你在PC端且追求极致，可以换成两趟分离高斯，但在移动端我强烈建议保留这个轻量方案。

如果要做180°完整视场的高保真档位，就不能走"透视画面+查找表"这条路了，因为透视相机FOV上不了180°。这时候得换成CubeMap路线：场景用六面透视相机（或者至少半球方向的三个面）渲染到一张CubeMap，后处理里对每个屏幕像素，根据它的归一化半径ρ通过VirtualLab数据反查物方视场角θ，再按当前方向构造一个三维向量去采样CubeMap。这个方案完整保留了"实际镜头拍到整个物方半球"的效果，代价是多一次场景渲染，性能开销大不少，所以我在项目里把它作为PC端专用的高质量档位，移动端还是先用查找表档位。

4.3 三个实机调试里踩过的坑，每个都花了我大半天

第一个坑是关于查找表纹理格式的兼容性。第一版我把查找表用成了RGFloat格式在Android上跑，结果Pico 4上画面直接全黑，连报错都没有。查了半天发现是部分移动端GPU对RGFloat格式的采样支持不完全。解决方案是改用R16G16B16A16_Float或者干脆用RGBA8（把偏移量映射到0-1区间），这两者的移动端兼容性就稳妥多。

第二个坑是UV坐标系的方向约定。VirtualLab里像面坐标Y轴向上，Unity的UV坐标系统里UV原点在左下角但纹理数据在部分平台可能从左上角开始，一旦没对齐，径向对称的畸变就会变成非对称的扭曲。我的解决办法是在Shader开头加一个显式的Y轴翻转开关，针对不同的Graphics API做判断。这不是一个"优雅"的解法，但在多平台项目里它是最不容易出错的。

第三个坑是后处理和XR渲染的交互。在Pico 4上如果开了Single Pass Instanced渲染，RenderFeature里直接做全屏quad绘制会出问题，因为XR模式下屏幕空间被分成了左右眼两个Viewport，全屏quad的顶点坐标必须按XR语义生成。绕行方案是把后处理放在左右眼分别执行，或者在Pass里用Unity的XR内置宏（UNITY_XR_FRAMEBUFFER_FETCH_AVAILABLE那套）手动匹配实例化变量。最后我用的是CommandBuffer的Blit链路，在XR模式下实测可以正常跑。

5. 在Pico 4上实机验证：XR模式与性能账

5.1 从普通相机到XR相机：RenderFeature在XR下的特殊处理

把同一套后处理搬到Pico 4的XR项目里，第一件需要处理的事就是Stereo Instanced Rendering。Unity的XR系统在Single Pass Instanced模式下会把两只眼睛的渲染打包成一个大的RenderTarget，分辨率和视口都翻了倍。这时候RenderFeature里的所有Blit操作得跟着变：源纹理已经不是普通单眼画面，而是左右眼拼接的宽纹理。

我的处理思路是不对整体画面做一次畸变，而是让后处理Shader识别当前像素属于左眼还是右眼，然后分别按各自的屏幕UV做畸变。具体做法是在Pass里读取unity_StereoEyeIndex，用它来把拼接后的UV换算成单眼UV，再做正常的查找表重映射。如果你用的是Multi Pass模式就简单了，后处理逻辑和PC端完全一致，但性能会差不少。

Pico 4的MR模式（彩色透视）下这套东西也能用：把VST相机画面作为源纹理，喂进同一个后处理Shader，就能实时看到"鱼眼透视"效果。我拿它做了个镜头安装位置模拟工具，在MR环境下把虚拟鱼眼画面叠加到真实环境里，辅助现场安防摄像头的安装选位，效果比在纯虚拟环境里看要直观太多。

5.2 性能实测与两处针对性优化

在Pico 4（骁龙XR2平台）上的实测数据，我记录了一下：

优化做了两处。第一处是后处理分辨率没有跟主相机走。我让后处理RT的分辨率设为主相机分辨率的0.8倍，因为鱼眼画面里边缘区域反正要被模糊掉，保持满分辨率纯属浪费。这是"视觉无损"的降分辨率——中心区域依然清晰，边缘本身就看不清细节。

第二处是把模糊权重图从Fragment阶段挪到Vertex阶段。模糊权重是缓变的径向函数，完全可以在顶点着色器里算好之后做插值传到片段着色器，省掉一次纹理采样。配合上把查找表纹理从三线性过滤改成双线性过滤，整体采样开销能再省一笔。

5.3 扩展到数字孪生：全景监控与透视校正的切换

这个项目做完之后，一个很自然的扩展就是数字孪生场景里的全景监控。现实中一个路口的鱼眼摄像头能覆盖几乎整个路口，但在数字孪生平台上，人不可能盯着畸变画面看车流。所以我还加了一个"透视校正"模式：把鱼眼画面的畸变逆向还原成透视图，操作者想看哪里就切到哪里。这个还原用的正好是同一张查找表的反向映射——查找表记录的是"理想UV -> 实际UV"，反向处理就是"实际UV -> 理想UV"，通过VirtualLab的数据反查一次就能拿到。

这种"鱼眼原图/透视校正图"双模式切换，对数字孪生运维系统特别实用。鱼眼原图管全貌，透视校正管细节，两者共用一套VirtualLab导出的数据链路，Shader里加一个开关就能切换。

最后再分享一个做这个项目最值的经验：用VirtualLab导出的数据在Unity里做还原时，最花时间的不是Shader也不是追迹，而是数据的方向对齐。我的习惯是在VirtualLab导出文件头里写明坐标系约定，Unity端写解析器时先跑一个最小验证用例——追迹一个网格，采样出来对着数。这个用例一旦通过，后面所有平台移植都不会出方向问题。另一个实用技巧是保一个"原始透视视角"的对照开关，联调时随时切换对比，能帮你快速分辨画面异常是数据问题还是Shader问题。做这类光学数据驱动渲染的项目，这两点能帮你省掉大量无头苍蝇式的排错时间。