开头从“轮子焦虑”到“手写引擎”在游戏开发这个圈子里聊到物理引擎第一反应多半是Bullet、PhysX、Box2D再不济也是Chipmunk。Rust生态里虽然也有Rapier这种成熟方案但我发现一个很有意思的现象真正动手写过一次小型物理引擎的开发者回去用现成引擎时往往更从容遇到调参、性能瓶颈、甚至诡异穿模问题时也比别人更快定位原因。这次我想聊的就是基于Rust从零实现一个轻量级2D游戏物理引擎的全过程——不是教科书式的泛泛而谈而是一个能跑、能看效果、能把Demo摆上桌面的实战项目。这个项目本身解决的核心痛点是“黑盒焦虑”当你的游戏里出现一个球以诡异姿态穿过墙壁或者刚体堆叠时疯狂抖动你能否在十分钟内判断出是宽相位出了问题、约束求解器迭代不够、还是时间步长没固定答案往往是“不能”因为现成引擎内部是个黑盒。自己动手写一个轻量级引擎不是为了替代Rapier或Box2D而是为了把碰撞检测、冲量求解、约束处理这些机制彻底摊开在面前。这个项目同时适合两类人一类是想深入理解物理模拟底层原理的游戏开发者另一类是刚学完Rust基础、想找一个有挑战又不至于劝退的综合练习项目的学习者。整个引擎的骨架包括刚体组件、AABB包围盒与宽相位碰撞检测、SAT分离轴窄相位、接触点生成、基于冲量的迭代求解器、以及一个可选的半隐式欧拉积分器。听起来知识点不少但拆开之后每一块都能独立验证这也是我认为它适合作为Rust中级实战项目的原因。另外Rust的所有权模型和严格的类型系统在实现物理引擎这种大量组件互相关联、后台数据频繁更新的场景下反而会逼你提前设计好数据布局——这种“被语言逼出来的架构感”用Python写玩具引擎时是很难体会到的。下面直接进入正题我会按照实际开发顺序来复盘整个项目的设计与实现每一步都会解释当时为什么这么选、踩了什么坑、后续又如何修正。1. 项目整体设计思路先定边界再谈创新1.1 功能边界的圈定什么叫做“轻量级”动手之前最先要确定的不是技术栈而是“这个引擎到底要做到什么程度”。我给自己定的范围是2D刚体物理支持圆与凸多边形两种碰撞体支持重力与自定义外力碰撞响应使用冲量法刚体间支持简单的静摩擦与动摩擦不考虑关节约束、不考虑流体、不考虑破碎与形变。之所以砍掉这么多功能是因为每增加一个子系统调试成本几乎是指数级上升——关节约束和碰撞求解是两套独立但又互相耦合的数学体系第一次写引擎就把它们全塞进来容易出现“哪里都在报错但说不清哪里错了”的局面。这个边界带来的直接好处是整个引擎核心代码控制在2000行左右不包括示例Demo单人维护不需要建立复杂的模块依赖图。同时因为功能边界清晰每一块都可以独立测试宽相位检测可以单独喂AABB数据验证窄相位可以只跑凸多边形对凸多边形的穿透深度计算冲量求解器可以暂时关闭重力验证单次碰撞的反弹效果。这种“可独立验证”的特性极大降低了Rust借用检查器带来的额外心智负担——每次只改动一个模块出问题时范围一定是可控的。另一个需要提前做好的决策是数据存储方式。做游戏物理引擎时刚体之间需要通过索引相互引用同时又需要在碰撞检测阶段快速遍历所有物体。用Rust实现时有两条常规路线一条是用VecEntity加上HashMapEntity, usize做间接索引另一条是直接用slotmap这类键值复用结构。我最终选择了后者理由很实际物理引擎运行过程中会频繁删除临时刚体例如Debug模式下点击生成的测试球如果使用HashMapEntity, usize删除操作需要额外维护空闲列表而slotmap天生支持复用键位语义上也更接近“Entity”这个概念。用Rust标准库的HashMap并不是不行但会让Demo代码和数据层耦合更大读起来也不够清爽。1.2 为什么选择Rust性能之外的隐性红利聊到“用Rust写游戏物理引擎”很多人第一反应是性能。确实Rust的零成本抽象、无GC、直接内存布局在物理模拟这种计算密集场景下优势明显。但对我来说更大的红利来自两方面第一是枚举与模式匹配让状态管理变得极其清晰。刚体可以定义成enum RigidBodyType { Dynamic, Static, Kinematic }然后在碰撞响应阶段用match处理不同类型之间的交互规则。C里实现同样逻辑通常要靠虚函数加类型枚举或者加各种if判断时间一长代码容易腐化。Rust编译器会强制你处理所有枚举分支不小心漏掉一种组合编译直接报错比运行时黑屏定位问题效率高得多。第二是所有权系统让资源释放变得安全。物理引擎运行期间会频繁创建临时结构比如每帧的接触点列表、流形数据如果用C手写内存管理一个delete时机错误就会出现悬垂指针然后在几秒钟后以极其诡异的方式崩溃。Rust的RAII和借用检查让这类问题从“运行时排查”变成了“编译期修正”虽然初次上手时借用检查器会让人烦躁但当你真的实现过一个中等复杂度的系统之后会发现它逼着你把数据流动理得一清二楚这种工程上的清晰度是实打实的时间节省。当然Rust也有不适合物理引擎的一面——最典型的是递归算法。如果你习惯用递归做四叉树或BVH遍历Rust的递归深度限制和所有权的交互会让代码变得很不自然。我在项目中选择了迭代式遍历AABB数组绕开了这个问题。如果你日后想给引擎加BVH加速结构建议优先设计成迭代式。1.3 模块划分与架构演进整个项目划分为五个核心模块模块间的依赖是单向的、显式的这一点在Rust的mod体系里天然容易维持数学基础层Vec2、Mat2最小实现即可不需要引入外部线性代数库。刚体层存储质量、速度、位置、形状、摩擦力、恢复系数。碰撞检测层宽相位用AABB遍历窄相位用SAT分离轴定理。碰撞响应层接触点生成流形喂给冲量求解器。求解与积分层半隐式欧拉积分、速度迭代约束求解。值得一提的架构决策是最底层数学层绝不依赖其他任何模块而最上层求解器也不直接操作刚体内的原始数据而是通过公开方法调用。这个设计在最初看起来“过度设计”但到了后期Debug阶段它的价值就体现出来了你可以单独为数学库写单元测试可以单独给SAT写测试用例比如五边形对三角形的穿透计算而不需要构造完整的物理场景。2. 核心细节解析碰撞检测的数学与工程2.1 宽相位碰撞检测用AABB快速排除物理引擎的性能瓶颈通常出现在碰撞检测阶段——如果每一帧都让每对物体做精确的凸多边形分离轴检测100个物体就是大约5000次SAT运算大部分其实根本不必要。宽相位的目标就是用廉价计算快速排除“绝对不可能相交”的物体对。我采用的是最简单的暴力AABB遍历每个刚体维护一个包围盒每帧更新包围盒位置然后双重循环检查包围盒是否重叠。对于轻量级引擎和几百个刚体以内的场景这种做法完全够用。AABB重叠检测本身只是一组比较运算pub fn overlaps(self, other: Aabb) - bool { self.min.x other.max.x self.max.x other.min.x self.min.y other.max.y self.max.y other.min.y }这组代码会放在引擎核心层的宽相位中后续如果刚体数量增大到几千才需要考虑替换成四叉树或扫描剪枝等加速结构。但引入这类结构之前必须想清楚一个问题它们虽然减少了窄相位的调用次数却增加了每帧的索引维护成本在刚体运动剧烈、频繁增删的场景下未必比暴力遍历快。实际测试中我的Demo在500个下落小球场景下稳定60帧这个性能对于轻量级引擎是完全可以接受的。2.2 窄相位碰撞检测SAT分离轴定理真正进入精确检测阶段圆与凸多边形的碰撞处理方式不同。圆对圆的碰撞最简单——两圆心距离与半径和比较即可。凸多边形之间则采用分离轴定理SAT核心逻辑是如果两个凸多边形不相交那么一定存在一条分离轴使得两者在该轴上的投影不重叠而分离轴的候选方向是每个多边形的法线。SAT的实现相比理论理解要多花一些心思尤其需要注意“穿透深度与碰撞法线”的提取。标准的SAT流程是遍历多边形A的所有边取每条边的法线作为候选轴。遍历多边形B的所有边同样取法线作为候选轴。对每个候选轴计算两个多边形各自在该轴上的投影区间。如果存在某个轴上的投影完全不重叠直接判定不相交。如果全部重叠找到重叠量最小的轴它就是碰撞法线重叠量就是穿透深度。这里有一个细节经常坑到新手边的法线需要归一化否则不同轴上计算出的重叠量没有可比性导致碰撞法线指向错误。我最初跳过归一化想省一点性能结果出现了一批“斜着弹开”的诡异物理表现。处理多边形对圆的碰撞时可以退化为找到多边形上离圆心最近的点判断这个点到圆心的距离是否小于半径。这个最近点可能是顶点也可能是边上的垂足点。实际操作中用点到线段距离的方式遍历每条边取最小值即可。下面这段代码展示了SAT中计算投影区间与重叠量的核心逻辑pub fn project_on_axis(vertices: [Vec2], axis: Vec2) - (f32, f32) { let mut min axis.dot(vertices[0]); let mut max min; for vertex in vertices.iter().skip(1) { let projection axis.dot(*vertex); if projection min { min projection; } if projection max { max projection; } } (min, max) } pub fn penetration_depth(a: [Vec2], b: [Vec2], axis: Vec2) - f32 { let (a_min, a_max) project_on_axis(a, axis); let (b_min, b_max) project_on_axis(b, axis); let overlap (a_max.min(b_max) - a_min.max(b_min)); if overlap 0.0 { 0.0 } else { overlap } }2.3 接触点生成从“知道碰了”到“知道在哪碰”SAT能够给出穿透深度和碰撞法线但还不能直接用于物理响应——求解器需要的是接触点或接触流形。对于圆对圆的碰撞接触点就是两个圆心连线与圆面的交点对于多边形对多边形接触点通常是穿透区域中对应的两个顶点或边上的交点。生成接触点时容易犯的错误是“生成了多个接触点但求解器没排序”。如果同一帧同一个碰撞对产生了两个接触点求解器需要用一个点来代表整个流形否则会重复施加冲量导致物体抖动。我的处理方式是如果检测到两个接触点取穿透深度更深的那一个作为主接触点并将另一个作为从接触点用于摩擦方向计算。这一步不做好的话在多个物体堆叠的场景中会明显出现“物体像果冻一样抖动”的现象根本原因就是同一接触点被重复求解了多次。这个坑我在调试堆叠方块Demo时踩得最深花了两天时间终于通过打印每帧接触点数量和冲量大小定位到问题。3. 冲量求解器与刚体运动让物体会“弹”会“停”3.1 半隐式欧拉积分简单但可靠在刚体动力学模拟中积分器负责根据加速度更新速度和位置。常见的选项有显式欧拉、半隐式欧拉也叫symplectic Euler、以及RK4等更高阶方法。物理引擎中RK4并不常用因为性能消耗大且游戏场景中物理模拟的精度要求远没有达到需要高阶积分器的程度。我选择半隐式欧拉——先更新速度再用新速度更新位置body.velocity body.inv_mass * force * dt; body.velocity * 0.999; // 简易线性阻尼 body.position body.velocity * dt;注意这里的dt必须是固定时间步长。如果直接使用帧间隔时间比如60fps下约16.7ms帧率波动会导致模拟的不稳定性——物体在高帧率下弹得更高低帧率下又显得沉重。更规范的做法是固定时间步长加累积器累加器按固定步长消费真实流逝时间保证模拟结果与帧率无关。这部分代码量不大但非常关键下面是一个标准实现const FIXED_DT: f32 1.0 / 60.0; let mut accumulator 0.0; fn tick(delta_time: f32) { accumulator delta_time; while accumulator FIXED_DT { step_physics(FIXED_DT); accumulator - FIXED_DT; } }3.2 冲量求解牛顿第三定律的代码表达碰撞响应的核心是冲量求解。给定碰撞法线n、相对速度v_rel我们希望计算出冲量j使得分离速度满足恢复系数约束。对于两个物体的碰撞公式为j -(1 e) * (v_rel · n) / (inv_mass_a inv_mass_b)其中e是恢复系数0表示完全无反弹1表示完全弹性。这个冲量作为向量施加在两个物体上方向为法线方向大小恰好使得“接近速度”变成“分离速度”。这里有一个新手很容易忽略的细节恢复系数本身并不是物理解释而是对碰撞过程中能量损失的简化建模。不同的材料组合应有不同的恢复系数因此我把恢复系数存储在刚体上而不是引擎全局配置中。施加冲量后的代码如下if let Some(contact) manifold.get_primary_contact() { let rel_velocity (b.velocity - a.velocity).dot(contact.normal); let restitution_velocity -contact.restitution * rel_velocity; let j -(1.0 contact.restitution) * rel_velocity / (a.inv_mass b.inv_mass); let impulse contact.normal * j; a.velocity - impulse * a.inv_mass; b.velocity impulse * b.inv_mass; }这里的关键在于判断相对速度的方向。如果两个物体正在相互接近相对速度在法线方向上的投影为负才需要施加冲量如果它们已经在分离就不应该加冲量否则会“吸引”物体。这个判断在前文代码中没有显式写出但在实际实现时务必加上if rel_velocity 0.0 { /* 施加冲量 */ }3.3 摩擦让加速度和减速度符合直觉摩擦是个容易让物理引擎看起来“假”或者“过于滑”的关键因素。一个没有摩擦的引擎里物体碰撞后会像冰球一样无限滑动视觉效果极其离谱。我实现的是库仑摩擦模型分为静态摩擦和动态摩擦静摩擦物体尚未相对滑动时提供足够大的力阻止滑动发生。动摩擦滑动已经发生时施加与滑动方向相反的减速度。在实际冲量求解流程中碰撞响应先处理法向冲量再处理切向冲量。切向冲量的大小不能超过法向冲量乘以摩擦系数——这是库仑摩擦的本质约束。在代码实现上先计算切向相对速度然后计算理论上的切向冲量再用摩擦系数截断它let tangent (rel_velocity - contact.normal * rel_dot_n).normalize(); let rel_dot_t rel_velocity.dot(tangent); let mut jt -rel_dot_t / (a.inv_mass b.inv_mass); let max_friction contact.restitution * contact.normal_impulse; // 摩擦锥约束 let friction_impulse jt.clamp(-max_friction, max_friction); a.velocity - tangent * friction_impulse * a.inv_mass; b.velocity tangent * friction_impulse * b.inv_mass;这里normal_impulse是法向冲量的大小。摩擦冲量永远被限制在这个值乘以摩擦系数的范围内否则物体会被“吸住”——这是很多初学者实现摩擦时最常见的错误。4. 常见问题与性能排查实测中踩过的深坑4.1 穿模问题子弹穿墙背后的时间离散化轻量级物理引擎遇到最多的问题就是快速运动的物体直接穿透障碍物也就是俗称的“子弹穿墙”。原因很简单固定时间步长内物体移动了很大的距离宽相位检测的AABB在这一帧没有与墙体AABB重叠窄相位完全没有机会参与检测。解决这类问题的标准手段包括连续碰撞检测CCD对快速移动的物体进行射线/扫掠检测。降低最大速度上限惩罚移动速度异常大的物体。减小固定时间步长提高物理帧率但会增加CPU负担。在轻量级引擎中我更推荐速度上限方案——简单可靠而且在游戏逻辑中通常没必要让物体以数百米每秒的速度运动。给刚体加一个max_velocity字段每帧积分后限制速度大小不超过该值if body.velocity.length_squared() max_velocity_squared { body.velocity body.velocity.normalize() * max_velocity; }这个方法几乎是零成本同时能避免绝大多数的穿模场景。4.2 堆叠不稳定震动与漂移的来源刚体堆叠是检验物理引擎质量的试金石。小球堆叠还好方块堆叠时经常会出现持续抖动甚至整体漂移的问题。我用三组参数排查解决接触点数量是否正确、迭代次数是否足够、位置修正是否缺失。堆叠稳定性通常需要位置修正position correction。冲量求解器只修正速度层面的穿透但每一帧都会重新检测到微小穿透如果穿透被持续忽略物体就会在重力作用下慢慢陷入地面。最朴素的位置修正是“伪冲量”——按穿透深度按比例将物体推开let correction penetration / (a.inv_mass b.inv_mass); a.position - contact.normal * correction * a.inv_mass * percent; b.position contact.normal * correction * b.inv_mass * percent;这里的percent通常取0.2到0.8之间的一个经验值太大容易造成“弹跳感”太小又达不到修正效果。我取0.35测试下来稳定性与响应速度比较平衡。4.3 性能分析与优化不是所有地方都需要极致在项目性能优化阶段我用火焰图查看了热点函数。结果并不意外SAT检测对凸多边形的顶点遍历最耗时。但真正让我惊讶的是主循环中访问刚体数组的方式影响了缓存友好度——把质量、速度、位置这些频繁访问的数据从一个大结构体里拆成连续数组即结构体数组SoA帧时间提升了大约三分之一。Rust中直接手写SoA布局比用封装好的库更灵活而且不会引入额外依赖。但我想强调的是轻量级引擎没必要在初期就做SoA优化它会让代码可读性下降。更合理的路径是先用AoS数组结构体写一个功能正确的版本跑通Demo之后再用性能分析驱动重构而不是一开始就猜瓶颈位置。物理引擎的瓶颈往往跟你想象的不一样。4.4 常见问题速查表现象可能原因排查方向物体持续下沉穿透地面位置修正缺失或迭代次数不够检查接触点穿透深度是否被处理堆叠物体震荡发疯同一接触点被重复求解检查流形是否去重迭代次数是否过高物体碰撞后飞向随机方向碰撞法线未归一化或SAT轴选择错误打印碰撞法线与分离轴做对比高速球体穿透墙体宽相位AABB未覆盖整帧运动路径加速度上限或CCD物体无限滑动摩擦实现缺失或切向冲量截断不正确检查摩擦锥约束帧率升高后物理变“轻”时间步长未固定或累加器实现错误检查固定时间步长设置5. 工程化细节测试、调试与Demo搭建5.1 单元测试策略数学正确性优先物理引擎的bug很容易表现为“连串怪象”比如乱飞、爆炸、穿地定位起来极其痛苦。我的经验是每一层数学模块都要写单元测试这部分工作带来的回报远超成本。测试的核心用例包括AABB的重叠与非重叠、圆的投影区间计算、SAT对特定形状的穿透深度、冲量求解器的单次碰撞反弹速度验证。用Rust自带的测试框架就够不需要额外引入测试库。一个典型的测试是验证恢复系数为1的完全弹性碰撞是否保持动能守恒#[test] fn test_perfectly_elastic_collision_energy() { // 1为动态球从左侧以速度v撞向静止球 // 验证碰撞后两球速度满足弹性碰撞公式 }这类测试不仅是回归保护也是“活文档”——后人接手代码时可以通过测试理解引擎的预期行为。5.2 可视化调试用图形让抽象物理可见物理引擎调试最痛苦的点在于很多问题在数值层面是“一瞬间”的打印日志根本来不及看。我在项目中使用了简单的窗口渲染Demo绘制刚体轮廓、速度向量、碰撞法线和接触点。没有引入重量级游戏引擎仅使用一个轻量级窗口库加即时模式绘图函数代码量便宜且调试效果直观。例如当堆叠不稳时把接触点绘制成红色小圆点就能一眼看出接触点是否生成在正确位置、是否在某帧丢失。碰撞法线用绿色线段绘制可以验证SAT法线方向是否一致。这个可视化层不是核心引擎的一部分但它是我能顺利完成整个项目的重要原因之一。在没有渲染反馈的情况下纯靠打印数字定位穿模问题几乎是不可能的。5.3 模块封装与接口稳定后续扩展的余地整个项目的收尾阶段我花了一些时间重构了对外API确保引擎核心与示例代码解耦。核心引擎仅暴露三组接口物理世界用于添加刚体、设置重力、刚体构建器、每帧step与sync方法。游戏侧只需要创建世界、填充刚体、每帧调用step而不需要知道内部碰撞检测算法实现细节。这个接口稳定性的意义在于后期扩展——后续如果要在引擎里加入关节约束或触发器只需要在物理世界内部增加模块而不需要改动示例代码的调用方式。对Rust项目来说这种模块边界的清晰度在编译周期层面会直接反馈给你类型不匹配、借用冲突、生命周期问题都会被拦截在编译阶段。写在最后的经验与扩展思路这个项目从头到尾做下来我个人最大的收获不是“我会写物理引擎了”而是对游戏物理系统中“计算精度、稳定性、性能”三者之间的取舍有了更真实的感知。之前用现成引擎时调一个参数解决一个问题但常常不清楚背后牺牲了什么。自己实现一遍之后看到任何物理引擎的文档都能大致猜到它内部是怎么构建的调参时也更有底气。最后分享一个我实际测试中摸索出来的小技巧千万不要在引擎早期就过度追求物理精度。先把一切能用最简单方式实现的功能跑起来哪怕穿模、抖动、乱飞都无所谓——重要的是整个系统是完整闭环的。当系统能稳定运行后再逐步替换某个环节比如将暴力AABB遍历换成带加速结构的扫描剪枝这样的学习效率远高于一开始就追求完美架构。如果你也想动手写一个自己的物理引擎Rust是一个非常值得尝试的选择。只要咬住“基本数学、碰撞检测、冲量求解”这三块硬骨头后面的一切都会逐渐顺畅起来。
开头从“轮子焦虑”到“手写引擎”在游戏开发这个圈子里聊到物理引擎第一反应多半是Bullet、PhysX、Box2D再不济也是Chipmunk。Rust生态里虽然也有Rapier这种成熟方案但我发现一个很有意思的现象真正动手写过一次小型物理引擎的开发者回去用现成引擎时往往更从容遇到调参、性能瓶颈、甚至诡异穿模问题时也比别人更快定位原因。这次我想聊的就是基于Rust从零实现一个轻量级2D游戏物理引擎的全过程——不是教科书式的泛泛而谈而是一个能跑、能看效果、能把Demo摆上桌面的实战项目。这个项目本身解决的核心痛点是“黑盒焦虑”当你的游戏里出现一个球以诡异姿态穿过墙壁或者刚体堆叠时疯狂抖动你能否在十分钟内判断出是宽相位出了问题、约束求解器迭代不够、还是时间步长没固定答案往往是“不能”因为现成引擎内部是个黑盒。自己动手写一个轻量级引擎不是为了替代Rapier或Box2D而是为了把碰撞检测、冲量求解、约束处理这些机制彻底摊开在面前。这个项目同时适合两类人一类是想深入理解物理模拟底层原理的游戏开发者另一类是刚学完Rust基础、想找一个有挑战又不至于劝退的综合练习项目的学习者。整个引擎的骨架包括刚体组件、AABB包围盒与宽相位碰撞检测、SAT分离轴窄相位、接触点生成、基于冲量的迭代求解器、以及一个可选的半隐式欧拉积分器。听起来知识点不少但拆开之后每一块都能独立验证这也是我认为它适合作为Rust中级实战项目的原因。另外Rust的所有权模型和严格的类型系统在实现物理引擎这种大量组件互相关联、后台数据频繁更新的场景下反而会逼你提前设计好数据布局——这种“被语言逼出来的架构感”用Python写玩具引擎时是很难体会到的。下面直接进入正题我会按照实际开发顺序来复盘整个项目的设计与实现每一步都会解释当时为什么这么选、踩了什么坑、后续又如何修正。1. 项目整体设计思路先定边界再谈创新1.1 功能边界的圈定什么叫做“轻量级”动手之前最先要确定的不是技术栈而是“这个引擎到底要做到什么程度”。我给自己定的范围是2D刚体物理支持圆与凸多边形两种碰撞体支持重力与自定义外力碰撞响应使用冲量法刚体间支持简单的静摩擦与动摩擦不考虑关节约束、不考虑流体、不考虑破碎与形变。之所以砍掉这么多功能是因为每增加一个子系统调试成本几乎是指数级上升——关节约束和碰撞求解是两套独立但又互相耦合的数学体系第一次写引擎就把它们全塞进来容易出现“哪里都在报错但说不清哪里错了”的局面。这个边界带来的直接好处是整个引擎核心代码控制在2000行左右不包括示例Demo单人维护不需要建立复杂的模块依赖图。同时因为功能边界清晰每一块都可以独立测试宽相位检测可以单独喂AABB数据验证窄相位可以只跑凸多边形对凸多边形的穿透深度计算冲量求解器可以暂时关闭重力验证单次碰撞的反弹效果。这种“可独立验证”的特性极大降低了Rust借用检查器带来的额外心智负担——每次只改动一个模块出问题时范围一定是可控的。另一个需要提前做好的决策是数据存储方式。做游戏物理引擎时刚体之间需要通过索引相互引用同时又需要在碰撞检测阶段快速遍历所有物体。用Rust实现时有两条常规路线一条是用VecEntity加上HashMapEntity, usize做间接索引另一条是直接用slotmap这类键值复用结构。我最终选择了后者理由很实际物理引擎运行过程中会频繁删除临时刚体例如Debug模式下点击生成的测试球如果使用HashMapEntity, usize删除操作需要额外维护空闲列表而slotmap天生支持复用键位语义上也更接近“Entity”这个概念。用Rust标准库的HashMap并不是不行但会让Demo代码和数据层耦合更大读起来也不够清爽。1.2 为什么选择Rust性能之外的隐性红利聊到“用Rust写游戏物理引擎”很多人第一反应是性能。确实Rust的零成本抽象、无GC、直接内存布局在物理模拟这种计算密集场景下优势明显。但对我来说更大的红利来自两方面第一是枚举与模式匹配让状态管理变得极其清晰。刚体可以定义成enum RigidBodyType { Dynamic, Static, Kinematic }然后在碰撞响应阶段用match处理不同类型之间的交互规则。C里实现同样逻辑通常要靠虚函数加类型枚举或者加各种if判断时间一长代码容易腐化。Rust编译器会强制你处理所有枚举分支不小心漏掉一种组合编译直接报错比运行时黑屏定位问题效率高得多。第二是所有权系统让资源释放变得安全。物理引擎运行期间会频繁创建临时结构比如每帧的接触点列表、流形数据如果用C手写内存管理一个delete时机错误就会出现悬垂指针然后在几秒钟后以极其诡异的方式崩溃。Rust的RAII和借用检查让这类问题从“运行时排查”变成了“编译期修正”虽然初次上手时借用检查器会让人烦躁但当你真的实现过一个中等复杂度的系统之后会发现它逼着你把数据流动理得一清二楚这种工程上的清晰度是实打实的时间节省。当然Rust也有不适合物理引擎的一面——最典型的是递归算法。如果你习惯用递归做四叉树或BVH遍历Rust的递归深度限制和所有权的交互会让代码变得很不自然。我在项目中选择了迭代式遍历AABB数组绕开了这个问题。如果你日后想给引擎加BVH加速结构建议优先设计成迭代式。1.3 模块划分与架构演进整个项目划分为五个核心模块模块间的依赖是单向的、显式的这一点在Rust的mod体系里天然容易维持数学基础层Vec2、Mat2最小实现即可不需要引入外部线性代数库。刚体层存储质量、速度、位置、形状、摩擦力、恢复系数。碰撞检测层宽相位用AABB遍历窄相位用SAT分离轴定理。碰撞响应层接触点生成流形喂给冲量求解器。求解与积分层半隐式欧拉积分、速度迭代约束求解。值得一提的架构决策是最底层数学层绝不依赖其他任何模块而最上层求解器也不直接操作刚体内的原始数据而是通过公开方法调用。这个设计在最初看起来“过度设计”但到了后期Debug阶段它的价值就体现出来了你可以单独为数学库写单元测试可以单独给SAT写测试用例比如五边形对三角形的穿透计算而不需要构造完整的物理场景。2. 核心细节解析碰撞检测的数学与工程2.1 宽相位碰撞检测用AABB快速排除物理引擎的性能瓶颈通常出现在碰撞检测阶段——如果每一帧都让每对物体做精确的凸多边形分离轴检测100个物体就是大约5000次SAT运算大部分其实根本不必要。宽相位的目标就是用廉价计算快速排除“绝对不可能相交”的物体对。我采用的是最简单的暴力AABB遍历每个刚体维护一个包围盒每帧更新包围盒位置然后双重循环检查包围盒是否重叠。对于轻量级引擎和几百个刚体以内的场景这种做法完全够用。AABB重叠检测本身只是一组比较运算pub fn overlaps(self, other: Aabb) - bool { self.min.x other.max.x self.max.x other.min.x self.min.y other.max.y self.max.y other.min.y }这组代码会放在引擎核心层的宽相位中后续如果刚体数量增大到几千才需要考虑替换成四叉树或扫描剪枝等加速结构。但引入这类结构之前必须想清楚一个问题它们虽然减少了窄相位的调用次数却增加了每帧的索引维护成本在刚体运动剧烈、频繁增删的场景下未必比暴力遍历快。实际测试中我的Demo在500个下落小球场景下稳定60帧这个性能对于轻量级引擎是完全可以接受的。2.2 窄相位碰撞检测SAT分离轴定理真正进入精确检测阶段圆与凸多边形的碰撞处理方式不同。圆对圆的碰撞最简单——两圆心距离与半径和比较即可。凸多边形之间则采用分离轴定理SAT核心逻辑是如果两个凸多边形不相交那么一定存在一条分离轴使得两者在该轴上的投影不重叠而分离轴的候选方向是每个多边形的法线。SAT的实现相比理论理解要多花一些心思尤其需要注意“穿透深度与碰撞法线”的提取。标准的SAT流程是遍历多边形A的所有边取每条边的法线作为候选轴。遍历多边形B的所有边同样取法线作为候选轴。对每个候选轴计算两个多边形各自在该轴上的投影区间。如果存在某个轴上的投影完全不重叠直接判定不相交。如果全部重叠找到重叠量最小的轴它就是碰撞法线重叠量就是穿透深度。这里有一个细节经常坑到新手边的法线需要归一化否则不同轴上计算出的重叠量没有可比性导致碰撞法线指向错误。我最初跳过归一化想省一点性能结果出现了一批“斜着弹开”的诡异物理表现。处理多边形对圆的碰撞时可以退化为找到多边形上离圆心最近的点判断这个点到圆心的距离是否小于半径。这个最近点可能是顶点也可能是边上的垂足点。实际操作中用点到线段距离的方式遍历每条边取最小值即可。下面这段代码展示了SAT中计算投影区间与重叠量的核心逻辑pub fn project_on_axis(vertices: [Vec2], axis: Vec2) - (f32, f32) { let mut min axis.dot(vertices[0]); let mut max min; for vertex in vertices.iter().skip(1) { let projection axis.dot(*vertex); if projection min { min projection; } if projection max { max projection; } } (min, max) } pub fn penetration_depth(a: [Vec2], b: [Vec2], axis: Vec2) - f32 { let (a_min, a_max) project_on_axis(a, axis); let (b_min, b_max) project_on_axis(b, axis); let overlap (a_max.min(b_max) - a_min.max(b_min)); if overlap 0.0 { 0.0 } else { overlap } }2.3 接触点生成从“知道碰了”到“知道在哪碰”SAT能够给出穿透深度和碰撞法线但还不能直接用于物理响应——求解器需要的是接触点或接触流形。对于圆对圆的碰撞接触点就是两个圆心连线与圆面的交点对于多边形对多边形接触点通常是穿透区域中对应的两个顶点或边上的交点。生成接触点时容易犯的错误是“生成了多个接触点但求解器没排序”。如果同一帧同一个碰撞对产生了两个接触点求解器需要用一个点来代表整个流形否则会重复施加冲量导致物体抖动。我的处理方式是如果检测到两个接触点取穿透深度更深的那一个作为主接触点并将另一个作为从接触点用于摩擦方向计算。这一步不做好的话在多个物体堆叠的场景中会明显出现“物体像果冻一样抖动”的现象根本原因就是同一接触点被重复求解了多次。这个坑我在调试堆叠方块Demo时踩得最深花了两天时间终于通过打印每帧接触点数量和冲量大小定位到问题。3. 冲量求解器与刚体运动让物体会“弹”会“停”3.1 半隐式欧拉积分简单但可靠在刚体动力学模拟中积分器负责根据加速度更新速度和位置。常见的选项有显式欧拉、半隐式欧拉也叫symplectic Euler、以及RK4等更高阶方法。物理引擎中RK4并不常用因为性能消耗大且游戏场景中物理模拟的精度要求远没有达到需要高阶积分器的程度。我选择半隐式欧拉——先更新速度再用新速度更新位置body.velocity body.inv_mass * force * dt; body.velocity * 0.999; // 简易线性阻尼 body.position body.velocity * dt;注意这里的dt必须是固定时间步长。如果直接使用帧间隔时间比如60fps下约16.7ms帧率波动会导致模拟的不稳定性——物体在高帧率下弹得更高低帧率下又显得沉重。更规范的做法是固定时间步长加累积器累加器按固定步长消费真实流逝时间保证模拟结果与帧率无关。这部分代码量不大但非常关键下面是一个标准实现const FIXED_DT: f32 1.0 / 60.0; let mut accumulator 0.0; fn tick(delta_time: f32) { accumulator delta_time; while accumulator FIXED_DT { step_physics(FIXED_DT); accumulator - FIXED_DT; } }3.2 冲量求解牛顿第三定律的代码表达碰撞响应的核心是冲量求解。给定碰撞法线n、相对速度v_rel我们希望计算出冲量j使得分离速度满足恢复系数约束。对于两个物体的碰撞公式为j -(1 e) * (v_rel · n) / (inv_mass_a inv_mass_b)其中e是恢复系数0表示完全无反弹1表示完全弹性。这个冲量作为向量施加在两个物体上方向为法线方向大小恰好使得“接近速度”变成“分离速度”。这里有一个新手很容易忽略的细节恢复系数本身并不是物理解释而是对碰撞过程中能量损失的简化建模。不同的材料组合应有不同的恢复系数因此我把恢复系数存储在刚体上而不是引擎全局配置中。施加冲量后的代码如下if let Some(contact) manifold.get_primary_contact() { let rel_velocity (b.velocity - a.velocity).dot(contact.normal); let restitution_velocity -contact.restitution * rel_velocity; let j -(1.0 contact.restitution) * rel_velocity / (a.inv_mass b.inv_mass); let impulse contact.normal * j; a.velocity - impulse * a.inv_mass; b.velocity impulse * b.inv_mass; }这里的关键在于判断相对速度的方向。如果两个物体正在相互接近相对速度在法线方向上的投影为负才需要施加冲量如果它们已经在分离就不应该加冲量否则会“吸引”物体。这个判断在前文代码中没有显式写出但在实际实现时务必加上if rel_velocity 0.0 { /* 施加冲量 */ }3.3 摩擦让加速度和减速度符合直觉摩擦是个容易让物理引擎看起来“假”或者“过于滑”的关键因素。一个没有摩擦的引擎里物体碰撞后会像冰球一样无限滑动视觉效果极其离谱。我实现的是库仑摩擦模型分为静态摩擦和动态摩擦静摩擦物体尚未相对滑动时提供足够大的力阻止滑动发生。动摩擦滑动已经发生时施加与滑动方向相反的减速度。在实际冲量求解流程中碰撞响应先处理法向冲量再处理切向冲量。切向冲量的大小不能超过法向冲量乘以摩擦系数——这是库仑摩擦的本质约束。在代码实现上先计算切向相对速度然后计算理论上的切向冲量再用摩擦系数截断它let tangent (rel_velocity - contact.normal * rel_dot_n).normalize(); let rel_dot_t rel_velocity.dot(tangent); let mut jt -rel_dot_t / (a.inv_mass b.inv_mass); let max_friction contact.restitution * contact.normal_impulse; // 摩擦锥约束 let friction_impulse jt.clamp(-max_friction, max_friction); a.velocity - tangent * friction_impulse * a.inv_mass; b.velocity tangent * friction_impulse * b.inv_mass;这里normal_impulse是法向冲量的大小。摩擦冲量永远被限制在这个值乘以摩擦系数的范围内否则物体会被“吸住”——这是很多初学者实现摩擦时最常见的错误。4. 常见问题与性能排查实测中踩过的深坑4.1 穿模问题子弹穿墙背后的时间离散化轻量级物理引擎遇到最多的问题就是快速运动的物体直接穿透障碍物也就是俗称的“子弹穿墙”。原因很简单固定时间步长内物体移动了很大的距离宽相位检测的AABB在这一帧没有与墙体AABB重叠窄相位完全没有机会参与检测。解决这类问题的标准手段包括连续碰撞检测CCD对快速移动的物体进行射线/扫掠检测。降低最大速度上限惩罚移动速度异常大的物体。减小固定时间步长提高物理帧率但会增加CPU负担。在轻量级引擎中我更推荐速度上限方案——简单可靠而且在游戏逻辑中通常没必要让物体以数百米每秒的速度运动。给刚体加一个max_velocity字段每帧积分后限制速度大小不超过该值if body.velocity.length_squared() max_velocity_squared { body.velocity body.velocity.normalize() * max_velocity; }这个方法几乎是零成本同时能避免绝大多数的穿模场景。4.2 堆叠不稳定震动与漂移的来源刚体堆叠是检验物理引擎质量的试金石。小球堆叠还好方块堆叠时经常会出现持续抖动甚至整体漂移的问题。我用三组参数排查解决接触点数量是否正确、迭代次数是否足够、位置修正是否缺失。堆叠稳定性通常需要位置修正position correction。冲量求解器只修正速度层面的穿透但每一帧都会重新检测到微小穿透如果穿透被持续忽略物体就会在重力作用下慢慢陷入地面。最朴素的位置修正是“伪冲量”——按穿透深度按比例将物体推开let correction penetration / (a.inv_mass b.inv_mass); a.position - contact.normal * correction * a.inv_mass * percent; b.position contact.normal * correction * b.inv_mass * percent;这里的percent通常取0.2到0.8之间的一个经验值太大容易造成“弹跳感”太小又达不到修正效果。我取0.35测试下来稳定性与响应速度比较平衡。4.3 性能分析与优化不是所有地方都需要极致在项目性能优化阶段我用火焰图查看了热点函数。结果并不意外SAT检测对凸多边形的顶点遍历最耗时。但真正让我惊讶的是主循环中访问刚体数组的方式影响了缓存友好度——把质量、速度、位置这些频繁访问的数据从一个大结构体里拆成连续数组即结构体数组SoA帧时间提升了大约三分之一。Rust中直接手写SoA布局比用封装好的库更灵活而且不会引入额外依赖。但我想强调的是轻量级引擎没必要在初期就做SoA优化它会让代码可读性下降。更合理的路径是先用AoS数组结构体写一个功能正确的版本跑通Demo之后再用性能分析驱动重构而不是一开始就猜瓶颈位置。物理引擎的瓶颈往往跟你想象的不一样。4.4 常见问题速查表现象可能原因排查方向物体持续下沉穿透地面位置修正缺失或迭代次数不够检查接触点穿透深度是否被处理堆叠物体震荡发疯同一接触点被重复求解检查流形是否去重迭代次数是否过高物体碰撞后飞向随机方向碰撞法线未归一化或SAT轴选择错误打印碰撞法线与分离轴做对比高速球体穿透墙体宽相位AABB未覆盖整帧运动路径加速度上限或CCD物体无限滑动摩擦实现缺失或切向冲量截断不正确检查摩擦锥约束帧率升高后物理变“轻”时间步长未固定或累加器实现错误检查固定时间步长设置5. 工程化细节测试、调试与Demo搭建5.1 单元测试策略数学正确性优先物理引擎的bug很容易表现为“连串怪象”比如乱飞、爆炸、穿地定位起来极其痛苦。我的经验是每一层数学模块都要写单元测试这部分工作带来的回报远超成本。测试的核心用例包括AABB的重叠与非重叠、圆的投影区间计算、SAT对特定形状的穿透深度、冲量求解器的单次碰撞反弹速度验证。用Rust自带的测试框架就够不需要额外引入测试库。一个典型的测试是验证恢复系数为1的完全弹性碰撞是否保持动能守恒#[test] fn test_perfectly_elastic_collision_energy() { // 1为动态球从左侧以速度v撞向静止球 // 验证碰撞后两球速度满足弹性碰撞公式 }这类测试不仅是回归保护也是“活文档”——后人接手代码时可以通过测试理解引擎的预期行为。5.2 可视化调试用图形让抽象物理可见物理引擎调试最痛苦的点在于很多问题在数值层面是“一瞬间”的打印日志根本来不及看。我在项目中使用了简单的窗口渲染Demo绘制刚体轮廓、速度向量、碰撞法线和接触点。没有引入重量级游戏引擎仅使用一个轻量级窗口库加即时模式绘图函数代码量便宜且调试效果直观。例如当堆叠不稳时把接触点绘制成红色小圆点就能一眼看出接触点是否生成在正确位置、是否在某帧丢失。碰撞法线用绿色线段绘制可以验证SAT法线方向是否一致。这个可视化层不是核心引擎的一部分但它是我能顺利完成整个项目的重要原因之一。在没有渲染反馈的情况下纯靠打印数字定位穿模问题几乎是不可能的。5.3 模块封装与接口稳定后续扩展的余地整个项目的收尾阶段我花了一些时间重构了对外API确保引擎核心与示例代码解耦。核心引擎仅暴露三组接口物理世界用于添加刚体、设置重力、刚体构建器、每帧step与sync方法。游戏侧只需要创建世界、填充刚体、每帧调用step而不需要知道内部碰撞检测算法实现细节。这个接口稳定性的意义在于后期扩展——后续如果要在引擎里加入关节约束或触发器只需要在物理世界内部增加模块而不需要改动示例代码的调用方式。对Rust项目来说这种模块边界的清晰度在编译周期层面会直接反馈给你类型不匹配、借用冲突、生命周期问题都会被拦截在编译阶段。写在最后的经验与扩展思路这个项目从头到尾做下来我个人最大的收获不是“我会写物理引擎了”而是对游戏物理系统中“计算精度、稳定性、性能”三者之间的取舍有了更真实的感知。之前用现成引擎时调一个参数解决一个问题但常常不清楚背后牺牲了什么。自己实现一遍之后看到任何物理引擎的文档都能大致猜到它内部是怎么构建的调参时也更有底气。最后分享一个我实际测试中摸索出来的小技巧千万不要在引擎早期就过度追求物理精度。先把一切能用最简单方式实现的功能跑起来哪怕穿模、抖动、乱飞都无所谓——重要的是整个系统是完整闭环的。当系统能稳定运行后再逐步替换某个环节比如将暴力AABB遍历换成带加速结构的扫描剪枝这样的学习效率远高于一开始就追求完美架构。如果你也想动手写一个自己的物理引擎Rust是一个非常值得尝试的选择。只要咬住“基本数学、碰撞检测、冲量求解”这三块硬骨头后面的一切都会逐渐顺畅起来。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
