很多人第一次在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 鱼眼镜头的几类投影模型做模拟前得先选定一条基准曲线鱼眼镜头的投影模型不止一种工程上常见的有这么几类投影模型像高公式典型应用场景透视投影r f·tanθ常规镜头、Unity默认相机等距投影r f·θ机器视觉标定、OpenCV fisheye模型、全景拼接等立体角投影r 2f·sin(θ/2)运动相机、部分安防鱼眼正交投影r f·sinθ特殊科研镜头体视投影r 2f·tan(θ/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负责系统级分析。我这套系统的目标参数是这样的参数数值说明最大视场角180°全视场半视场90°覆盖整个物方半球焦距2.1mm配合等距投影在1/2.5传感器上刚好打满像面F数2.8考虑边缘照度后仍能保证可用通光量适配像面1/2.5 CMOS对角线约6.4mm半对角线约3.2mm投影模型等距投影rf·θ为理想基准这里有个参数我是特意算过的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和灰度图。像高曲线和照度曲线存CSVPSF存成多页灰度图或者一个多维矩阵文件。到这一步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的后处理畸变Shader4.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平台上的实测数据我记录了一下配置分辨率帧耗时增加说明查找表档透视FOV 100°源2K单眼约0.8-1.1ms后处理重映射模糊渐晕查找表档同上1.5K单眼约0.5-0.7ms推荐移动端使用档位CubeMap档半球3面1024×1024 CubeMap增量约2.5-3.5msPC/高端移动设备CubeMap档 色差1024×1024 CubeMap增量约3.8ms一般不推荐移动端优化做了两处。第一处是后处理分辨率没有跟主相机走。我让后处理RT的分辨率设为主相机分辨率的0.8倍因为鱼眼画面里边缘区域反正要被模糊掉保持满分辨率纯属浪费。这是视觉无损的降分辨率——中心区域依然清晰边缘本身就看不清细节。第二处是把模糊权重图从Fragment阶段挪到Vertex阶段。模糊权重是缓变的径向函数完全可以在顶点着色器里算好之后做插值传到片段着色器省掉一次纹理采样。配合上把查找表纹理从三线性过滤改成双线性过滤整体采样开销能再省一笔。5.3 扩展到数字孪生全景监控与透视校正的切换这个项目做完之后一个很自然的扩展就是数字孪生场景里的全景监控。现实中一个路口的鱼眼摄像头能覆盖几乎整个路口但在数字孪生平台上人不可能盯着畸变画面看车流。所以我还加了一个透视校正模式把鱼眼画面的畸变逆向还原成透视图操作者想看哪里就切到哪里。这个还原用的正好是同一张查找表的反向映射——查找表记录的是理想UV - 实际UV反向处理就是实际UV - 理想UV通过VirtualLab的数据反查一次就能拿到。这种鱼眼原图/透视校正图双模式切换对数字孪生运维系统特别实用。鱼眼原图管全貌透视校正管细节两者共用一套VirtualLab导出的数据链路Shader里加一个开关就能切换。最后再分享一个做这个项目最值的经验用VirtualLab导出的数据在Unity里做还原时最花时间的不是Shader也不是追迹而是数据的方向对齐。我的习惯是在VirtualLab导出文件头里写明坐标系约定Unity端写解析器时先跑一个最小验证用例——追迹一个网格采样出来对着数。这个用例一旦通过后面所有平台移植都不会出方向问题。另一个实用技巧是保一个原始透视视角的对照开关联调时随时切换对比能帮你快速分辨画面异常是数据问题还是Shader问题。做这类光学数据驱动渲染的项目这两点能帮你省掉大量无头苍蝇式的排错时间。