游戏开发中 3D 背景数据如何从 Maya 到 Unity 逐层检查

引言

游戏用的3D背景在Maya中完成模型时，并不一定就已经成为“可在游戏中使用的数据”。

即使模型的形状和外观没有问题，如果在Unity中的设置、碰撞体或实际游玩时的视觉效果存在问题，也需要进行修正。

我以前负责过一个智能手机游戏项目，将大量背景数据外包给外部制作方。背景数据共155张地图。检查工作主要由我一人承担，忙碌的时候一天最多要在游戏内确认20条路线的量。

本文按Maya → Unity → 游戏运行 → 修改请求的顺序，整理当时实际进行的检查。本文并非全面覆盖Maya和Unity操作步骤的文章，而是总结在哪个阶段、确认什么、为什么确认这一实务上的思路。

※这里介绍的是某个项目中的一个示例。所需项目和设置值会因游戏规格和开发环境而有所不同。

检查大致分为4个阶段

我进行确认时，大致遵循以下流程。

1. Maya数据检查：模型结构和制作规则是否正确
2. Unity数据检查：导入的资产和各种设置是否存在问题
3. 游戏内检查：实际操作时，是否已成为可游玩的背景
4. 修正请求与再确认：具体说明问题所在及修正方法

重要的是，不是在最后才统一查看，而是在容易发现问题的阶段进行确认。

首先要看的，不仅仅是外观的好坏。

• 模型结构是否符合制作规范？
• 模型名称、材质名称等命名规则是否得到遵守？
• 是否残留了不必要的数据？
• UV 和光照贴图 UV 是否符合预期？
• 颜色集和顶点颜色是否正确导入？
• 形状是否符合碰撞数据的设计？

尤为重要的是，碰撞与外观的一致性。

玩家行走的部分是基于游戏端的碰撞来确定的。无论地形多么精美，如果可行走范围和外观差异过大，在游戏中就无法使用。

此外，如果Maya一侧的数据结构从根本上不同，那么在Unity上完成设置后会产生大量的返工。因此，在量产初期，我们要求外包方先提交Maya数据，确认没有问题后再进行Unity的工作。

根据最初的确认结果，改变检查流程

在这个项目中，最初提交的数据精度很高，是严格按照规格说明文档和示例数据来制作的。

因此，从第二个开始，我们省略了先单独确认 Maya 数据的环节，改为让提交方将 Maya 数据和 Unity 数据一并提供。

当然，并不是不再确认 Maya 数据本身。因为通过第一个数据确认了制作方法的根本方向是正确的，所以我们调整了流程。

处理大量数据时，如果始终用同样的密度去检查所有内容，确认方的工作就会陷入瓶颈。为了把时间花在容易出现问题的部分上，对检查流程进行重新审视是必要的。

2. 在 Unity 中确认的事项

Unity 包到达后，并不是马上运行游戏。首先，确认新添加的数据和设置。

• 文件夹结构是否正确？
• 模型、纹理、材质的命名是否符合规范？
• 纹理的压缩设置是否合适？
• 材质设置是否与规格说明书一致？
• 对象的 Static 设置和 Layer 设置是否正确？
• 光照探针的放置间隔是否有问题？
• 光照贴图的大小和外观是否有问题

对于手机游戏来说，数据容量和渲染负载也是重要的条件。

如果纹理的压缩设置或光照贴图的大小不合适，不仅会影响外观，也会影响文件容量。如果文件夹和命名混乱，当数据增多时就难以确定需要修改的对象。

每一项单独来看都不起眼，但产量越大，逐项确认的意义就越大。

\n 3. 在 Unity 中运行游戏进行确认

确认完数据后，实际运行游戏，让角色走动。

确认的内容例如包括以下几点。

• 能否从起点沿路线前进
• 分支或战斗区域附近是否存在不自然的地方
• 是否存在看似可以通过但实际上无法通行的地方
• 反过来，是否存在看似无法进入但实际上可以进入的地方
• 碰撞体和背景模型的位置是否存在较大偏差
• 检查开始、通关等演出镜头是否会出现背景内侧或穿模

在Scene视图中看起来美观，与在游戏中能自然游玩，是两回事。

在本项目中，基本上是将5条路线的内容汇总到一个Maya数据文件中。作为Unity包大约相当于4张地图的量，但在游戏内需要逐条步行确认20条路线。

写成“每天最多确认20张地图”容易被误解，准确地说，是每天最多确认20条路线。

4. 实际找到的修正案例

UV接缝

本次的背景场景是将预制好的部件组合起来构建地形，然后再重新展开UV的制作方式。

这时候，纹理的接缝往往会比较明显。尤其是墙面，在某些摄像机角度下，甚至比地面更引人注目。

因此，我们要求将UV的切割线尽可能移到容易形成凹陷或阴影的位置。

不是简单地"请把UV做得干净一点"，而是要告知哪些接缝比较显眼、应该往哪里藏，这一点非常重要。

顶点颜色缺失

在这个项目中，Unity端的着色器使用了顶点颜色。因此，如果Maya端的顶点颜色缺失，Unity上就可能无法呈现出预期效果。

有些问题只在 Maya 中查看时不易发现，因此也需要在最终显示环境中进行检查。

5. 修正指示要能传达"具体改什么"

发现问题后，将修正内容反馈给外包方。

这里要避免的是"做得好看点""再自然一些"这类含糊的指示。

我意识到的要点如下。

1. 用截图标出有问题的位置
2. 在相应位置画上圆圈等标记
3. 写明问题所在
4. 具体写明希望如何修改
5. 如有需要，由我方准备好修正版的模型或纹理

尤其是第 4、5 点，我们非常重视。
例如，如果指示为"请再亮一些"，不同人对"再一些"的程度理解不同。
因此，如果可能的话，先自己调整一次纹理，确认达到预期亮度后，再以具体数值传达，例如"请将此纹理的亮度提高 10"。
此外，对于仅凭数值难以传达的修改，我方有时也会将修正后的图像或数据作为示例提供给对方。

关键在于，使对方能够不犹豫地按照我方的意图完成修改。

一旦来回沟通发生好几轮，仅此就会拖慢量产的速度。有时甚至由这边制作修正数据并交给对方会更快。

外包检查的目的并不是指出缺点，而是让数据达到可用于游戏的状态，并且不阻断量产的流程。

总结：完成数据并不是“制作”完就结束了

本次确认中重视的是以下几点。

无论模型制作得多么精美，如果无法在游戏中正确使用，就不能说是完成的。

在Maya中制作，在Unity中设置，运行游戏并确认。在这个过程中进行必要的修正，最终使其达到可以在游戏中使用的状态。

在3D背景制作中，不仅需要制作的能力，还需要确认的能力。