企业官网建设流程全解析

1. 物理与动画系统在游戏引擎中的定位与整体设计

聊到游戏引擎架构，渲染管线往往是大家最关注的部分，毕竟画面好不好看，一眼就能看出来。但真正做过完整项目的人都知道，物理系统和动画系统才是决定“手感”和“沉浸感”的关键。一个角色跑起来飘不飘、撞到墙之后反馈对不对、布料和头发会不会穿模，这些体验层面的东西，几乎全部由物理与动画系统承担。

我在多个中小型团队里参与过引擎模块的搭建和调优，一个很深的体会是：物理和动画这两个子系统，表面上看是独立的，实际上耦合非常紧密。动画驱动骨骼，骨骼带动碰撞体，碰撞体又反过来影响动画状态机的切换。如果架构设计时把这两块完全割裂，后期做复杂交互时会非常痛苦。所以这一篇，我打算从整体架构的角度，把物理系统和动画系统的设计思路、核心模块、数据流转以及实操中容易踩的坑，尽量讲透。

这篇文章适合已经对游戏引擎有基本了解、想深入理解底层机制的开发者，也适合正在做自研引擎或者想改造现有引擎的团队参考。我会尽量用生活化的类比来解释抽象概念，同时给出可以直接参考的模块划分和参数配置思路。需要说明的是，不同引擎的具体实现差异很大，我讲的是基于常见工程实践总结出来的通用架构，具体到某个引擎时，细节需要根据其源码和文档做调整。

1.1 为什么物理与动画要放在一起讲

很多人会问，物理和动画明明是两套东西，为什么架构解析要放在同一篇里？原因很简单：在现代游戏引擎中，这两者共享大量的底层数据结构，比如变换层级、时间步管理、事件系统。物理系统每帧要更新刚体的位置和旋转，动画系统每帧要更新骨骼的姿态，而骨骼往往又绑定了物理碰撞体。如果两者的更新顺序、时间步长不一致，就会出现角色动画和物理表现不同步的经典问题——比如角色已经撞到墙了，动画还在往前跑。

从架构分层来看，物理和动画通常都位于引擎的“模拟层”，介于核心层和渲染层之间。核心层提供数学库、内存管理、任务调度；模拟层负责每帧的状态推进；渲染层只负责把当前状态画出来。这种分层的好处是，物理和动画可以独立于渲染帧率运行，比如物理固定以60Hz步进，而渲染可能跑到120Hz，中间通过插值来平滑显示。

1.2 物理系统的核心模块划分

一个完整的物理系统，通常包含以下几个核心模块：

• 碰撞检测模块：负责判断物体之间是否发生接触，包括宽相和窄相两个阶段。
• 约束求解模块：负责处理接触点、关节、摩擦力等约束，计算出最终的速度和位置修正。
• 积分器模块：负责根据力和速度更新物体的位置和旋转。
• 场景查询模块：提供射线检测、形状扫描、重叠查询等接口，供游戏逻辑调用。
• 事件回调模块：在碰撞发生、进入触发区等时刻通知上层逻辑。

这些模块的划分不是随意的，而是基于“职责单一”和“数据流向清晰”两个原则。碰撞检测只负责找出潜在的接触对，约束求解只负责根据接触对计算修正量，积分器只负责推进状态。这样拆分之后，每个模块都可以独立测试和替换，比如把离散碰撞检测换成连续碰撞检测，只需要改动碰撞检测模块，不影响其他部分。

1.3 动画系统的核心模块划分

动画系统同样有清晰的分层：

• 动画数据层：存储关键帧、曲线、蒙皮信息等原始数据。
• 动画采样层：根据当前时间从曲线中采样出骨骼的局部变换。
• 动画混合层：把多个动画片段按权重混合，支持叠加、遮罩等操作。
• 状态机层：管理动画状态之间的切换条件，比如从“待机”切换到“奔跑”。
• 骨骼更新层：把局部变换计算成全局变换，并处理蒙皮矩阵。
• IK与后处理层：在基础动画之上做反向动力学修正、布料模拟等。

这个分层的关键在于，采样和混合是纯数学操作，不涉及游戏逻辑；状态机是逻辑层，决定当前该播放哪些动画；骨骼更新是性能热点，需要重点优化。把这几层分开，可以让动画师和程序员各司其职，动画师调曲线和状态机，程序员优化采样和骨骼更新。

1.4 两套系统的数据交互设计

物理和动画之间的数据交互，主要通过以下几个通道：

1. 骨骼到碰撞体：动画更新完骨骼后，把关键骨骼的位置同步给物理碰撞体，比如角色的胶囊体、武器的盒体。
2. 物理到动画：物理系统计算出刚体的位置和旋转后，反向驱动骨骼，比如布娃娃系统、被击飞时的物理反馈。
3. 事件通道：物理碰撞事件触发动画状态机切换，比如落地时从“下落”切到“着陆”。
4. 时间同步：物理固定步长和动画可变步长之间需要做时间对齐，避免累积误差。

这四个通道的设计质量，直接决定了角色控制的跟手程度。我见过不少项目，物理和动画各自跑得挺好，但一结合就出问题，根源往往就在时间同步和更新顺序上。

2. 物理系统核心细节与实操要点

物理系统的实现细节非常多，这里我挑几个最关键、也最容易出问题的点来展开。这些内容在官方文档里往往一笔带过，但实际做项目时，每一个都可能让你调半天。

2.1 碰撞检测的宽相与窄相分工

碰撞检测分两个阶段，这是物理引擎的经典设计。宽相负责快速排除明显不相交的物体对，窄相负责精确计算相交细节。

宽相常用的数据结构有：

• 动态AABB树：适合物体数量多、运动频繁的场景，插入和查询都是O(log n)。
• 空间哈希网格：适合物体分布均匀的场景，实现简单，但物体大小差异大时效率下降。
• 扫描与剪枝：适合物体沿单一轴分布的场景，比如横版游戏。

窄相则根据形状类型选择算法：

我个人的经验是，角色和场景的碰撞尽量用胶囊和凸包，不要用三角网格直接碰，性能差距可能达到一个数量级。三角网格碰撞只在必要的时候用，比如角色和复杂地形的精确接触。

2.2 约束求解的迭代次数与稳定性

约束求解是物理系统里最“玄学”的部分。同样的场景，迭代次数不同，表现可能天差地别。常见的求解器有：

• 顺序冲量求解器：实现简单，适合中小规模场景，但收敛慢。
• 投影高斯-赛德尔：收敛快，适合大规模场景，但需要更多内存。
• 基于位置的动力学：适合布料和软体，但刚体表现偏软。

迭代次数一般设置在4到20之间。迭代次数太少，物体会“软”，堆叠时会下陷；迭代次数太多，性能开销大，而且可能引入抖动。我的做法是，先设8次，然后根据场景复杂度调整。如果场景里有大量堆叠物体，可以提高到12到16次；如果只是简单的角色碰撞，4到6次就够了。

还有一个关键参数是松弛因子，它控制每次迭代的修正幅度。松弛因子太大，物体容易抖动；太小，收敛慢。一般设在0.8到1.0之间，具体要看求解器类型。

注意：约束求解的稳定性还和物体的质量比有关。如果一个质量1的物体和一个质量1000的物体碰撞，求解器需要更多迭代才能稳定。解决办法是限制质量比，或者用质量缩放。

2.3 固定时间步长与插值显示

物理系统必须用固定时间步长，这是铁律。原因很简单：可变步长会让物理表现依赖帧率，同样的力在不同帧率下产生不同的加速度，这是不可接受的。

固定步长的典型值是1/60秒，也就是60Hz。如果渲染帧率高于60Hz，物理状态在两次步进之间需要插值显示。插值的做法是：

// 伪代码：物理状态插值 float alpha = accumulator / fixedDeltaTime; Vector3 renderPos = Lerp(prevPos, currPos, alpha); Quaternion renderRot = Slerp(prevRot, currRot, alpha);

这里的accumulator是累积的时间，每次渲染时把帧时间加进去，超过固定步长就步进一次物理，剩下的时间用于插值。

这个机制看起来简单，但实际做的时候有几个坑：

• 插值只影响显示，不影响物理状态，所以射线检测要用物理状态，不能用插值后的位置。
• 如果物理步进次数太多，比如一帧跑了5次物理，说明帧率太低，需要考虑降级或者优化。
• 插值会让快速运动的物体看起来有延迟，这是正常的，不要试图用外推来消除，外推会导致穿透。

2.4 场景查询的性能优化

场景查询包括射线检测、形状扫描、重叠查询，这些接口游戏逻辑调用非常频繁。优化手段主要有：

• 分层过滤：给物体设置碰撞层和掩码，查询时只检测指定层，减少候选数量。
• 缓存查询结果：对于每帧重复的查询，比如角色脚下的地面检测，可以缓存结果，隔几帧更新一次。
• 异步查询：把查询放到任务线程里，避免阻塞主线程，但要注意数据同步。
• 批量查询：把多个查询合并成一次遍历，减少重复的树遍历开销。

我做过一个测试，在一个有5000个物体的场景里，不加过滤的射线检测每次要遍历几百个节点，加了分层过滤之后降到几十个，性能提升非常明显。所以碰撞层设计不是可选项，是必选项。

2.5 物理材质与摩擦系数

物理材质定义了摩擦系数、弹性系数、密度等属性。这些参数的设置直接影响手感：

• 摩擦系数：0表示无摩擦，1表示完全摩擦。角色站在地面上，摩擦系数一般设0.6到0.8；冰面设0.05到0.1。
• 弹性系数：0表示完全非弹性，1表示完全弹性。球类物体一般设0.6到0.8，角色设0。
• 密度：影响质量计算，进而影响碰撞响应。角色密度一般设1.0左右，和水的密度接近。

这里有个容易忽略的点：摩擦系数是成对使用的，两个物体接触时，实际摩擦系数是两者的组合。常见组合方式有相乘、取平均、取最小值。不同引擎策略不同，做跨引擎移植时要注意。

实操心得：调物理参数时，不要只调一个物体的参数，要同时看接触双方。我遇到过角色在某种地面上滑得离谱，最后发现是地面材质的摩擦系数设成了0.1，而不是角色的问题。

3. 动画系统核心细节与实操要点

动画系统的复杂度不比物理低，尤其是现代游戏对动画质量要求越来越高，状态机、混合树、IK、布料模拟，每一项都有大量细节。这里我重点讲几个在实际项目中最影响效果和性能的部分。

3.1 动画曲线的采样与压缩

动画数据本质上是一堆随时间变化的曲线。每条曲线对应一个骨骼的一个通道，比如位置X、旋转四元数的W分量等。采样就是从曲线中取出当前时间对应的值。

采样方式有：

• 最近邻采样：取最近的关键帧，速度快但质量差，适合低精度场景。
• 线性插值：在两个关键帧之间线性过渡，适合位置和缩放。
• 球面线性插值：用于旋转四元数，保证插值路径最短。
• 三次样条插值：平滑度最好，但计算量大，适合过场动画。

实际项目中，位置和缩放用线性插值，旋转用球面线性插值，这是标配。三次样条只在电影级过场里用，实时游戏很少用。

动画数据的压缩也很关键。原始动画数据可能占用几十MB，压缩后可以降到几MB。常用压缩手段：

• 关键帧抽稀：去掉变化平缓的中间帧，用插值补回来。
• 量化：把浮点数降到16位甚至8位，精度损失在可接受范围内。
• 曲线合并：把变化相似的曲线合并成一条，减少采样次数。

我做过一个测试，一个包含200个骨骼、每个骨骼10个通道的动画，原始数据约8MB，经过抽稀和量化后降到1.2MB，视觉上几乎看不出差别。所以压缩不是可选项，是必选项。

3.2 动画混合树的构建与权重管理

混合树是动画系统的核心，它决定了多个动画片段如何叠加。常见的混合方式有：

• 线性混合：按权重把多个动画的采样结果加权平均，适合待机到奔跑的过渡。
• 叠加混合：把一个动画的增量叠加到另一个动画上，适合呼吸、受伤等叠加效果。
• 遮罩混合：只混合指定骨骼，比如上半身射击、下半身奔跑。
• 状态混合：根据状态机的当前状态和下一状态做过渡。

权重管理是混合树里最容易出问题的地方。权重之和必须归一化，否则会出现动画幅度异常。比如两个动画各0.5权重，混合结果应该是两者的平均；如果权重是0.8和0.8，不归一化的话结果会放大。

还有一个常见问题是混合空间的设计。比如用速度和方向两个维度来混合走、跑、冲刺，需要构建一个二维混合空间。混合空间的采样点要均匀分布，否则会出现某些区域动画质量差。

实操心得：混合树的调试一定要可视化。把当前权重、当前播放时间、混合空间的位置都画出来，能省下大量猜测时间。我见过不少团队靠打印日志调混合树，效率极低。

3.3 状态机的设计与过渡条件

状态机管理动画状态之间的切换。一个典型的状态机包含：

• 状态：比如待机、奔跑、跳跃、攻击。
• 过渡：状态之间的连线，带有条件和过渡时间。
• 参数：驱动过渡的变量，比如速度、是否在地面、是否按下攻击键。

过渡条件的设计要避免两个极端：条件太复杂，状态机难以维护；条件太简单，会出现频繁切换。我的经验是，每个过渡最多用两到三个参数，参数之间用与或组合，不要嵌套太深。

过渡时间也很关键。过渡时间太短，动画切换生硬；太长，响应迟钝。一般设0.1到0.3秒，具体看动画类型。攻击动作的过渡要短，0.05到0.1秒；待机到奔跑可以长一点，0.2到0.3秒。

还有一个高级技巧是过渡中断。当角色在过渡过程中收到新的输入时，应该中断当前过渡，直接切到新状态。这需要在状态机里加中断优先级，优先级高的过渡可以打断优先级低的。

3.4 反向动力学与骨骼后处理

反向动力学用于在基础动画之上做修正，比如让角色的脚贴合不平的地面、让手准确抓住物体。常见的IK类型有：

• 双骨骼IK：用于手臂和腿，计算量小，效果稳定。
• FABRIK：用于多骨骼链，迭代收敛，适合尾巴和触手。
• CCD：循环坐标下降，实现简单，但可能陷入局部最优。

IK的求解顺序很重要。一般先解算腿，再解算手臂，最后解算脊柱。因为腿的稳定性要求最高，手臂次之，脊柱最灵活。

IK的权重也要动态调整。比如角色从奔跑切换到待机时，IK权重应该逐渐增加，避免突然修正导致抖动。权重过渡时间一般设0.1到0.2秒。

注意：IK修正后要重新计算蒙皮矩阵，否则渲染出来的骨骼位置和IK结果不一致。这个步骤容易漏，漏了之后会出现“IK算了但没生效”的诡异现象。

3.5 布料与头发模拟的架构选择

布料和头发模拟介于物理和动画之间。它们既可以用物理引擎的柔体来模拟，也可以用动画系统的后处理来模拟。两种方案各有优劣：

我个人的选择是：主角的重要布料用物理柔体，次要角色和头发用骨骼链模拟。骨骼链模拟的核心是给每根骨骼加弹簧和阻尼，用Verlet积分更新位置，然后约束骨骼长度。参数方面，弹簧系数一般设100到500，阻尼设0.1到0.5，具体看材质。

4. 物理与动画的协同与常见问题排查

物理和动画单独调好之后，真正的挑战才刚开始：两者协同工作时，会出现各种单独测试时看不到的问题。这一章我整理了几个最典型的场景和排查思路。

4.1 更新顺序与时间步对齐

物理和动画的更新顺序，直接决定了最终表现。常见的顺序有两种：

方案A：先物理后动画

1. 物理步进，更新刚体位置。
2. 动画采样，更新骨骼局部变换。
3. 骨骼全局变换计算。
4. 物理同步骨骼位置（用于下一帧）。

方案B：先动画后物理

1. 动画采样，更新骨骼局部变换。
2. 骨骼全局变换计算。
3. 物理同步骨骼位置。
4. 物理步进，更新刚体位置。

方案A适合物理驱动的角色，比如布娃娃；方案B适合动画驱动的角色，比如常规角色控制。大多数游戏用方案B，因为角色动画是主导，物理只是辅助。

时间步对齐方面，物理固定步长，动画可变步长。如果动画帧率高于物理帧率，动画采样时要用物理的插值状态；如果低于，物理要在一帧内步进多次。这个逻辑要封装好，不要让上层逻辑感知到。

4.2 角色穿透与抖动问题排查

角色穿透和抖动是物理动画协同中最常见的问题。排查思路如下：

我遇到过一个经典案例：角色在斜坡上会缓慢下滑，即使输入为零。排查后发现是摩擦系数设得太低，而且斜坡角度刚好在摩擦角附近。解决办法是提高摩擦系数，同时在角色控制器里加一个“静止时锁定位置”的逻辑。

4.3 动画事件与物理事件的时序问题

动画事件（比如脚步落地、武器挥砍）和物理事件（比如碰撞进入、碰撞退出）的时序，如果处理不当，会出现逻辑错误。比如角色在落地动画的“落地帧”触发音效，但物理上角色还没真正接触地面，导致音效提前播放。

解决办法是统一事件分发时机。我的做法是：

1. 物理步进完成后，收集所有物理事件。
2. 动画采样完成后，收集所有动画事件。
3. 在帧末统一分发事件，按时间戳排序。
4. 上层逻辑处理事件时，可以查询当前物理状态和动画状态。

这样能保证事件处理时，物理和动画状态都是一致的。

4.4 性能热点定位与优化

物理和动画都是性能大户。定位热点的方法：

• 物理：用性能分析工具看碰撞检测、约束求解、场景查询各占多少时间。一般碰撞检测占40%，约束求解占40%，场景查询占20%。
• 动画：看采样、混合、骨骼更新、IK各占多少。骨骼更新通常是大头，占50%以上。

优化手段：

• 物理：减少活跃刚体数量，用睡眠机制让静止物体不参与模拟；降低求解迭代次数；用分层过滤减少碰撞对。
• 动画：用多线程并行采样和混合；用SIMD加速骨骼矩阵计算；用LOD减少远处角色的骨骼数量。

我做过一个优化，把骨骼更新从单线程改成多线程，200个角色的场景从8ms降到3ms，效果非常明显。但多线程要注意数据竞争，每个角色的骨骼数据要独立，不能共享。

4.5 跨平台架构差异与适配

不同平台的硬件架构差异，对物理和动画系统的影响很大。比如ARM架构和x86架构在浮点运算、SIMD指令集上就有区别。做跨平台引擎时，要注意：

• 浮点精度：不同平台的浮点运算结果可能有微小差异，物理模拟要容忍这种差异，避免确定性要求过高的设计。
• SIMD指令：x86有SSE/AVX，ARM有NEON，要封装统一的SIMD接口，底层用条件编译适配。
• 内存对齐：不同平台对内存对齐要求不同，物理和动画的数据结构要按最大对齐要求分配。
• 线程模型：不同平台的线程调度策略不同，任务粒度的划分要适配。

实操心得：跨平台适配最怕的是“在我机器上好好的”。一定要在目标平台上做完整测试，尤其是物理模拟的稳定性，不同平台可能表现不同。

5. 从零搭建一个最小物理动画协同框架

前面讲了这么多理论，这一章我给出一个可以直接参考的最小框架，把物理和动画的核心协同逻辑串起来。这个框架不是完整引擎，但包含了最关键的模块和接口设计。

5.1 核心数据结构设计

// 变换组件：物理和动画共享 struct Transform { Vector3 position; Quaternion rotation; Vector3 scale; }; // 刚体组件：物理系统使用 struct RigidBody { Transform transform; Vector3 velocity; Vector3 angularVelocity; float mass; float inverseMass; Transform prevTransform; // 用于插值 }; // 骨骼组件：动画系统使用 struct Skeleton { std::vector<Transform> localTransforms; std::vector<Transform> globalTransforms; std::vector<int> parentIndices; }; // 动画状态机 struct AnimationStateMachine { int currentState; int nextState; float transitionTime; float transitionDuration; std::unordered_map<std::string, float> parameters; };

这个设计的关键是Transform结构被物理和动画共享，保证数据一致性。RigidBody里存了prevTransform，用于插值显示。Skeleton里存了局部和全局变换，全局变换是采样后计算出来的。

5.2 每帧更新流程

void UpdateFrame(float deltaTime) { // 1. 累积时间，决定物理步进次数 accumulator += deltaTime; int stepCount = 0; while (accumulator >= fixedDeltaTime && stepCount < maxSteps) { // 2. 物理步进 PhysicsStep(fixedDeltaTime); accumulator -= fixedDeltaTime; stepCount++; } // 3. 计算插值因子 float alpha = accumulator / fixedDeltaTime; // 4. 动画采样和混合 AnimationSample(deltaTime); AnimationBlend(); // 5. 骨骼全局变换计算 SkeletonUpdate(); // 6. IK和后处理 IKSolve(); ClothSimulate(deltaTime); // 7. 物理同步骨骼位置 SyncPhysicsToSkeleton(); // 8. 事件分发 DispatchEvents(); // 9. 渲染数据准备（带插值） PrepareRenderData(alpha); }

这个流程里，物理步进可能执行多次，动画只执行一次。插值因子用于渲染时平滑显示。事件分发放在最后，保证物理和动画状态都已更新完毕。

5.3 关键参数配置参考

这些参数不是绝对的，要根据项目实际情况调整。比如移动端可以把物理步长降到1/30秒，迭代降到4次，换取性能。

5.4 调试工具与可视化

调试工具的重要性怎么强调都不为过。我建议至少实现以下可视化：

• 碰撞体线框：显示所有刚体的碰撞形状，颜色区分静态和动态。
• 接触点标记：显示当前帧的所有接触点，大小表示穿透深度。
• 骨骼层级：显示骨骼的父子关系和当前姿态。
• 动画权重：显示混合树各节点的当前权重。
• 状态机状态：显示当前状态和过渡进度。
• 性能计数器：显示物理和动画各模块的耗时。

这些工具在开发期能省下大量时间。我见过不少团队前期不重视调试工具，后期调bug时靠打印日志，效率极低。

实操心得：调试工具要支持运行时开关，不要影响正常游戏性能。可以用宏或者运行时标志控制，发布版本自动关闭。

6. 物理动画系统的扩展方向与个人经验

这个框架搭起来之后，可以根据项目需求做各种扩展。这里我列几个常见的扩展方向，以及我在实际项目中的一些体会。

6.1 网络同步与确定性

如果做多人游戏，物理和动画需要网络同步。物理同步的难点是确定性：不同客户端上同样的输入要产生同样的结果。这要求物理模拟完全确定，包括浮点运算顺序、随机数种子、迭代次数都要一致。

实现确定性的手段：

• 用定点数代替浮点数，避免浮点误差。
• 固定随机数种子，所有客户端一致。
• 固定更新顺序，不能依赖哈希表遍历顺序。
• 定期做状态校验，发现不一致时回滚重算。

动画同步相对简单，因为动画是表现层，不需要严格确定性。一般同步状态机的参数和当前时间就够了，客户端各自采样。

6.2 大规模场景的物理优化

开放世界游戏里，物理对象可能上万。全量模拟不现实，需要做分块和LOD：

• 空间分块：把场景分成网格，只模拟玩家附近的块。
• 物理LOD：远处的物体用简化碰撞体，甚至完全不模拟。
• 睡眠机制：静止物体进入睡眠，不参与模拟，被碰撞时唤醒。
• 异步模拟：把物理模拟放到独立线程，和主线程并行。

这些手段组合使用，可以把物理开销控制在可接受范围内。我做过一个开放世界场景，用分块加睡眠之后，活跃刚体从8000降到500，物理耗时从15ms降到2ms。

6.3 动画系统的机器学习扩展

最近几年，用机器学习做动画越来越流行。比如用神经网络做运动匹配、用强化学习做角色控制。这些技术可以看作动画系统的扩展层，在传统状态机之上做增强。

我的看法是，机器学习适合做传统方法难以处理的场景，比如复杂地形上的自然运动、大量角色的群体动画。但传统状态机和混合树仍然是基础，不能完全替代。实际项目中，可以把机器学习作为状态机的一个特殊状态，或者作为IK的替代方案。

6.4 个人经验与建议

最后分享几点我在实际项目中的体会：

第一，物理和动画的架构设计要留足扩展空间。不要一开始就把接口定死，比如碰撞形状、动画混合方式，都要支持后续增加新类型。

第二，性能优化要尽早做。物理和动画的性能问题往往在项目中期才暴露，那时候改架构成本很高。建议在原型阶段就做性能测试，确定性能预算。

第三，调试工具要持续投入。物理和动画的问题往往很隐蔽，没有好的调试工具，排查效率极低。我建议每个模块都要有对应的可视化工具。

第四，跨平台适配要提前规划。如果项目要上多个平台，物理和动画的底层实现要抽象好，避免平台相关代码散落在各处。

第五，参数调优要数据驱动。物理材质、动画过渡时间这些参数，不要凭感觉调，要建立测试场景，用数据说话。我见过太多项目靠“感觉”调参数，最后效果不稳定。

这个系列写到第三篇，物理和动画系统的内容其实还有很多可以展开，比如具体的碰撞算法实现、动画压缩的数学原理、IK的数值解法等。如果后续有机会，可以针对某个具体模块做更深入的源码级分析。对于正在做引擎开发的朋友，我的建议是先跑通最小闭环，再逐步优化，不要一开始就追求完美架构。