【Unreal Fest 2023】利用虚幻引擎打造《诛仙2》的实时光影和大世界技术
来源：C:\Users\shaotang\Downloads\Bilibili_Videos[UFSH2023]利用虚幻引擎打造《诛仙2》的实时光影和大世界技术 _ 柴毅哲 完美世界.mp4
提取时间：2026-05-11 22:57:08
技术方案总结：大世界与实时渲染优化
1. 实时阴影方案
- 场景阴影
- 动态阴影：以玩家为中心，分层处理（最近层实时更新，中远层采用Cascaded Shadow Maps分帧更新）。
- 远景优化：通过将远处阴影“烘焙”到Base Color中，避免瞬时性能压力，同时保持立体感。
- 角色自阴影
- 定制化方案：采用Mask Only Prepass技术，结合角色专用Shading Model生成Shadow Map，通过高斯模糊实现柔和阴影。
- 性能权衡：仅在摄影棚或特写镜头中启用，确保性能可接受。
2. 大世界方案
- 核心目标
- 实现PC与移动端性能平衡，拒绝为移动端牺牲PC画质。
- 关键技术
- Level Streaming：动态加载不同区域资源，实现无缝衔接。
- World Composition：高效管理大规模场景拼接与数据组织。
- 场景分层策略
- 近景：高精度模型直接渲染。
- 中景：通过Level Streaming动态加载。
- 远景：采用LOD技术简化模型，降低性能消耗。
3. 流式加载与资源管理
- 物体分类
- 按包围盒表面积、对角线尺寸划分为四类（巨型、Lbu/Mbu/Sbu），差异化加载策略。
- 一键场景切分工具
- 自动化流程：资源分类、规范制定、LOD烘焙等全由工具完成，减少人工干预。
- 效果对比：改进后方案通过美术工作流优化，实现内存节省（如石头仅需4张贴图）与细节保留的平衡。
4. LOD烘焙优化
- 美术工作流
- 定制化处理：美术手动剔除远处无关细节（如栏杆、棱角），保留主体造型，避免自动减面算法的局限性。
- 效果提升：LOD精度与原模型一致，内存占用降低50%。
- 地形处理
- Static Mesh优化：调整锁边算法，确保Landscape与Static Mesh边缘面数比例1:1，解决漏光问题。
5. 多平台适配策略
- 流式加载配置
- PC端：支持复杂流送策略，优先画质。
- 移动端：优化加载效率，平衡性能与画质。
- 多相机支持
- 剧情触发时，即使在2公里外的代理网格中，也能通过多相机位置处理实现良好效果。
6. 地形方案（Unity原生方案）
- 待补充内容：原文在此部分被截断，需进一步补充Unity地形方案的具体优化措施（如Heightmap精度、植被分布策略等）。
总结
- 核心优势：通过Level Streaming、LOD烘焙、美术工作流优化，实现跨平台性能与画质的平衡。
- 创新点：
- 角色自阴影的Mask Only Prepass技术，解决全天候光照下的阴影异常问题。
- 自动化工具链减少人工干预，提升开发效率。
- 未来方向：完善地形方案细节，进一步优化移动端加载策略，探索AI辅助的LOD生成技术。
Slide 1 — 00:00:00
📌 要点汇总
- （过渡内容，无关键要点）
大家好，首先做个简短的自我介绍。我叫柴一哲，来自完美世界技术中台和《诛仙二》项目组。目前负责《诛仙二》的引擎和性能优化相关工作。
我们先看一段《诛仙二》的真机实录演示。
Slide 2 — 00:00:20
📌 要点汇总
- （内容过短，无关键要点）
！！
Slide 3 — 00:01:17
（该幻灯片时间段内未检测到语音内容）
Slide 4 — 00:01:24
📌 要点汇总
- 采用基于物理的渲染（PBR）技术实现动态光源与全局光照算法
- 实时光影技术提升画面真实感并增强剧情与玩家互动的视觉表现
- 大世界场景构建结合分层LOD技术与程序化生成算法实现无缝衔接
- 动态加载/卸载机制平衡画面质量与硬件资源占用率
《诛仙二》是一款仙侠类、仙侠未来式风格、写实画面表现的MMORPG游戏。该作同时在PC和手机平台进行同步研发，具备实时光影技术、大世界场景构建、多样化的场景风格以及独特的玩法等核心特点。今天我将重点分享《诛仙二》中实时光影技术的实现方案，以及大世界场景构建的具体技术路径。
\n\n
在实时光影技术方面，我们采用了基于物理的渲染（PBR）技术，通过动态光源计算和全局光照算法，实现了角色与场景在不同时间、天气条件下的光影变化。这种技术方案不仅提升了画面的真实感，还为后续的剧情表现和玩家互动提供了更丰富的视觉语言。
\n\n
针对大世界场景构建，我们采用了分层LOD（Level of Detail）技术，结合程序化生成算法，实现了从宏观地形到微观植被的无缝衔接。通过动态加载与卸载机制，确保了玩家在探索大世界时的流畅体验，同时有效控制了硬件资源的占用率。这种方案在保持画面质量的同时，也兼顾了游戏的性能表现。
Slide 5 — 00:01:58
📌 要点汇总
- 多光源动态阴影通过GPU光线追踪实现高精度实时渲染
- 大规模开放世界采用LOD管理策略降低硬件负载
- 跨平台网络框架结合UDP与预测回滚算法实现毫秒级同步延迟
- 端到端同步方案解决多人同屏高延迟操作同步问题
首先，从定制化渲染管线、实时光影、大世界这几个方面入手，其中会穿插一些端到端同步研发的经验，与大家一起探讨《诛仙二》研发过程中的心得。
在具体实施过程中，我们重点突破了多光源动态阴影的实时计算技术，通过基于GPU的光线追踪算法实现了复杂场景下光影效果的高精度渲染，同时优化了大规模开放世界的LOD（Level of Detail）管理策略，确保在保持画面质量的前提下降低硬件负载。
针对端到端同步研发的特殊需求，我们构建了跨平台的网络通信框架，采用基于UDP协议的自适应流量控制机制，结合预测回滚算法有效解决了高延迟场景下的操作同步问题，这套方案在多人同屏交互场景中实现了毫秒级的响应延迟。
Slide 6 — 00:02:14
📌 要点汇总
- 移动端基于前向渲染管线进行功能定制以匹配PC端延迟渲染效果
- 定制化渲染管线是实现跨平台一致渲染效果的必要手段
首先是定制化渲染管线。为什么？首先需要解释，我们为什么要自己定制一套渲染管线？在PC端我们使用的是延迟渲染管线。而移动端为了达到与PC端一致的渲染效果，在基于移动端前向渲染管线的基础上，我们针对游戏中需要的功能进行了大量定制。因此，对渲染管线进行定制化是必要的。
今天如果要详细展开对定制化渲染管线的描述，时间是不允许的。因此，我将从以下几个重点进行说明。
Slide 7 — 00:02:54
📌 要点汇总
- 体积云使用两张3D噪声纹理，一张控制大轮廓，另一张减少移动端cache miss
- 通过rematching步长判断和preview RT混合，实现32次rematching效果仅需2-3次渲染
- 移动端混合雾效在AO阶段通过SSO apply场景深度，实现大气雾与高度雾分离渲染
- 海底雾效采用不透物体→雾→半透物体的blend mode混合，避免雾叠加半透的视觉冲突
- 移动端水面反射使用世界空间base pass单次rematching，配合参数矫正消除错位
- 高德锐镜像模糊考虑相机方向与视野变换，实现树林间线性过渡的动态模糊
- TOD天气系统切换材质时，静态宏（static switch）比动态if判断更优但需美术程序协作
- 低端机半实时GI扩展Volume Metric Light Map至静态物体，流式加载烘培数据结合天气系统
- 高端机DDGI使用八面体映射存储中间变量（位置/方向/反射率），Relate阶段优化Radiance渲染
方向，来展示一下我们这个定制化渲染管线的一些功能。首先第一个的话，体积云后面一些效果的话，不特殊几乎都是我们在PC端和移动端都能达到的一个品质。体积云的话，它主要有三个特点。做体积云的话，这个是第一个的话是云的形状，然后第二个的话云的光照，第三个的话是云的优化。云的形状的话，实际上的话是云的一个密度问题，为此我们使用了两张3D的一个噪声纹理。第一张的话就是基本表现了云的一个因为是大世界，云的面积特别大，基本表现了一个云的基本轮廓。但是这张图如果特别大的话，就会引起一定的贴图的cache miss，会影响移动端的性能。但我们怎么做呢？会引入一张细节纹理去减少rematching步进的时候，然后用细节纹理去弥补它之间的一个摩尔文的一个效果表现，从而能达到一个比较好的一个效果。还有那个rematching的过程中的话，会判断rematching的起始步长和进入没rematching的一个实际的一个判断。还有一个的话就是还有跟上一帧的preview的一个RT的一个时间序的一个混合。这样的话，比如说三十二次rematching的话，我们用两三个preview RT的话，比如说两三个的话，可能会达到三十二除以三的一个rematching次数，可以达到三十二的一个rematching的一个效果。
第二个的话是混合雾效。UE中它原生提供了两种场景雾，一种是大气雾，一种是高度雾。如果大世界的话，场景雾和大气雾都是需要的。对于PC端来说场景雾、大气雾直接使用就OK。但是移动端如果用的话，可能性能这一块儿的话扛不住。具体怎么做呢？我们在base pass阶段并没有去实现雾的效果，而是在base pass之后在做AO的阶段，把大气雾和高度雾同步拿到场景的深度，然后根据场景的深度和位置信息，然后把大气雾和高度雾在SSO阶段，然后进行了一个场景的一个apply，就实现了目前远处山谷有高度雾的表现，然后天际线有大气雾的一个表现的一个效果。
海底雾效，海底雾效也是一种雾。首先解释一下海底雾效为什么不用那个大气雾和高度雾的那种做法呢？因为海底的话它有一个特点，它的雾的话并不是大气雾的天际线和高度雾的，就是山谷下浓山谷上淡的一个效果。它是远处的话表现根据距离表现的，远处的话可能海里就看不到。如果用那个大气雾和高度雾的话，无法就是很完美的表现一个海底雾效的一个效果。具体海底雾效是怎么做的，我大概解释一下。在海底雾常规的话，我们做雾的效果是先画了场景，然后用雾去覆盖场景。但是海底雾的话，可以用一个trick的一个做法，就是首先先画场景的不透物体，不透物体画完了之后，能拿到场景的一个深度，在这个深度，然后还有场景的位置结合去先画雾，画完雾了之后再去画半透物体，半透的混合方式是blend mode，然后用半透的blend mode的阿尔法去跟场景已经有的雾做一个混合，这样的话，场景里面的是半透去叠加雾，而不是雾去叠加半透。整个场景因为海底有很多的半透物体，这样的话就整个场景看起来比较的协调一致，能达到一个比较好的一个海底雾的一个效果。
接下来是移动和平台都能实现比较好的水面效果。水的话用的是Single Layer Water的那个shading model。重点解释一下在移动端水的反射是怎么做的？常规我们做图形学里面做渲染做那个反射的话，首先那个真反射效果比较好，但是性能扛不住。SSR的话是rematching次数多，效果也OK，但是rematching次数多的话，性能也扛不住。具体我们是怎么做的呢？是类似SSR的那种形式，在base pass的世界空间，然后在世界空间中算反射有什么好处呢？不需要去重构反射法线，也不需要去重构用深度去重构世界坐标，还不还能拿到真实的法线信息和IBR的一个做真实的一个融合，然后在那个世界空间的base pass阶段直接在通过反射向量去rematching，也是用rematching的方式，但是我们只需要一次rematching，一次rematching了之后，画面有有那个错位，这个错位怎么办呢？可以通过两个参数去矫正它的位置，矫正位置了之后，可以达到在玩家大部分情况下的视视野下它的反射会非常的漂亮，能达到平面反射的那个没有多次rematching的断层的，然后还要把那个blur之后把断层糊上的那个不好的一个效果，而且性能消耗的话只有一次rematching这一块儿移动端所以是非常合适的。
后面是定制化后效，定制化后效的话就是像比如说高德瑞了、bloom了、dof了、图mapping，还有格雷尔等等在。PC端和移动端都有实现。大概解释一下这个高德锐。高德锐的话是镜像模糊，但是在镜像模糊的时候，我们还考虑了一下场景的相机方向和视野和那个视线的一个变换的一个过渡。这样的话，在树林间高德锐在左右做变换的时候，它会非常的线性丝滑。格雷二的话，这这其他的都是一些正规的常规的做法，不做详细解释。
好，接下来介绍一下实时光照方案。第一个的话就是TOD。TOD的话就是写一套天气系统工具，然后在各种天气，比如说晴雨雪了，还有二十四小时早早中晚了，还有等等一些放大招了之后去应用一些天气变换。里面我解释一点，就是有一个比较有借鉴意义的一个做法。天气变换其中有一点的话就是切不同的天气的时候需要切物体的材质。去切物体的材质的话，常规做法有两种。第一种的话是在材质里面添加if动态判断。第二种的话是实现使用材质里面的一个节点static switch的一个静态宏。第一种方法的优点是实现简单，但缺点是性能开销大，容易导致帧率波动。第二种方法虽然实现复杂，但性能更优，适合大规模场景。不过需要美术和程序紧密配合，确保材质切换的合理性。
哦，接下来介绍一下半实时GI，半实时GI的话有我们那个低端机和高端机有两种方式。低端机的话是一是在基于UE里面的Volume Metric Light Map的基础上去做了一个扩展。原生的Volume Metric Light Map只应用于动态物体。但是我们是大世界。如果静态物体去烘Light Map的话，整个包体和内存是运行时内存是扛不住的。好，具体我们怎么做的呢？我们基于Volume Metric Light Map去同时用于动态物体和静态物体，运行时的话去流式加载volumetric light map的那些烘培数据，然后结合天气系统去做实时的一个间接光反射结果的一个实时变换，从而实现运行时的一个动态GI的一个效果。这里面可能会有一个疑问，你都烘培了，怎么能是半实时GI呢？我们高端的方案，高端机的方案是这样的：烘培的时候不烘培iridens信息，烘培的是什么呢？烘培的是场景的中间变量，比如说位置了、方向了、反射率等等这些，在relate阶段需要用到的一个中间变量。然后存储的话，全景封锁那边存储的话，它它是存在了cable map里面，但是做移动游戏，存Qube Map的话，运行时的内存是无法估量的根本扛不住。然后我们是DDGI的一个存储方式，是八面体映射的一个方式。然后运行时的话，也是一个流式加载。然后在那个Relate阶段的话，优化一下算法，就是Radiance渲染。这一块儿的话，高端也能达到光照变换的情况下，场景不变的一个动态半实时解决方案。
Slide 8 — 00:15:10
📌 要点汇总
- 仙侠类游戏需角色始终明亮，独立于场景光照
- 角色光照通过light channel独立配置方向光/点光/聚光灯参数
- 移除全局光照（GI）计算以避免角色参与间接光照
- Camera Light系统模拟平行光形成独特光束效果
- 背光设计增强角色立体感，符合影视摄影打光逻辑
- 多光源组合确保角色在全天候场景保持视觉一致性
- 光照方案需结合影视美术摄影知识（主光/环境光/背光分层）
第三部分是定制化角色光照。首先需要解释为什么在已有实时光的基础上，还需要为角色定制一套光照方案。以仙侠类游戏为例，这类游戏有一个显著特点：角色无论身处场景中的任何位置，或处于不同季节时，都需要始终保持明亮。这种效果可以理解为高级的自发光，但与普通自发光不同，它不会受到场景光照的影响。例如在三A大作中，角色进入较暗区域时可能会显得暗淡，而仙侠类游戏则需要通过定制光照确保角色始终清晰可见。
接下来具体说明定制方案。场景中的方向光、点光、聚光灯、天光等光源都会通过light channel形式进行单独配置。这些灯光的方向、强度和颜色等参数仅应用于角色模型，形成独立的光照系统。对于全局光照（GI），由于角色本身不需要参与间接光照计算，因此在技术实现中会将其移除。
特别为角色添加了Camera Light系统，该系统以相机视角模拟平行光，形成独特的光束效果。同时增加了背光设计，这种多光源组合方式与影视摄影中的打光逻辑相似：以Camera Light作为主光源，真实世界的方向光作为辅助光源，通过背光增强角色立体感。这种光照方案确保角色在任何光照条件下（包括全天候24小时场景）都能保持视觉效果的完整性。
在实际应用中，这种光照系统需要与影视美术的摄影知识相结合。例如在摄影棚打光时，主光通常来自Camera Light，环境光作为补充，而背光则用于突出角色轮廓。通过这种多层光照设计，角色在不同场景和时间条件下的表现都能保持一致性，既符合仙侠类游戏的视觉需求，又避免了传统光照方案可能带来的画面失衡问题。
Slide 9 — 00:17:04
📌 要点汇总
- 场景阴影分四层，最近层每帧更新，后续层使用cascaded shadow maps分帧更新
- 最远层通过base color处理性能压力，避免大世界瞬时阴影更新压力
- 角色阴影尝试shadow map/CSM/ES等方案，但动态光照导致阴影效果异常
- 自定义角色shading model，prepass阶段生成2048 shadow map并高斯模糊处理
- 仅在摄影棚/特写场景使用角色自阴影方案，性能消耗可控
接下来介绍一下实时阴影方案。实时阴影我们也有两套，一套是应用于场景的，一套是应用于角色的。先说场景的。场景的话这张图就比如说中间的那个dynamic shadow是玩家所在的位置，以玩家所在的位置为中心，距离越远最近一分三四层，最近一层的话是完全实时动态的，每帧的更新。然后第二层、第三层的话是cascaded shadow maps的一种赛道形式，更新的话是根据光照的变换或者是玩家走的时候他位置的一个变换去分帧更新。然后最远处的话，为什么还要加一个cascaded shadow maps呢？因为这个是为了解决分帧更新的时候一个帧，如果像大世界的话几千米，比如我们三千米、四千米非常远，如果整个都开始。正常情况下是没有问题的，它完全更新的时候，会有一个瞬时的一个压力。back的话，就把那个后面要介绍的大世界最远处的那些阴影back到base color里面，back到直接back的阴影，这样的话，整个性能也是OK的，效果这张图整个世界远处的物体都是有阴影的，显得立体感比较好。
好，先来介绍一下实时角色自阴影。实时角色自阴影这一块儿的话我们做了比较多的尝试。像常规的shadow map、CSM那个shadow map加PCF软阴影的方案，还有ES各种各种软阴影，我们都试过。最后效果不尽如人意。具体原因的话，还是因为我们是二十四小时的动态光，有些角度下角色的表现是OK的，但是免不了就是二十四小时，有时候它的光照方向非常的刁钻，导致某那个时候的话，可能会有很诡异的情况。这个时候我们就需要实现一套角色定制的自阴影方案去解决这个效果问题。
具体是怎么做的呢？角色有它独特的shading model，然后在pre pass阶段去绘制。先解释一下那个渲染管线，因为刚才没有详细说，我们是那个mask only的prepass。然后在prepass阶段，特写角色和摄影棚创角等等一些需要展现角色效果的情况下，会在prepass阶段里面根据角色的shading model，把角色在prepass里面也绘制出来。绘制出来了之后，能拿到角色的场景深度，然后为角色单独做了一张2048的一个shading map。用这张shadow depths和prepass阶段拿到的shadow mask场景深度，还有角色的一个模板里面的一个角色抠出来的一个信息值，能算出来角色的一个shadow mask屏幕阴影。然后对这个shadow mask做一个高斯blur，完了之后再后面的base pass真正渲染角色的时候，把这张shadow mask applied到角色上面，角色的阴影会非常的柔和。效果很OK，代价就是性能，那性能消耗也相对偏大一些。但是什么情况下用它呢？只有在摄影棚和拉近的时候使用，所以说性能这一块儿也是扛得住的。
Slide 10 — 00:20:56
📌 要点汇总
- 核心目标：实现PC与移动端性能平衡，坚持PC端画质不妥协
- 采用Level Streaming实现场景动态加载与无缝衔接
- World Composition系统管理大规模开放世界场景拼接与数据组织
- 场景分层策略：近景高精度渲染，中景动态加载，远景LOD简化处理
- 渐进式加载机制平衡画质表现与性能消耗
接下来我将介绍我们的大世界方案。作为一款同时在PC和移动端同步研发的游戏，我们的大世界方案核心目标是实现两个平台的性能平衡。我们坚决反对为适配移动端而牺牲PC端画质的折中方案，因此方案设计始终遵循”PC端效果不受移动端限制”这一基本原则。
UE4大世界方案的核心技术框架包含两个关键机制：首先是level streaming流式加载技术，通过动态加载不同区域的场景资源实现无缝衔接；其次是world composition世界构建系统，这套机制能够高效管理大规模开放世界的场景拼接与数据组织。
在场景层次划分方面，方案采用由近及远的渐进式加载策略。近景区域由高精度模型直接渲染，中景区域通过level streaming技术动态加载，而远景区域则采用level of detail（LOD）技术进行简化处理，这种分层架构有效平衡了画质表现与性能消耗。
Slide 11 — 00:21:57
📌 要点汇总
- 全流程工具化实现资源分类、规范制定、类型烘焙等自动化处理
- 工具替代人工操作，降低资源处理环节的人工干预需求
- 自动化方案提升开发效率并保障资源处理的一致性与规范性
详细介绍。这个是我们那个大作大世界方案的工具化全流程，不需要人工做过多的工作，包括资源分类、规范、类型烘焙等等，这些全都能通过这个工具去搞定。
通过这个工具，原本需要人工参与的资源处理流程被完全自动化。从资源分类到规范制定，再到类型烘焙等关键环节，所有操作都由工具自动完成，极大降低了人工干预的必要性。这种全流程工具化方案显著提升了开发效率，同时保证了资源处理的一致性和规范性。
Slide 12 — 00:22:16
📌 要点汇总
- 根据包围盒表面积、对角线尺寸等维度划分物体为四类
- 巨大物体在场景任何位置均可见，无需动态加载
- Lbu/Mbu/Sbu分类为差异化加载策略提供基础
- 多维分类指标提升流式加载效率和渲染性能
流式加载的第一步是先对场景中的所有物体标记 tag，可以根据其包围盒的表面积、对角线尺寸等各个维度，将世界中的所有物体划分为四大类。第一类是巨大的物体，这类物体在大世界的任何位置都能被看到。
第二类是根据物体尺寸标记为 Lbu（大型物体）、Mbu（中型物体）和 Sbu（小型物体）的物体。这种分类方式为后续的流式加载策略提供了基础，不同类别的物体将采用差异化的加载和渲染策略。
Slide 13 — 00:22:46
📌 要点汇总
- 引入美术工作流定制LOD模型，保留主体造型并移除冗余细节（如栏杆、棱角）
- 石头贴图复用率达100%，仅需4张贴图覆盖全场景，节省内存与性能开销
- 改进Mesh LOD方案通过严格Base Mesh LOD规则，提升复用率并降低内存占用
- 地形处理优化锁边算法，使Landscape与Static Mesh边缘面数比例1:1，消除漏光
- 定制化LOD方案一次性处理后可复用，避免后续重复工作量
哦，第二个的话就是大世界的一个通用的一键场景切分不详细介绍了。好，这块儿有一个比较好的一点是，我们为什么能做到PC端和移动端在LOD烘焙的时候都能有比较好的一个效果。像这幅图左边三列三张图是原模型，然后右面两张图是美术为language Chinese
烘焙LOD定制的一个模型。细节的话右边的面数是左边的面数的一半儿，但是细节的话是完全一样的。用它去生成烘焙的LOD内存这一块儿是没有问题，面数也没有问题。为什么能达到精度一致呢？是因为引入了美术的工作流，美术再去定制化那个生为了生成LOD的一个。原模型的话，它会把里面的会要求美术把里面的一些，比如说栏杆啦，还有一些棱啦等等一些最浪费面反而在远处看不到的一些细节给抠掉，保留主体的一个造型。因为烘焙的LOD它是在远处显示的，也不需要这些信息。用其他的你再用自动减面算法再优化也达不到直接把它抠掉的一个优化效果。所以说能达到远处性能、内存、照靠都达标的情况下，效果还优秀的一个情况。 这个是另外一个建筑。我举个数据例子：我们整个大世界里面的所有的石头，用这种方式只需要四张贴图。就可以把整个大世界的所有石头全做出来，性能内存这一块儿节省很多。哦，这个是对比基础方案和改进后的方案的一个对比。Mesh LOD的话，基础的话是全局统一设置，然后改进的方案的话是严格规定了Base Mesh的LOD。材质贴图的话，基础方案的话是复用率低贴图精度不高。如果应language Chinese
硬要高的话，可能内存会成倍增长。哦，然后改进方案的话是美术引入美术工作流完全可控，复用率高效果提升也明显。内存这一块儿的话是最大的一个优化。 哦，整体的话是基础方案的话刚才也说了，就是无需外处理。定制化方案的话是需要美术去定制化处理。一次工作量后面场景不需要再二次工作量，可以完全复用很划算。这个的话是为了为了解释大世界已经处理了建筑了处理了石头了，但是另外一个重要的地形怎么处理？地形的话，如果直接把landscape烘焙成static mesh的话它可能会因为你去强剪面会引起一些漏光。怎么解决漏光呢？在生成static mesh的时候优化了锁边的一个算法，让真实的landscape的边缘和static mesh的边缘的面数比例是一比一，这样的话是不会有漏光的一个情况。
Slide 14 — 00:26:27
📌 要点汇总
- 支持多相机位置处理，解决大世界中两公里外剧情触发的流送问题
- 采用代理网格技术优化远程剧情表现，避免近距离触发效果不佳
- 分平台配置流送策略，PC端侧重复杂性，移动端平衡性能与加载效率
- 多相机支持实现跨区域剧情无缝衔接，提升大世界沉浸感
- 流送方式适配不同平台特性，确保跨终端一致性与最佳体验
流送方式和关卡方式是游戏的一个特点。比如说玩家在大世界中的某个地方触发了一段剧情，这个剧情发生在大世界的另外一个地方，可能距离两公里以外。那个地方是一个代理网格的情况。如果发生在距离较近的位置，可能效果会不太好。因此我们支持了多相机位置的处理streaming。在那个地方实现多相机支持之后，即使剧情发生在两公里以外，也能有比较好的效果表现。
分平台配置流送方式是因为我们是PC和移动平台同步研发的游戏。如果能够分平台配置的话，可以针对各个平台的特点进行适配。例如PC端可以使用更复杂的流送策略，而移动端则需要考虑性能和加载效率的平衡。这种灵活性能够确保不同平台都能获得最佳的体验效果。
Slide 15 — 00:27:25
📌 要点汇总
- 地形方案支持128种贴图自由组合，采用三层混合技术实现逐像素混合
- 通过权重图和ID图编码，将地形样貌预处理为静态资源降低运行时计算量
- 使用二维纹理处理地表与模型过渡，解决原生Unity移动端贴图采样超限问题
- 植被方案需兼顾密集分布与性能，采用四维优化：撒点算法、合批处理、剔除策略、渲染技术
- 自由飞行模式下植被数量直接影响场景饱满度，需通过科学撒点算法实现自然分布
- 合批处理减少绘制调用，剔除优化提升性能，最终实现大规模植被高效渲染
然后介绍一下我们的地形方案。原生的Unity地形方案在移动端可能会出现贴图采样次数过多超过十六个的问题，某些平台如OpenGL等可能根本无法编译通过，且性能存在浪费。具体我们是怎么做的呢？我们的地形方案支持整个大世界使用一百二十八种贴图自由组合，逐像素采用三层混合技术。通过权重图和层的ID图编码，将编译时的地形样貌存储到ID图和权重图中，运行时只需处理已编码完成的ID图和权重图即可。此外还使用了二维纹理处理地表与模型之间的过渡。
\n\n接下来介绍一下植被方案。大世界场景中地形、石头和建筑的处理方式已如前述，植被部分则需要特别关注。由于大世界包含大量野外区域，若想呈现良好的视觉效果，需要通过密集植被来点缀这些区域。从截图可见，除了主干道外，场景中到处都是密密麻麻的草，远处也分布着大量树木。游戏采用自由飞行模式，玩家可在大世界中任意位置无限遨游，因此植被数量对场景饱满度至关重要。
\n\n植被方案主要从四个维度进行规划：植被撒点、合批处理、剔除优化和渲染技术。通过科学的撒点算法确保植被分布自然，利用合批技术减少绘制调用，结合剔除策略提升性能，最终通过优化的渲染方案实现大规模植被的高效呈现。
Slide 16 — 00:29:31
📌 要点汇总
- 植被分为全域植被（全地图可出现）和生态域植被（仅限特定区域如冬季/草原）
- foliage type方案通过同一模型+不同mask实现草形态/颜色差异并合批渲染
- instance buffer中自定义材质含索引，用于从texture array/atlas采样获取mask/base color等参数
- 混合剔除方案：全域植被用GPU-driven剔除，生态域植被用CPU cluster剔除
- 草渲染采用two sided foliage shading model并添加双层高光增强视觉效果
撒点的话，我们把整个大世界的植被分成两大类：一类是全域植被，一类是生态域植被。全域植被可以在大世界的任何地方出现；生态域植被则只能在特定区域出现，比如某个区域是冬季的，那么该区域的植被只能是冬季特有的类型。另一个区域如果是绿绿的草原或灌木，那么该区域的植被只能是对应的生态域植被。
合批方面，我们自行实现了一种foliage type的方案。foliage type的核心在于：使用同一模型但通过不同颜色、不同mask来区分植被类型。由于我们是通过mask来控制草的形态，因此只要模型相同，不同形状、不同颜色的草都可以合并到同一个合批中。这意味着大世界中长得差不多的草或灌木，都可以通过foliage type的方式进行合并。
具体实现上，foliage type在instance buffer中加入了自定义材质。该材质包含一个索引，用于从texture array的某一层或texture atlas的某区域采样，从而获取不同的mask、base color、normal等参数，最终实现不同草的形状和颜色差异。运行时会根据foliage type的类型，将所有实例化对象进行实例化处理。
剔除方面，大世界中植被数量庞大，若没有有效的剔除机制，性能将难以支撑。我们采用混合剔除方案：全域植被和地形草使用GPU-driven剔除，而生态域植被则使用CPU cluster剔除。这种分层方案的优势在于，若全部使用GPU-driven剔除，生态域植被将无法被剔除；若全部使用CPU cluster剔除，全域植被又会无法被剔除。通过区分使用两种剔除方式，我们实现了针对草类的专用剔除管线。
最后是草的渲染，采用常规的two sided foliage shading model，并额外添加了双层高光效果，以增强视觉表现。
Slide 17 — 00:32:27
📌 要点汇总
- 软剔除依赖遮挡查询，需控制遮挡体面数以避免CPU过载
- 改进方案用Box体素化封闭物体替代凸包，提升遮挡查询效率
- 非封闭物体支持人工添加ECLD作为遮挡体
- GPU driven方案复用SSAO模块的HZB实现深度计算
- 安卓平台因instance buffer限制采用folly type驱动GPU
- 软剔除通过跨帧复用遮挡查询结果降低计算开销
- 遮挡体面数过高会导致CPU消耗激增，需严格优化
刚才那个植被方案有介绍到剔除方案这块儿的话就详细介绍一下我们的整个大世界的一个两种剔除方式。第一种的话就是软剔除，软剔除的基本原理是通过遮挡查询来实现。在一帧剔除结束时，系统会收集场景中所有物体的遮挡体和被遮挡体，然后在专门的线程中使用软光栅去渲染遮挡体。通过被遮挡体的包围盒进行遮挡查询，下一帧会使用上一帧的遮挡查询结果。由于软剔除的查询依赖于遮挡体的光栅化，因此遮挡体的面数需要尽量低。如果面数过高，会导致CPU消耗非常大，得不偿失。
我们如何优化遮挡体的面数呢？图上可以显示出来。下面那一组是凸包的常规实验方式，它的缺点是可能会有物体遗漏，但如果不使用凸包，遮挡体的面数会非常多，性能也不理想。上面那个方式是我们改进后的方案，不使用凸包，而是将封闭物体体素化后，用Box方式模拟其形状。由于Box不会突破曲面，因此不会出现遮挡体突破模型本身的情况，这样处理封闭物体的效率会更好。对于没有封闭的物体，我们还支持人工制作遮挡体的方案。对于复杂模型或不封闭的物体，可以手动添加ECLD作为遮挡体。采用这套方案后，软剔除的性能表现会比较理想。
第二种方案是GPU driven。我们统一使用GPU驱动PC和iOS平台，但安卓平台没有采用相同方案，因为安卓平台的instance buffer尺寸较小。如果采用相同方案，原理上可能无法通过。因此在安卓平台，我们会使用另一种GPU驱动形式，根据之前提到的folly type数量来开启GPU driver。这种方式会增加一些call调用，但能保证GPU driver的合理运行。
遮挡剔除方面，使用上一帧已有的GPU driver数据。GPU驱动的深度计算依赖HZB（Hierarchical Z-Buffer），而我们已经在SSAO模块实现了HZB，因此可以与GPU driven方案复用，性能没有问题。以上就是《诛仙二》关于实时光影和大世界的一些技术心得。在不久的未来，《诛仙二》即将上线，敬请期待上线后的表现。好，谢谢。