做项目最痛苦的一件事，就是在“人群”上翻车。你满怀信心地把城市NPC、军队士兵、街上的行人做成一套逻辑，结果一进游戏，同屏超过一两百个，CPU的骨骼更新直接红温，GPU蒙皮带宽也扛不住，帧数哗哗往下掉。你开始砍骨骼、减顶点、削动画采样率，折腾一圈回来，画面也降级了，性能还是不够。

所以当我第一次接触 Mesh Animation Baker 这类思路时，第一反应是：这个方向终于对了。它和传统 SkinnedMeshRenderer 完全是两条路，核心做法是提前把骨骼动画“烘焙”成网格顶点数据，运行时不跑任何骨骼计算，直接让 GPU 按时间轴播放顶点动画。配合 Instanced Indirect 渲染，一个 DrawCall 画几百上千个动态角色不再是做梦。

这篇内容我会从原理、烘焙流程、Shader 实现、性能取舍到踩坑经验，完整拆解这套 GPU Optimized Crowd Animation 的技术方案。适合正在做开放世界、模拟经营、战争题材、城市NPC 同屏优化的技术美术和图形程序员参考，有些代码和配置细节可以直接抄走用。

1. 为什么要把动画“烤”进网格里

很多人第一次听到“顶点动画烘焙”时，第一反应是：这不等于是退回十年前的做法吗？早期的引擎做不了骨骼动画，才会用顶点动画。但这里有个关键区别——我们不是放弃骨骼动画，而是把骨骼动画的“计算结果”在离线阶段全部算完，让运行时不再重复计算。

烘焙的意义在于，把“计算”和“播放”解耦。传统 SkinnedMeshRenderer 的动画链路里，每一帧都要做：动画状态机更新 => 骨骼矩阵计算 => 蒙皮计算。这个链路在小规模角色下没问题，但人一多就完蛋，因为 CPU 需要处理成千上万根骨骼的矩阵运算，GPU 端每个顶点还要做一次蒙皮权重累加。这套流程本身就是为“少量精细角色”设计的，不是为“千人同屏”设计的。

而 Mesh Animation Baker 的思路是：在编辑器里，把所有动画帧的顶点位置、法线、切线全部预先采样，写成一张或多张动画纹理。运行时，Shader 根据当前动画时间，从纹理里读出顶点的新位置，直接替换网格原始顶点。骨骼、权重、动画状态机全部不需要了。

1.1 骨骼动画的成本到底高在哪

先算一笔账，你就知道传统管线有多亏。假设你有 200 个角色，每个角色 30 根骨骼，角色动画 30 FPS 更新。CPU 每帧要完成的骨骼矩阵计算量就是 200 × 30 = 6000 个矩阵变换。这个数字看着不多，但你还要算上 AnimationClip 的采样、状态机切换、事件回调，还有每个角色各自的 Transform 层级依赖。一旦角色数量上了千，CPU 的负担根本不是线性增长，而是拖慢整个游戏主循环。

GPU 端的蒙皮也不轻松。传统的 SkinnedMeshRenderer 在每个顶点上都要执行权重矩阵混合，虽然 GPU 并行处理很强，但蒙皮计算消耗的是 ALU 和带宽。顶点越多、骨骼权重通道越多，开销越大。更致命的是，每个角色至少一个 DrawCall，哪怕你用 GPU Instancing，骨骼动画的实例化处理也比顶点动画复杂。

在这种背景下，“先算好、再播放”的方案就显得非常合理。因为动画本身是确定性的，同一个 Clip 在相同时间点，顶点位置永远一样。那为什么不在离线时把它烤出来，运行时直接查表？

1.2 用空间换时间：烘焙方案的核心逻辑

烘焙的本质是典型的空间换时间。原本运行时需要 CPU 算骨骼矩阵、GPU 做蒙皮，现在这些计算全部提前完成，运行时要做的就是：根据时间采样纹理，拿到顶点数据，渲染。这换来的优势很明显：

• CPU 侧几乎零动画开销，不再需要骨骼矩阵更新。
• GPU 侧不再做蒙皮混合，顶点位置直接来自纹理采样。
• 配合 Instanced Rendering，同屏角色数量可以提升一个数量级。

代价也很直接：数据量变大。每个顶点、每个动画帧都要存一份位置和法线数据，烘焙的 Clip 越长、模型顶点越多，内存和显存压力越大。后面我会详细讲压缩和量化，这是整个方案能不能落地的关键。

用生活里的例子打个比方：传统骨骼动画就像一家每天现做菜的餐厅，客人多点几桌就忙不过来。Mesh Animation Baker 相当于把菜提前做成半成品，客人来了直接加热上桌。半成品肯定占仓库位置，但出餐速度是肉眼可见地快。

1.3 GPU Instancing 与 Indirect：让海量角色真正可行

光有顶点动画还不够。如果烘焙完还是每个角色一个 DrawCall，那省了 CPU 骨骼计算，却死在 API 调用上。这里必须配合 GPU Instanced Indirect 渲染。

传统 GPU Instancing 虽然能合并相同网格的多个实例，但实例数量需要在 CPU 侧明确指定。而 Indirect 更进一层——通过一个 ComputeBuffer 当作“绘制命令缓冲区”，GPU 自己决定画多少个实例、从哪个实例开始。对整个群体做剔除、排序、填充数据都可以在 ComputeShader 或 C# 侧完成，最后只需要一次 Graphics.DrawMeshInstancedIndirect 调用。

这一套组合拳下来，2500 个角色同屏，主线程的渲染调用只有一笔 DrawCall，CPU 侧工作量基本是常数。这也是为什么很多大规模战争模拟、城市人口系统都在走这条技术路线。

2. Mesh Animation Baker 的核心环节拆解

很多人以为 Mesh Animation Baker 就是把动画顶点存到 Texture2D 里，然后在 Shader 里读一下，其实没那么简单。真正做下来，核心环节至少有四个：烘焙采样、数据编码、Shader 顶点流替换、动画播放管理。任何一个环节出问题，效果都可能直接崩。

2.1 动画采样：怎么把动画“画”成数据

第一步是在编辑器里对每个 AnimationClip 逐帧采样。Unity 有一个非常好用的接口 SkinnedMeshRenderer.BakeMesh，它可以在指定时间点把蒙皮后的网格直接烘焙出来。你写个循环，从 0 跑到 Clip 时长，每隔固定时间采样一帧，每一帧都能拿到一套完整的 Mesh.vertices、normals、tangents。

采样频率的选择要谨慎。如果你原始动画是 60 FPS，烘焙采样也按 60 FPS，数据量直接翻倍。实践上，大多数游戏动画 30 FPS 播放足够流畅，尤其是人群里的小角色，30 FPS 采样完全够用。如果角色有快速爆发动作，比如挥剑、冲刺，建议对这部分单独提高采样率，而不是把整段 Clip 都提高。

另一个容易忽略的问题是第一帧和最后一帧。如果你的 Clip 是循环动画，比如“走路”，烘焙时要保证最后一帧采样点和第一帧一致，否则循环时会跳变。我的做法是：判断 Clip 的 isLooping 属性，如果是循环动画，最后一帧直接采集第 0 帧的数据，不额外多采一帧。

2.2 数据编码与压缩：显存控制的关键

拿到顶点数据后，直接存成 Float4 纹理是非常奢侈的。一个 5000 顶点的模型，存一个 Float4 位置纹理，光位置数据就是 5000 × 4 × 4 字节 = 80 KB，再乘上动画帧数，很快就爆显存。所以压缩是必须的。

常用的压缩套路有几个：

• 位置数据量化到 16 位。把模型的局部坐标范围缩放到 0~1，然后映射到 0~65535 的整数范围，存储时用 RG16 或者 RGBA16 格式的纹理。Shader 里再反量化回真实坐标。位置精度一般能接受，因为大多数角色模型尺寸不超过几米，16 位精度足够。
• 法线量化到 8 位。法线本身就是方向向量，用八位把 xyz 压缩到 [-1, 1] 范围，精度损失肉眼几乎不可见。
• 时间维度增量编码。很多时候，相邻帧之间顶点位置变化很小，可以存当前帧相对于第一帧的偏移量，数值范围缩小后，量化误差更小，压缩率更高。

数据纹理的排布也有讲究。最简单的布局是：纹理宽度等于顶点数，纹理高度等于动画帧数。但顶点数经常不是 2 的幂，直接这么排有点浪费。更常见的做法是把顶点 ID 映射到二维 tile 上，然后加上时间轴，形成一个小 Atlas。像素坐标的换算公式一定要写清楚：uv = (float2(vertexID % tileWidth, vertexID / tileWidth) + 0.5) / tileSize + float2(animTime, 0)。注意那个 0.5 偏移，这是像素中心对齐的经典操作，不加的话会有半像素偏移，导致顶点抖动。

2.3 Shader 侧顶点流替换：从 Bones 到 Texture

终于到了 Shader 部分。常规角色的 Shader 里，顶点位置来自 Mesh 的 POSITION 语义，法线来自 NORMAL。用了 Mesh Animation Baker 后，这些都要“骗”一下：你把 Mesh 本身当成一个空壳子，它的顶点数量和布局必须和烘焙时一致，但真正的位置和法线从动画纹理里读。

核心思路是把顶点索引作为关键 ID。在顶点着色器里，你可以通过 SV_VertexID 拿到当前顶点的索引，但这个索引是 0 到顶点数-1 的连续值，和你烘焙时的顶点顺序一一对应。然后用这个索引去计算纹理 UV，采样位置、法线、切线，最后覆盖输入结构体里的 position 和 normal。

Shader 侧要特别注意的是，动画纹理的采样必须用 tex2Dlod 或者显式 LOD，因为顶点着色器里默认的纹理采样行为可能带 mipmap，一旦采样到低 mip，顶点位置会被“糊”没，模型直接炸开。我习惯把动画纹理设成 Point 滤波、Clamp Wrap，不需要任何 mipmap。

另外，光照计算依赖法线。如果你只烘焙了位置，法线还是用原始网格的静态法线，那么角色扭动时光照就是错的。所以烘焙阶段必须同时把法线、切线写入纹理，Shader 里读出来后替换。切线同理，尤其是用了法线贴图的材质，切线不对，法线贴图会完全错乱。

2.4 动画播放管理与多 Clip 切换

烘焙只是把静态数据准备出来，播放逻辑还得自己实现。最简单的做法是 Shader 里传一个全局时间 _AnimTime，shader 用它去采样纹理。但人群动画的难点在于，你不能让所有角色行动完全同步，否则看起来会像克隆人军团，非常假。

每实例数据里最好加一个 _AnimOffset，偏移量可以是负数也可以做随机小数。Shader 里实际采样时间 = _AnimTime * _AnimSpeed + _AnimOffset。这样每个角色在同一个时刻处于动画的不同相位，人群自然就“活”了。

多 Clip 支持要看你怎么组织纹理。最粗暴的方案是每个 Clip 一张纹理，材质球一大堆，切换时换 MaterialPropertyBlock；更优雅的方案是用 Texture2DArray，把不同 Clip 放到不同 layer，实例数据里带一个 clipIndex，Shader 里做动态分支采样。过渡动画可以再加一个 crossfade 时间参数，两层采样后做一次插值，这个在大量同屏时成本也不高，尤其适合远程角色。

3. 从 0 到 1 实现一套 GPU 人群动画

理论聊完，直接上实操。我做了一个简化版 Demo：一个 2000 顶点的低模角色，三段动画（待机、走路、跑步），目标是把 500 个实例一次性画出来，CPU 主线程开销控制在极小范围。

3.1 烘焙工具：遍历 Clip 并逐帧 BakeMesh

编辑器下的烘焙脚本是整个流程最脏最累的活。核心逻辑长这样：

// 简化版：SkinnedMeshRenderer 动画烘焙工具 [MenuItem("Tools/Bake Animation To Texture")] public static void BakeAllClips() { SkinnedMeshRenderer skin = target.GetComponent<SkinnedMeshRenderer>(); List<AnimationClip> clips = GetClips(target); int vertexCount = target.sharedMesh.vertexCount; float sampleRate = 30f; foreach (var clip in clips) { int frameCount = Mathf.CeilToInt(clip.length * sampleRate) + 1; Vector3[] positions = new Vector3[vertexCount * frameCount]; Vector3[] normals = new Vector3[vertexCount * frameCount]; for (int f = 0; f < frameCount; f++) { float time = Mathf.Min(clip.length, f / sampleRate); Mesh bakedMesh = new Mesh(); skin.BakeMesh(bakedMesh); // Unity 会根据当前动画状态采样 // 注意：这里需要先设置采样时间 clip.SampleAnimation(target.gameObject, time); Array.Copy(bakedMesh.vertices, 0, positions, vertexCount * f, vertexCount); Array.Copy(bakedMesh.normals, 0, normals, vertexCount * f, vertexCount); } SaveToTexture(clip.name, positions, normals, vertexCount, frameCount); } }

有几个关键点要注意。

BakeMesh 之前必须先 SampleAnimation，否则采样到的是当前 Playable 的状态，不是你想要的帧。Clip.SampleAnimation 是编辑器下非常好用的 API，它会临时把角色的姿势设到特定时间点。

Mesh 的顶点顺序和 sharedMesh 必须一致。有些模型有 Optimization 选项，会把顶点重排。烘焙时我建议关掉 Mesh 的 Read/Write 优化，并且不要使用 CombineChildren，否则后期 Shader 里用 SV_VertexID 索引会对不上。

最后的 SaveToTexture 就是把你选好的编码方式落地。我推荐用 Texture2D 的 RGBAHalf 或 RG16 格式，按 Atlas 方式排布，并关闭 mipmap、改成 Clamp。

3.2 渲染端：DrawMeshInstancedIndirect 与 ArgsBuffer

烘焙完纹理，接下来就是运行时渲染。我用 Graphics.DrawMeshInstancedIndirect 来画所有角色，但这个 API 需要你提供一个参数 Buffer，告诉 GPU 画多少个实例、网格有几条索引。

// 初始化间接绘制参数 ComputeBuffer argsBuffer = new ComputeBuffer(4, sizeof(uint), ComputeBufferType.IndirectArguments); uint[] args = new uint[4]; Mesh mesh = bakedSharedMesh; args[0] = mesh.GetIndexCount(0); // 索引数量 args[1] = (uint)instanceCount; // 实例数量 args[2] = mesh.GetIndexStart(0); args[3] = 0; argsBuffer.SetData(args);

实例数据我用一个单独的 ComputeBuffer 存，每个实例包含 position、scale、randomOffset、clipIndex 等。这里有个细节：DrawMeshInstancedIndirect 默认不支持每实例数据直接绑定到 MaterialPropertyBlock，所以要显式把实例 Buffer 绑定到 Shader 里的 StructuredBuffer。

instanceBuffer = new ComputeBuffer(instanceCount, instanceSize); instanceBuffer.SetData(instanceData); material.SetBuffer("_InstanceBuffer", instanceBuffer); // 每帧绘制，不需要额外 SetPass 调用 Graphics.DrawMeshInstancedIndirect(bakedMesh, 0, material, argsBuffer);

这里要注意的是，bakedMesh 本身只是“壳”，它的 Renderer 不存在也没关系。我们只用它的顶点数量、索引、UV 这些静态信息。经过烘焙后，真正的顶点坐标完全是 Shader 说了算。

3.3 Shader 实现：从动画纹理到最终顶点

Shader 部分是最容易翻车的地方，我直接给一个核心片段：

StructuredBuffer<InstanceData> _InstanceBuffer; sampler2D _AnimTex; float4 _AnimTex_TexelSize; int _TileCount; struct InstanceData { float4 position; float4 scaleOffset; // xyz: scale, w: random offset }; float4 GetAnimPos(uint vertexID, float time) { int tileWidth = _TileCount; float2 tileUV = float2(vertexID % tileWidth, vertexID / tileWidth); float2 uv = (tileUV + 0.5) * _AnimTex_TexelSize.xy; uv.x += _AnimTex_TexelSize.x * time; float4 pos = tex2Dlod(_AnimTex, float4(uv, 0, 0)); return pos; } v2g vert (uint vertexID : SV_VertexID, uint instanceID : SV_InstanceID) { InstanceData data = _InstanceBuffer[instanceID]; float animTime = _Time.y * _AnimSpeed + data.scaleOffset.w; float4 pos = GetAnimPos(vertexID, animTime); float3 worldPos = pos.xyz * data.scaleOffset.xyz + data.position.xyz; v2g o; o.worldPos = worldPos; o.clipPos = UnityWorldToClipPos(worldPos); return o; }

注意这段代码里的顶点索引来自 SV_VertexID，而不是语义化的 POSITION。使用 DrawMeshInstancedIndirect 时，SV_InstanceID 会自动提供实例索引，正好用来访问结构化缓冲区。

动画时间我用 _Time.y，这是 Unity Shader 内置的全剧时间。但要注意：如果所有实例用一模一样的时间，看起来就会完全同步，所以每个实例的随机偏移是必须的。另外，如果角色在场景里移动，position 字段应该是世界空间的位置，我们的动画坐标烘焙时用的是模型局部空间，所以要先缩放再平移，顺序别搞反。

3.4 百人同屏的性能调优实践

我的测试场景里放了 500 个角色，每个 2000 顶点，三段动画，烘焙到一张 2048×2048 的 RGBAHalf 纹理里。实测下来，DrawCall 是 1，Main Thread 的耗时几乎可以忽略不计，真正的开销集中在 GPU 带宽上——因为每个顶点都要从纹理里读位置和法线。

这种情况下，压缩的意义就体现出来了。如果用 Float4 存位置，带宽翻倍；改用 RGBAHalf 后，视觉差异不大但带宽直接减半。我还对远处的实例做了 LOD，超过一定距离直接切换成低模，进一步降低带宽压力。

还有一个非常容易忽视的优化点：Culling。DrawMeshInstancedIndirect 不会自动做视锥剔除，你必须在 CPU 或 ComputeShader 里做。我的做法是，每帧把相机视锥矩阵传到查完 ComputeShader 里，让每个实例判断自己在不在视锥内，不在就把它的缩放置为 0，这样 GPU 虽然还是处理全部实例，但大部分顶点都挤到一点上，实际渲染开销小很多。

4. 踩坑实录与排查技巧

如果只看原理，你可能会觉得这套方案很美好，但真正落地时坑密集度非常高。我把自己踩过的、帮别人排查过的问题整理在这里，每条都能省你半天时间。

4.1 显存占用计算：别让小成本变成大负担

烘焙前一定要算一笔账。假设你有一个 8000 顶点的角色，素材比较精细，动画 Clip 总时长 10 秒，采样率 30 FPS，位置用 RGBAHalf（8 字节/顶点），法线用 RGBAHalf（8 字节/顶点）。那么单个 Clip 的纹理大小大约是：8000 × 300 帧 × 16 字节 = 38.4 MB。如果三段动画就是 100 多 MB，直接吃掉巨大显存。

所以实际操作里，我强烈建议：

• 把模型减面到 2000~3000 顶点，人群角色根本不需要太精细。
• 采样率 30 FPS 足够，除非有慢动作镜头。
• 位置用 RGBAHalf 或量化到 RG16，法线用 RGBAHalf，别全用 Float。
• 共享纹理 Atlas 时，把多个 Clip 拼到同一张纹理里，而不是一张 Clip 一张纹理。
• 对循环动画做特殊优化：只存一整个循环周期，不要为不同循环位移多占空间。

这个账不算清楚，做出来的方案可能在性能和内存之间两头挨打。

4.2 “顶点乱飞”与纹理寻址 Bug

我见过太多人做顶点动画纹理，第一帧是好的，第二帧开始模型像爆炸一样乱飞。这种问题九成出在 UV 计算上。你是不是只在 U 方向加了时间？如果你的纹理布局是时间在 U 方向，那没问题；但很多人把时间放到了 V 方向，又用 UV 的 y 作为顶点索引，就会乱。

还有像素中心问题。GPU 纹理采样时，UV 坐标落在像素边缘和像素中心的差别非常大。标准做法是：

uv = (pixelCoord + 0.5) / textureSize

这个 0.5 必须加。不加的话，某些顶点会采到相邻像素，表现就是个别顶点周期性跳动。

Wrap 模式也必须设成 Clamp。如果设成 Repeat，当你采样的时间超过纹理长度时，UV 会回绕，动画会瞬间跳回开头，看起来像瞬移。想循环播放，应该靠 Shader 里的取模运算控制时间，而不是靠纹理寻址。

4.3 阴影、包围盒与剔除问题

烘焙顶点动画后，Unity 的剔除和阴影系统会有一个通病：它不知道你的网格顶点在动画时会跑到哪里。如果你直接用一个静态 Mesh 的 Bounds，那么动画幅度大的角色，比如跳跃、挥舞武器，有可能被视锥剔除错误的裁剪掉，或者阴影完全消失。

解决办法是在烘焙时根据所有动画帧的顶点位置，计算一个“联合包围盒”，在运行时覆盖到 Mesh 的 renderer.bounds 上。更稳妥的做法是，在 Shader 的顶点阶段输出一个足够大的包围球位置，让物体永远不会被错误剔除。但注意，这个方法会降低遮挡剔除效率，所以只对动画幅度大的角色使用。

阴影方面，如果角色在烘焙动画中移动位置，阴影会根据最终变换矩阵生成，一般没问题。但如果烘焙位置是局部空间，而实例会移动，必须确保传给阴影 Pass 的矩阵和阴影 Pass 里的实例变换逻辑一致，否则阴影会留在原地。

4.4 动态骨骼、挂点和换装：烘焙方案的边界

Mesh Animation Baker 不是银弹。它是为“绝对大量、绝对重复、不需要交互的群体”设计的。如果你的角色需要动态 IK、头部跟踪、挂点武器、表情 BlendShape，烘焙方案就很别扭。

挂点问题尤其典型。角色手上拿武器，武器位置是跟着手骨走的。烘焙后没有骨头了，武器怎么挂？通用的做法是：把武器位置也烘焙成动画数据，甚至把武器网格合并进角色网格一起烘焙。但如果武器可以随时切换，这就很麻烦。

所以我自己项目里的策略是：远处和中间层的群体 NPC 用全套烘焙动画；靠近摄像头、有交互、有特殊挂点的角色保留 SkinnedMeshRenderer。这两个角色可以用同一套模型，只是渲染路径不同。为了纹理资源不翻倍，远处和近处的 LOD 共享烘焙纹理，近距离切回骨骼后仍然用原来的动画 Clip，烘焙精度和骨骼动画原始效果保持一致。

4.5 常见问题速查表

这里还想补充一个真正容易忽略的坑：如果用 Animation Clip 里的 Root Motion，也就是角色位移，不要把它烘焙进顶点动画。因为你在实例化时已经给每个角色设置了独立的世界坐标，如果再把 root motion 一次性合入顶点偏移，角色会走“双倍距离”。正确做法是把 root motion 的位移单独剥离，运行时作为实例位置增量处理。具体可以从 AnimationClip 的 rootCurves 里读出位移，检查是否位移曲线有值，烘焙时只保存网格本身的局部动画，不解算 root motion。

5. 后续还能怎么扩展

最后再说一点我自己的心得。Mesh Animation Baker 这套能力落地后，你还可以把它扩展成更通用的“人群动画管线”：比如把粒子系统的人群、动物群、甚至远景的交通工具都做成同一套数据驱动。只要动画是确定性的，都能先烘焙再播放。这套思路和程序化生成结合，也能做出规模感很强的城市背景层。我个人建议从一个小项目开始试验，先解决 200 个 NPC，再上量到 2000。等技术手感有了，再考虑大规模合批和更激进的压缩方案。如果你在项目中踩到新的坑，欢迎回来一起交流。