如何为移动游戏创建低多边形模型:多边形预算、工作流程与优化
移动游戏的多边形预算限制严格。学习如何为移动设备创建优化的低多边形 3D 模型,涵盖分设备三角形预算、Blender 重拓扑工作流程、LOD 设置,以及 iOS 和 Android 的绘制调用优化。
您创建了一个角色模型,将其导出到 Unity,打包成 Android 版本,但在 Pixel 6 上帧率却跌至 22 FPS。该模型仅有 8,000 个三角形。
这就是没人告诉你的部分。一个8000个三角形的角色看起来偏低。在桌面端游戏中,确实如此。但在移动端,多边形数不是你应该紧盯的数字。在三角面数变得重要之前,绘制调用和填充率早就影响了场景性能。模型需要的不仅仅是更少的三角形。它需要一个性能指标预算,以及从一开始就为移动端构建的导出管线。
读完本文后,您将拥有一份立即可用的多边形预算表、一个从 Blender 到游戏引擎的分步工作流程,以及区分移动端与桌面端版本的特定 LOD 和材质合批规则。
为什么移动平台重塑了低多边形建模规则
移动端真正关键的三个指标
三角形数量是新手常看的指标。它并不是导致移动端性能崩溃的数字。
像素填充率受限于像素预算。中端 Android GPU 每帧能处理的像素数量仅为桌面级 GPU 的四分之一左右。在 RTX 显卡上渲染良好的同一模型,在移动 GPU 上会出现过度着色(overshade),这意味着 GPU 在每个像素上消耗的周期数超出了其预算。模型本身并不过于复杂,问题在于渲染的像素数量过多。
绘制调用是 CPU 向 GPU 发送的命令。移动设备的 CPU 受限于功耗,而非时钟频率。您无法像桌面端那样向移动端 GPU 发送同等数量的绘制调用。网格上的每个独立材质都会触发一次绘制调用。一个拥有五个材质槽位的主角模型,在计入环境开销前便会占用五次调用。
Setpass 调用在移动端的性能开销比 Draw Call 更大。当 Unity 切换 Shader 时,会触发一次 Setpass,其开销是标准 Draw Call 的三到四倍。在 Android 设备上,若一个场景产生 80 次 Draw Call 并分布在 12 次 Setpass 中,其帧率会比相同数量的 Draw Call 仅分布在 2 次 Setpass 中的情况低约 10 FPS。因此,比起关注三角形数量,应优先通过减少材质数量和合批来解决此问题。
移动端性能预算
新手移动游戏开发者常犯的最大错误是将手机硬件视为单一目标。Pixel 7 和入门级三星 A 系列并非同一款设备,其硬件配置差异巨大。你需要采用分层预算策略。
资产类型 | 经济型手机(低于200美元) | 中高端 ($200–$500) | 旗舰产品($600+) |
|---|---|---|---|
路人 NPC | 300–500 tris | 500–1,000 个三角面 | 1,000-2,000 三角面片 |
配角 | 1,000–3,000 TRIS | 3,000–5,000 个三联体 | 5,000–10,000 特里斯币 |
英雄角色 | 5,000 – 10,000 三角形面片 | 10,000–20,000 特里斯 | 20,000——30,000 三角面片 |
小道具 | 50–150 次 | 100–300 个三角面 | 200—500 三角面 |
环境物件 | 200–1,000 个三角面片 | 500–2,000 TRIS | 1,000-4,000 个三角面片 |
Android 开发者团队在其于 GAMESCon 上展示的 Armories Demo 中提供了一个实用的真实性能基准测试案例。该演示中的人群角色面数约为 360 个三角形,整个场景在中端硬件上能稳定维持 60 fps。这并非极端的低多边形标准。当先设定预算并据此制作美术资源时,这正是移动游戏场景在实际开发中的典型表现。
帧预算的概念很简单。在 60 fps 下,每帧有 16.6 毫秒。GPU 大约占用其中一半的时间用于渲染场景。每一次顶点着色器调用、每一次像素着色器调用以及每一次纹理采样都受限于该时间窗口。如果模型包含过多材质,CPU 端甚至在 GPU 端开始之前就会成为瓶颈。
移动游戏开发低多边形建模流程
设置Blender用于移动设备导出
启动 Blender 并检查单位比例。打开场景属性,确认单位比例设置为 1.0,且单位系统为公制。移动端引擎默认以米为单位;若 Blender 与引擎之间的比例不匹配,会导致在 100 倍比例的模型上触发高强度的纹理过滤,从而造成隐性的帧率损耗。
将 FBX 导出预设设置为与目标引擎匹配。在“几何体”下,将“平滑”设置为“面”,以避免导入时拆分顶点。勾选“应用缩放”并将其设置为"FBX 单位比例”。对于 Unity,请将“前方向”保留为 -Z,“上方向”保留为 Y。
导出前需仔细检查法线。请启用“自动平滑”并将角度设为30度。这样既能保持硬边清晰,又不会导致大量不必要的边拆分。避免在移动端模型上使用倒角修改器。每个倒角边都会增加三角面数,并在导入时产生更多边拆分。建议改用硬边标记,让引擎在构建时自动合并这些顶点。
在三角形数量限制内生成网格
移动端的角色拓扑遵循与桌面端相同的规则,但间距更窄。建模时使用四边形以利于变形,并导出为三角形供引擎使用。导入时每个四边形会被拆分为两个三角形,因此构建时需预设按三角化后的实际面数进行规划。
对于一个 3,000 面的次要 NPC,应按头、躯干和四肢的比例来规划。头部约分配 500 个面,躯干 1,200 个,每只手臂 300 个,每条腿 350 个。这并非硬性规定,但能帮助确定细节的分配重点。如果脸部有 300 个面而身体只有 100 个,比例会显得失调。应根据在屏幕上的尺寸按比例分配细节。
道具是新手最容易浪费三角面预算的地方。一个简单的板条箱、一盏灯笼、一个木桶,每个都不需要超过150个三角面。每个都用盒子建模。如果从玩家距离看它像圆柱体,每条水平边只需增加六个额外顶点,而不是32个。
环境组件应以模块化方式设计。构建共享相同材质的墙段、地砖和柱基。一座使用单一材质、包含200块墙体组件的寺庙仅增加1次绘制调用(draw call)。而同一座寺庙,如果其200块墙体组件使用了10种不同材质,则会增加10次绘制调用。游戏会检测到加载时间和帧 pacing 的差异。
移动端UV展开
移动 UV 映射遵循一条规则:每个网格的每种材质对应一个 UV 岛。有关包括 UV 岛策略在内的拓扑结构最佳实践指南,请参阅我们的专属指南。请勿将 UV 岛分散在纹理上。将面部和身体分别设为单个 UV 岛,可使纹理图集排列更紧凑。
在移动设备上,当两个相同道具/物体的副本共享纹理空间时,重叠的UV是可以接受的。这能释放内存,但仅适用于两个物体顶点数据完全相同的情况。一块岩石复制20次并原地旋转可以共享UV空间,但经过缩放或形变处理的岩石则无法实现。
2的幂次方纹理尺寸在移动端的重要性高于桌面端。道具建议使用512x512分辨率,次要角色使用1024x1024分辨率,仅在主角角色上使用2048x2048分辨率。GPU纹理采样器按2的幂次方块进行工作,非2的幂次方纹理会因填充数据而浪费内存带宽。
如何无损优化移动端 3D 模型
通过材质批处理减少绘制调用
Draw Call 是移动端的性能瓶颈,而讨论多边形数量的文章几乎从未提及这一点。单个使用五种材质的网格会产生五次 Draw Call。五个共享同一种材质的网格则只产生一次 Draw Call。计算就这么简单。
首先清点你的材质数量。场景中保留的每个PBR材质都是每帧的绘制调用(draw call)。当纹理差异较小时,请合并材质。两块使用不同棕色噪声纹理的岩石可以共享一个使用单一噪声纹理的材质。在正常游玩距离下肉眼难以察觉差异。
Unity 的 静态批处理会在打包时将标记为静态的网格合并为更大的网格。从不移动的静态对象,包括墙壁、地板和大型环境部件,都应使用静态批处理。构建时间会稍长几秒,但每帧耗时会立即减少。
GPU 实例化对相同网格体的处理方式不同。它不是合并顶点数据,而是通过单个命令告诉 GPU“在多个位置绘制此网格体”。GPU 实例化适用于那些由相同网格体构成、仅经过旋转和缩放的树木、岩石和板条箱。Unity 会在支持该功能的着色器上默认启用它。请检查材质检视器,确认已勾选“启用 GPU 实例化”。
中端移动设备上的游戏,其实际目标是每帧的绘制调用次数控制在100次以下。在桌面端需要300次调用才能呈现现代视觉效果的游戏,在移动端需将相同场景压缩到80次调用以内。若Unity性能分析器中绘制调用次数超过150次,应首先合并材质,而非减少多边形数量。
移动设备纹理优化
纹理压缩是移动端与桌面端管线存在根本差异的领域。关于3D文件格式对比(包括纹理图集策略和平台原生导出)的详细拆解,请参阅我们的指南。桌面端使用BC7和BC5格式,而移动端硬件则读取ASTC(适用于Android 8+及iOS设备)或ETC2(适用于旧版Android设备)。完整格式详解请查看Android纹理压缩指南。请使用平台原生格式导出纹理,不要使用BC7。
将纹理分辨率设置为满足要求的最低质量。在最近的观察距离下,一个在屏幕上占据 200 像素的道具并不需要 2048x2048 的纹理,它只需要 256x256 的纹理。与具有完整 mip 链的 2048 纹理相比,其内存占用减少了 99%。
法线贴图的分辨率通常应为基础颜色纹理的一半。1024x1024 的基础颜色贴图对应 512x512 的法线贴图。这样可以节省内存,而 GPU 不会感知到细节丢失,因为法线贴图在像素着色器中已经进行了插值处理。
为移动游戏设置 LOD
何时在移动端使用 LOD
LOD 并非零成本。CPU 每帧都会计算 LOD 层级切换。在包含 5 个角色的场景中,这些计算的开销超过了其节省的资源。相比之下,在包含 50 棵树或 30 个可见 NPC 的场景中,LOD 的收益明显。
在以下情况下使用 LOD:场景中同时可见 20 个及以上角色或道具、游戏过程中摄像机距离变化较大,或目标硬件为入门级手机。
无需使用LOD的情况:摄像机位置固定、角色很少进入场景,或全细节状态下构建成本已低于预算。
在大多数移动游戏中,环境 LOD 的见效速度比角色 LOD 更快。一片包含 50 棵树的森林采用两级 LOD:近处树木保持完整细节,远处树木则简化为由 4 个三角形组成的 billboard 卡片。这样可将 50 次 Draw Call 压缩至 2 次,且从常规视角观察时不会造成可见的质量损失。
移动端注意事项:LOD切换会强制GPU重新绑定网格,每次切换大约消耗一次绘制调用。20个同时发生的突发切换可能导致帧时间出现尖峰。请务必在最低目标设备上进行性能分析。Unity编辑器的性能数据不具参考性。
Unity 和 Unreal 中的 LOD(层级细节)集群运作机制
细节层次系统会自动将远处的网格(mesh)替换为更简化的版本。Unity 将其称为 LOD Group,Unreal 也使用相同名称。该系统对角色、道具和环境资产的处理方式完全一致。
Unity的LOD Group默认定义了四个级别:
等级 | 三角形数量 | 当它激活时 |
|---|---|---|
LOD 0 | 100%(全网状) | 离镜头最近 |
LOD 1 | 50% | 中距离 |
LOD 2 | 25% | 遥远的距离 |
LOD(细节层次)3 | 10% 至 12% | 最远可视距离 |

在 LOD Group 组件上设置屏幕高度百分比,以控制每个层级的激活时机。Unreal 还提供了层级化 LOD (HLOD) 功能,可在远距离时将多个网格体替换为一个合并后的网格体。有关配置步骤,请参阅 Unreal HLOD 文档。该功能在移动端尤为实用,例如当地平线处包含 30 栋建筑的整个村庄可合并为单个网格体时。而 Unity 则通过 GPU Instancing 来处理此类场景,其设置复杂度较低。
导出设置与引擎导入设置
6个步骤从Blender导出适用于移动端的FBX文件
使用错误的 FBX 设置导出会导致网格文件体积增大并丢失材质引用。具体步骤如下:
- 打开文件 > 导出 > FBX (.fbx)。查看 官方搅拌机 FBX 导出指南有关完整选项参考。在"包含"部分,仅勾选"选定对象"。取消勾选任何非网格(mesh)对象类型。
- 在“变换”设置中,将缩放设置为 1.0 并选中“应用缩放”。在 Unity 中,请将前方设置为 -Z,上方设置为 Y。
- 在“几何体”部分中,勾选“应用修改器”。这会将镜像、细分和阵列修改器烘焙到导出数据中。将“平滑”选项设置为“面”。
- 对于静态网格体,请取消勾选“离场动画”。静态箱体不需要默认动画轨道,以免使导入文件大小翻倍。
- 将切线空间设置为生成。在 FBX 中生成切线可省去导入时的计算步骤。单网格差异虽小,但在大量资产中将显著累积。
- 导入到 Unity。若模型大小符合预期,请将模型缩放因子设置为 1。如果模型大或小 100 倍,请返回 Blender 并以正确的单位缩放重新导出。
在导入角色批次之前,请使用单位立方体测试确认比例。在 Blender 场景中放置一个 1m 立方体,将其导出为 FBX 格式并导入 Unity。场景中的宽度应显示为 1m。如果显示为 100m,则单位缩放设置错误,批次中的所有网格都需要进行修正。
导入 Unity 用于移动平台
在Project面板中右键点击FBX文件并打开模型选项卡。如果模型看起来正确,将比例因子设置为1。如果模型尺寸大了100倍,请返回Blender并按正确单位比例重新导出。
在“网格压缩”下,将其设置为“高”。这会对大型网格使用 64 位索引,对小型网格使用 16 位索引。在移动设备上,使用 16 位索引能优化绘制调用性能,因为 GPU 索引缓冲区可降低内存带宽占用。
取消勾选 Read/Write Enabled。Unity 在加载时会将网格数据复制到 GPU 内存中。启用 Read/Write Enabled 时,Unity 还会在 CPU 端保留一份副本。对于在运行时不会修改的静态网格而言,这份 CPU 副本是不必要的内存开销。
在优化选项中,勾选“优化网格”。Unity会重新排序顶点以提升GPU缓存利用率。在顶点缓存容量较小的移动GPU上,这种重新排序可将像素着色器处理时间减少10–15%。
移动端常见的低模误区
过度细化主角设计
主角模型在初次处理时总是面数过多。关于低多边形与高多边形资源分配在不同平台上的差异,请参阅我们的低多边形与高多边形3D模型指南。
一个拥有雕塑般颧骨、单根睫毛和链甲圆环的面部模型,在教程指导下其面数已达15,000,而此时身体部分尚未开始制作。在移动设备上,15,000个三角面已让场景几乎没有余量添加其他内容。
在建模前设定角色面数预算并严格遵守。如果预算为 10,000 个三角面片,则头部分配 3,000,身体分配 4,000,每个肢体分配 500。将这些数值记录在笔记中,并依据预算从头构建,而非从高模雕刻入手。
未考虑材料数量
一个使用10种材质的低模、低面数英雄,性能反而不如一个仅使用2种材质的高模、高面数英雄。移动端GPU处理三角面的能力优于处理绘制调用。即使三角面数量多出三倍,仅使用2种材质的英雄运行速度也更快,因为引擎只需发出2次绘制调用,而非10次。
解决方案是使用纹理图集。将整个角色的漫反射贴图、法线贴图和组合贴图整合到一个图集中。一张 2048x2048 的图集配合单一材质,仅需 1 次绘制调用即可渲染角色。而五张独立的 1024x1024 纹理配合五种材质,则需要 5 次绘制调用以及 5 次 SetPass 状态切换开销。请参阅我们的适配游戏的 3D 模型指南,获取关于符合游戏标准的质量在实际项目中的完整检查清单。
未针对目标硬件进行测试
Unity 编辑器在桌面硬件上运行。桌面 GPU 不同于移动 GPU。在编辑器中以 120 fps 运行的场景,在真机上可能仅以 22 fps 运行。
Unity 的性能分析器按 CPU 时间、GPU 时间和内存显示帧耗时细分。通过 ADB 连接 Android 设备,在性能分析器目标下拉菜单中选择该设备,然后运行场景。查看渲染部分以检查绘制调用、SetPass 调用和批处理。
Android 的 GPU Profiler 可提供每帧的顶点和像素着色器时间统计。如果当角色面向摄像机时像素着色器时间出现尖峰,则该帧的过度绘制过高。修复方法是减少材质数量或简化着色器,而非减少三角形数量。
使用Triverse AI工具生成低面数手机游戏素材
概念迭代是手游项目的时间黑洞。角色简报要求“蒸汽朋克矿工,手臂发光”,美术师却花了两天建模,结果设计师并不买账。模型虽已达到可交付标准,却因外观不符而遭弃用。
Triverse AI 的Artist Mesh工作流能够在全流程启动前精准锁定概念剪影。
步骤 1:上传参考图或草图
打开 Triverse Studio 并选择 Artist Mesh。拖拽或粘贴 PNG、JPG、JPEG 或 WebP 图像。粗略的概念草图或清晰的剪影照片均适用。
步骤 2:选择顶点数量并生成
选择 三角面或四边面拓扑结构。根据您的移动端性能目标选择合适的顶点数量预设:背景道具选 1K,标准道具选 2K,重点道具或精细角色选 4K。点击“生成”。25 积分的生成通常在一分钟内即可完成。

步骤 3:根据需要检查并添加贴图
Artist Mesh 生成一个供您立即评估比例、姿势和整体形状的网格。如果轮廓不正确,请删除并重新生成。仅需 25 积分和数秒时间,而无需耗费两天进行手动建模。

步骤4:导出并确定是否需要在Blender软件中精修
将概念导出为GLB或OBJ格式并导入Blender,以获得正确的拓扑流和变形,同时应用前面章节的优化规则。生成的网格结果是一个起点,而非最终游戏资产,但它使概念阶段从数天缩短至数小时。
关于移动游戏低多边形模型的常见问题
核心要点
移动端3D开发最大的教训是:三角形面数并非头号敌人,Draw Call才是。在打开Blender之前先设定好多边形预算,严格按照预算构建,并花更多时间合并材质,而非削减顶点。当场景中有足够多对象,足以抵消CPU开销时,LOD才会发挥作用。请在你目标市场的最低配置设备上测试,而不是在桌面编辑器里。本文其余内容都是细节,上述优先级才是核心框架。此外,你可以直接使用Triverse AI的Artist Mesh功能,一键快速生成自定义风格化低多边形游戏模型,限时内下载模型免费!


