技术美术谈工具、管线与工程化：让问题在发生前被拦住
你多年来参与过 AAA、AA、移动端和模拟项目。在如此广泛的平台与制作环境中，你的技术美术方法是如何演变的？
在职业生涯早期，我就已经在寻找节省时间、让工作流更可预测且更不容易出错的方法。即使在我专注于场景美术时，我也一直在构建小工具或流程来消除阻力。
随着时间推移，这演变成更多地从系统层面思考。尤其是在移动端和模拟项目之间工作，会迫使你尊重各种限制（内存、性能、迭代时间），而这种纪律也会延续到 AAA 项目中，在那里规模会放大每一个问题。
现在我的方法核心是构建能够预防问题的工作流，而不是等问题出现后再做出反应。如果某个东西反复出问题，那通常是管线问题，而不是美术师的问题。
你的职业生涯一直专注于构建工具和管线。你认为当今制作管线中最常见的低效问题是什么，你通常如何着手解决它们？
最大的低效问题在于缺乏可见性和结构不佳。团队往往直到某个问题已经影响性能或稳定性时才知道出了问题。除此之外，薄弱的项目组织（命名不一致、文件夹结构混乱以及缺乏有用的文档）会随着时间推移使这些问题进一步加剧。
- 我专注于同时解决这两个方面
- 将验证和反馈提前到管线更早的阶段
- 建立清晰的命名规范和文件夹结构
- 创建真正有用、得到维护且易于访问的文档
如果知识只存在于脑海中，它就会成为一种负担。当有人离开时，这些知识也会随他们一起离开。尽早把结构做对，日后会带来巨大回报。它能让团队保持一致，更快暴露问题，并使复杂任务变得可重复，而不是脆弱易碎。
你长期深耕虚幻引擎，还帮助过工作室从自研引擎迁移过来。团队在迁移过程中面临的最大挑战是什么？技术美术又能如何让这个过程更顺畅？
最大的挑战是思维方式，而不是技术。团队常常想方设法在虚幻引擎里重建他们原来的自研引擎，而不是去适应这个引擎本身的设计方式。这通常会带来不必要的复杂性。另一个挑战是，这些东西往往无法干净利落地一一对应。资产结构、工作流和系统各自的行为方式都不一样。
虽然我过去几年大量使用虚幻引擎，但我在职业生涯早期也深入使用过 Unity。在这两个引擎中，底层概念其实非常相似，只是呈现方式不同。我发现，给团队一份清晰的思维导图和可视化对照表，说明什么对应什么，会很有帮助，这样他们就能更快地建立这些联系。
技术美术可以通过以下方式让这个过程更顺畅：
- 把工作流转化为引擎原生的实现方式
- 尽早建立标准
- 在需要的地方构建衔接工具
目标是快速减少摩擦，让团队能够专注于制作内容，而不是与引擎较劲。
光照一直是你工作的一个关键领域。你如何构建光照管线，在艺术意图与严格的性能和内存预算之间取得平衡？
首先要尽早定义约束条件，并让它们清晰可见。如果没有关于灯光使用、阴影和材质响应的明确指南，光照可能会变得不可预测。我专注于建立这些基线以及可复用的设置，并确保光照美术对相关成本有良好的心智模型。一旦成本被清晰地定义，他们就能更有意识地、更准确地创作作品。
光照也是我最喜欢的领域之一，所以我尽量与团队保持亲力亲为。直接与光照美术合作可以建立主人翁意识，创造指导机会，并有助于确保我们在预算范围内与艺术方向保持一致。当约束清晰时，美术可以做出明智的决定，这时你才能真正提升质量而不破坏性能。
你曾使用 Unreal Insights 和 PIX 这类工具进行性能分析。你如何将这些工具中的数据转化为美术和设计人员可执行的改动？
原始的性能分析数据对大多数美术来说并不太有用。它太抽象了。关键在于把数据转化为可视化且可执行的内容。过去，我构建过自动化的性能遥测系统，按固定频率采集指标，然后与团队合作生成帧报告，把数据转化为图表、趋势和明确的目标。
与其说“这一帧开销很大”，不如变成：
- 具体是什么导致了开销
- 它存在于内容中的哪个位置
- 可以采取什么措施来修复它
这样能让美术师和设计师更容易理解，也能更轻松地向总监和利益相关者传达状态。
自动化在现代游戏开发中有多重要？你认为团队在哪些方面对其利用不足？
自动化至关重要，但仍然在很大程度上未被充分利用。许多团队默认采用人工操作，仅仅因为这是他们熟悉的方式。人们常常会认为“工具做不到这一点”，而实际上，它通常可以做到。我会花大量时间直接与美术师交流，了解他们工作流程中哪些部分繁琐或令人沮丧，然后构建工具来消除这些痛点。
这正是自动化最能发挥影响的地方：
- 重复性的设置任务
- 验证与清理
- 开发过程中的性能检查
没有什么比解决一个人们原本没意识到可以解决的问题更让人满足的了。你会收获很多“我不知道你还能做到这个”的反应，这通常是个好迹象，说明你关注的是正确的问题。
作为连接艺术与工程的人，你如何确保工具对艺术家友好，同时保持技术上的稳健和可扩展？
这归结为将界面与复杂性分离。底层系统可以按需做到稳健和可扩展，但面向用户的一侧应该简单直观。我尽量构建自带文档的工具（清晰的命名、提示信息和可预测的行为）。良好的文档仍然重要，但理想情况下，工具使用起来不应该需要太多解释。
我也会与艺术家紧密迭代。如果某个东西让人困惑或拖慢他们，它就会被简化。工具越直观，就越可能真正被使用。未被使用的工具不会提供任何价值。我还发现，艺术家、设计师和工程师非常喜欢工具被归类到容易找到/使用的地方。在这方面，我的首选是直接内置于编辑器中的自定义菜单。
展望未来，尤其是随着引擎、管线和实时渲染日益复杂，你如何看待技术美术角色的演变？
技术美术正变得越来越处于制作的核心，尤其是在管线层面。专家（灯光、渲染、VFX、动画）仍有空间，但对能从更大图景思考的人的需求正在增长：管线结构、工作流效率和可扩展性。
很多团队仍在因手动或过于复杂的流程而损失时间，而这些流程本可以大幅精简。有人专注于这一领域，会成为整个团队的效力倍增器。这是我最喜欢的领域：帮助团队更清晰、更高效地运作，并减少瓶颈。
最后，任何幕后、制作中或拆解风格的内容和作品，如果你能分享，我们的观众会非常想看一看。
我的大部分工作都发生在幕后的工具和管线开发中，所以它并不总能转化为传统的视觉拆解。话虽如此，我喜欢分享的一个例子是我构建的一个 Steam 更新器工具，它可以自动化部署和验证工作流。更重要的是，它有效地分摊了不断切换 Steam 分支的成本，这在迭代修复和向线上环境推送更新时节省了大量时间。它把通常具有破坏性的事情变成了工作流中可预测、低摩擦的一部分。
更广泛地说，正是这种思考促使我创办了 Damascus Interactive。在生产一线多年后，我意识到大多数团队并不是因为缺乏人才而苦苦挣扎。他们挣扎是因为摩擦。糟糕的管线结构、不清晰的工作流、缺失的工具，或无法扩展的系统。这些问题会随着时间推移不断累积，并悄悄消耗生产力。
这个工作室背后的理念就是直接解决这个问题：
- 找出团队在哪里浪费时间或与工具对抗
- 构建有针对性的解决方案来消除这种摩擦
- 留下能在工作完成后很长一段时间内持续提供价值的系统
这一理念的很大一部分在于，它不仅仅是为了帮助团队更快地交付。它关乎帮助团队打下更坚实的基础。工具、管线和流程应当让开发更具可预测性，而不是更混乱。这也是为什么这种方法非常注重生产实践并且强调协作。它始于理解团队实际是如何运作的，然后构建契合这一现实的解决方案，而不是强行套用某种过于复杂或理论化的东西。
我已经开始公开分享其中一部分工作，包括代码示例和工具化方案，让人们了解我是如何思考解决这类问题的。
喜欢这篇内容吗？