双高斯镜头可视化：VirtualLab联合Unity搭建三维光学仿真交互方案

前阵子做光学设计方案汇报，我把Zemax里的点列图和MTF曲线投到屏幕上，对面几个不懂光学的同事眼神明显放空。一个经典的双高斯照相机物镜，在光学设计软件里剖成平面图之后，只有业内人能脑补出那些光线在空气与玻璃之间来回折射的走向。后来我们换了个路子：用VirtualLab做物理光学仿真，再把它和Unity的三维交互环境接起来，镜头可以从任意角度旋转、剖面切光路、像面上直接看光斑，整套双高斯结构一下子就“讲得出口”了。

这篇就是把那套结合方案完整复盘一遍。内容覆盖双高斯物镜的基础设计参数、VirtualLab侧建模与仿真要点、Unity三维重建、光路可视化与交互演示，以及我们踩过的坐标系翻转、透明排序、DrawCall爆炸之类的坑。适合光学工程师想做跨平台呈现，也适合Unity开发者接到光学仿真项目时快速建立技术框架。

1. 双高斯物镜搬进Unity这个事儿，到底是解决了什么痛点

1.1 双高斯结构是哪种镜头，为什么拿它当演示对象

双高斯结构是从高斯望远镜物镜一路演化来的对称式镜头。最经典的原型大概是6片4组，后来为了增大孔径和矫正色差出现了很多衍生型，比如把两组之间的间隔拉开、把两侧负透镜改成胶合透镜，或者增加一片靠近光阑的改进型。从结构上看，它的核心特征是以孔径光阑为轴，前后大致对称，每个半组里通常包含正负透镜交替排列，让光线在一个有限的长度内完成多次偏折。

它特别适合作为光学仿真的演示对象，原因是它的像差矫正逻辑非常典型且不那么抽象。对称结构会天然抵消垂轴像差，比如畸变和倍率色差，而球差、彗差、像散这些轴像差则依靠非对称微调和折射率搭配去压制。这意味着当你想要演示“某一组透镜到底起了什么作用”时，双高斯比那种极端非对称的远摄镜头更容易拆开来解释。

我们项目里采用的演示规格也很有代表性：焦距50mm、F数2.0、半视场角约21°、可见光波段成像。这差不多对应一颗日常标准镜头的规格范围，F2.0既体现得出大孔径下的像差矫正难度，又不会像F0.95那样让方案变得不接地气。

1.2 传统光学设计交付和现实展示之间的落差

光学设计软件本身是很强的工程工具，但它最终产出的东西基本是二维剖视图、光线追迹图和一堆像差曲线。这个组合对光学工程师来说信息密度很高，可一旦要拿去内部评审、客户演示或课堂教学，问题就来了：

• 二维剖视图无法让观看者建立“光线在三维空间中如何穿过一组旋转对称面”的直觉。
• MTF和点列图是结果数据，听的人很难把这串数字和刚才看到的剖面结构对应上。
• 想表达不同视场角光线在光阑附近的走向差异，靠鼠标在软件里切截面并不直观。
• 光学设计软件里改参数、看结果的交互方式偏专业，不适合让非专业人员直接上手探索。

如果只是做汇报，静态截图勉强够用。但我们想要的是让观看者自己旋转镜头、拨动光圈、像拿了一台虚拟拆解机一样观察内部结构。这时就需要一个实时的三维环境来承载整个镜头模型和光路，Unity是相当自然的选择。

1.3 项目的技术分工：VirtualLab做算力，Unity做表达力

这个分工在项目一开始就该定清楚。VirtualLab擅长的是物理光学层面的场追迹与衍射计算，它能把一个双高斯物镜在焦平面上产生的精确光强分布仿真出来。Unity作为游戏引擎，长处是交互、三维渲染和跨平台部署。两者不是替代关系，VirtualLab负责“算得准”，Unity负责“看得懂”。

实际操作中，虚拟仿真的参数以VirtualLab一侧为准，Unity拿到的是一套经过归纳的结构与结果数据。也就是说，我们不是真的在Unity里重新跑一遍完整的物理光学追迹，而是把镜头结构参数、采样光线数据、像面光强分布和主要像差结果同步到Unity里，用实时三维手段把它们呈现出来。这个观念非常重要，一开始我们试图在Unity里复刻所有物理光学效果，做了两星期后发现没有必要，而且数据量根本撑不起实时性。

2. VirtualLab侧建模：把一台双高斯镜头做成可信的仿真源

2.1 先捏合一套参数合理的演示镜头

在VirtualLab里建模之前，第一步不是打开软件，而是确定镜头系统的设计参数。双高斯结构的经典设计规格虽然有很多专利可以参考，但我建议不要直接复制专利表，因为专利里的镜片间距往往包含浮动设计、非球面补偿等复杂条件，给第一次做集成的人增加很多负担。

我们最终采用的是一组简化的单色光演示参数组合，方便验证系统逻辑而不是纠结实际量产公差。下表是核心系统参数的纲要：

面型半径、厚度、玻璃折射率这些数据，我们从设计库中导出后会整理成统一的透镜参数表。这里有个很关键的习惯：不要只在VirtualLab里建了一个光学系统就完事，要同步在项目目录里维护一份CSV或JSON格式的透镜表。这份表后来会被Unity侧的建模脚本直接读取，是连接两个软件的核心数据结构。

2.2 在VirtualLab里的构建路径

在VirtualLab里搭建双高斯结构有两条路线。一条是从头构建：在元件列表中逐个添加透镜，设置每个面的曲率半径、厚度、孔径和材料；另一条是把设计好的镜头文件导入后，在VirtualLab里统一分配表面属性和材料。

两条路我们都试过。从光学设计软件导入的优势是结构参数不容易录入出错，而且能直接继承设计时的视场和波长配置；缺点是你必须额外花时间检查导入后的表面方向，特别是在非序列排布下，一个表面方向颠倒就可能导致整个系统变成“一团迷雾”。

从VirtualLab元件库直接构建则更可控。每个光学面独立添加，遇到胶合面时明确设定胶合材料，这样后台的场追迹算法不会搞错折射率顺序。但缺点同样明显：如果遇到几十个面的复杂系统，手动录入的出错率会急剧上升。

双高斯这种十几二十个折射面的镜头，两条路线都可以走。第一次做集成验证，我个人建议选择元件库手动构建，因为出错后定位路径最短；当流程稳定以后，再切换成导入方式提升批量效率。构建时把每个透镜或镜组用一个清晰的命名前缀，比如L1_Front_Positive，便于在检测光路时快速定位。

2.3 光源、孔径、探测器与波长的调试要点

VirtualLab里的光源设置决定了你最终仿真的是“无限远物体成像”还是“有限共轭成像”。双高斯通常作为摄影物镜，所以在虚拟实验中我们一般把光源放到无限远，用准直光模拟无限远景物发出的光。对单视场点来说，可以设置一束有一定发散角或完全准直的入射光，让它以某个入射角打到镜头第一面。

光阑位置是一个需要特别小心的地方。实物镜头中的孔径光阑一般位于两半组中间的机械结构上，VirtualLab建模时要把它配置成真正的孔径限制面，而不是只在一个平面上挂一个“光圈贴图”。常见做法是在系统中间插入一个圆形孔径，把它设为系统的光阑，再让VirtualLab的光线在这个面处被实际裁剪。只有这样，后面去分析不同F数下的成像差异时，改动光阑大小才会真实地反映到像面光强分布上。

探测器方面，像面上的采样分辨率需要和后续Unity显示的图像质量联动。我们常用的做法是设置探测器分辨率为1024×1024或更高，保证像面中心区域的点列图和光斑模式有足够的细节。探测器记录的是辐射强度分布，后续导出时要保留原始浮点数据，不要直接用屏幕截图，否则高光区域会直接饱和丢失很多低频信息。

波长设置则视实验目的而定。如果只验证单色像差，可以用单波长光显著降低仿真参数复杂度，方便排查光线异常；一旦要跑色差，就必须设置多个波长并指定合理的权重。双高斯色差矫正情况在各波长下并不相同，只跑一个波长会让人觉得色差完全不存在。

2.4 导出数据的注意事项

VirtualLab计算完成后，需要导出的数据远不止一张图片。我们在项目里统一导出以下几类内容：

• 镜头结构参数表：几何尺寸、折射率，作为Unity建模依据。
• 像面强度分布：以高动态范围数据导出，后在Unity中映射为可视纹理。
• 点列图和MTF结果：作为Unity中“分析模式”界面切换展示的素材。
• 若干关键视场角的采样光线坐标：用于在Unity里渲染近似光路。

关于采样光线坐标，要特别提醒：VirtualLab不同版本、不同许可等级的导出能力有差异，如果无法直接导出完整光线条数据，可以退而求其次，在Unity里自己写一个仅针对双高斯球面的逐面折射计算器。只要透镜表正确，轴上与若干离轴视场的光线走向足以做到视觉上的精确。

因为物理光学仿真数据本身就比较大，建议在VirtualLab一侧做一次数据清洗。例如像面强度分布，正视角下图中像素值是浮点强度，一定要规定好它在Unity里面颜色映射的范围。我们习惯在导出时保存一份minimum和maximum的元数据，这样Unity侧显示伪彩色图时不会出现整张图全亮或全暗的尴尬情况。

3. Unity侧重新把镜头“长出来”：从透镜表到三维模型

3.1 透镜参数表的统一格式

这部分是Unity和VirtualLab衔接的地基。虽然两个软件都处理光学系统，但它们的数据结构千差万别。VirtualLab关心每个面在光轴上的位置和面型；Unity里的模型则关心每个透镜中心的空间坐标、旋转体轮廓和材质参数。为了不让改动一个半径就要去改三处代码，我们把透镜表抽象成一个核心数据结构。

透镜表在项目里使用JSON存储，一个极简结构类似这样：

json复制{
  "focalLength": 50,
  "fNumber": 2.0,
  "units": "mm",
  "elements": [
    {
      "name": "L1",
      "frontSurfaceRadius": 42.5,
      "backSurfaceRadius": -380.0,
      "centerThickness": 6.2,
      "apertureRadius": 23.0,
      "refractiveIndex": 1.5168,
      "glass": "N-BK7"
    },
    {
      "name": "L2",
      "frontSurfaceRadius": -80.4,
      "backSurfaceRadius": 31.2,
      "centerThickness": 2.8,
      "apertureRadius": 20.5,
      "refractiveIndex": 1.7174,
      "glass": "N-SF5"
    }
  ]
}

实际的表里还会包含透镜间空气间隔、胶合面分组和可能的非球面系数。统一按“透镜实体”为单位而不是按“光学面”为单位存储，在Unity建模时会更顺手，因为一个双凸/弯月透镜实体可以直接由一个旋转体生成。

3.2 由半径和厚度生成透镜体

拿到这张透镜表后，Unity侧最核心的建模任务就是把每个透镜实体变成可渲染的网格。

双高斯物镜包含大量球面透镜，而球面透镜具有旋转对称性，因此从轮廓构建一个“车削体”是最高效的方式。基本思路是：沿着一个透镜的前表面和后表面分别采样曲线点，映射出透镜截面的多边形轮廓，再用Unity的网格工具围绕光轴旋转一周生成表面网格。

一个示意性的生成流程如下：

csharp复制Vector3[] BuildHalfContour(LensElement le, int samples)
{
    // 先求前表面在孔径范围内的矢高，形成前半段轮廓
    // 通过球面方程: z = r - sqrt(r^2 - h^2)
    // 再求后表面矢高，形成后半段轮廓，最后加上边缘厚度
}

实际操作中不需要每帧生成网格，可以在编辑阶段或Awake阶段执行一次，然后把Mesh保存到本地Asset。几个容易出错的地方：

• 球面中心厚度的计算要考虑前后表面矢高差，不能只把透镜当圆柱。
• 透镜边缘要留一个不参与光学的“安装环”外观，用于表现实际机械装配的姿态。
• 凸面的法线方向要和光线折射计算时的法线约定保持一致，避免Unity光照显示和光线计算互相矛盾。

对于UV坐标，建议按柱坐标展开，这样后续给透镜侧面叠加条纹纹理或标注时更方便。网格顶点数不需要极高，双高斯这种口径不大的透镜，一圈128个顶点足够让边缘在近距离观察时也很平滑。

3.3 坐标手性和单位比例处理

这是整个集成项目里第一个真正的大坑。VirtualLab使用常规右手坐标系，光学系统沿正Z方向传播；Unity是左手坐标系，相机默认看正Z方向，但场景中的物体坐标约定经常因团队习惯而不同。

两边的单位比例差异也是极大隐患。VirtualLab里默认用毫米描述镜头尺寸，Unity引擎内部虽然没有强制单位，但物理引擎、光照衰减、后处理效果中的很多参数都以“1单位=1米”为前提。如果把一个等效50mm的镜头直接按50 Unity单位摆进去，标准点光源衰减会异常，摄像机的近裁剪面也可能裁剪掉内部透镜。

我们最终的约定方案是：

跑过一轮后，你会发现让透镜模型保持毫米级真实尺寸有额外好处：后续如果要接入真实的机械镜筒CAD模型，可以直接合并到场景里，不必二次缩放。前提是场景中与光有关的后期效果都改用不受物理准确度约束的简化方案。

3.4 材质与层级结构建议

Unity里面多透镜模型的层级结构如果不提前规划，后面的交互逻辑会非常难写。我们采用的层次大致是：

• LensRoot：空物体，挂LensSystem组件，负责载入JSON、触发模型生成、管理光线显示开关。
  • LensGroup_1：前镜组，包含多片独立透镜。
  • LensGroup_2：后镜组。
  • Aperture：模拟孔径光阑的圆环。
  • SensorPlane：像面屏，未来用于显示虚拟成像纹理。

透镜材质使用带透明度的表面着色器。这里如果使用默认Standard透明模式，会出现比较严重的透镜间排序问题。后面第5节专门展开。单纯建模阶段，材质参数先以半透明白玻璃效果为主，折射率数值不用直接交给着色器，视觉上只需要做出玻璃质感即可。

4. 光路可视化的实现：不要假装在实时追迹物理光学

4.1 三种做法

想把光路展示在Unity场景里，有三种实现路线，它们的工作量和真实度递增：

第一种，完全不做光线计算，把VirtualLab中仿真得到的像面强度和几个视场的光线截图当成2D Sprite贴进场景。优点是实施极快，缺点是一旦用户旋转视角，光线图完全是扁的，起不到三维演示效果。

第二种，按照透镜表在Unity里写一个简化的球面折射计算器，只在需要时预计算若干视场、若干入瞳采样点的光线，然后生成Mesh。这套方案不实时模拟整个物理过程，但能保证三维空间中的折线对用户来说“看得懂”，适合教学和演示。

第三种，把VirtualLab的场追迹结果以批量光线数据导入Unity，用GPU实例化或数据纹理方式渲染成千上万条光线。视觉震撼力最强，但数据格式转换复杂，对项目版本管理要求高。

再往下就是完全在Unity里做波前传播仿真，听起来很潇洒，但对绝大多数项目属于杀鸡用牛刀。我们最初想搞第三步，后来因为VirtualLab导出的光线数据在各版本中结构差异大、坐标系标识不明确，最终版本选择了第二种为主、第一种为辅。三种按需组合更高效。

4.2 预计算光线的数据流

为了达到“像那么回事”的光路展示效果，第二路线的核心是写一个轻量追迹器。它不关心衍射，不考虑波前，只是按照几何光学定律把一条光线的路径逐面推算出来。

在Unity里，我们把每条光线视为一个结构体：

csharp复制public struct RayPath
{
    public Vector3[] points;    // 各交点
    public int segmentCount;    // 实际段数
    public float wavelength;    // 波长标记
    public float intensity;     // 相对强度
}

追迹核心是每次击中球面后计算交点、再按斯涅尔定律计算折射方向。球面交点的解析求解是标准数学问题，这里不展开公式，但有一个容易被忽略的细节：玻璃的折射率会随波长变化，用Unity里单一的float存折射率是不够的。建议在透镜表里为每个玻璃至少保存d光和F光两个折射率，在预计算阶段插值出当前波长下的折射率，否则展示多波长光路时，色散效果完全是假的。

追迹结果不需要实时产生。初始化时对固定视场角和入瞳采样点循环一次，把得到的RayPath数组缓存到内存里，任何交互只更新它的可见性和渲染状态。

4.3 光线的表示与渲染技巧

这是另一个技术重点。Unity里最直观的管线是给每条光线的每一段加一个LineRenderer，但这个方案在几十条光线多个折线段时就崩了。假设你有9个视场、每个视场7条入瞳光线、每条光线经历10段，那么LineRenderer组件会有630个，DrawCall直接爆炸，而且这些线段在远处会闪烁。

我们的方案是预先将一条条光线作为细长的四边形管道构建成一个合并Mesh，整批光线只提交一次绘制。具体做法是，在计算完RayPath后，把每个线段按垂直于光线的方向展开成两个顶点，形成宽度几像素的带状几何。这样光线的粗细可以在构建时设定，并且合并成一个Mesh后可以整体控制半透明和颜色渐变。

物体空间中的光线颜色建议按视场区分，而不是全部用单一绿色或红色。更直观的约定是：轴上光线用暖色，越往边缘视场越偏冷色。这样观众一眼就知道哪些光线来自画面中心、哪些来自边缘。

如果要表现光强，除了改变颜色亮度，还可以把光线段的透明度按强度字段设置。注意不要用线宽来表示强度，常规三维软件里的线宽在Unity渲染中极不可控。

4.4 成像平面的模拟和虚拟放大观察

光路展示到位后，需要给用户一个“看最终成像”的窗口。我们在相机传感器位置放置了一个半透明的像面屏，把VirtualLab导出的像面强度图片作为纹理贴在屏上。这个屏可以切换两种状态：

• 全视场预览：显示整个像面的模拟图像。
• 焦点扩散观察：显示某一指定位置的放大后光斑，比如点击屏上一点，切换成一处局部放大的纹理视图。

放大视图可以通过一个独立的UI窗口实现，里面用RawImage显示局部裁切后的Texture2D。由于VirtualLab导出的数据是高动态范围图像，我们需要在Unity侧做一个浮点到0~255的映射。这里强烈建议保留一个可调的曝光滑块，因为光学仿真数据中，峰值可能比暗区域高出几个数量级，不做动态范围压缩的话，观众只会看到一片白。

伪彩色映射也是一个实用选项：将光强数值映射到深蓝到黄白的渐变，比灰度更容易看出低强度区域的结构。我们内部默认使用伪彩色模式，对外演示时可以一键切换成黑白模式，方便和传统光学教材中的光斑图形对应。

5. 集成调试阶段真正让人头疼的几个问题

5.1 左右手坐标系造成的镜像翻转问题

这是整个项目调试时间最长的一个问题。现象很典型：VirtualLab里计算出的某个离轴视场像点偏向像面右上方，但Unity里同步出来的像面图像却出现在左上方。

根源就是坐标系手性。VirtualLab的右手坐标系在经过外层导出、硬编码进Unity后，如果单纯把X、Y坐标直接拾取，没有做镜像处理，表现出的图像自然翻转。更麻烦的是，如果只是把整个镜头模型旋转180°，透镜间的光学顺序又会对调，前后镜组位置错乱。

解决办法不是到处加负号，而是在数据层做一次坐标转换。我们把所有从VirtualLab来的数据先经过一个TransformUtil函数，统一把Y或Z方向反转，转换之后再进入场景管线。后端的渲染逻辑、交互逻辑完全不感知这个翻转过程。

排查这种问题，最快的方法是单根光线验证：选轴上点，如果轴上点没问题，再选一个边缘点，在VirtualLab里输出它的像面坐标，在Unity里打印同样的坐标，逐个轴对比。不要一边打印一边凭感觉猜，很容易把自己绕晕。

5.2 毫米级场景和Unity物理后处理不兼容

把镜头整个按毫米单位放进去之后，最直观的异常是摄像机一靠近镜头，画面就会出现大块裁剪。常见Unity项目里把1单位当1米使用，近裁剪面默认0.3，毫米级镜头第一片透镜在这个距离内几乎紧贴相机，必然被裁掉。

近裁剪面调整是一个办法，但设到0.001又会引入深度缓冲精度问题，尤其当场景里还有很远的背景参照物时，Z-fighting会变得明显。第二个办法是整体缩放，1mm映射为0.1 Unity单位，镜头总长会变成几个单位，与场景常规数值匹配。

我们走了第二种方案后，光照系统仍然有若干反直觉现象。实际上，如果用Unity自带的实时阴影和点光源衰减，无论如何调都很难准确模拟真实光源。后来统一改为无光照的Unlit材质配合自定义色调，效果干净，还少很多排查工作。在光学演示项目里，视觉上“清楚”比物理上“真实光照”更重要。

5.3 多个半透明透镜的排序问题

双高斯镜头在Unity里显示时，所有透镜都是凹透镜与凸透镜的堆叠，并且多数表面是透明的。前向渲染下Unity对透明物体的渲染顺序并不总是按“距离相机由远到近”稳定排序，当多片透镜的中心点几乎靠在一起时，排序会频繁出错。

表现的典型现象是：明明应该从侧面看到A透镜挡住B透镜，渲染结果却是B透镜整个从A透镜中透过来，颜色发虚，边界混乱。

处理方案从简单到复杂排列：

• 确保透镜模型之间在Z方向上有一定距离，避免中心点完全相同；
• 使用双面渲染并关闭深度写入，但各个透镜要求比较宽松时效果还可以接受；
• 最彻底的办法是自己编写一个透明的透镜着色器，在同一个Pass内处理正反面，并对透镜表面做简单的反射高光模拟，而不是依赖Unity默认的Surface Output。

同时，在项目里我们默认把透镜的透明度控制在0.8以下而不要完全透明。完全透明的玻璃在背光视角下会让人看不清透镜形状。反而维持一点雾感效果，在演示中更清楚。

5.4 光线太多导致卡顿和闪烁

预计算出的光线如果数量很多，即使在构建阶段合并成一个Mesh，在运行时也会因为顶点数太大而卡顿。尤其当我们想展示每个视场整个入瞳面被均匀采样时，几十个视场乘以几十个光瞳点的组合很容易上万条光线。

这里要分清楚视觉目标和性能目标。给教学演示用，不需要展示密密麻麻的所有光线。实际操作中，每个视场采样7条光线已经能清晰表达光瞳成像特点。7×9视场约63条光线，在合并成一个Mesh后，几乎不占性能。

如果确实想要高密度光线效果，比如展示点列图的形成机理，建议不要使用3D光线，而是在像面屏上叠加一个基于VirtualLab结果的粒子系统或纹理动画，用二维形象替代三维线缆。这样观众理解效果不逊于看一堆交错线，而性能压力小一个数量级。

6. 演示模式与交互设计：用一套可调参数讲清楚双高斯镜头

6.1 观测方式的打造

光学演示项目的交互设计不需要复杂，关键是让用户下意识就懂怎么操作。我们把相机控制分成两种模式：环绕模式和剖切模式。

环绕模式下，用户可以任意旋转视角，从镜头前方、侧面、背部观察整体结构。默认相机应该略微偏上，这样能看出镜头的圆柱感，而不是正对着像一堵墙。

剖切模式则把镜头从侧面剖开一半，隐藏上半部分透镜，只显示沿光轴的剖面区域。这时用户能直接看到光线的内部折射过程，因为被隐藏的半个镜体不再遮挡视线。这个剖切操作可以用一个Slider控制剖切角度，从0°到180°连续滑动，视觉反馈极其直观。

实际操作中还要做一层镜头外壳的半透明化处理，因为双高斯镜头如果带镜筒金属外壳，会完全挡住光路，演示也就失去了意义。我们在演示模式下把外壳透明度调低，露出内部镜片和光栏。

6.2 调节孔径与焦面位置

用户调节F数和焦面偏移，是理解大孔径镜头像差的好途径。F数从F1.4到F5.6变化时，光阑孔径变化会直接改变光线束的粗细，球差和彗差的可见程度也会相应变化。

这一交互看起来简单，背后尽量不要做实时光追。我们的做法是提前在VirtualLab里仿真好若干档F数、若干焦点偏移量下的像面强度图，在Unity里做纹理集的切换。例如F2.0焦面正常，准备一张点列图；焦点前移0.1mm再准备一张，用户滑块移动时按最近邻或轻微插值切换。

实时切换的代价是纹理内存，但由于每张图可以控制在1024×1024以内，十来组图完全能够接受，比在Unity里做精确实时追迹靠谱得多。

6.3 标签标注与教学导览

演示的最后一块拼图是信息标注。双高斯镜头结构中的每个面都承载光学作用，点击某个透镜时，一个浮出的World Space UI应该显示它的曲率半径、厚度、玻璃牌号、承担的像差矫正任务。

我们制作了一个“教学导览模式”：内置若干节点，比如“前组正透镜：主要承担光线会聚”“中央光阑：决定系统孔径”“胶合面：校正色差”等。点击某一个节点，Unity摄像机会平滑移动至相应部件附近并高亮该部件，同时旁边的说明面板显示对应VirtualLab仿真图表。整个导览模式直接从某个教学路径构建，不需要用户手动操作镜头，适合课堂演示和展厅大屏播放。

这套交互结构做好以后，双高斯镜头就不再只是光学设计软件里的一个工程文件，而变为一台可以被“拆开、旋转、拨动”的虚拟实物。实际给几位光学背景不深的朋友试用过，效果最明显的节点是剖切模式配合多视场光路图开启时，几乎每个人都会立刻明白镜头中间为什么要那么厚、光阑为什么要放在那个位置。后续如果想把流程复用到其他镜头类型，只要继续沿用这套透镜表、VirtualLab数据源和Unity交互框架，就无需另起炉灶。