《万象敦煌：秘宝与黄沙》是一个运行在背包电脑上的大空间 VR 项目。我当时担任执行主美，负责 CG 内容生产管理，协调模型、地编、特效、动画、角色与 TA 的工作，也参与了部分引擎效果和性能优化。整个开发周期大约半年。

项目里比较难处理的是场景规模和角色表现。沙州城需要有足够的建筑，远处也不能显得空；主要角色会出现在观众面前，盔甲、服饰和面部表演都要保留。随着内容增加，背包电脑的性能压力也越来越明显。

后期做了不少调整，包括建筑实例化、远景合并、地表材质优化，也有需要和程序一起排查的问题。这篇就结合我参与的部分，聊聊当时怎么处理，以及现在回头看还有哪些地方可以改进。

几项主要调整

先用一张表把几项主要内容列出来，后面再分别说明。

建筑模块的复用和整合

沙州城用了不少可复用的唐代建筑模块。我们先在蓝图 Actor 里把模型块拼成完整建筑，再复制、调整和布置。对地编来说，这比每次从零搭一栋房子方便得多。

不过，蓝图复用主要方便的是制作和摆放。里面有多少网格组件、材质槽，哪些部分需要投影，还是要另外检查。复制一栋建筑，并不会自动把这些内容合成一次绘制。

当时团队做过重复构件的实例化，也做过建筑和远景合并。下面这张示意图把它们和前面的蓝图复用放在一起，方便说明各自的作用。

建筑处理思路示意

1. 组合建筑模块

   在蓝图里组合模型，方便重复布置和修改。

2. 实例化或远景整合

   重复构件考虑实例化；远景另做合并、简化与材质整合。

3. 检查效果和性能

   从实际观看位置检查轮廓、层次和渲染开销。

处理思路示意。实例化和远景整合需要根据资产用途选择，不必每栋建筑都做一遍。效果和性能检查最好贯穿制作过程。

实例化适合符合条件的重复网格；合并把一组对象整理成组合资产；简化与材质整合则继续处理几何、材质槽、贴图和 UV。对象数量减少了，如果材质槽原样保留，绘制开销未必跟着等比例下降。

具体可以参考 Epic 的 Actor 合并文档。文档用于补充说明原理，具体工具以所用的引擎版本为准。

远景建筑的简化

沙州城需要通过远景表现城市的规模。虽然观众不会走到每一栋建筑旁边，但屋顶的高低、建筑的疏密和前后层次还是能看出来。

我们对部分远景建筑做了静态网格整合、几何简化和材质贴图整合，减少材质槽。对画面影响不大的远景投影，也会考虑关闭。我的想法是先处理远处看不清的细节，尽量保留建筑群的整体效果。

比如窗棂一类的细节，远距离下可以简化；屋顶轮廓和建筑之间的层次则需要多看几遍。简化之后还是要从观众的观看位置检查，不能只在资产窗口里看。

现在回头看，合并范围也值得单独检查。合并后的包围盒变大，剔除粒度会跟着改变，原本可以单独剔除的部分可能继续参与渲染。如果再做类似场景，我会按街区或同时可见的建筑组分别测试，再决定合并到什么程度。

主要角色和路人的区别

项目里有主要表演角色，也有配角和循环动作的路人。主要角色需要动作和面部表演，身上的盔甲、服饰也会被近距离看到，和环境中的路人要求不一样。

后期有些角色已经减过一轮，再减就比较容易影响轮廓和装饰细节了。我觉得这时候要结合角色的用途看：主要人物离观众近，细节需要保留；路人更多是配合场景，可以考虑简化。

角色的开销还包括骨骼蒙皮、面部形变、动画更新、材质和阴影。多个人物同时表演时，需要和动画、程序同事一起看具体耗时。模型已经压得比较低的情况下，继续减面可能改善不大。

地表材质与灯光

地面有沙、泥土、湿润地表和草地等混合效果。我参与过这部分多层材质的优化，也结合贴图规格、材质槽和场景整合控制开销，同时尽量保留不同地表区域的变化。

这里需要区分绘制提交和材质计算。减少材质槽、整理对象，主要是在处理提交方面的开销；混合层、纹理采样和计算复杂度，还要到材质里检查。合批之后，材质本身的计算量可能并没有减少。

如果现在重新检查，我会先比较主行走区域和远景的材质。远处的湿润变化是否需要做得这么细，有些混合层能不能换成更简单的遮罩，这些都可以单独对照效果再决定。

灯光方面，当时有烘焙光照，也有实时光照。远景中不明显的投影可以考虑关闭，主要人物和周围环境的明暗关系则需要保留，避免角色和场景看起来不协调。另外，物件设为静态之后，网格、材质和贴图仍然有运行开销。

和程序一起排查性能问题

项目后期，除了美术资源的调整，也有一些 CPU 侧的性能问题需要和程序同事一起排查。模型、材质改到一定程度后，如果运行仍然不稳定，就需要进一步确认耗时出在哪个环节。

排查时需要先看主要耗时在游戏线程、渲染线程还是 GPU。如果瓶颈在 CPU 侧提交，继续降贴图分辨率可能帮助有限；如果是 GPU 的着色或阴影成本，就要检查对应的材质、像素覆盖和渲染设置。线程之间也会互相等待，单个数字偏高还需要进一步定位。

VR 还需要看帧时间是否稳定。平均 FPS 提高了，转头、角色集中表演或切换场景时仍可能出现明显波动。Epic 的 VR 性能测试文档里有相关说明，实际测试还要戴上头显，沿体验路线检查画面与响应。

后续项目的制作规范

敦煌的制作经验也影响了后续项目的资源要求。例如，后续项目的场景制作规范将同屏 20 万面、Draw Call 300 以下列为制作预算，并要求为灯光和特效预留空间。这类预算需要结合目标设备、渲染路径和具体场景使用。

场景制作时就要考虑后面还有角色、灯光和特效接入。环境资产如果已经占满预算，其他内容加进来以后，往往又要回头调整模型和材质。

规范中还要求尽量复用相同网格和材质实例，通过位置、旋转、缩放形成变化，并控制材质槽。建筑在制作阶段就按这些要求组织，后面做实例化和资源整合会方便一些。

三维资产的制作要求、第三方资源接入和目录命名，也需要提前约定。不同工种按统一要求交付，能减少导入引擎后再改规格、整理资源的工作。

关于测试和记录

如果再做类似项目，我会建议更早把典型建筑群、主要角色和复杂地表放到目标设备上一起测试。等大部分内容做完再集中调整，很多地方就不太好改了。

记录这件事也需要提前考虑。做项目时很容易顾不上，事后再整理，有些细节就记不清了。我觉得可以先从每次关键改动开始，留下一份简短记录：

• 条件：构建版本、PC 与头显、刷新率、分辨率和质量设置。
• 场景：同一条路线、观察位置和触发状态，注明角色、灯光与特效是否同时出现。
• 改动：这次具体动了什么，尽量分项比较，避免一次改完后猜收益来源。
• 观察：相关线程与 GPU 耗时、帧时间波动，以及头显里的画面和响应。
• 代价：轮廓损失、闪烁、突变、剔除变差或后续修改变难，都和收益一起留下。

把测试条件、具体改动和结果放在一起，后面复查时才比较容易知道差别是怎么来的。

更多项目画面与视频见 《万象敦煌：秘宝与黄沙》作品页。