cowx的笔记页

渲染七大核心模块

18 min read

1.管线基础设施与底层抽象 (Infrastructure & RHI)

2.场景组织与可见性剔除 (Scene Management & Visibility)

渲染组

mesh.renderingGroupId = transparent ? 1 : 0 这会让玻璃在另一个 rendering group 里渲染。跨组后，透明物体可能不再正确受前面不透明物体的深度遮挡，于是就出现你说的现象：玻璃明明在后面，但像整块跑到前面一样盖住楼体。

3.材质系统与着色模型 (Material & Shading Models)

4.光照与全局光照 (Lighting & GI)

IBL (Image-Based Lighting / 基于图像的光照)

反射与折射

  • 怎么理解：这是 PBR（基于物理渲染）的绝对核心。如果不用 IBL，你的金属材质看起来就是一坨死黑，玻璃也不会有漂亮的倒影。它相当于给整个场景套一个全景高清环境球（通常是 .env 或 .dds 格式），让物体表面去反射周围天空和环境的光线。

  • 关键词：HDR Environment Map (环境贴图), Standard probe (反射探针)。

HDR

平时的理解， HDR 理解为“包裹在模型外面的一层无限大的彩色大球”，但是底层的 Shader（着色器）逻辑里，HDR 最终是面向“材质采样”生效的

它的内部生效机制：

当 PBR 材质在渲染某一个像素点时，它会计算：

  1. 摄像机看这个像素的角度（View Vector）

  2. 这个像素表面的朝向（Normal Vector，法线）

  3. 通过这两个方向，计算出一条反射光线（Reflection Vector）。

  4. 材质的 Shader 拿着这条反射光线，去那张 HDR 图上“采样（Lookup）”对应方向的颜色。如果反射光线指向上方，它就采到 HDR 里的天空色；指向下方，就采到 HDR 里的地面色。

因此，HDR 的本质就是一张供材质 Shader 查询的颜色查找表（反射源）。

用法 A：全局绑定

  • 效果：场景里所有模型（地面、猴子、建筑）的 PBR 材质，默认都会去采样这个 HDR。

  • 缺点：如果给全局设置了 HDR (scene.environmentTexture)：巴比伦的底层 Shader 机制会默认让场景里的所有 PBR 材质都去响应这个环境球。这就意味着，本该全烘焙的地面（以及场景里其他几百个静态物体），在 GPU 渲染时，都会在 Shader 里强行塞入一套复杂的环境反射计算。哪怕你把地面的粗糙度设为 1、金属度设为 0，GPU 依然要白白消耗算力去执行反射采样和矩阵运算。并且，一旦开了这个，之前烘焙好的地面等就会被这个全局 HDR “二次照亮”，导致之前烘焙的光影和暗部细节被二次影响。

用法 B：材质独享

  • 效果：此时，场景里只有被选定材质（尤其玻璃）的 Shader 会去激活“视角-法线反射”的计算，去采样这张 HDR 里的亮光和天空，从而在表面形成流动的、极其真实的玻璃高光与倒影。

  • 对地面的影响：0 影响。地面的材质没有设置 reflectionTexture，它会继续安安静静地走它的 useLightmapAsShadowmap = true 路径，保持纯净、省资源的烘焙光影。 只需要在内存中创建一个 HDR 纹理实例（注意：是一份数据，不是 new 5次），然后把这同一个实例丢给这 5 个玻璃材质的 reflectionTexture，全场景只有这 被选定物体的 Shader 包含了“反射采样”的复杂代码

5.阴影与遮蔽 (Shadows & Occlusion)

阴影

级别技术名称核心舞台网页端（WebGL/WebGPU）能用吗？
经典基石PCF / PCSS / ESM所有引擎、所有平台（手游/网页/独立游戏）能（当前主力）
大场景标配CSM (级联阴影)任何有太阳光的开放世界能（巴比伦原生自带）
次世代王牌Virtual Shadow (虚拟) / 光追 / SDFUE5、Unity HDRP、3A级别PC/主机游戏WebGPU 时代正在逐步引入

阴影基石

传统的阴影贴图（Shadow Map）锯齿严重且边缘死板。为了让阴影边缘像现实中一样具有“过渡”（半影区），演进出了以下几种方案：

  • PCF (Percentage-Closer Filtering - 百分比靠近过滤)：最经典的软阴影底子。它在阴影贴图周围采样几个点算平均值，让边缘变模糊。它解决的是像素边缘毛糙的问题。不管是近处的影子还是远处的影子，如果没有滤镜，拉近了看都是楼梯状的锯齿。PCF 的作用就是在这些阴影像素的边缘进行采样模糊，把锯齿“擦”成平滑的斜线。

    • 痛点：不管离光源多远，阴影都是“一样糊”，缺乏空间层次感。

  • PCSS (Percentage-Closer Soft Shadows - 百分比靠近软阴影)：模拟物理世界的“接触面硬化”。它会先搜索遮挡物距离，离得近（如脚底）阴影锐利，离得远（如头顶阴影投在远处墙上）阴影极度扩散。

    • 代价：多次采样计算开销大，容易出噪点。

  • VSM (Variance Shadow Maps - 方差阴影贴图)：另辟蹊径，利用概率学中的方差（切比雪夫不等式）来估算阴影。阴影贴图不仅存深度，还存深度的平方。

    • 优势：快，支持硬件级模糊和 Mipmap。

    • 痛点：在两个叠在一起的遮挡物之间容易出现严重的“漏光（Light Bleeding）”现象。

UE5的VSM

的文档里绝对会高频看到 VSM 这个词，但一定要注意：

  • 巴比伦/Unity里的 VSM = Variance Shadow Maps（方差阴影贴图，上面说的那个会漏光的经典算法）。

  • UE5 里的 VSM = Virtual Shadow Maps（虚拟阴影贴图）。

UE5 的 VSM 是配合 Nanite（无限高模）使用的次世代技术。它的逻辑把阴影贴图变成像《我的世界》一样的超大虚拟平铺贴图，按需加载像素。这解决了传统阴影贴图分辨率不够、大场景影子发虚变毛糙的问题。两者虽然都叫 VSM，但底层数学原理完全不同。

大场景阴影

CSM (Cascaded Shadow Maps / 级联阴影) —— 大场景必备

  • 怎么理解：无论是 UE、Unity 还是巴比伦，只要做室外大场景，必开 CSM。

  • 原理：离镜头近的地方，用一张高分辨率的阴影贴图；离得远的地方，用低分辨率的。引擎把视锥体切成好几段（Cascades），动态拼接。它解决的是“走着走着，远处的影子就变成马赛克”的问题。它解决的是大场景分辨率不够的问题。如果一个数字孪生园区有几公里大，只用一张常规的阴影贴图，那分配到你眼前一个小汽车上的阴影可能只有 2x2 个像素，影子就会变成巨大的马赛克。CSM 的做法是：离镜头近的单独给一张高清图，远的给中清图，更远的给低清图。

  • CSM级联阴影 原生仅支持叠加 PCF 和 PCSS

次世代阴影

Ray Traced Shadows (硬件光线追踪阴影) —— 终极写实

  • 怎么理解：现代 PC 单机游戏（开启RTX）的标配。

  • 原理：它不再生成什么“阴影贴图”了，而是直接从光源或者像素点发射真实的光线射线去求交点。

  • 视觉：完美解决物理硬化（比 PCSS 更精准、没有 Bug、支持半透明物体的彩色阴影）。在 Web 端，随着 WebGPU 的普及，未来网页端也能跑起原生的光追阴影。

SDF Shadows (Signed Distance Field / 符号距离场阴影) —— 虚幻引擎的看家本领

  • 怎么理解：UE 里的“纯动态大场景远景阴影”（Distance Field Shadows）。

  • 原理：把模型在后台简写成一个“距离场数据体”，不依赖传统的几何体和阴影贴图。

  • 优势：计算超远距离（比如几公里外的高山、树木树荫）的软阴影时，性能极其恐怖，内存占用极小。

使用案例

场景 A：室内/园区局部数字孪生（如：智慧机房、单个高端工厂车间）

  • 阴影方案：只用普通 ShadowGenerator + PCF / ESM

  • 原因：这类场景范围小（可能就几百平米），视线不会拉得极远。不需要动用复杂的 CSM 级联去切分视锥。直接给一张 2048x2048 的标准阴影贴图，配上 PCF 或者是过渡更柔和的 ESM，在网页端就足够漂亮且流畅了。

场景 B：室外大范围数字孪生（如：智慧城市、大型化工园区、港口码头）

  • 阴影方案：动态物体用 CSM + PCF 混合，静态建筑全烘焙

  • 原因：在这类大场景里，如果全场建筑都用实时 PCF，网页绝对会崩溃。WebGL 顶不住成百上千栋大楼同时压榨显卡去计算实时阴影。

🛠️ 大场景数字孪生的业界标配方案（Hybrid 混合流）：

  1. 静态背景（地形、楼宇、道路）：全部在 Blender 里把光影和 AO 烘焙成 Lightmap。正如你之前所说，直接贴图，实时阴影对它们完全关闭。

  2. 动态元件（AGV小车、巡检无人机、走动的人员、动态开闭的闸门）：开启 CascadedShadowGenerator (CSM) + PCF。并且设置阴影包含列表（shadowGenerator.getShadowMap().renderList），只让这些动起来的小东西产生实时阴影。

AO（环境光遮蔽 / Ambient Occlusion）

AO 解决的就是“物体有没有分量、是不是悬空”的问题，没有 AO，墙角、桌脚、设备接缝看起来就会像漂浮在空中一样虚浮。

实时派：SSAO / SSAO 2（屏幕空间环境光遮蔽）

这是纯靠前端显卡实时计算的后期特效。巴比伦内置了 SSAO 和 SSAO 2。

  • SSAO（一代）：只根据屏幕的深度图（Depth）去算周围有没东西挡住。边缘比较粗糙，容易有噪点和斑驳感，基本过时了。

  • SSAO 2（二代）：WebGL 端的绝对主力。它同时读取屏幕的深度图和法线图（Normal），并且加了双边模糊滤镜。算出来的墙角、结构缝隙阴影极其精准、细腻。

  • 针对数字孪生的建议：

    • 室内孪生（智慧机房、展厅、变电站室内）：无脑开 SSAO 2。只要是 PC 端访问，开 SSAO 2 配合基础灯光，设备的机械层次感和房间的立体感会瞬间拔高一个档次。

    • 园区/大场景孪生：慎开。因为它是屏幕空间算法，当视野里有成千上万个几何体边缘时，显卡在后处理里采样压力极大，移动端直接卡死。

材质派：PBR 材质自带的 Occlusion 贴图（通常是 ORM 贴图）

这属于“半动态”方案。我们在做数字孪生精细设备（比如一门高精度的机械臂、一台服务器机柜）时，会在 SP（Substance Painter）里把物体的微观缝隙 AO 烘焙出来。

  • 怎么玩：在游戏和高阶 WebGL 工业界，我们通常把 Occlusion（遮蔽）、Roughness（粗糙度）、Metallic（金属度）三张单通道图，合成为一张 ORM 贴图的 R、G、B 三个通道。

  • 优势：性能消耗极低。因为它是贴图，巴比伦在渲染 PBR 材质时顺便就读了。而且模型运动时，这个 AO 跟着模型走（比如机械臂关节转动，关节缝里的暗部依然在）。

  • 针对数字孪生的建议：重点、核心的交互设备、车辆、机械，必须在材质里自带这种 AO 贴图。

离线派：Baked AO / Lightmap（全场景全局光照烘焙）

这是大场景、移动端网页数字孪生的“终极外挂”。

  • 怎么玩：在 Blender 或 3ds Max 里，把整个园区、大楼的建筑和地形，直接把光照和 AO 烘焙成一张大贴图。要么像你之前说的，直接“拍死”融合进 BaseColor 固有色里，要么作为独立的 Lightmap 贴在 UV2 上。

  • 优势：性能消耗绝对为零。效果是好莱坞级别的，因为它是在全功能 3D 软件里用光线追踪算了几十分钟甚至几小时的结果，墙角和建筑死角的过渡极其柔和逼真。

  • 缺点：完全静态。太阳转动、大楼拆除，这个影子和暗部都不会变。

使用案例

根据硬件平台和场景大小做对对碰：

场景类型目标平台最合适、性价比最高的 AO 方案
大型室外大屏（智慧城市、港口、大园区）控制台大屏 PC全场景离线烘焙 AO/Lightmap + 局部动态物体（车、人）不给 AO（靠浅色阴影遮丑）。
室内精细孪生（智慧工厂车间、机房、实验室）高清 PC 浏览器开启巴比伦原生的 SSAO 2（拉开空间感） + 设备自带 ORM 材质 AO（丰富机械细节）。
任何移动端交付（手机微信小程序、iPad 汇报）手机 / 平板严禁开启任何实时 SSAO。全部在 Blender 里把建筑、地面、设备的 AO 融进 BaseColor 贴图。

6.后期处理与显示输出 (Post-Processing & Presentation)

7.资源流送与虚拟化系统 (Streaming & Virtualization)

8.应用建议

如果追求极致画质（PC端强力显卡）： IBL环境光 + 实时阴影 + SSAO 2 + 开启 Clear Coat 材质 + ACES色调映射 + TAA抗锯齿。

如果追求极致流畅（移动端或大场景）： IBL环境光 + 离线烘焙好的 Lightmap/AO 贴图（代替实时阴影和SSAO） + 基础后期滤镜（开启色调映射即可）。

玻璃的话，专门给

Graph View