企业官网建设流程全解析

有没有见过这种画面：一张卡牌被击碎，几十个碎片带着旋转和速度向外崩开；一个BOSS被打出硬直，身后的人物立绘瞬间碎成满屏飞屑；或者一个转场动画里，上一张海报被“炸”成粒子飘散，露出下一张。这种效果在游戏开发里就叫图片破碎（Image Shatter），在动作反馈、抽卡演出、UI转场里用得非常多。这篇文章我直接用Unity + C#实现一套成熟的图片破碎算法，不是那种“放个粒子就算完事”的偷懒版本，而是把图片按照网格真正切成一个个独立的 Mesh 碎片，每个碎片都有自己的位置、旋转、速度和延迟。工程级代码会放在正文里，适合想快速上手、也适合想搞懂底层原理的 Unity 开发者。

这个方案我从头到尾跑了好几轮，踩过不少坑，比如碎片生成后直接消失、三角形绕序反了导致看不到面、材质用错导致黑块、碎片数量一多就卡顿，这些在文章最后的排查部分都整理成了速查表。你可以直接照着代码抄，也可以根据自己的项目改出更复杂的变体。

1. 先想清楚：图片破碎到底在拆什么

1.1 三种常见实现方式的优劣拆解

图片破碎看着唬人，核心就一句话：把一张完整图片拆成多个独立的小块，然后让每个小块按自己的规则运动。但“拆图片”本身就有三种完全不同的拆法，我当初都试过，各自优缺点非常明显。

第一种：像素级切割。直接从 Texture2D 的像素数组入手，用 GetPixels / GetPixels32 把纹理按矩形区域切开。这个方法听起来很“底层”，实际操作会发现几个问题：一张 1024x1024 的图片切成 8x8 的碎片，需要生成 64 份像素数据，内存占用直接翻几十倍；而且像素数据切出来后，你还得为每一块重新创建 Texture2D 和 Sprite，生成和销毁的 GC 压力极大；最要命的是，切出来的每条边都带着抗锯齿的半透明像素，拼接处稍不注意就会出现黑边或白边。这个方案适合做“缓慢溶解”这种需要像素级别的效果，不适合做飞散破碎。

第二种：粒子系统替代。把图片烘焙成一张大贴图，然后用 ParticleSystem 的 Texture Sheet Animation 去播放碎片动画，或者让粒子沿网格区域采样颜色。这个方案实现快，性能也不错，但可控性很差。你没法让某一块碎片有独立的碰撞体，也没法精确控制每块碎片的旋转轴心和延迟顺序。如果要做一个“受击后某一块碎片恰好飞向玩家”的交互反馈，粒子方案基本做不到。它适合做大面积的氛围碎屑，不适合做核心的破碎交互。

第三种：网格级切割。把一个 SpriteRenderer 对应的渲染网格（Mesh）按行列分成若干子网格，每个子网格单独成为一个 Mesh 对象，配合独立 GameObject + MeshRenderer 渲染。碎片的“视觉身份”和“逻辑身份”完全绑定，每一块可以挂自己的组件、做自己的物理模拟、接受射线检测。配合协程或 Tweener 控制飞散，效果非常灵活。这个方案唯一的“缺点”是需要对 Mesh 的顶点、三角形、UV 有个基本认知，但只要理解了这三个概念，后面所有代码都是顺水推舟。也是我最终选定的方案。

1.2 为什么我最终选择了网格拆分

选择网格拆分，不是为了显得技术高，而是因为它在“视觉表现”和“代码可控性”之间取得了最好的平衡。一张图片在 Unity 里最终显示到屏幕上，本质上就是一个四边形网格外加一张贴图。既然如此，想要“破”这张图，最自然的思路就是破这个网格：把原来的一个大四边形拆成很多小四边形，每个小四边形的 UV 都指向原图对应的位置。渲染结果拼在一起跟原图一模一样，但物理上已经是独立个体了。

另一个决策点是：切分时采用“矩形网格”，不做不规则多边形。这个决策很多人不理解，觉得矩形碎片不够真实。我的理由很实际：矩形网格的数学最简单，UV 可以均匀映射，三角形的绕序不会出错，而且性能开销容易预估。不规则碎片的视觉效果确实更好，但需要用 Voronoi 分割后再做多边形三角化，涉及 Earcut 这类算法，代码量会翻几倍。本文先用矩形网格打通整条流水线，在最后一个章节我会给不规则碎片的实现思路和优化方向，这样你既能快速落地，又有后续进阶的抓手。

2. 核心原理：从 Mesh 到碎片的三个关键要素

2.1 一张图在 Unity 里是怎么画出来的

要真正理解图片破碎，先得知道 SpriteRenderer 在底层做了什么事。SpriteRenderer 拿到一个 Sprite 后，会用 Sprite 的纹理和四个角的位置构造一个 Mesh，这个 Mesh 只有 4 个顶点、2 个三角形和 4 个 UV 坐标。顶点坐标决定四边形在场景里占多大、在哪，UV 坐标决定贴图上哪个区域被采样。屏幕上的“一张图片”，本质是 GPU 把这个贴图贴到一个由两个三角形拼成的正方形上。

做破碎的时候，我不去改贴图，而是重新生成一组新的 Mesh。每个碎片 Mesh 的顶点坐标，是从原图片的矩形范围里切出的一小段；UV 坐标也对应着原贴图的一小块矩形。顶点和 UV 都切好了，GPU 采样时自然就能画出正确的局部图片。你可以把 Mesh 理解成一个“画框”，贴图是“画纸”，图片破碎就是在把画框切成小块，然后分别拿出框里的那部分画纸。

2.2 分块时如何保证图片不错位

分块时最容易犯的错误是：顶点位置切对了，但 UV 没有同步切。一旦 UV 和顶点对不上，画出来的碎片要么偏移、要么拉伸、要么采样到邻近像素。正确的做法是让顶点坐标和 UV 坐标保持“线性映射”关系。

假设一张图片的宽度是 w，高度是 h，要切成 columns 列、rows 行。每一格的矩形范围是：

• 第 c 列的横向范围：minX = -w/2 + c * (w / columns)到maxX = minX + w / columns
• 第 r 行的纵向范围：minY = -h/2 + r * (h / rows)到maxY = minY + h / rows
• 对应的 UV 横向范围：uMin = c / columns到uMax = (c + 1) / columns
• 对应的 UV 纵向范围：vMin = r / rows到vMax = (r + 1) / rows

这里有一个 Unity 特有的细节：Sprite 的 UV 坐标原点是左下角，v 轴向上增长；而本地坐标也是 y 向上。所以上面的映射是完全一致的，不需要翻转。很多初学者把 v 的方向写反，结果碎片上下颠倒。如果你实在记不住，就记住一句话：顶点坐标算出来的百分比（x / w），就是 UV 坐标里对应的比例。

另外不要忽略 Sprite 的 pivot。默认 pivot 在中心时，图片矩形范围是-w/2 ~ w/2。如果 pivot 改成左上角，图片的实际范围就变成0 ~ w和-h ~ 0。我们在写代码时用sprite.bounds来获取这些信息，会比手写死数值通用很多。

2.3 飞散动画的本质

碎片切出来之后，第二个核心问题就是“怎么让它动起来自然”。飞散动画本质上只做了两件事：给每个碎片一个初速度，然后在每一帧更新它的位置和旋转角度。最常见的做法有两种：一种是用协程每帧计算位移和旋转，一种是把碎片挂上 Rigidbody，交给物理引擎模拟。

协程方案的好处是可控性强、不依赖物理场景配置、没有刚体之间的互相碰撞干扰。每个碎片的初速度方向可以按它的中心点相对整张图中心的方向来定，同时加一点随机扰动，避免飞得太整齐。为了让效果更带感，我会在初速度上叠加一个向上的分量，让它先向上飘、再往下掉，给人一种被“炸开”的错觉。旋转角速度也加随机值，有的快转、有的慢转，甚至反向转。

物理方案的好处是能提供真实的碰撞和反弹。如果破碎的场景里还有地面、墙壁，你会希望碎片落在地上之后还能弹几下，这时用物理引擎是最省力的。但这要求每个碎片额外添加 Collider 和 Rigidbody，碎片数量一多，物理开销会明显上升。我的经验是：如果只是 UI 演出或短时反馈，协程方案完全够用；如果碎片要和场景碰撞，再考虑物理方案。

3. 实操：可直接落地的 C# 实现

3.1 场景与资源准备

先准备一个干净的试验场景。创建一个空物体，挂上 SpriteRenderer，把你要破碎的图片拖到 Sprite 属性里。图片的 Import Settings 建议设置为 Sprite(2D and UI)，Pixels Per Unit 根据自己的项目调，默认 100 就行。不需要额外的纹理特殊设置，也不需要勾选 Generate Physics Shape，因为我们不走 Sprite 的物理逻辑。

然后在同一个物体上挂一个ImageShatter脚本。这个脚本既是切分器，也是飞散效果的触发入口。场景搭建部分就这些，剩下全是代码。为了让调试方便，我给脚本加了右键菜单功能，在 Inspector 里右键组件名，点 “Shatter”，就能立刻看到破碎效果。这个习惯强烈推荐保留，它能让你在编辑器里反复调参，不用每次跑到 Play 模式。

3.2 切分核心：生成碎片 Mesh

下面是第一个关键脚本，负责把 SpriteRenderer 的图片从逻辑上切成 N 个碎片。我简化了命名和字段，方便你直接阅读和改造。

using System.Collections.Generic; using UnityEngine; public class ImageShatter : MonoBehaviour { [Header("切分参数")] public int columns = 6; public int rows = 4; [Header("飞散参数")] public float power = 4f; public float upwardBias = 1.5f; public float gravity = -9.81f; public float drag = 0.2f; public float angularSpeed = 240f; public float delayBase = 0f; public float delayStep = 0.05f; [Header("行为")] public bool hideSource = true; private SpriteRenderer spriteRenderer; private List<ShatterPiece> pieces = new List<ShatterPiece>(); private bool shattered; private void Awake() { spriteRenderer = GetComponent<SpriteRenderer>(); } [ContextMenu("Shatter")] public void Shatter() { if (shattered || spriteRenderer == null || spriteRenderer.sprite == null) return; shattered = true; Sprite sprite = spriteRenderer.sprite; if (hideSource) spriteRenderer.enabled = false; Material mat = new Material(Shader.Find("Sprites/Default")); mat.mainTexture = sprite.texture; mat.color = spriteRenderer.color; Bounds bounds = sprite.bounds; float w = bounds.size.x; float h = bounds.size.y; float cellW = w / columns; float cellH = h / rows; Vector2 center = bounds.center; for (int r = 0; r < rows; r++) { for (int c = 0; c < columns; c++) { float minX = center.x - w * 0.5f + c * cellW; float maxX = minX + cellW; float minY = center.y - h * 0.5f + r * cellH; float maxY = minY + cellH; float uMin = (float)c / columns; float uMax = (float)(c + 1) / columns; float vMin = (float)r / rows; float vMax = (float)(r + 1) / rows; GameObject go = new GameObject("Piece_" + r + "_" + c); go.transform.SetParent(transform, false); go.transform.localPosition = Vector3.zero; go.transform.localRotation = Quaternion.identity; go.transform.localScale = Vector3.one; MeshFilter mf = go.AddComponent<MeshFilter>(); MeshRenderer mr = go.AddComponent<MeshRenderer>(); mf.mesh = BuildQuadMesh(minX, minY, maxX, maxY, uMin, vMin, uMax, vMax); mr.sharedMaterial = mat; mr.sortingOrder = spriteRenderer.sortingOrder; mr.sortingLayerID = spriteRenderer.sortingLayerID; Vector3 localDir = new Vector3( (minX + maxX) * 0.5f, (minY + maxY) * 0.5f, 0f); localDir += new Vector3( Random.Range(-0.2f, 0.2f), Random.Range(-0.2f, 0.2f), 0f); ShatterPiece piece = go.AddComponent<ShatterPiece>(); piece.Setup(localDir.normalized, delayBase + Vector2.Distance(localDir, Vector2.zero) * delayStep); pieces.Add(piece); } } for (int i = 0; i < pieces.Count; i++) { pieces[i].Fly(power, upwardBias, gravity, drag, angularSpeed); } } private Mesh BuildQuadMesh(float minX, float minY, float maxX, float maxY, float uMin, float vMin, float uMax, float vMax) { Mesh mesh = new Mesh(); mesh.name = "QuadPiece"; mesh.vertices = new Vector3[] { new Vector3(minX, minY, 0f), new Vector3(maxX, minY, 0f), new Vector3(maxX, maxY, 0f), new Vector3(minX, maxY, 0f) }; mesh.uv = new Vector2[] { new Vector2(uMin, vMin), new Vector2(uMax, vMin), new Vector2(uMax, vMax), new Vector2(uMin, vMax) }; mesh.triangles = new int[] { 0, 1, 2, 0, 2, 3 }; mesh.RecalculateBounds(); mesh.RecalculateNormals(); return mesh; } }

这段代码的核心是BuildQuadMesh。它生成一个由两个三角形拼成的四边形，顶点顺序分别是左下、右下、右上、左上。三角形索引0,1,2和0,2,3保证了面的法线方向一致，不会出现“只有一半图片可见”的问题。RecalculateBounds非常重要，它计算出 Mesh 的包围盒，否则 Unity 的渲染剔除系统可能直接把碎片当作屏幕外物体丢掉了。

有一个容易忽略的点：mat.color = spriteRenderer.color。如果原图片在 SpriteRenderer 上设置过半透明或变色，直接生成 MeshRenderer 会丢掉这个颜色状态，画面就“变亮”或“变暗”了。这里统一把颜色赋给新材质，保证视觉一致。

3.3 飞散控制：协程里的物理模拟

生成的碎片物体需要一个能自己飞起来的组件。我把飞散逻辑放在ShatterPiece里，用协程驱动。这样每个碎片都是独立的“小个体”，加延迟也好、加随机旋转也好，都不会互相影响。

using System.Collections; using UnityEngine; [RequireComponent(typeof(MeshFilter))] [RequireComponent(typeof(MeshRenderer))] public class ShatterPiece : MonoBehaviour { private Vector3 localDirection; private float delay; public void Setup(Vector3 dir, float d) { localDirection = dir; delay = d; } public void Fly(float power, float upwardBias, float gravity, float drag, float angularSpeed) { StartCoroutine(FlyRoutine(power, upwardBias, gravity, drag, angularSpeed)); } private IEnumerator FlyRoutine(float power, float upwardBias, float gravity, float drag, float angularSpeed) { yield return new WaitForSeconds(delay); Vector3 worldDir = transform.TransformDirection(localDirection); Vector3 velocity = worldDir * power; velocity += Vector3.up * upwardBias; float angleSpeed = angularSpeed * Random.Range(-1f, 1f); while (velocity.sqrMagnitude > 0.01f) { velocity.y += gravity * Time.deltaTime; velocity *= 1f / (1f + drag * Time.deltaTime); transform.position += velocity * Time.deltaTime; transform.Rotate(0f, 0f, angleSpeed * Time.deltaTime); yield return null; } Destroy(gameObject); } }

这段代码我常用，几个细节值得说明。transform.TransformDirection(localDirection)是为了兼容父物体有旋转的情况。如果你的图片挂在某个旋转过的 UI 元素或 NPC 身上，碎片方向必须从本地坐标系转到世界坐标系，否则会出现“朝左打，碎片却向右飞”的诡异效果。velocity *= 1f / (1f + drag * Time.deltaTime)是一个近似阻尼公式，比直接乘个固定系数更稳定，不会出现帧率不同导致速度变化不同的问题。sqrMagnitude比较是避免开方运算的小优化，也和物理引擎的判断习惯一致。

协程方案的好处是你可以随时在while循环里加自己的逻辑，比如加一个螺旋偏移、让碎片在第二帧后切换成自由落体、或者根据灰度值调整飞出颜色。这些扩展都是几行代码的事，物理方案反而不容易做到。

3.4 主要参数速查表

我调破碎效果时依赖一套自己的参数手感，分享出来给你当初始参考。不同项目风格需要的数值完全不同，但一开始就有一个大致合理的档位，能省很多时间。

我最常用的一组“卡片破碎”参数是：8x4、power 5、upwardBias 2、gravity -9.81、drag 0.25、angularSpeed 300、delayStep 0.05。这个组合在卡牌游戏里表现很好，碎片不会飘太久，也不会一秒全落地，刚好在玩家能看清的 0.8 秒内完成主要飞散。

3.5 编码时容易忽略的几个细节

第一个细节：排序。我的代码里pieces列表是按生成顺序遍历的，也就是一行一行从左到右飞的。如果你希望碎片从中心向外扩散，要给pieces按 delay 排序再逐个触发。中心部分的 delay 小、边缘的 delay 大，视觉上就是一个“冲击波”。把 delayStep 调大一点，比如 0.1，甚至可以做出慢镜头式的爆炸感。

第二个细节：原有 SpriteRenderer 的 sortingLayer。如果图片原本在某层 UI 之上，碎片必须继承同样的sortingLayerID和sortingOrder，否则会出现图片消失了、碎片却在其他层级下面看不到的情况。这个坑很隐蔽，一旦出现，现象就是“主图消失了，但碎片什么都看不见”。

第三个细节：动态生成材质的生命周期。new Material(Shader.Find("Sprites/Default"))创建的材质是运行时实例，属于未托管的资源，在场景里用完之后如果没有销毁，会一直留在内存里。在编辑器里频繁右键触发 Shatter，会导致材质越积越多。正式项目里建议加一个回收逻辑，或者在碎片全部销毁后把材质Destroy掉。简单做法是把材质放在一个静态变量里复用，全局只创建一次。

4. 常见问题与排查实录

4.1 碎片生成后完全看不到

这个问题的排名第一，因为我第一次写的时候就遇到了。现象是代码运行了，层级面板里出现了几十个Piece_x_y子物体，MeshRenderer 也勾选了，但场景视图和游戏视图里什么都看不到。

排查第一步，确认是否因为spriteRenderer.enabled = false导致原来的图消失了，而碎片自身的渲染又没有生效。这时先在 Inspector 里随便选中一个碎片，看它的 MeshFilter 是否真的存在 Mesh，MeshRenderer 是否被禁用，材质是否为空。材质为空最常见，尤其是你用了别人的代码，没处理material赋值。

排查第二步，如果 Mesh 和材质都在，那就检查 Mesh 的 bounds。在代码里调用mesh.RecalculateBounds()之前，新 Mesh 的 bounds 是默认无效的，渲染剔除系统会把碎片视为在屏幕外。这个很好验证：把 MeshRenderer 的Renderer.isVisible属性打出来，如果为 false，基本就是 bounds 的问题。

排查第三步，看 sorting layer 和 order。碎片的 MeshRenderer 如果 sortingOrder 比同一相机下的其他层低，会被其他物件盖住。尤其是 Canvas 下场景，默认 UI 都渲染在极高的 sortingOrder，碎片如果没继承，会被 UI 挡住。代码里我已经处理，但你自己扩展时要注意。

4.2 碎片显示为黑色色块或边缘白边

黑色色块的原因通常是材质 Shader 不对。如果直接用默认 Standard Shader，没有设置主纹理，或者把 Sprite 贴图传给了一个不支持透明度混合的材质，就会出现“整个碎片是一个黑色方块”。我用Sprites/Default就是为了处理透明贴图，它内置了 alpha 混合，专为 2D 精灵设计。如果你导入的是不透明纹理，可以用Unlit/Texture。

边缘白边的问题多在 UV 边界采样。Sprite 在导入时如果开启了 texture compression，边缘像素会和相邻像素有颜色混合，切成小片后采样边界会看到一圈淡白色的线。解决方法是给 UV 做内缩。把uMin、uMax、vMin、vMax分别向内缩半个像素的距离，即offset = 0.5f / sprite.texture.width，这样 GPU 采样时不会恰好踩到边界。这个方法在处理图集里的子图时也适用。

4.3 三角形绕序错误导致只有一半图片可见

如果你自己改写了BuildQuadMesh，最容易出问题的是三角形索引写错。Unity 渲染一个三角形时，会根据顶点顺序判断这个面的朝向。顶点按顺时针方向排列时，法线朝向屏幕外；逆时针排列时，法线朝屏幕内，就会被剔除掉（如果你开了背面剔除）。

常见的现象：四边形的一半正常，另一半空白。这就是两个三角形中有一个的绕序反了。检查方法很简单，把 Mesh 的顶点和 triangles 手动列出来算一次叉积。我的写法0,1,2和0,2,3是经过验证的，你不需要自己改写。如果你需要做不规则碎片的三角化，记住一个口诀：绕序一致是生死线，写完后先用一个最简单的四边形测试。

4.4 性能问题：碎片数量和 GC 压力

碎片数量一旦超过 100，物体的创建、Mesh 生成、协程启停都会造成明显的卡顿。这个项目如果只是做短演出，问题不大；但如果要做成高频技能效果，一定要做对象池。

对象池的优化思路是：预热一批碎片 GameObject，每个碎片包含等尺寸的 Mesh 和材质。触发破碎时，从池里取出并随机分配一个切分区域；碎片落地后回收，不销毁。这样 Mesh 的顶点数据可以提前全部分配好，只需要在触发时修改顶点坐标和 UV，再调用一次mesh.vertices = ...即可。用SetVertices配合NativeArray还能避免大量 GC Alloc，但普通项目里mesh.vertices就够了。

协程本身也会产生 GC。每个StartCoroutine都会在堆上分配一个 IEnumerator 对象，100 个碎片就是 100 个对象。如果碎片数量大，改用Update里的循环统一驱动，或者用轻量级的 Tween 库。我自己在性能敏感的项目里会把协程换成自定义的 Update 驱动，但中小项目没必要这么折腾。

5. 优化与进阶方向

5.1 从矩形碎片升级到不规则碎片

矩形碎片虽然代码简单，但在表现力上有个硬伤：它太“整齐”了，飞散时容易让玩家看出明显的网格线。要让效果真实，可以把切分矩形内部的顶点坐标做随机扰动。比如在原矩形网格的交叉点上，加上一个随机偏移，让每一块的边界变得曲折。但这种方式有一个隐藏问题：相邻两块如果共用边界点，它们的顶点偏移必须保持一致，否则会出现缝隙。

做得更彻底一点，就是叠 Voronoi 图。在图片范围内随机撒几十个种子点，每个像素归属到最近的种子点，形成不规则的 Voronoi 单元。对每个单元做多边形裁剪，再三角化，就能得到完全不规则的碎片。这个方案我建议用第三方库或者自己实现一个 2D 三角剖分工具类，尽量不要手写多边形的 Ear Clipping，容易在凹多边形上踩坑。实现思路是：先生成种子点和 Voronoi 边缘，再对每个碎片做三角形网格生成，之后套用本文的 Mesh 渲染和飞散逻辑。

5.2 加入物理碰撞的破碎效果

协程飞散适合“飘”的效果，但如果要表现碎片掉落到地面后弹跳、堆积，就需要物理引擎配合。每个碎片只要加一个PolygonCollider2D和一个Rigidbody2D就能参与物理模拟。PolygonCollider2D 的路径可以直接从碎片的 Mesh 顶点取出来，注意顶点要是顺时针顺序，且不能有自交。碎片数量控制在 30 到 60 个之间，物理性能压力不大。

物理方案和协程方案可以混合使用。我的习惯是：先给碎片一个飞散的初速度，等它飞出去 0.2 秒后再挂上 Rigidbody2D，切换成物理模式。这样既保留了爆炸瞬间的可控性，又获得了落地后的自然反弹。切换时机用协程的简单延迟就能实现。

5.3 UI 场景里怎么用

如果你破碎的对象是 UGUI 的 Image，而不是 SpriteRenderer，上面的代码不能直接用。一个相对省事的做法是：先把 Image 的显示内容烘焙成一个 Sprite，然后隐藏原 Image，在 Canvas 下新建一个同样尺寸的 SpriteRenderer 对象，挂上本文的破碎逻辑。烘焙可以用RenderTexture配合临时相机，也可以直接用Image.sprite如果它本身就有 Sprite 引用。也就是说，核心算法完全不变，变的是展示层从 UGUI 切到 SpriteRenderer。演出结束后，把碎片清空，再恢复 Image 的显示。

另一个思路是把整个 Canvas 设为 WorldSpace，让 SpriteRenderer 和 UI 处于同一渲染空间，这样层级关系更好控制。但 WorldSpace Canvas 的缩放和事件系统都要额外适配，不是每个项目都值得。我个人的经验是：破碎效果强依赖 Mesh 的灵活性，早晚要脱离 UGUI 体系，与其花力气让 UGUI 接受 Mesh，不如把破碎这块单独交给 SpriteRenderer 去跑。

最后再多说一句：图片破碎这个效果看着小，但很能体现一个开发者对渲染、网格和动画的综合把控能力。我建议你把上面的代码亲手敲一遍，然后试着改三件事：行列数、延迟排序方式、把飞散换成物理掉落。这三件事做完，你对 Mesh 的理解会上一个台阶。后续如果项目里要做自定义 Mesh 特效、做碎玻璃、做技能爆炸，你都能复用这套底子重新发挥。