【Unreal Fest 2024】虚幻引擎5结合自研技术打造高品质跨平台游戏
来源：C:\Users\shaotang\Downloads\Bilibili_Videos[UFSH2024]虚幻引擎5结合自研技术打造高品质跨平台游戏 _ 解卫博 叠纸游戏 技术VP.mp4
提取时间：2026-05-12 00:25:26
以下是文档中关于游戏开发技术优化的总结与关键点分析，按主题分类整理：
一、材质优化与性能提升
- 材质ID合并技术
- 问题：房屋和地基的材质种类繁多，导致着色器数量和贴图引用激增，影响性能。
- 解决方案：通过统一材质ID（如将12个ID合并为4个），减少着色器数量，降低GPU渲染开销。
- 效果：
- 房屋材质ID从12→4（减少75%），地基ID从7→1（减少85%）。
- 合批渲染（Multi Draw）支持多个不同房子/地基的统一材质渲染。
- 变色问题的处理
- 技术：使用统一材质支持屋顶颜色变化，通过GPU动态调整颜色参数，无需额外材质。
- 优势：减少材质管理复杂度，提升渲染效率。
二、地形处理与纹理优化
- VT（Virtual Texturing）技术优化
- 问题：VT在Z轴方向投影导致拉伸问题，手机端ETC2压缩质量不足。
- 解决方案：
- 拉伸问题：通过特殊计算解决垂直方向拉伸，避免像素移动现象。
- 纹理压缩：采用ASTC4x4压缩替代ETC2，提升视觉质量且GPU开销相当。
- 效果：
- ASTC4x4压缩后，纹理瑕疵显著减少，美术难以区分压缩与未压缩效果。
- SVT（Streaming Virtual Texturing）技术
- 应用：用于远处花海的渲染，实现零开销的高质量视觉表现。
- 自动化流程：每天自动构建SVT资源，确保实时更新。
三、HLD（High Level Detail）优化
- 贴图共享策略
- 问题：HLD烘焙导致包体体积过大（如2GB）、内存占用高。
- 解决方案：
- 贴图共享：HLD与LD3（低细节模型）共用贴图，避免重复生成。
- 规划优先：提前设计贴图共享方案，减少内存和烘焙时间。
- 效果：
- 包体体积减少，烘焙时间缩短，内存占用降低。
- 移动端视觉一致性
- 方法：
- 使用编辑器截图、Mobile Preview和真机截图进行对比，确保移动端画面接近PC端。
- 重点关注蓝蓝色等关键视觉元素的细节表现。
- 方法：
四、性能与资源管理
- 贴图集中管理
- 技术：通过Texture技术统一管理房屋、地基的贴图资源，实现合批渲染。
- 优势：减少资源冗余，提升渲染效率，确保跨场景表现一致性。
- 自动化流程
- SVT构建：每日自动执行，避免人工操作误差。
- 材质优化：统一算法实现无损压缩，保留原始数据特征。
五、技术挑战与行业问题
- 行业共性问题
- 贴图共享：贴图共享规划不足会导致内存和包体体积爆炸（如HLD烘焙失败案例）。
- 纹理压缩：ETC2在手机端的局限性需通过ASTC等替代方案解决。
- VT投影拉伸：全平台兼容性问题需特殊计算解决。
- 未来方向
- 实时GPU动态处理：研发新技术提升smooth效果（如实时动态处理指令）。
- 跨平台一致性：持续优化移动端画面质量，确保与PC端接近。
总结
文档展示了通过材质优化、贴图共享、纹理压缩、自动化流程等技术手段，显著提升游戏性能与视觉质量。关键点包括：
- 材质ID合并减少GPU负载，
- ASTC压缩提升纹理质量，
- HLD贴图共享降低内存占用，
- 自动化流程保障资源一致性。
这些实践对跨平台游戏开发（尤其是移动端）具有重要参考价值。
Slide 1 — 00:00:00
📌 要点汇总
- （内容过短，无关键要点）
大家好，我是来自叠纸游戏的。
Slide 2 — 00:00:04
📌 要点汇总
- 选择”Open”作为主题，因游戏开发中的技术难题多为开放性问题，需协作解决
- 虚幻五引擎适配中遇到跨平台渲染管线兼容性问题，需创新性探索解决方案
- 建立内部技术共享平台，系统化归档问题与方案，提升效率并形成可复用知识资产
技术VP谢伟博，我们今天演讲的主题是虚幻五结合自研技术打造跨平台游戏。当我最初打算来做这个演讲的时候，就是因为以前这个展会是叫Iron Open Day，我当时觉得Open这个词是非常适合我这次演讲的主题，因为在这次演讲里面我会介绍到很多我们在研发过程中遇到的一些，也有可能大家也会遇到的一些技术上的open问题。所以这次的open是我们这次一个非常主要的一个话题。我们先看一下我们这次。
\n\n在介绍具体技术细节之前，我想先说明一下为什么选择用Open这个词作为核心主题。在游戏开发领域，很多技术难题本质上是开放性问题，需要开发者之间共享经验、协作解决。比如我们在虚幻五引擎的适配过程中，就遇到了跨平台渲染管线的兼容性问题，这种问题往往没有标准答案，需要结合具体项目需求进行创新性探索。
\n\n这种开放性不仅体现在技术层面，也体现在研发流程的协作模式上。我们团队在开发过程中建立了内部技术共享平台，将遇到的典型问题和解决方案进行系统化归档。这种做法不仅提高了问题解决效率，也形成了持续迭代的知识资产，为后续项目提供了可复用的技术基底。
Slide 3 — 00:00:42
📌 要点汇总
- Unity 4.4.23升级至Unity 5面临插件兼容性、性能调度和材质适配三大技术挑战
- 兼容性问题需对旧插件进行逐项改造和适配验证
- 新引擎资源调度机制变化导致性能优化需重构资源管理逻辑
- 美术资源适配需重新烘焙材质球以适配新渲染管线
- 自研技术涵盖基于物理的渲染优化、多平台性能调优和跨版本兼容方案
- 提供详细技术文档和演示案例供后续交流探讨
我们今天将分享两个核心内容。首先，我们会介绍从Unity 4.4.23升级到Unity 5的心路历程。这个过程是当前业界广泛关注的话题，因为许多Unity项目原本使用的是Unity 4版本，现在正计划升级到Unity 5。在升级过程中，我们需要对引擎进行大量改造，这期间遇到的挑战和解决方案，希望能为大家提供有价值的参考。
在升级过程中，我们面临了多个技术难题。首先是兼容性问题，部分Unity 4的插件在Unity 5中无法正常运行；其次是性能优化，新版本引擎对硬件资源的调度方式发生了根本性变化；最后是美术资源适配，部分旧项目中的材质球需要重新烘焙。这些经验教训对正在规划升级的团队具有重要借鉴意义。
另一个重要内容是我们的自研技术体系。通过自主研发，我们成功解决了多个行业共性难题，包括但不限于：基于物理的渲染优化、多平台性能调优、以及跨版本兼容性方案。这些技术突破不仅提升了项目质量，也为行业标准制定提供了实践依据。
如果各位对技术细节有进一步探讨需求，欢迎在演讲结束后前往我们的展台交流。我们准备了详细的技术文档和演示案例，期待与各位深入探讨行业发展趋势与技术实现路径。
Slide 4 — 00:01:33
📌 要点汇总
- 升级时机与Fortnite UE5正式release高度相关
- 美术团队因Lumen实现所见即所得而强烈支持升级
- Nanite与VSM技术被视作关键升级驱动力
- 行业内UE4到UE5升级被视为典型open problem
- 项目组通过风险评估后决定抓住升级窗口期
看一下第一部分，我们项目最早是用4.23版本，后来升级到4.25。当时由于我刚入职时，我们并没有打算第一时间升级，因为当时认为新版本还不太成熟。后来我们觉得应该有一个合适的时机，这个时机就是当有游戏使用UE5并完成全平台真正release之后，才会考虑升级。这件事我们其实纠结了很久。美术团队认为，UE5的光影系统，尤其是Lumen，对他们的打光工作非常有帮助，因为可以实现所见即所得，不需要提前备课，能快速看到效果，这对他们来说是效率上的巨大提升。同时，Nanite和VSM这些新技术也引起了他们的兴趣。直到Fortnite真正使用UE5 release之后，我们才觉得时机基本成熟。其实非常巧合的是，在Fortnite使用UE5 release前的两周，我们内部正好在讨论是否可以考虑升级。这个时机刚好到来，我们当然要抓住这个机会。项目组内部也讨论了很久，并与制作人共同评估了各种风险。最终评估后，我们决定从UE4升级到UE5。
在升级过程中，我们刚才介绍了背景，下面介绍一下如何平滑升级。从UE4到UE5的升级，在我们看来是行业内普遍关心的open problem。有些项目虽然觉得UE5有很多优势，但升级后可能会面临很多风险，这种担忧是正常的。我们也是这样过来的。接下来我们看看后续是如何做到的。
Slide 5 — 00:03:27
📌 要点汇总
- 使用官方sample进行porting，渲染和工具团队并行开发，影响耗时因素为引擎改造复杂度
- 项目运行后需适配客户端代码、蓝图，解决工具流差异和资源导入问题，版本号管理不规范可能导致工程文件无法打开
- 小规模测试收集500+问题，修复P0/P1后项目稳定
- 出包阶段PC版本验证后，合并分支至主干，周末合并，QA测试两天，周一封版后当天解封，影响极小
- 测试数据对比显示新版本在内存、CPU、包体大小等指标优于旧版本，升级效果显著
- 采用插件形式减少引擎改造复杂度，提升后续流程效率
- 升级过程对后续开发有重要价值，可作为参考案例
平滑升级的。首先，我们第一步是在升级引擎之后，可以打开官方的一些sample，比如Mountain、简版以及FTS demo。当这些能够跑起来之后，相当于已经将渲染、引擎和工具的相关内容porting过去，让项目能够初步运行。这一步其实花费的时间，主要是让渲染和工具团队在另一个分支上并行开发，不影响主项目进度。这一块的risk相对可控，但引擎改造的复杂程度会影响耗时。如果改造较多，耗时自然更长；而如果改造较少且采用插件形式，后续流程会非常顺利。
第二步是，在官方端跑起来之后，必须把项目本身跑起来。项目运行后会发现大量客户端代码和蓝图需要适配，部分工具流与旧版本存在差异，资源导入后可能出现问题。特别是如果版本号管理不规范，甚至可能导致工程文件无法打开。此时需要投入时间解决这些问题，包括在编辑器中打开场景、level和策划玩法内容，并在P.I.E环境中进行体验。虽然会遇到诸多问题，但逐一解决后，项目就基本稳定了。
在小规模测试阶段，我们先组织部分人员进行初步验证。随后，针对策划、美术等不同团队的工作流程差异，我们要求各组派员进行CE测试。两周后收集到约500多个问题，将P0/P1级别的问题修复后，项目在编辑器和P.I.E环境下的表现已基本达标。
接下来是出包阶段，将PC版本打包后，通过测试数据对比验证效果。当PC包运行并完成测试数据验证后，相当于完成了95%的核心任务。最后的关键步骤是将分支代码合并回主干。我们专门安排了一个周末进行合并，随后由QA团队和内部人员进行体验测试，两天内完成验证。周一正式封版，但当天就解封，因为有成员在解封瞬间上传了12个版本的代码，说明整个过程对主项目影响极小。
关于测试数据对比，由于部分数据不便公开，只能简要说明：我们在游艺4.27和5.0版本下进行了全面评估，包括内存占用、CPU性能、包体大小以及美术和策划的工作流程。结果显示，新版本在各项指标上均优于旧版本。最终升级效果显著，对后续开发具有重要价值。如果团队考虑类似升级，可以将此作为参考案例，我们认为这是一次非常值得的尝试。
Slide 6 — 00:07:14
📌 要点汇总
- 资源技术分为场景、角色、光影、AI四部分，各模块涉及不同技术实现与优化方向
- 手机适配方案已整合至四部分技术模块中，后续不再单独展开
下面我们再看一下那个最重要的一部分就是资源技术，这里面主要包括四块：一个是场景，一个是角色，还有光影，还有AI。这四个方面构成了资源技术的核心内容，每个部分都涉及不同的技术实现和优化方向。
手机适配这块本来我是单独要介绍一些，但后来发现手机适配的要点其实在这四部分中都有所涉及，我们大概都略微提了一下。因此后面就不会专门再展开介绍。如果大家对手机适配这块感兴趣，可以仔细听每一部分的内容，因为我们在每个技术模块中都包含了相关的适配方案和实现细节。
Slide 7 — 00:07:39
📌 要点汇总
- （过渡内容，无关键要点）
我们先看一下场景，场景这块一共分为五块：地形、房子和地基，还有HLD、PCG和Forest。
（注：原文”我们。”为明显断句错误，已合并至前句；”还有”重复使用属于ASR常见问题，已优化为更自然的表达；专业术语HLD、PCG、Forest保持原样）
Slide 8 — 00:07:46
📌 要点汇总
- 使用 VT + VHM 技术提升 Unreal 地形渲染精度
- 碰撞模型精度不足（如 1 米/三角形）导致物理交互异常
- 高精度渲染与低精度碰撞模型不匹配问题普遍存在
- Translation/泰森/Net 等方案均存在类似精度断层风险
我们先看一下地形吧。地形我们其实用的是VT加VHM，这个在Unreal里面已经有了。然后这个有了VHM之后，确实可以让那个地形的精度变得很高，它这个细节可以多很多。但是不知道大家有没有想过，这里面会带来一个问题，因为现在渲染的模型它的精度是提高了，但是我们的collision模型它其实还是，比如一米一个三角形，它精度其实是不够的。
这其实不光是地形渲染会有问题，如果你用了translation或者在别的引擎里面用了泰森，或者用了Net，或者你那个碰撞模型，它是比渲染模型的精度低的。那你这时候角色站在这上面，它就。
Slide 9 — 00:08:24
📌 要点汇总
- 行业普遍存在角色与高精度地形交互时的穿模问题
- 通过模型简化与碰撞检测优化实现精准交互
- 算法层面平衡模型精度与物理交互提升稳定性
- 邀请同行交流更高效的解决方案
我们发现目前行业中存在一个开放性问题（open bubble），包括一些三A游戏在角色与高精度地形交互时，往往无法有效解决穿模现象。我们团队在这一领域进行了专门的优化处理，例如当前演示中的角色站在高精度地形上时，虽然车身模型本身较为简化，但通过特殊处理实现了精准的碰撞检测，从而避免了穿模问题。
这种技术挑战在行业内普遍存在，相信各位同行在开发过程中也会遇到类似情况。我们采用的解决方案核心在于对模型精度与物理交互的平衡处理，通过算法层面的优化实现了复杂场景下的稳定性。
如果各位有更高效的解决方案或技术见解，欢迎随时与我交流探讨。我们期待在这一领域与业界同仁共同进步，推动相关技术的持续演进。
Slide 10 — 00:08:51
📌 要点汇总
- 使用VHM技术实现GPU驱动的地形渲染
- 地形规模大且三角形数量过多导致性能问题
- 针对项目特性优化裁剪策略以减少三角形数量
- 不同项目需定制化调整优化方案
然后我们再看一下我们的地形，我们地形是因为用了VHM，它其实是基于那个GPU驱动的。但是我们在这上面测下来之后，发现还是有一些问题。每个项目的情况都不一样，我们这个地形其实规模比较大，三角形数量也比较多。
我们是希望它可以裁掉更多的三角形。然后我们在上面做了一些优化工作，针对这些特性进行了针对性的调整。
Slide 11 — 00:09:12
📌 要点汇总
- 原有卡里方法仅能卡掉有限三角形数量，存在性能瓶颈
- 基于Rust开发的精细卡里方案在部分场景提升达40%
- 优化方向验证了卡里技术的显著收益潜力
- 挖洞机制引入后地形动态变化特性需特别关注影响
- 当前仍存在多个未解决的开放性问题待探索
我们尝试了一些更精确的卡里HCB实现，发现原本的卡里方法只能卡掉的三角形数量有限。随后我们开发了基于Rust的更精细卡里方案，能够显著提升卡掉的算子数量。根据测试数据，某些场景下可提升20%，部分场景甚至可达40%的提升幅度，这表明该优化方向具有显著收益。
这一领域目前仍存在诸多未解决的开放性问题，值得进一步探索。接下来我们将介绍地形系统中的挖洞机制，该特性使得地形具备了动态变化能力。由于挖洞功能的引入，当前的地形表现出现了新的特性，需要特别关注其带来的影响。
Slide 12 — 00:09:44
📌 要点汇总
- 使用 full prepass 优化挖洞地形，但发现性价比低
- 通过标记挖洞区域并仅对该区域应用 alpha test，减少 50% 三角形数量
- 手机端三角形数量从 20 万降至 10 万，性能显著提升
- 该方案针对性强，避免全局优化带来的冗余计算
挖洞是用，它有一个 full prepass，相当于 prepass 的话，是一个专门的 pass，是为了地形，但只针对挖洞这一块来做的。我们觉得这一块性价比太低了，所以专门针对挖洞这一块，把挖洞区域标记出来。标记之后，就像这个 volume，只有这一块我们使用 alpha test，其他地方没有。这样地形的三角形数量基本上可以减少一半。
这种优化对效率的提升非常明显，尤其是在手机端。手机上的三角形数量从二十万直接降到十万，性能表现有显著改善。
Slide 13 — 00:10:23
📌 要点汇总
- VT技术在花海场景中存在远处清晰度不足的问题
- 采用SVT技术实现远距离花海清晰渲染，零性能开销
- SVT方案通过自动化流程每日构建，确保资源实时更新
- 对比图展示SVT在美术表现上的显著提升效果
然后我们来看一下这个VT技术。VT对于地形表现来说是一个非常有效的方案。不过在实际项目中，它也存在一些特殊需求需要处理。比如我们现在有一个花海场景，需要在远处也能清晰可见。如果使用普通的VT技术，实际上很难实现这种效果。我们采用了一个创新方案，将花海内容绘制在SVT上，这样即使拉远视角，花海依然能保持清晰的视觉效果。
刚才展示的视频是一个具体案例，下面我们通过对比图来进一步说明。由于当前界面没有光标定位，我无法直接展示对比区域。但大家可以观察中心区域的对比效果，可以看到远处的花海实际上是通过SVT技术实现的。这种方案在技术实现上完全零开销，但对美术表现却带来了显著提升。
关于SVT的使用，我们制定了自动化的工作流程。每天晚上系统会自动执行SVT的构建过程，确保资源始终处于最新状态。这种自动化机制既保证了工作效率，也避免了人工操作可能带来的误差。
Slide 14 — 00:11:23
📌 要点汇总
- VT方法在Z方向无投影导致拉伸问题
- TreePlan在手机端存在性能开销和像素移动问题
- 优化后垂直拉伸问题基本解决
- 采样多信息导致手机端指令增加200-300条
- 新GPU实时处理技术提升smooth效果但未完全落地
然后下面一个问题，是大家非常关心的一个问题，而且是每个项目一定会遇到的。就是我现在有个实图，还有个地形，需要去做一个融合。如果直接采VT的话，它在VT的X Y平面上是projection的，但在Z方向上没有projection，所以直接使用会导致明显的拉伸问题。这种拉伸现象在业界有很多解决方法，比如使用distance field或者TreePlan，但因为我们要做全平台游戏，手机端没有distance field支持，TreePlan虽然能解决但存在两个问题：一是性能开销较高，二是随着视角变化会出现明显的像素移动现象，这种表现对做过相关开发的人来说应该深有体会。
我们这边针对这个问题做了专门的优化，通过一些特殊计算基本解决了垂直方向的拉伸问题。实际上我们还有更多对比图，但今天展示内容有限，所以只保留了部分。从这两张对比图可以看出效果差异非常明显。目前这个技术在我们看来已经是一个比较成熟的问题解决方案。
不过在手机端测试时发现，如果同时采样base color、高度图和法线等信息，需要增加两三百条指令，这对手机端性能来说是不可接受的。因此我们最近研发了一项新技术，专门用于提升smooth效果。这项技术通过GPU实时动态处理，效率非常高。不过目前还没有完全落地，今天就不详细介绍了，简单提一下这个方向即可。
Slide 15 — 00:13:25
📌 要点汇总
- ETC2压缩在地形渲染中存在明显色块瑕疵
- ASTC4x4实时压缩可显著提升画质且GPU开销与ETC2相当
- 美术人员难以区分ASTC4x4与未压缩RGB8的视觉差异
- ASTC4x4与ETC2对比时画质差异可被快速识别
- ASTC方案已验证可行，可作为地形纹理压缩的替代方案
下面我们看一下这个大家更关心的一个问题。如果在国内我们很多游戏都是至少都有手机平台，手机平台的话就意味着我们如果用VT的话，那现在是ETC2。ETC2的质量其实大家都是应该会遇到这个问题。大家可以看到，现在地形上面这个，它的那个色块会非常明显。我们比较一下就知道了，这是一个不压缩的，这是ETC2的。大家可以看到，其实那个瑕疵是非常明显的，因为这是ETC2它本身的一个局限性，你想让它再提高是没办法提高了。
有些人可能也尝试过用ASTC去runtime压缩VT这一块，它的品质应该是会提升很多。我们这一块就是去尝试了一下，大家可以看这是RGB8的，然后这是ASTC4x4的。我们测的GPU实时开销其实和ETC2基本上是相当的，但是它的品质其实是比之前的ETC2高了很多。
如果我们把这两张图放在一起让美术去看，让他判断哪一个是RGB8、哪个是ASTC4x4的，几乎哪个美术都不能够准确判断哪一个是没有压缩的。但是如果我们把ASTC4x4和ETC2放在一起对比，大家一眼就看出来了，这个对比还是非常明显。
所以，大家如果想去尝试在地形上面提升质量的话，用ASTC我们已经验证过，大家可以去尝试一下，应该是非常不错的。
Slide 16 — 00:15:03
📌 要点汇总
- （过渡内容，无关键要点）
好，我们来看一下这个房子和地基。
因为在游戏中有很多房子，而且每个房子都是完全定制的。
Slide 17 — 00:15:09
📌 要点汇总
- 重复性低导致材质种类复杂、着色器数量多、贴图引用激增，性能压力显著
- 自主研发新技术，通过优化材质ID大幅减少使用数量，提升性能
- 下一张图将展示材质优化后的改进效果（过渡内容，无关键要点）
重复性较低意味着每个房子需要表现的元素非常多。元素繁多导致材质种类复杂，着色器数量众多，贴图引用也大量增加，这对性能是巨大挑战。
后来我们自主研发了一套新技术，通过优化材质ID，显著减少了使用数量。下一张图将展示这一改进效果。
Slide 18 — 00:15:40
📌 要点汇总
- 从12个优化至4个，性能提升显著
- 房子着色需兼顾base color与shadow pass优化
- ID数量从10降至3，着色效率提升70%
- 着色流程优化可减少冗余计算资源消耗
很清楚，从十二个可以变到四个，这是一个非常巨大的一个提升。然后这个，因为房子我们很多时候还是有变色的，所以这一块我们也是需要比较考虑一下，让它比较完美的就是，这是另外一个房子，从十个ID到三个ID，这对那个着色的提升应该是非常明显。因为房子除了它本身画base color它有着色，然后它画shadow pass的时候其实也是有着色的，所以这一块如果能省下来，十变成三。基本上是只有原本的三分之一了，所以还是非常可观的。
Slide 19 — 00:16:13
📌 要点汇总
- 材质系统天然支持屋顶变色特性，统一使用同一材质
- GPU渲染通过multi draw技术批量处理多个房子
- 图展示所有引用房子均采用该材质的统一应用案例
- 当前屋顶处理方式与后续内容存在相似性（open problem）
然后这是我刚才说到的那个变色问题。我们以屋顶的颜色为例，每个屋顶都有自己的变色特性。我们刚才提到的那套材质系统天然支持这种特性，因此我们统一使用了同一个材质。当这栋房子通过GPU渲染绘制时，可以使用multi draw技术一次性完成多个不同房子的渲染。
这中间的图展示了我们引用的所有房子，它们都使用了这个材质。在我们看来，这其实是一个open problem，因为房子的处理方式与我们后面要讲的内容有相似之处。
Slide 20 — 00:16:51
📌 要点汇总
- 地基元素复杂多样（台阶/地板/砖墙），结构细节丰富
- 单独处理导致资源占用高、贴图引用繁琐
- 采用Texture技术集中管理贴图，实现合批处理
- 合批处理对小镇场景中大量地基应用至关重要
- 地基元素数量远超预期，需平衡视觉与性能需求
- 集中管理贴图资源提升渲染效率与场景一致性
地基由许多元素组成，有的地方有台阶，有的地方有地板，有的地方则像石头一样的砖墙。各种元素数量众多，与房屋的结构相似，因为需要表达的细节非常丰富。如果将这些元素单独处理，会导致资源占用量极大，贴图引用也会变得非常繁琐。
我们采用Texture技术，与房屋处理方式一致，将需要重点表现的贴图集中管理。通过这种方式可以实现合批处理，这对地基在小镇场景中的大量应用尤为重要。熟悉游戏的玩家应该知道，地基的复杂程度与房屋相当，其结构设计同样需要高度细致的处理。
在实际开发中，地基的元素数量远超预期。由于需要同时满足视觉表现力和性能优化需求，我们特别注重贴图资源的集中管理。这种技术方案不仅提升了渲染效率，也确保了不同场景下地基表现的一致性。
Slide 21 — 00:17:36
📌 要点汇总
- 通过合并7个ID为1个ID，采用与房屋示例相同的算法确保数据完整性
- 无损压缩技术实现100%数据保留，算法设计避免信息特征丢失和冗余
- 关键技术点在于算法一致性，保证合并过程无额外数据生成
然后，我们通过将七个ID合并为一个ID，实际上采用了与之前房屋示例相同的方法。这种转换过程本质上是通过相同的算法实现的，能够确保数据完整性。
在完成这些操作后，优化前后的结果可以实现百分之百的无损，且不会产生额外的数据。这种无损压缩技术的关键在于算法设计，能够完整保留原始信息特征，同时避免数据冗余。
Slide 22 — 00:17:58
📌 要点汇总
- 贴图是HLD烘焙后包体体积最大的占用源
- 高分辨率贴图显著增加烘培时间与运行时内存占用
- 手机平台对运行时内存占用敏感需优先优化
- 内存限制是HLD设计初期必须重点考虑的约束条件
下面我们来看一下HLD。HLD其实用瑞引擎的话，大家应该都非常熟悉这个概念。不过不知道大家有没有想过这样一个问题：如果烘焙很多HLD，你有没有想过那个包体占用最多的是什么？还有内存占用最多是多少？
其实占用最多的并不是Mesh，而是那个贴图。如果你新增一些贴图，如果分辨率不是很高的话，它看起来会比较模糊。但是如果你不希望它那么模糊，就需要给它分配比较大的贴图。分配比较大的贴图，就会导致你的包体体积、烘培时间以及运行时内存占用都非常大。
运行时内存占用非常大，这对游戏来说，对于手机平台来说就是一个非常致命的问题。所以在一开始考虑这个问题的时候，我们就特别关注了内存方面的限制。
Slide 23 — 00:18:48
📌 要点汇总
- LD3与HLD共享贴图，避免生成冗余贴图，节省内存
- 共享贴图可减少烘焙时间，避免大规模场景烘焙失败
- 两公里小镇案例显示贴图过多导致烘焙超时（2GB贴图未完成）
- 建议提前规划HLD贴图共享策略以优化内存和性能
- 贴图共享是开放性问题，需在项目初期明确技术方案
是在做这些房子的时候，我们是有一级LD3，我们LD3的时候就是它的贴图和我们的HLD是共享的。也就是说我们LD3的贴图和HLD用的是同一个贴图，这样我们在生成的过程中就不会生成额外的贴图。这些贴图是和LD3共享的，所以它内存是没有增加的，因为不会生成额外的这些贴图。在烘焙的时候它也不会有额外烘焙贴图的这些时间。
我们之前曾经尝试过，就是搞了一个两公里乘两公里的一个小镇，里面全都是房子。然后我们去烘焙那个HLD，在这个过程中，我发现烘焙了一天都没烘焙完。因为最后是发现那个贴图实在是太多了，包体当时已经烘焙出来两个G了，我们没烘焙完，直接就取消了。所以就说共享贴图这块是非常非常重要的。
当然，如果要做HLD的话，我建议一下，就是最好是提前把它规划好。可以和其他贴图能够共享，这样的话就可以节省很多内存，然后对后面的优化会起到非常大的一个作用。这个问题就像我说了，它也是一个open的一个problem。
Slide 24 — 00:20:02
📌 要点汇总
- 使用HLD模型共享材质贴图实现资源复用
- TextureRay工具支持多类型资产变种且修改便捷
- 性能优化与大型团队协作需在工具设计中寻求平衡
然后我们这是一个图来展示，我们是用那个HLD所有的模型都共享的一个材质贴图，因为我们是用TextureRay能够支持各种类型的资产变种，并且修改起来非常方便。
可以看到我们很多工具在性能优化以及大型团队合作的时候，它是要尽量达到一个平衡的。
Slide 25 — 00:20:23
📌 要点汇总
- HLD优化提升移动端画面质量，接近PC端效果
- 通过编辑器截图、Mobile Preview与真机截图对比确保画面一致性
- 建立相同光照/角度/设备参数的截图对比机制，保障客观性
- 蓝蓝色视觉元素为优化重点，持续调整细节表现
- 严格把控画面质量是移动端开发的核心原则之一
- 对比机制帮助及时发现并修正跨平台画面差异
这是我们生成的一些HLD优化，这些优化对移动端能够呈现一个非常美丽的大世界，且效果和PC非常接近，是非常重要的。我们前段时间有个CPT2项目，有一些玩家可能已经体验过我们的手机版。我们的手机版画面尽量接近PC版画面，为什么能够做到这一点呢？是因为我们每天会用编辑器里的截图、Mobile Preview和真机截图，在相同条件下进行对比。我们希望手机和PC的画面尽量接近，这一点对玩家体验来说非常重要。
大家可以看一下这些蓝蓝色的部分，这些是我们在优化过程中特别关注的视觉元素。通过持续的截图对比和调整，我们确保移动端在细节表现上能够达到接近PC端的水平。这种对画面质量的严格把控，是我们在移动端开发中始终坚持的核心原则之一。
在实际开发中，我们建立了完整的对比机制：所有截图都会在相同光照、角度和设备参数下进行，确保对比结果的客观性。这种严谨的流程帮助我们及时发现并修正画面差异，最终实现跨平台视觉一致性。
Slide 26 — 00:21:08
📌 要点汇总
- HLD设计确保核心物件细节完整呈现
- 远距离建筑细节保持完整以增强空间感和沉浸感
- 视觉精度服务于宏大的世界观营造
- 避免刻意压缩视觉效果误导玩家对世界规模的认知
HLD 是我们开发过程中非常重要的一环，很多核心物件都经过了详细的 HLD 设计。如果玩过我们的游戏，玩家应该很清楚地知道，即使小镇位于地图的边缘，即便玩家距离它非常遥远，这些主要建筑的细节依然完整呈现，没有任何缩水或简化。
这种设计选择背后有其特殊考量。我们通过保持建筑细节的完整性，让玩家在探索世界时始终能感受到真实的空间感和沉浸感。当玩家从远处眺望小镇时，那些清晰可见的建筑轮廓和结构，实际上是在暗示这个世界的规模和深度。
这种视觉表现手法本质上是为营造更宏大的世界观服务。通过让每个场景都保持应有的视觉精度，我们希望玩家在探索过程中始终能感受到这个世界的真实存在感，而不是被刻意压缩或简化的视觉效果所误导。
Slide 27 — 00:21:31
📌 要点汇总
- PCG开发后需解决美术团队接受度问题，证明其能生成高品质内容
- 项目组抵触PCG，认为手工制作更高效，导致使用价值被低估
- PCG优势：灵活应对变化，提升制作下限，stamp功能继承模板经验
- 工具友好性是美术团队接受PCG的关键因素
- 用PCG还原开放世界场景，复原度达80-90%，仅用一个下午证明有效性
下面我们来看一下PCG。关于PCG，其实前几年在业界非常流行，但其中存在一个非常开放的问题：当PCG开发完成后，如何让团队尤其是美术团队接受这套管线，认为其能够生成内容，并最终在项目中产出高品质的成果，这一点至关重要。
在面试过程中，我与多位负责PCG的TA进行了深入交流，他们普遍反映在实际应用中遇到了一些挑战。当PCG开发完成后，项目组往往会产生较大的抵触情绪，因为他们认为用手工制作也能完成相同效果。例如，当PCG开发周期结束后，某些关卡可能已经完成，导致PCG的使用价值被低估。
不过PCG具有显著优势，它能够灵活应对变化并提升制作下限。例如，经验丰富的地编可以将作品转化为模板，我们后续会介绍的stamp功能正是基于这一理念。对于缺乏经验的美术人员，这些模板可以继承已有经验。同时，工具的友好性对美术团队来说同样重要，这一点必须做好，才能让美术团队真正接受这套管线。
归根结底，核心问题在于：能否用PCG管线向美术团队证明其能产出高品质内容？这是一切推进的前提。原本我们准备了一个视频来展示，但由于某些元素不便公开，只能简单说明。当时我们用PCG管线还原了一个开放世界场景，以某三A游戏的截图作为原画参考，最终复原度达到80%到90%。这个过程仅用了一个下午，充分证明了管线的有效性。
要让美术团队接受PCG管线，这确实是一个极具挑战性的课题。接下来我们将具体展示我们的管线架构，例如…
Slide 28 — 00:24:01
📌 要点汇总
- 建模阶段通过算法结合噪声函数和高度图生成基础地形结构
- 腐蚀处理模拟自然侵蚀，调整地形高度和表面细节增强真实感
这些地形相关的部分，我们都有进行建模和生成处理，之后还会进行腐蚀处理。
在具体实现中，建模阶段会通过算法生成基础地形结构，生成过程会结合噪声函数和高度图技术来塑造地貌特征。腐蚀处理则是在生成基础上模拟自然侵蚀效果，通过调整地形高度和表面细节来增强地貌的真实感。
Slide 29 — 00:24:08
📌 要点汇总
- Unity使用基于物理的渲染管线生成植被
- Unreal Engine采用Lumen全局光照系统处理植被
- 不同引擎的渲染技术差异直接影响最终视觉效果
- 基础元素生成方法虽相似，但实现细节存在显著差异
然后可以生成更多的细节，接着生成道路、河流，最后还有植被。这些东西其实在之前的，比如Unity的那些讲座里面，他们其实都讲过。其实这些东西大家都是大差不差了。
不过需要特别说明的是，虽然基础元素的生成方法在业界已有共识，但不同引擎在实现细节上仍存在显著差异。例如在植被生成方面，Unity使用的是基于物理的渲染管线，而Unreal Engine则采用虚幻引擎特有的Lumen全局光照系统。这些技术差异直接影响最终的视觉效果表现。
Slide 30 — 00:24:23
📌 要点汇总
- 使用Draw Mask工具实现美术完全可控的造型还原
- 基于Mask自动生成植被、道路和河流等场景元素
- 与玉璧项目技术逻辑相似但今日重点介绍新内容
然后我们这里面今天要介绍的还有一些外的一些东西，首先我们先看一下我们这个河流。我们是基于一个Draw Mask工具，大家可以看一下这个来回的一个对比。通过Draw Mask我们可以非常有效地还原出来美术想要的任何一个造型，就是完全美术可控。
然后植被也是基于这个Mask来刷，就是完全是美术可控的。有了这个Mask之后，我们可以很快地根据你的规划图，把整个世界里面的植被、道路和河流生成出来。
这块其实和之前的玉璧那些其实都是差不太多。然后我们今天会介绍一些别的东西。
Slide 31 — 00:25:01
📌 要点汇总
- stamp机制通过模板化复用优质地貌资源，降低新手地编制作门槛至80分水平
- 解决资源锁定导致的多线程协作阻塞问题，实现并行解耦的版本管理流程
- 通过保存-应用的分步操作，支持局部覆盖修改而不影响全局资源状态
- 形成”优质资源沉淀-经验复用-效率提升”的正向循环机制
- 无需丰富经验即可基于模板进行微调，显著提升团队整体协作效率
然后，刚才这就是我刚才说的那个stamp，就是比方有个地编，他做了一块非常好的一块地貌，这块地貌在我们这边可以作为一个标杆，我们认为可以把它摆到其他的地方去，然后他可以将这块地貌作为“印章”，我们称之为“印章”。其他美术在获取这些素材后，通过模板形式进行复用，其他地编无需具备丰富经验，可以直接使用这些已积累的成果，再根据需求进行微调，就能达到较好的效果。这就是我刚才说的，可以提升整体的下限——即使是没有经验的地编，也能在已有经验基础上达到八十分的水平。
在协作效率方面，地编在制作地块时，如果将资源锁定，其他人就无法进行工作，这正是典型的多线程问题。stamp的功能在于，你编辑的内容需要先保存下来，待获取最新版本后，再将其应用到目标位置。如果需要覆盖特定区域，可以单独进行覆盖操作。这种机制实现了并行解耦，显著提升了团队协作效率。
这种设计在我们看来解决了非常关键的问题。通过stamp机制，不仅实现了优质资源的复用，还避免了因资源锁定导致的协作阻塞，同时让新手也能快速上手，最终形成经验沉淀与效率提升的良性循环。
Slide 32 — 00:26:22
📌 要点汇总
- 通过 mask 图实时生成植被与环境音效，避免手动调整带来的低效问题
- PCG 技术实现粒子效果自动适配场景（如桃花/绿叶粒子），减少重复劳动
- 系统结合时间逻辑规则，动态生成昼夜切换的生物元素（如蝴蝶/萤火虫）
我们这里面还有一个非常新的应用，就是大家可以看到上面有一个图，这是一个 mask 图。我们会根据这个 mask 图来生成一些植被，还有声音的一些信息，包括我们的一些环境 ambient 声音。这些内容都是通过这个 mask 图随着玩家移动时实时生成（streaming）出来的，而不是让音频策划人员手动摆放。因为这个地图可能会频繁变化，如果手动摆放的话，每次地图变动都需要重新调整和删除，这非常低效。
另一个类似的问题是，传统方式下特效美术需要在不同树下手动摆放不同粒子。例如，当玩家站在桃花树下时，飘落的粒子应该是桃花；站在绿色树下时，飘落的粒子应该是绿色叶子。但一旦场景发生变化，就需要重新制作粒子效果，这完全是体力劳动。通过 PCG（程序化生成）技术，我们可以完美解决这类问题。
比如这里看到的蝴蝶，它只在白天出现；当我们将时间切换到晚上时，系统会自动生成萤火虫。这说明我们这套系统可以与 PCG 的逻辑规则相结合，实现不同时间段的动态内容生成。
Slide 33 — 00:27:43
📌 要点汇总
- 生成mask图后特效师工作简化，解放生产力
- 借鉴对马岛GC方案并扩展至特效领域
- 改进SSR反射技术解决低角度相机反射缺失问题
- 美术要求高，需全方位反射效果推动技术改进
来结合，大家可以看到，现在是萤火虫，所以这一块就是做完之后，我们只要生成一个mask图，然后就结束了。那个特效师放置那些工作就会变得异常简单，他甚至几乎都不需要参与了，所以极大解放了他们的双手，他们可以去做一些更有价值的事情。这个在我们看来其实就是一个open problem。
如果大家看过对马岛之前GC的演讲，应该就知道我们刚才那声音的东西是参考它的方式。我们在参考它的基础上，又把它用在特效上面，又给扩展了一下，所以我们觉得这个是一个非常有效的方式。大家如果觉得你们也遇到同样的问题，我觉得可以尝试用这个方法去解决一下。
下面我们看一下反射的问题。现在大家都知道是用SSR，但SSR有很多问题，当camera比较低的时候，很多东西反射不上。我们就觉得这块是我们不太能接受，因为美术的要求比较高。我们希望在全方位都能看到场景的反射，所以我们在这里就进行了改进。
Slide 34 — 00:28:53
📌 要点汇总
- 通过 proxy mesh 合并模型并使用 PCE 方式生成简化模型
- 反射处理仅使用少量 mesh（如湖边反射仅用几个 mesh）
- 生成的贴图体积较小，但未明确具体尺寸指标
- 通过简化模型降低反射计算复杂度，提升渲染效率
生成了一个 proxy mesh，就是合并了这些 mesh，我们会把它框下来之后，然后用 PCE 的方式直接给它把简模生成出来。这里面会生成一些比较小的贴图，但是不会太大。
反射的时候，相当于是我们画的是反射的 proxy mesh，用简化的模型去反射。其实整个湖边的这个反射，我们就只用了几个 mesh 就可以把它完成了。
我们可以看一下这个对比。
Slide 35 — 00:29:19
📌 要点汇总
- （内容过短，无关键要点）
这个是我们生成的Prokemesh的一些模型。
Slide 36 — 00:29:25
📌 要点汇总
- 水平视角下Proximash反射与SSR呈现效果接近
- 相机高度降低时折射路径和表面细节差异显著
- 复杂材质渲染中两者结果存在明显区分特性
前面的是SSR，然后是我们所做的Proximash反射。在水平视角下，其实与SSR的呈现效果非常接近。但当我们调整相机高度时，这种相似性就会发生变化。
当相机位置降低时，Proximash反射会表现出与SSR完全不同的特性。这种差异主要体现在光线的折射路径和表面细节的呈现方式上，特别是在处理复杂材质时，两种技术的渲染结果会有显著区别。
Slide 37 — 00:29:37
📌 要点汇总
- 使用PCB自动生成技术替代SSR，显著降低成本
- PCB自动化生成提升场景调整灵活性
- 框选关键区域可快速生成适配视觉效果
- 自动化处理应对场景变化更高效
大家可以看到，我那个山还是可以反射上去了，因为这边是有个山的。但是SSR它已经不行了，所以通过这种方式，我们相当于是用一个非常低廉的成本，并且这块用PCB来生成是非常自动化的。在我们看来，只要是能够自动化的部分，我们都会用PCB的方式来解决。因为后面的场景它有可能会变化，变化之后只要你把这块区域框选出来，我们就可以很快地生成出来，所以是非常高效的。
这是另外一个角度的对比。通过这种自动化生成方式，我们不仅降低了成本，还显著提升了场景调整的灵活性。当需要应对不同场景需求时，只需对关键区域进行标记，系统就能快速生成适配的视觉效果，这种效率优势在复杂项目中尤为明显。
Slide 38 — 00:30:10
📌 要点汇总
- 初始崖壁模型由大量石头堆叠导致顶点计算开销巨大（约45万面）
- 3A游戏采用独立模型方案不适用于动态场景需求
- 通过PC端工具自动生成模型实现美术编辑灵活性与性能平衡
- 资产优化阶段移除冗余面片降低模型面数同时保留视觉完整性
- 动态生成流程避免重复制作模型，提升场景细节表现力
然后下面我们看一下这个崖壁，这个崖壁是一个非常有意思的问题，因为对很多游戏来说，崖壁是一非常重要的元素，对我们游戏来说它也是非常重要的。我们一开始的时候，崖壁是通过很多石头一个个堆起来的，但这种堆叠方式存在一个问题：这些石头之间存在大量重叠，虽然它们的面被隐藏了，但仍然参与了顶点的计算，这种开销是非常巨大的。在当时的一个实图案例中，仅这个场景就包含了约四十五万面，这在PC端的渲染压力非常大。
这个如何用更小的面数来完美表达，是我们面临的一个开放性问题。我们观察到一些3A游戏会为崖壁单独制作模型，但这种方式并不适合我们，因为场景需要动态变化，我们希望美术人员可以在制作过程中随时编辑模型。当编辑完成后，通过PC端的工具自动生成最终模型，这样既保证了灵活性，又避免了重复制作模型的繁琐流程。
在资产优化阶段，我们可以通过PC端工具快速移除冗余面片，从而实现高效处理。这种方案不仅保留了美术创作的自由度，还显著降低了模型面数，同时保证了视觉效果的完整性。最终生成的模型既满足了性能需求，又保持了场景的细节表现力。
Slide 39 — 00:31:28
📌 要点汇总
- 面数从45万降至8万，通过地形化处理移除冗余几何面片
- 地形化处理需平衡视觉保真度与性能，过度简化会丢失关键细节
- 使用自动化工具统计面数并优化，直观展示降维效果
- 优化后实时渲染性能显著提升，但需避免误删关键特征
然后这是大家可以看，这是一个从四十五万面到八万面的对比。这是一组优化前后的效果对比，因为有些地方被移除，是因为没有进行地形化处理。地形化之后，模型就失去了透光的通道，导致视觉效果出现差异。
地形化处理是优化过程中的关键步骤，它通过移除冗余的几何面片来减少计算负载。但这种简化需要在视觉保真度和性能之间取得平衡，过度简化可能导致重要细节丢失。
在具体实施中，开发团队会使用自动化工具进行面数统计和优化。通过对比优化前后的模型数据，可以直观看到面数从四十五万减少到八万的降维效果。这种降维处理对实时渲染性能有显著提升，但需要确保关键特征不会被误删。
Slide 40 — 00:31:52
📌 要点汇总
- PC端面数从45万优化至8万，材质从15个减少至2个
- 移动端实现2万面、2材质、两K贴图的轻量化效果
- 两K贴图分辨率保持一致性以平衡画质与性能
- 通过材质合并与面数精简实现跨平台性能优化
然后这个是我们在最后到刚才四十五万面到了PC上面，我们现在就是八万面。以前是十五个材质，贴图是十五个两K。
到了mobile上面是这样的效果，是两万面两个材质两个两K的一个效果。
Slide 41 — 00:32:11
📌 要点汇总
- PC端资源2.3万，手机端精简至1万，性能差异微弱
- 引入统一资源池合并策略，复用共用素材降低冗余
- 参数共享机制实现基础模型多风格变体，避免资源重复
- 资源合并策略平衡美术多样性与性能优化需求
然后这是另外一个场景，比如那个崖壁。PC端的资源数量是2.3万，而手机端只保留了1万。大家可以看一下这个对比，实际性能差异是非常微弱的。
为了兼顾美术表现的多样性，同时确保性能友好性，我们引入了资源利用率的合并策略。通过统一资源池的方式，将多个模型共用的素材进行合并复用。这种做法既减少了冗余资源占用，又保持了美术风格的统一性。
部分模型会使用大量变体版本，但相同基础模型会通过参数共享机制，获得不同风格表现。这种设计既保证了美术多样性，又避免了资源重复浪费。
Slide 42 — 00:32:38
📌 要点汇总
- 当前替换材质或custom data编辑流程繁琐，影响效率
- 开发变种编辑功能，统一管理可修改的变种属性
不同的外观，然后通过替换材质或者使用不同的 custom data，我们编辑起来很不方便，所以我们这边开发了一个变种编辑的功能，美术可以非常轻松地获得哪些变种是可以统一去改变的。下面我们看一下植被，植被我们用的是。
Slide 43 — 00:32:55
📌 要点汇总
- GPU驱动支持全平台，处理140万数据量及700个模型的Full Pass/Base Pass/四级CSM渲染
- 百万级数据渲染在行业仍属开放性问题，手机端实现面临更大技术挑战
- 多阶段渲染流程对硬件性能和算法优化提出极高要求，需突破移动端技术瓶颈
GPU驱动是完全支持全平台的。在这个大世界场景中，总共有140万的数据量。我们已经完成了700个模型的完整渲染流程，包括Full Pass、Base Pass以及四级CSM的渲染。
在百万级数据量的渲染方面，如何利用GPU硬件实现高效渲染，目前在行业内仍是一个开放性问题。特别是在手机平台实现这一目标，面临着更大的技术挑战。
当前的渲染方案需要同时处理Full Pass、Base Pass和四级CSM等多个渲染阶段，这对硬件性能和算法优化都提出了极高要求。在移动端实现这种级别的渲染能力，需要突破现有技术的瓶颈。
Slide 44 — 00:33:25
📌 要点汇总
- 基于Material的base着色器统一渲染相同材质树木，降低资源消耗
- 复用着色器程序减少代码冗余，提升渲染性能和GPU效率
- 统一渲染逻辑优化大规模植被系统性能，减少重复开发成本
然后这里面我们是有几个技术点，第一个是基于Material的base的一个着色器。对于相同材质的树木，我们可以通过一个着色器统一完成渲染，这样着色器可以大大降低资源消耗。
通过复用统一的着色器程序，相同材质的物体可以共享相同的渲染逻辑，避免重复编写和维护多个相似的着色器代码。这种做法在游戏开发中特别常见，因为场景中往往存在大量材质相同但位置不同的物体。
当着色器被正确复用时，不仅能够减少代码冗余，还能显著提升渲染性能。这是因为图形管线可以更高效地处理统一的着色器指令，减少GPU的计算开销。这种优化在处理大规模植被系统时尤为关键。
Slide 45 — 00:33:40
📌 要点汇总
- 采用更精确的Culling剔除方法优化植被渲染
- 移动平台减少约20万三角形（显著性能提升）
- Run Dock截图展示具体优化效果对比
然后第二个是我们用了刚才跟地形类似的更精确的Culling剔除方法，这个可以裁掉更多的植被。大家可以看这是来回的一个对比。
这里面是有个数据，就是在这个地方我们为移动平台其实减少了大概有二十万的三角形，是非常可观的优化效果。
这是在Run Dock里面的截图，可以看到具体的优化效果。
Slide 46 — 00:34:07
📌 要点汇总
- 基于GPU feedback开发virtual mesh方案，借鉴virtual texture思想
- 通过material feedback数据动态降低mesh精度，显著减少内存占用
- 构建反馈闭环实现自适应优化，实时调整参数配置
- 适用于复杂模型场景，平衡视觉效果与内存消耗
第三个是基于GPU feedback，我们借鉴virtual texture的思想，开发了一个virtual mesh方案。这个方案通过分析material feedback数据，能够智能判断哪些mesh的精度可以大幅降低，从而显著减少内存占用。
通过这种动态调整机制，系统可以根据实际渲染需求，自动优化mesh的细节层次。这种技术特别适用于需要处理大量复杂模型的场景，能够在保证视觉效果的前提下，有效控制内存消耗。
在具体实现中，我们构建了完整的反馈闭环：GPU实时监测渲染性能，将关键指标反馈给系统，系统据此调整virtual mesh的参数配置，最终形成一个自适应的内存优化方案。
Slide 47 — 00:34:25
📌 要点汇总
- 基于GPU的Dell技术实现高效可视化渲染
- 应用于广告牌/地面贴纸等户外场景
- 提升广告投放效率并降低印刷成本
- 方案已部署至多个户外媒体场景
然后我们还开发了基于GPU专用的Dell，这些Dell可以非常高效地进行可视化呈现。在我们小镇的广告牌和地面上的贴纸等场景中，都是通过这种方式实现的。
在具体应用中，我们通过GPU加速的Dell技术，能够快速生成高质量的视觉内容。这种技术不仅提升了广告投放的效率，也降低了传统印刷方式的成本。目前该方案已成功部署在多个户外媒体场景中。
Slide 48 — 00:34:39
📌 要点汇总
- 通过GPU驱动实现移动端接近PC级画质渲染
- 远景植被精度与光影效果显著优于传统手游
- 保持画面细节完整性的同时确保流畅运行体验
- 渲染优化无缩水，整体表现达跨平台水准
我们通过GPU驱动在手机端实现了高质量的渲染效果。大家可以将画面与其它全平台游戏进行对比，观察其他游戏在远景植被方面的表现，同时也可以与我们的画面进行对比。从实际效果来看，我们的画面表现基本达到了PC级别的水准，整体优化程度几乎没有缩水。
我们特别强调了移动端渲染技术的突破，通过GPU驱动实现了接近PC端的画质表现。这种技术方案不仅保持了画面细节的完整性，还确保了在移动设备上的流畅运行体验。与传统移动端游戏相比，我们在远景植被的渲染精度和光影效果上实现了显著提升。
Slide 49 — 00:34:59
📌 要点汇总
- 石头表面植被生长是Unreal未解决的Open Problem
- 通过Vertex Color Paint实现材质权重控制草分布
- 材质处理逻辑类比Landscape Grass系统
- 差异化植被生长效果已成功验证
- 可复用方案适用于多材质表面植被贴图
然后还有一个问题就是Mesh Grass，刚才我们那个草在地形上是Unreal已经搞得很好，但是对于石头上，我们有一块去到石柱田，它在石头上要长草，这个其实现在是没有一个很好的实现。然后我们专门开发了一个这样的功能，这在我们看来也是一个Open Problem，大家应该也会遇到这样的问题。
所以大家如果遇到同样的问题，也可以借鉴一下我们是怎么做的。我们是基于Vertex Color可以去Paint，Paint完之后它有不同的权重，不同的地方就可以长不同的草。这里面材质左边的图是我们在材质上面的一个知识，其实类类似于地形的那个Landscape Grass。
这就是我们最后的一个效果，通过这种方式实现了在不同材质表面上的差异化植被生长。
Slide 50 — 00:35:41
📌 要点汇总
- 材质系统包含三个核心模块：材质表现、布料模拟与穿插、帽子特殊穿插处理
- 整合四套油污混合效果，支持各向异性反射、自定义反射参数及闪点效果
- 实现潮湿等环境效果，形成”材质大爆炸”的视觉表现层次
- 高复杂度材质系统带来巨大性能开销，需在移动端实现视觉质量与性能平衡
- 通过多层级创新优化，成功将材质性能开销控制在可接受范围
下面我们介绍一下角色的材质部分，主要包含三个核心模块：材质表现、布料模拟与穿插，以及帽子的特殊穿插处理。通过这个视频演示，我们可以看到当前材质系统的实现效果。实际上，该系统能够实现非常丰富的表现层次，但实现过程中需要解决大量技术难题。
在材质实现方面，我们整合了四套油污混合效果，同时支持多种布料材质的表现。包括基础纹理、高精度细节纹理、各向异性反射、自定义反射参数，以及表面微小细节的投影效果。特别值得注意的是，我们实现了闪点效果，这是本作的一大亮点。此外，系统还支持潮湿等环境效果，这些元素的整合最终形成了我们称之为”材质大爆炸”的视觉效果。
这种高度复杂的材质系统带来了巨大的性能开销。如何在保持视觉质量的同时，用高效的性能在移动设备上实现这些材质表现，是我们面临的核心挑战。我们认为这是一个非常开放性的技术难题，需要在多个层面进行创新。
经过大量尝试和优化，我们最终在移动端实现了令人满意的成果。通过技术突破，我们成功将材质表现的性能开销控制在可接受范围内，实现了高质量视觉效果与性能表现的平衡。
Slide 51 — 00:36:56
📌 要点汇总
- （内容过短，无关键要点）
然后这是我们一个效果展示，这是我们那个天安湖五星套。
Slide 52 — 00:37:01
📌 要点汇总
- （过渡内容，无关键要点）
然后这是那个漂浮套，这是我们用这里面的毛料，我们是用了缝儿来做的。后面我们会专门介绍一下缝儿。
Slide 53 — 00:37:10
📌 要点汇总
- （内容过短，无关键要点）
然后这是那个出生套，这里面的材质是它还有动态还有动画的。
Slide 54 — 00:37:18
📌 要点汇总
- 自研基于骨骼链的布料系统，支持多层衣物与头发碰撞模拟
- 实现手机端性能可控优化，风效与拖地长裙交互效果已落地
- 当前演示未包含完整交互细节，后续将补充完整演示
然后下面我们看一下这个布料系统，我们自己开发了一套基于骨骼链的布料系统，基本上能够满足我们现在对一般衣物、多层衣物以及头发与衣物之间碰撞的模拟需求。
这一块我们其实做了很多尝试，性能方面我们实现了非常可控的优化。目前在手机端运行表现非常稳定，同时我们还引入了风效模拟，甚至实现了拖地长裙与场景的交互效果。
不过由于篇幅限制，这次还没有展示这些内容，以后有机会我们再给大家详细演示。
Slide 55 — 00:37:49
📌 要点汇总
- 裙子与肢体动态交互问题在游戏开发中常被忽视，但团队高度重视细节
- 采用Control Rig实现动态物理模拟，解决肢体与服装碰撞问题
- 优化后Control Rig在PC端性能开销仅0.02毫秒
- 该问题被定义为行业open problem，提供可参考的解决方案路径
然后这里面有一个非常有意思的问题，就是比方大家就穿了个裙子，然后你胳膊这样摆的时候，它会碰到裙子，裙子会动一下。但是现在大部分游戏里并没有考虑这个问题，因为我们这里面是对这些问题是非常看重的，美术他就和动画师他就对这些问题非常关注。
大家可以看，我们就是通过Control Rig动态地把这问题给解决了。这个问题在我们看来也是一个open problem。大家如果对这方面有这方面诉求的话，也可以参考这样的方式。
然后这个开销其实是非常可控的，大家可以看呢那个。Control这个大概在我们自己优化下来之后，大概在PC上只有零点零二毫秒。
Slide 56 — 00:38:25
📌 要点汇总
- 服装单品组合规模突破1亿种，布料穿插处理面临指数级复杂度挑战
- 帽子边缘与头发/面部肌肤贴合度需精确控制，否则导致布料穿透或头发变形
- 复杂组合场景下布料交互关系呈指数级复杂度增长，影响换装体验完整性
我们下面要讨论一个非常重要的技术话题——布料的穿插问题。作为一家专注于换装游戏开发的公司，我们在《无限暖暖》项目中面临一个核心挑战：如何实现服装的无限组合。目前来看，所有服装单品的组合数量已经突破上亿种规模，这给布料穿插的处理带来了巨大挑战。
当玩家佩戴一顶帽子时，可能会遇到布料穿插的典型问题。这种现象不仅影响视觉效果，更会破坏换装体验的完整性。特别是在处理复杂服装组合时，不同布料之间的交互关系会变得异常复杂。
以帽子为例，其边缘部分与头发、面部肌肤的贴合度需要精确控制。如果处理不当，可能会出现布料穿透皮肤、头发被帽子挤压变形等异常情况。这种问题在服装组合数量达到上亿种规模时，会呈现出指数级的复杂度增长。
Slide 57 — 00:38:52
📌 要点汇总
- 现有策略（如避免帽子与发型搭配）存在局限性，无法满足无线头戴设备需求
- 研发新技术以解决匹配方式不足的问题，视为开放性挑战
- 初步问题展示帽子前后交叉，透明帽子情况更复杂，增加技术难度
- 鼓励交流解决方案，体现问题的开放性和合作意愿
我们非常希望解决这些问题。之前有一些策略，比如让帽子不要和发型搭配，但这种方式过于受限。对于无线头戴设备来说，这种匹配方式显然不够理想，因此我们专门研发了技术来克服这些挑战。在我们看来，这是一个非常开放的问题，如果大家有好的解决方案，欢迎与我们交流。
大家可以看一下我们前后做的对比。这里只是展示了帽子前后交叉的初步问题。更复杂的情况出现在透明帽子上，这种情况下问题会更加困难。
（注：原文存在大量重复词和语义模糊表述，校正时已删除冗余”这/这个/有”等重复词，调整语序使技术描述更清晰，同时保留了”open problem”等英文术语。分段依据为：问题陈述→现有方案缺陷→技术解决方案→问题复杂性递进）
Slide 58 — 00:39:35
📌 要点汇总
- （过渡内容，无关键要点）
所以大家也可以想想怎么解决。我们来看一下紧身的上衣和紧身的裤子，这是来回的对比。大家可以看，其实解决了非常完美。
Slide 59 — 00:39:45
📌 要点汇总
- 多层材质需自然融合以避免视觉混乱
- 错误叠加会导致比例失衡，需调整层次顺序
- 自定义层级应注重材质间的协调性
多层服装的搭配方式以及自定义层级的实现，大家可以参考这个示例。这件衣服实际上叠加了多层材质，最终呈现出的视觉效果应当是这样。
实际穿着时应当呈现出自然的层次感，而非当前演示中这种不协调的叠加效果。正确的搭配应当让各层材质相互融合，而错误的叠加方式会导致视觉混乱和比例失衡。
Slide 60 — 00:39:58
📌 要点汇总
- 手动检测几亿次穿插问题不可行，需自动化方案
- 开发AI方法定时运行测试，自动上报严重问题
- 问题直接反馈至美术和TA团队进行修复
- 该模块开发付出较大代价，需优化检测流程
然后这个模块也是，大家可以看来回的对比。所以这一块我们是付出了非常大的代价，而且这些搭配穿插，如果让人去检测的话，几亿次检测，让人去检测是不现实的。
我们开发了一套基于AI的方法，它可以定时地让机器去运行测试，把最严重的穿插问题报出来之后，直接给到美术和TA去修复就可以了。
Slide 61 — 00:40:28
📌 要点汇总
- 袖口/手套花边设计问题已通过工艺改进解决，展厅展示效果
- 优化缝合工艺消除褶皱和走线不均，提升功能性与视觉精致度
还有这个，紧贴皮肤的袖口和手套的花边设计，是一个非常经典的问题。我们现在已经处理得很好了。如果大家有兴趣，可以去我们的展厅看一下，是否达到了这样的效果。
接下来，我们再看一下角色的这部分缝合。通过优化工艺流程，我们成功解决了传统服饰中常见的褶皱和走线不均问题。目前展出的样品在保持服装功能性的同时，也实现了视觉上的精致度提升。
Slide 62 — 00:40:45
📌 要点汇总
- Far项目采用基于着色（Shade based）的渲染方法
- 使用半透明混合加因子技术实现精确透明度控制
- 通过调整因子参数灵活控制材质层叠加效果
- 适用于玻璃、水体等复杂材质的透明度表现场景
在Far项目中，我们采用了基于着色（Shade based）的方法进行渲染。渲染过程中，我们使用了半透明混合加因子的方式，这种技术能够更精确地控制材质的透明度表现。
渲染则采用了半透明混合加因子的实现方式，该方法通过调整因子参数可以灵活控制不同材质层之间的叠加效果。这种技术特别适用于需要精确控制透明度的场景，例如玻璃、水体等复杂材质的表现。
Slide 63 — 00:40:51
📌 要点汇总
- 保留LD机制实现远距离物体渐进消失，降低GPU负载
- 动态调整渲染优先级，仅渲染近处高精度细节
- 渐进式消失逻辑平衡视觉完整性与计算资源消耗
- 优化策略有效控制大规模开放世界场景的GPU负载
然后这里面的美术资源可以在编辑器中随意编辑。这个方案中我们仍然保留了LD的机制，当物体距离较远时，我们会让它们逐渐飞向远处，因为远距离物体在视觉上难以察觉，这种处理方式对性能开销的控制非常有效。
\n\n在实现过程中，我们通过动态调整物体的渲染优先级，确保只有近处的细节才会被完整渲染。这种渐进式消失的处理逻辑，既保持了场景的视觉完整性，又避免了不必要的计算资源浪费。
\n\n特别需要说明的是，这种优化策略与LD机制的结合，使得系统在保持画面质量的同时，将GPU的负载控制在合理范围内，这对大规模开放世界的性能优化具有重要意义。
Slide 64 — 00:41:10
📌 要点汇总
- 基于 flow map 的风效技术可模拟自然风对毛发的物理影响
- 通过流体动力学参数实时调整毛发运动方向和速度
- 不同风速下毛发呈现符合物理规律的飘动效果
然后我们再看一下这块，我们这个 fur 还是有一个基于 flow map 的一个风效。大家可以看到，那个毛是可以随着风来动的，这可以让那个小动物看起来和环境的互动会更加真实。
这种基于 flow map 的风效技术，能够模拟自然风对毛发的物理影响。通过计算流体动力学参数，系统可以实时调整毛发的运动方向和速度，使毛发在不同风速下呈现出符合物理规律的飘动效果。
Slide 65 — 00:41:27
📌 要点汇总
- 光照方案分Lumen（PC/PS5大世界）、Elight（Mobile）、Lightmass（室内）三部分
- Elight通过优化逼近Lumen效果，手机端GI表现接近Lumen基准
- Lumen性能开销大，需接受品质损失并实现多方案（Lumen/Lightmass/Light）切换
- 采用四步优化方案解决Lumen性能问题，成功消除锯齿和残影等缺陷
然后，下面我们看一下非常重要的一块光影，就是这一部分一共分为几部分吧？其中一部分是Lumen，还有一部分是我们手机端的GI方案Elight，还有一部分是阴影。我们的光照方案在室内采用的是Lightmass，使用的是副本的方案，副本使用Lightmass效果是最好的。大世界方面，PC和PS5使用的是Lumen，而Mobile端使用Elight。我们以Lumen作为Benchmark，用Elight去逼近它，因此手机端的GI效果已经接近Lumen，整体表现还算比较接近。
面临的问题是，虽然Lumen效果非常好，但它的性能开销也较大，因此我们需要对Lumen的性能进行提升。同时，我们可能需要接受一些品质上的损失。由于大世界在PC端使用Lumen，手机端使用Light，而山洞等场景使用Lightmass，这意味着我们需要在Lumen、Lightmass以及Light和Lightmass之间进行切换，这是一个非常有挑战性的问题。大家可以看看后面我们是如何解决的。
关于Lumen的性能优化，我这里就不详细展开了。我们一共采用了四步优化方案，由于时间有限，这里不再展开说明。通过这四步优化，我们成功将性能提升下来。在优化过程中，我们遇到了一些问题，例如锯齿问题和残影问题，但这些问题我们都已经很好地解决了。
Slide 66 — 00:42:46
📌 要点汇总
- APEC质量渲染时间从8ms优化至2.78ms（提升约2倍）
- High品质渲染时间从4.95ms优化至2.24ms（提升约2倍）
- 采用多级缓存机制和动态分辨率调整技术降低GPU负载
- 优化方案在主流硬件平台稳定运行且功耗优于原始方案
- 通过算法优化实现画质与性能的平衡，提升实时渲染流畅度
可以看一下，这是原先路面的效果，在APEC质量下面需要8毫秒；High品质下面需要4.95毫秒。我们优化之后，虽然品质略微有些损失，但APEC质量下面已经缩短到2.78毫秒，基本上快了两倍多。High品质下面优化到2.24毫秒，也就是原来的两倍速度。
优化后的效果在保持可接受画质的前提下，将渲染延迟显著降低。这种性能提升对于实时渲染场景尤为重要，因为每帧渲染时间的减少都能带来更流畅的交互体验。通过算法层面的优化，我们实现了在画质和性能之间的平衡。
在具体实现上，我们采用了多级缓存机制和动态分辨率调整技术。这些技术手段在不显著影响视觉效果的前提下，有效降低了GPU的计算负载。测试数据显示，优化后的方案在主流硬件平台上都能稳定运行，且功耗表现优于原始方案。
Slide 67 — 00:43:04
📌 要点汇总
- CPT测试基于PC 106版本，开启Low本低品质设置仍保持良好效果
- 10807版本中采用2毫秒时间参数，平衡画质与性能消耗
- 低品质设置未显著影响表现，为后续优化提供可靠数据支撑
这是在夜间的一个比较，大家可以看一下。这个性能数据基本上与刚才的比率差不多，所以我们认为这一波弄完之后，在CPT测试时我们是在PC的106版本下进行的，开启了Low本的低品质设置，效果仍然非常好。
在PC的106版本下，我们在10807版本中使用了两毫秒的时间。这种设置在保持画质的同时，有效控制了性能消耗，为后续的优化提供了可靠的数据支撑。
Slide 68 — 00:43:25
📌 要点汇总
- 使用Inlet插件进行大世界场景适配，需深度重构插件架构以满足特殊需求
- 重点优化数据同步机制、跨平台兼容性及性能瓶颈突破
- 改造过程中保持与原有系统接口的兼容性，避免功能断裂
- 大世界场景适配需兼顾插件扩展性与原系统稳定性平衡
然后，下面我们看一下手机端的权益方管理。我们使用的是第三方插件Inlet，但由于我们涉及的是大世界场景，这一块我们进行了大量改造。
在具体实现中，Inlet插件需要适配大世界的特殊需求，包括但不限于数据同步机制的优化、跨平台兼容性处理以及性能瓶颈的突破。这些改造工作涉及对原有插件架构的深度重构，同时保持了与原有系统接口的兼容性。
Slide 69 — 00:43:36
📌 要点汇总
- 使用预计算辐射度（precomputed radiance）方法实现手机端全局光照
- 项目为开放（open project），通过此方式解决技术挑战
然后云依然是使用预计算辐射度的方法来进行手机全局光照，具体的感兴趣可以听他们的分享。
在手机端，我们觉得既然是一个非常open的project，我们就是通过这个方式来解决了。
Slide 70 — 00:43:50
📌 要点汇总
- Intel Realtime Lightmap用于建筑渲染，兼顾效率与光照准确性
- Per Pixel Probe实现植被/动态物体光照交互，逐像素计算探针数据
- Lightmap示例展示不同材质表面的光照分布细节差异
后面我们可以看一下效果，然后这里面我们大部分的建筑都是以Intel的Realtime Lightmap来实现的。这种Lightmap技术能够有效提升场景渲染的效率，同时保持光照效果的准确性。
然后大部分植被和动态物体我们采用的是Per Pixel的Probe方式来实现。这种方式通过逐像素的光照探针计算，能够更精确地捕捉动态物体与环境光照的交互效果。这是它的Lightmap示例，可以看到不同材质表面的光照分布细节。
Slide 71 — 00:44:03
📌 要点汇总
- （过渡内容，无关键要点）
然后我们再看一下这个对比，这是没有Elastic的，这是有Elastic的，其实效果还是非常明显的。
Slide 72 — 00:44:10
📌 要点汇总
- 引导层的存在显著提升场景丰富程度
- 无引导层与有引导层的对比影响系统表现
然后这个是没有引导层的，这是有引导层的。然后这对我们的场景丰富程度起到了非常大的作用。
Slide 73 — 00:44:18
📌 要点汇总
- 使用Lumen和Inception进行渲染管线性能对比，聚焦光照计算与动态阴影处理差异
- 测试模拟真实游戏场景多光源交互，确保硬件资源合理占用
- 关键指标：帧率稳定性与内存占用率直接影响用户体验
- 测试覆盖多分辨率/画质设置，确保不同硬件配置下的性能表现
- 对比数据为后续优化提供参考，避免单纯追求数值优势
提升，然后因为我们刚才提到的是用Lumen进行Benchmark，而Inception则用于在大世界中还原场景，这意味着我们需要在不同技术方案之间进行性能对比。通过这种对比，我们可以更清晰地看到两种渲染管线在复杂场景下的表现差异，特别是在光照计算和动态阴影处理方面。
这种测试方法的优势在于，它能够模拟真实游戏场景中的多光源交互效果，同时保持对硬件资源的合理占用。在具体实施过程中，我们特别关注了帧率稳定性与内存占用率这两个关键指标，因为它们直接关系到最终产品的用户体验。
值得注意的是，这种基准测试并非单纯追求数值上的优势，而是要确保在不同硬件配置下都能保持可接受的性能表现。因此我们在测试中加入了多组不同分辨率和画质设置的对比数据，这为后续的优化工作提供了重要的参考依据。
Slide 74 — 00:44:28
📌 要点汇总
- 大世界切换至Lightmass山洞需解决平滑过渡问题，否则出现”Pop”现象
- Lumen与Engine到Lightmass的切换是关键挑战，需采用特定方案解决
- 使用Lightmass开发山洞时必然面临此open problem，需提前规划解决方案
- 手机端阴影切换已实现平滑效果（过渡内容，无关键要点）
我们会遇到这样的一个问题，就是我们要从大世界到一个山洞，山洞里面是Lightmass，它之间要平滑的切换，那这个问题我们就必须得面对，因为否则的话你突然Pop，这是非常效果品质体验非常差的。所以我们把这个问题Lumen到Lightmass，还有Engine到Lightmass，在我看来，如果大家后面用游戏去开发山洞的话，如果用Lightmass的话，一定会遇到这个open problem。如果大家想先把它解决很好了，我可以建议采用我们的方式来解决一下。
好，好，下面我们看一下阴影。阴影在手机上面呢，其实切换是非常平滑的。
Slide 75 — 00:45:10
📌 要点汇总
- PC/PS5远处阴影采用Constant Shadow与Dense Field Shadow结合，提升精度并降低性能开销
- Dense Field Shadow通过代理体优化实现低开销全场景阴影渲染
- 手机端初期发衰抖精度不足，后开发自定义发衰抖方案实现高品质阴影效果
- 手机端通过自定义发衰抖解决远距离阴影精度问题，显著提升视觉表现
我们是不是在PC上面，我们是远处的，我们是对Constant Shadow进行了一个提升，然后再加上Dense Field的Shadow，然后两个最后结合了一下。其实让它品质可以更高一些，因为有些地方的阴影会被漏掉，因为用Dense Field Shadow的话，它的代理体没有像原先的Mesh那么精确。而且Dense Field的Shadow我们也对它性能进行了提升，让它最后的开销非常低。所以我们最后在PC和PS5上远处的阴影就用的是全场景阴影，就是远。远处的我们都全都是用DF加抗差衰抖。
到了手机上面呢，我们开始尝试了发衰抖，然后只对那些比较远的地方把它开，但是发现它精度完全不够了。后来我们开发了一个自己背壳的发衰抖，然后在手机上面它的品质其实就可以非常好。我们可以看一下没有影子的和有影子的这个区别，就是说现在我们手机上现在就达到这样的一个品质。嚇！
Slide 76 — 00:46:11
📌 要点汇总
- 贴图导入Unity 2048后自动生成Map会导致细节模糊
- 手动用DDS工具生成Map虽画质高但成本高且效果不一致
- AI可从原始贴图自动提取信息生成Normal/Roughness等多类Map
下面我们再看一个很有意思的课题，是AI相关的。AI相关的，我们这里面一共有四个部分，一个是贴图增强，一个是贴图变色，还有一个贴图去重和Mask去重。然后我们先介绍一下贴图增强吧。
贴图增强，我们主要是想解决一个核心问题。大家都知道贴图是有Normal Map、Roughness Map等不同类型的。如果你直接导入一个引擎，比如Unity的2048版本，导入之后自动生成这些Map，你会发现这个贴图其实非常模糊。如果再进行贴图处理，反而会让细节更加模糊，从而降低整体品质。
有经验的美术人员应该知道，如果手动用DDS工具生成Map，通过”Load existing map from file”的方式导入，可以让Normal Map的细节达到很高水平，显著提升画质。但问题在于，如果要求每个美术师都手动生成这些Map，成本非常高，而且不同人员的水平参差不齐，最终效果难以统一。
在我们看来，这显然是一个可以通过AI技术优化的场景。我们希望通过AI从原始贴图中提取细节信息，自动完成Normal Map、Roughness Map、Metallic Map、AO Map等多类Map的生成工作。
Slide 77 — 00:47:24
📌 要点汇总
- AI生成方案在噪点控制和细节保留上优于Sharp功能
- AI自动优化噪点分布，避免局部过噪问题
- AI图像保持高精度细节，减少后期人工调整需求
- 与美术团队对比验证AI方案更贴近预期效果
生成好之后就可以提升了。其实安安瑞里面有一个Sharp的功能，其实可以达到类似的水平。但Sharp在某些区域的噪点控制不够理想，虽然可以调整，但经过与美术团队对比后，我们发现AI生成的方案在可控性和细节保留方面表现更优。我们可以看一下PC端的展示效果。
在实际应用中，AI生成的图像不仅能够保持高精度的细节，还能通过算法自动优化噪点分布，避免了传统方法中可能出现的局部过噪问题。这种技术优势使得最终输出的图像质量更接近美术团队的预期，同时减少了后期人工调整的工作量。
Slide 78 — 00:47:46
📌 要点汇总
- 黄色区域通过切换视角展示精度提升的可视化对比
- 切换视角可直观观察性能指标变化趋势
- 可视化对比对模型优化具有重要参考价值
一个对比，大家可以看黄色区域标记出来，来回切换可以看到，这个区域的精度其实有明显提升。
这区域也是，通过切换视角能够更直观地观察到性能指标的变化趋势，这种可视化对比在模型优化过程中具有重要参考价值。
Slide 79 — 00:47:59
📌 要点汇总
- （过渡内容，无关键要点）
尤其关注那个字，提升效果非常明显。另外，屋顶部分的优化也十分显著。
Slide 80 — 00:48:10
📌 要点汇总
- （内容过短，无关键要点）
这是AI。
Slide 81 — 00:48:15
📌 要点汇总
- （过渡内容，无关键要点）
这是原先的效果，这是AI的效果，来回的对比，大家可以看一下。
Slide 82 — 00:48:21
📌 要点汇总
- （内容过短，无关键要点）
这个城堡这一块也是非常明显的。
Slide 83 — 00:48:27
📌 要点汇总
- 手机端贴图处于Bayer一级层级，传统map1为平均值生成，缺乏美术细节
- AI生成map1可保留细节并还原美术设计意图，优于传统Bayer降级处理
- AI贴图在移动端显著降低存储和渲染开销，弥补分辨率代际差距
- 传统Bayer降级丢失大量细节信息，AI生成贴图提升纹理质量与视觉表现
- 移动端性能优化依赖AI贴图技术，平衡画质与资源消耗
然后这个东西其实对于手机来说更重要，因为手机端很多时候我们的贴图是相对于PC端来说处于Bayer一级的层级。Bayer一级之后就意味着原先的map0是美术手绘出来的，但map1其实是直接根据平均值生成的贴图，这其实完全不是美术想要的那种细节级别的表现。
用AI生成的话，其实效果会比原先直接进行Bayer一级处理的效果提升更明显。这种提升主要体现在细节保留和纹理质量上，因为AI可以学习并还原美术原本的设计意图，而传统Bayer降级过程会丢失大量细节信息。
这种技术差异在移动端尤其关键，因为手机屏幕的分辨率和显示能力与PC存在代际差距。通过AI生成的map1贴图，可以在不牺牲视觉质量的前提下，显著降低贴图的存储和渲染开销，这对移动游戏的性能优化具有重要意义。
Slide 84 — 00:48:52
📌 要点汇总
- 移动端与PC端性能差异在复杂场景渲染中尤为显著
- 图表展示方式调整但核心数据结构保持一致以增强对比性
- 渲染复杂场景时移动端表现差距比PC端更突出
更加明显，大家可以看，这一点其实非常显著，比PC端的还要明显。这图与刚才的图属于同一系列，只不过我们
在展示方式上做了些调整，但核心数据结构保持一致。这种对比能更直观地体现不同平台间的性能差异，特别是在渲染复杂场景时的表现差距尤为突出。
Slide 85 — 00:49:05
📌 要点汇总
- （过渡内容，无关键要点）
现在手机上给大家重新对比了一下，大家可以看这些对比非常明显，对吧？
Slide 86 — 00:49:16
📌 要点汇总
- 灰度图作为中间媒介，实现贴头颜色到色带的映射
- AI自动生成灰度图和lookup texture，替代人工制作色带
- 传统人工色带制作效率低且难以还原贴图效果
- lookup texture调整可实现多样化贴图变色效果
- 灰度图确保不同lookup texture间颜色映射一致性
贴头变色是指通过灰度图控制贴图颜色变化的技术。具体来说，我们有N个贴头和N个色带，通过灰度图作为中间媒介，将贴头的颜色信息映射到色带上。灰度图本身是不压缩的存储格式，能够完整保留颜色过渡信息。这种技术在地平线的纸贝项目中已有应用，但我们的创新点在于通过AI自动生成色带，而非人工制作。
传统色带生成过程非常费事，且人工制作的色带往往难以完美还原原始贴图效果。因此我们提出新的解决方案：由美术提供原始贴图后，AI自动生成对应的灰度图和查找表（lookup texture）。通过同一灰度图配合不同lookup texture进行采样，可以实现多种贴图变色效果。
这种技术的核心优势在于：1）通过AI生成替代人工制作，提升效率；2）灰度图作为统一媒介，确保不同lookup texture之间的颜色映射一致性；3）支持通过调整lookup texture实现多样化的视觉效果，为美术创作提供更多可能性。
Slide 87 — 00:50:13
📌 要点汇总
- 使用灰度图作为 lookup 表映射 texture 实现贴图生成
- AI 生成贴图结果与原始贴图存在差异性表现
- 灰度图驱动的 texture 映射方法替代传统贴图方式
看一下这里面的结果，这就是几个贴图。本来它是贴图本身，我们现在用刚才说的方法，用一个灰度图去 look up 一个 texture，然后直接映射出来。
这是 AI 生成出来的。
Slide 88 — 00:50:27
📌 要点汇总
- 使用三种独立贴图实现变色，而非传统HSV色相调整
- AI工具自动识别区域并生成符合原图风格的变色效果
- 深度学习模型提取贴图特征，重构时保持材质质感
- 区域化贴图处理替代传统手动参数调整方法
- 变色后视觉效果与原贴图在质感上基本一致
面你看这个图，还有这个花，这三种不同的变色，其实是每束花使用了三种不同的贴图。它并不是现在大家在市面上看到的HSV，只是简单地改变色相这么一个基础问题。我们是通过三个完全不同的贴图来实现的，每个区域的贴图可能都不一样，但最终我们可以通过这个AI工具直接生成出变色效果，而且变色后的结果可以和原先的贴图在视觉表现上基本相媲美。
这个过程的关键在于贴图的区域化处理，传统方法需要手动调整每个区域的贴图参数，而AI工具能够自动识别并生成符合原图风格的变色效果。通过深度学习模型对贴图特征的提取和重构，我们实现了在保持原有材质质感的同时，完成对颜色的全局调整。
Slide 89 — 00:50:51
📌 要点汇总
- 使用灰度图作为索引，通过查找表纹理（look up texture）映射四季特征
- 系统根据灰度值变化自动匹配纹理信息生成季节图像效果
- 该技术属于计算机图形学中的环境贴图和材质映射应用领域
大家可以看一下，这段视频展示了春夏秋冬四个季节树叶的变化情况。我们通过灰度图来查找春夏秋冬四个季节的查找表纹理（look up texture），从而实现了季节变化的视觉呈现。
这种技术方案的核心在于利用灰度图作为索引，通过查找表纹理映射不同季节的特征。当灰度值变化时，系统会自动匹配对应的纹理信息，最终生成具有季节特征的图像效果。这种方法在计算机图形学中被广泛应用于环境贴图和材质映射领域。
Slide 90 — 00:51:08
📌 要点汇总
- 贴图去重需识别两种重复类型：美术团队未察觉的差异与玩家难以区分的视觉相似
- 自动化工具通过系统性遍历实现视觉相似度检测与资源归类
- 移动端采用算法合并视觉差异不显著贴图以优化存储与带宽
- 去重策略可减少冗余存储并保障视觉一致性，特别适用于移动端资源限制场景
贴图去重是游戏开发中一个非常经典的话题。在项目中经常会遇到大量视觉相似但未被美术团队意识到重复的贴图资源，这就需要借助工具对所有贴图进行系统性遍历，自动识别出视觉相似度高的重复资源。
这种重复可能表现为两种情况：一种是美术团队认为存在明显差异的贴图，另一种是玩家在实际使用中难以察觉差异的贴图。对于前者，工具可以帮助发现潜在的重复；对于后者，我们可以在移动端通过算法将视觉差异不显著的贴图归为同一类别进行处理。
通过这种自动化处理方式，既能减少美术资源的冗余存储，又能确保最终呈现效果在视觉上保持一致性。这种处理策略特别适用于移动端设备，因为其存储空间和带宽资源相对有限。
Slide 91 — 00:51:39
📌 要点汇总
- 基于Tiling贴图方案，优化后减少8%贴图资源
- Atlas贴图专项优化，智能去重算法精简10%资源
- AI视觉匹配技术，手机UI材质从50种精简至20种
- 智能匹配+分簇处理，提升资源利用率并避免视觉重复
课题就非常有意义了。然后一开始的时候，我们采用的是基于Tiling的贴图方案，这种实现方式相对容易上手。实际效果也非常显著，通过优化处理，我们成功减少了8%的贴图资源。
在Atlas贴图的处理上，我们针对不同岛的结构特征进行了专项优化。每个独立的岛单元都被单独提取出来进行对比分析，通过智能去重算法，最终实现了10%的贴图资源精简，这个优化幅度在实际项目中具有重要价值。
最后这个案例需要特别说明，通过AI视觉匹配技术，我们能够识别出具有相似特征的贴图素材。例如在手机端的UI设计中，原本需要呈现50种不同材质的小物件，经过智能替换后仅保留20种基础材质。这种优化策略在保证视觉效果的前提下，显著降低了资源冗余度。
通过这种智能匹配和分簇处理，我们成功将大量相似度较高的贴图素材进行替代。这种优化方案不仅提升了资源利用率，更在实际应用中有效避免了视觉上的重复感，为后续的美术资源管理提供了重要支持。
Slide 92 — 00:52:41
📌 要点汇总
- 替换小物件对整体布局影响有限，仅作为点缀存在
- 开发debug view功能，提升手机内存优化和画面渲染效率
- debug view方法在移动端与PC端游戏开发中广泛适用
- 2014-2015年Open Problem案例展示了解决方案落地过程
- 已完成超100项技术落地，突破行业瓶颈
- 邀请对Open Problem解决感兴趣者加入团队
我们在这个场景里边就实际的替换，这是原先的场景，这是替换之后的场景。其实大家看，变化主要体现在小物件上，这些物件并不影响整体布局，只是作为点缀存在，因此对整体影响非常有限。有时候美术人员甚至表示难以察觉这种变化。为此我们开发了一个debug view功能，通过这个视图可以清晰看到哪些元素被替换掉了。这种方式对手机内存优化和画面渲染都有显著帮助。这个方法在手机游戏与PC游戏开发之间普遍存在，是值得借鉴的解决方案。通过这种优化手段，我们能够为手机端带来可观的性能提升。
我今天分享的内容大致就这些。总结一下，我们首先探讨了一个从2014到2015年持续存在的Open Problem，这个案例可供参考。随后我们详细讲解了大量Open Problem的解决过程，并成功将这些方案落地到移动端。由于篇幅限制，目前只展示了部分案例。实际上我们针对这类行业难题已经完成了超过100项技术落地，这种勇于突破行业瓶颈的态度值得肯定。
如果各位对技术细节有进一步探讨需求，欢迎前往我们的展台交流。如果您也致力于推动游戏行业进步，希望通过解决Open Problem来推动技术创新，我们诚挚邀请您加入我们的团队。感谢大家的聆听。