5.1 渲染引擎
5.1 渲染引擎
本节摘要：Gazebo 的渲染引擎（ogre1/ogre2）在仿真中的首要职责不是给人看画面，而是给视觉类传感器（相机、深度相机、RGBD）制造像素数据。渲染管线沿"场景图 → 材质与光照 → 帧缓冲 → 传感器消息"走一遍，GPU 传感器让多个相机共享一次渲染。理解这条管线，才能配置出对算法友好（而非对人眼好看）的传感器。
一个反直觉的事实：画面是副产品
GUI 里那幅三维画面，和相机传感器收到的图像，走的是同一套渲染管线，但服务对象不同：前者给人（帧率流畅即可），后者给算法（内参、畸变、光照一致性必须严格）。区分这两种需求，是配置渲染的第一步。
一个直接推论：无头模式（-s）下没有 GUI 画面，但相机传感器照样出图——因为渲染发生在服务器进程的传感器系统里，GUI 只是又一个消费者。这也解释了 2.1 的架构红利从哪来。
渲染管线四段
引擎选择与传感器声明
世界级 <render_engine> 可选 ogre1 或 ogre2：ogre2 是现代管线（更好的光照与 PBR 支持，视觉传感器推荐），ogre1 兼容旧素材。一个务实的相机配置：
<sensor name="front_camera" type="camera"> <update_rate>30</update_rate> <!-- 挂在仿真时间上(2.2) --> <topic>/model/robot/front_camera/image</topic> <camera name="front"> <horizontal_fov>1.4</horizontal_fov> <image><width>1280</width><height>720</height></image> <clip><near>0.1</near><far>100</far></clip> <!-- 噪声与畸变在 5.3 展开 --> </camera> <visualize>false</visualize> <!-- 生产环境关掉可视化窗口 --> </sensor>
三个对算法影响最大、对人眼无感的参数：horizontal_fov（与内参直接相关，标定代码会用到）、clip near/far（太近的 near 裁剪会让近处障碍"消失"）、update_rate（30Hz 相机配 5Hz 的处理节点，队列会积压——2.2 的时间账在感知侧的回响）。
⚠️ 常见坑：分辨率开到 1920×1080 还开三个相机，RTF 直接掉到 0.2。视觉实验的默认起点应是 640×480 单相机，确认管线跑通、且实验确实需要细节时再升级。渲染是仿真里最贵的奢侈品。
💡 关键直觉：给算法的相机不需要好看，需要一致。光照突变、材质闪烁这些"视觉噪声"如果不在你的实验变量里，就该消除；如果在（比如做光照鲁棒性），就该受控——总之是设计决策，不是意外。
内参自证：从 SDF 算出针孔模型的 fx/fy
"horizontal_fov 与内参直接相关"这句话可以落到可验证的数字。针孔模型里，焦距（像素单位）与分辨率、视场角的关系是 fx = fy = (W/2) / tan(HFOV/2)。把 SDF 声明代入，就得到算法侧 camera_info 里应当出现的内参——仿真传感器的内参不需要标定，但需要核对，因为 SDF 里改一个 FOV 数字，下游所有依赖内参的视觉里程计都会受影响：
# 从 SDF 相机声明推导内参并核对 camera_info import math, re sdf = open("front_camera.sdf").read() W = int(re.search(r"<width>(\d+)</width>", sdf).group(1)) H = int(re.search(r"<height>(\d+)</height>", sdf).group(1)) hfov = float(re.search(r"<horizontal_fov>([0-9.]+)", sdf).group(1)) fx = (W / 2) / math.tan(hfov / 2) cx, cy = (W - 1) / 2, (H - 1) / 2 print(f"推导内参: fx=fy={fx:.1f}, cx={cx:.1f}, cy={cy:.1f}") print(f"校验口径: 用该内参把 3D 点投到像素, 与渲染图比对误差应 < 1 px")
# 对照实测：桥接相机信息话题，直接读仿真发布的内参 gz topic -e -t /model/robot/front_camera/camera_info --num 1 \ | grep -E "focal|principal"
两路输出应当严丝合缝——如果不一致（比如桥接节点套了裁剪、或 SDF 与实际加载版本不符），视觉里程计的深度估计会出现系统性偏差，且没有随机噪声提示你。配套经验：在场景里放一块已知边长 1 米的标定板，用推导内参投影其四个角点、与图像像素对齐一次，是每次改相机配置后的三十秒回归。FOV、内参、外参三者的"账"在仿真里全部显式可查，这是仿真相机相对真机最大的纪律优势——前提是你真的去查。
同一套核对思路也适用于深度相机与 RGBD：深度图的量纲（米还是毫米）、无效值约定（超出 far 裁剪面的像素填什么）、左右目基线（双目配置时）三项是下游点云处理最常见的踩坑点。把它们与内参一起写进传感器的"规格卡片"注释进 SDF，配置变更时随文件一起被 review，感知管线的隐式假设就都有了出处。
本节要点回顾
- 渲染为传感器服务，GUI 画面是副产品；无头模式下相机照常出图。
- 管线四段：场景图 → 材质光照 → 相机帧缓冲 → 按节拍发布；GPU 传感器共享渲染，快且一致。
- ogre2 为主，旧素材兼容才用 ogre1；无显卡 CI 用 CPU 型传感器。
- 三个隐形参数：FOV、裁剪面、更新率——对算法影响大，对人眼无感。
管线清楚了，下一节逐个拆常用传感器：每一种的数据从场景的哪个部位被"制造"出来，保真边界画在哪。