自己动手写一个能跑起来的物理引擎这事我想了很久。原因其实很简单在做游戏开发和虚拟仿真项目的时候Unity、Unreal 自带的物理系统确实强大但碰到需要精确控制、需要嵌入算法流程、需要轻量部署的场景一整套重型引擎就显得既笨重又不好下手。用 Python 从零实现一个轻量级物理引擎把碰撞检测、刚体动力学、积分器这些核心算法吃透同时在性能上做针对性优化最后应用到 2D 游戏开发和虚拟仿真环境里这条路我完整走了一遍踩了不少坑也沉淀了不少经验。这篇文章就把整个过程中的设计思路、核心算法、代码实现和优化实战全部摊开来讲适合对物理引擎原理感兴趣的开发者、游戏开发入门者以及需要在 Python 环境下做仿真实验的研究人员参考。1. 内容整体设计与思路拆解1.1 轻量级物理引擎要解决什么问题先明确一下“轻量级”的定义。不是说代码量少就叫轻量级而是指引擎的核心能力聚焦在 2D 刚体物理上不做布料模拟、不做流体、不做破碎效果只解决游戏开发和简单仿真里最常用到的问题物体移动、碰撞、反弹、堆叠、摩擦和阻尼。这样的引擎可以在一台普通笔记本上流畅跑几千个刚体对象不需要 GPU 加速不依赖外部物理库核心逻辑压缩到几百行 Python 代码里。那为什么不用现成的 Box2D、Pymunk 或者 Bullet我的观点是用现成库确实省事但如果目标是理解物理引擎的底层原理或者需要在某个特定场景下深度定制行为自己实现一遍的价值非常大。比如在虚拟仿真项目里可能需要模拟非标准的物理规则重力反向、阻尼系数动态变化、碰撞响应自定义等等这些在封闭引擎里改起来非常痛苦自己写就灵活得多。另一个考虑是部署环境有些仿真系统运行的嵌入式设备或 Web 环境里安装一个完整的 Box2D 绑定并不方便一个纯 Python 实现的轻量引擎拿过去就能用。1.2 为什么选 Python 作为实现语言很多搞物理引擎的人第一反应是Python 性能不行物理引擎这种每帧海量计算的任务用 Python 写不是找虐吗这个观点部分正确但不全对。Python 的优势在于开发效率和可读性。物理引擎的核心是算法不是性能先把算法跑通再针对热点做优化这比一上来就用 C 边调试边改算法要快得多。而且 Python 生态有非常强大的数值计算支持NumPy 的向量化操作可以把很多逐物体循环变成矩阵运算,性能上并不差。我在实际测试中发现纯 Python 实现一个 2D 刚体引擎不加任何优化可以稳定处理几百个物体用 NumPy 向量化之后可以处理两三千个物体再加空间哈希做碰撞筛选上万物体也能跑到实时。这个量级对大多数 2D 游戏和中小规模仿真场景完全够用。做完之后也可以把核心代码通过 Cython 或 Numba 加速但那是后话先把架构和算法做好优化才有意义。1.3 引擎功能边界的确定开始写代码之前我给自己定了一个功能清单这非常重要没有边界就容易无限膨胀几个月都写不完。第一版引擎覆盖以下能力刚体基本属性质量、位置、线速度、角速度以及碰撞后的反弹系数 restitution碰撞检测支持圆形和矩形两种基本碰撞体这是 2D 物理里应用最广泛的两种形状碰撞响应基于冲量法的速度级求解实现碰撞后的速度变化处理摩擦效果积分器半隐式欧拉法和 Verlet 积分两种方案用于更新物体的位置和速度力场与约束重力、线性阻尼、以及简单的距离约束用于模拟弹簧或绳索效果场景管理空间哈希网格加速碰撞检测的 broad phase 阶段这个范围覆盖了 2D 游戏里 80% 的物理需求虚拟仿真里的多物体运动模拟、路径规划验证、机械运动演示也基本够用。复杂的东西像连续碰撞检测 CCD、关节约束、流体模拟统统不做等后续版本按需添加。2. 核心算法详解碰撞检测、碰撞响应与积分器2.1 碰撞检测的核心思路Broad Phase 与 Narrow Phase碰撞检测是物理引擎性能的关键。想象一下场景里有一千个物体如果两两检测碰撞每帧要检测接近五十万对这个计算量对 Python 来说非常吃力。因此需要把碰撞检测分成两个阶段。Broad Phase 阶段用简单的算法排除掉明显不可能碰撞的物体对只留下可能碰撞的候选对。常用方法有空间哈希网格、四叉树、扫描线算法等。我在引擎里选择了空间哈希网格实现简单且性能稳定。原理是把 2D 空间划分为固定大小的网格单元格每个物体根据其位置映射到对应单元格中只检测同一单元格或者相邻单元格内的物体对。这个算法在物体分布相对均匀的场景下效率极高从 O(n²) 降到接近 O(n)。Narrow Phase 阶段对 Broad Phase 筛选出的候选对做精确的碰撞检测。圆形与圆形的碰撞检测非常简单判断两个圆心距离是否小于半径之和即可圆形与矩形、矩形与矩形的碰撞检测要复杂一些需要用到分离轴定理 SAT。SAT 的核心思想是如果两个凸多边形没有碰撞那么一定存在一条分离轴使得两个形状在这条轴上的投影不重叠。对于矩形只需要检查四条法线方向的投影即可。2.2 碰撞响应基于冲量的速度级求解检测到碰撞之后需要计算碰撞后的速度变化。物理引擎里最常用的是冲量法它直接在速度层面求解不需要模拟碰撞过程的微小时间步计算效率高视觉效果好。冲量法的核心公式来自动量定理和恢复系数。假设两个物体发生了碰撞碰撞法线方向为 n则碰撞产生的冲量大小为j -(1 e) * Vrel · n / (1/m1 1/m2)其中 e 是恢复系数0 到 1 之间Vrel 是两个物体在碰撞点的相对速度m1、m2 是两个物体的质量。算出冲量 j 之后分别作用在两个物体上v1 v1 - (j / m1) * n v2 v2 (j / m2) * n这里要注意分母中还有一项与转动惯量相关的处理带旋转的刚体时需要加上。摩擦力的处理是把切向方向的相对速度也计算一遍冲量再乘以摩擦系数即可。实际实现时还会涉及一个细节当两个物体堆叠在一起时会同时有多个接触点需要迭代求解才能稳定。这也是引擎里所谓“迭代求解器”的来源。常见的做法是进行若干次迭代每次迭代只处理一个接触点重复多轮让结果收敛。2.3 积分器的选型半隐式欧拉为什么好用有了力和速度怎么更新位置这部分由积分器完成。物理引擎最常用的是半隐式欧拉法也叫半显式欧拉法。它的逻辑是先用当前速度计算加速度更新速度再用新的速度更新位置。acceleration force / mass velocity acceleration * dt position velocity * dt与显式欧拉相比半隐式欧拉稳定得多。显式欧拉是先更新位置再用旧速度会导致物体在做圆周运动时能量不断增加出现发散的视觉效果。半隐式欧拉则像是一个弹簧系统长期运行的稳定性明显更好。我还实现了 Verlet 积分作为可选方案。Verlet 积分不直接存储速度而是存储当前位置和上一帧位置通过位置差隐式计算速度。这种方式的优势是约束处理非常方便弹簧、绳索、布料这类约束系统用 Verlet 积分实现起来非常优雅。缺点是速度的控制不如半隐式欧拉直接碰撞响应的精度稍差。两种积分器我都保留在引擎里默认使用半隐式欧拉需要做柔性体仿真时切换到 Verlet。这里再补充一个经验固定时间步长非常重要。不要直接用帧间隔时间作为 dt而应该固定 dt比如 1/60 秒物理计算若干次后再渲染。这样可以避免游戏帧率波动导致物理表现不稳定。3. 实操过程从零构建物理引擎的核心代码3.1 引擎的模块划分和数据结构设计开始写代码前先把架构想清楚。我设计的引擎分为三个核心模块第一个是刚体类RigidBody负责存储物体的状态和物理属性。第二个是碰撞检测模块负责 broad phase 和 narrow phase。第三个是碰撞求解模块负责计算冲量和调整速度。除此之外还有场景类World把所有模块整合起来对外提供简单的调用接口。刚体类的属性设计上我参考了行业引擎的常见做法把基本数据都放进字典里管理因为 Python 的类属性访问开销相对较大而字典的批量更新配合 NumPy 向量化会更高效。刚体经常需要保存的数据包括质量、质心位置、线速度、角速度、半径圆或半宽高矩形、恢复系数、摩擦系数、是否静态等。3.2 刚体类的具体实现# body.py import math class RigidBody: 2D刚体支持圆形和矩形使用半宽高定义 def __init__(self, body_typecircle, mass1.0, x0.0, y0.0): self.body_type body_type self.mass mass # 如果是静态物体将质量设为无限大用0表示无限大的倒数 self.inv_mass 1.0 / mass if mass 0 else 0.0 self.position [x, y] # 质心位置 self.velocity [0.0, 0.0] # 线速度 self.force [0.0, 0.0] # 力累积 self.restitution 0.5 # 恢复系数 self.friction 0.3 # 摩擦系数 # 圆形专属属性 self.radius 1.0 # 矩形专属属性半宽、半高 self.half_width 1.0 self.half_height 1.0 # 旋转相关的属性第一版先用0处理 self.rotation 0.0 self.angular_velocity 0.0 def apply_force(self, fx, fy): 累积力的输入在积分时统一应用 self.force[0] fx self.force[1] fy def apply_impulse(self, ix, iy): 直接改变速度用于碰撞响应 self.velocity[0] ix * self.inv_mass self.velocity[1] iy * self.inv_mass这里的核心设计点在于inv_mass也就是质量的倒数。为什么要存倒数而不是直接存质量因为在物理引擎里大量使用1/m每次除法计算开销不小而且如果物体质量为 0 表示静态物体它的倒数就是 0碰撞响应时计算冲量天然不会影响静态物体这个设计非常巧妙。静态物体比如地面、墙壁都属于这一类。3.3 空间哈希网格Broad Phase 的工程实现空间哈希网格的实现思路是这样的先把世界空间划分为边长固定的网格然后对每个物体计算它占据哪些单元格放在一个字典里键是网格坐标值是该单元格内的物体列表。检测时只需要取出物体所在单元格以及周围 3×3 邻域内的物体做两两检测即可。# broad_phase.py class SpatialHashGrid: def __init__(self, cell_size2.0): self.cell_size cell_size self.grid {} def _hash_pos(self, x, y): cx int(x // self.cell_size) cy int(y // self.cell_size) return (cx, cy) def clear(self): self.grid.clear() def insert(self, body): # 圆形物体根据圆心和半径确定占据的网格范围 cx, cy body.position r body.radius min_cx, min_cy self._hash_pos(cx - r, cy - r) max_cx, max_cy self._hash_pos(cx r, cy r) for gx in range(min_cx, max_cx 1): for gy in range(min_cy, max_cy 1): key (gx, gy) if key not in self.grid: self.grid[key] [] self.grid[key].append(body) def get_nearby_candidates(self, body): 返回可能与body碰撞的物体集合用id去重 candidates set() cx, cy body.position r body.radius min_cx, min_cy self._hash_pos(cx - r, cy - r) max_cx, max_cy self._hash_pos(cx r, cy r) for gx in range(min_cx, max_cx 1): for gy in range(min_cy, max_cy 1): cell self.grid.get((gx, gy)) if cell: for other in cell: if other is not body: candidates.add(id(other)) return [obj for obj in self.grid.values() for o in obj if id(o) in candidates]这个实现有个需要优化的地方get_nearby_candidates每次都遍历整个网格去筛选候选物体实际上应该让insert直接维护每个物体的邻居列表或者让World在遍历物体时直接查单个单元格和周边单元格。上面的代码是为了展示清楚逻辑实际工程里可以进一步优化比如在一次循环里同时完成 insert 和查询避免重复遍历。网格大小的选择对性能影响非常大。我在测试中发现网格边长设为场景中绝大多数物体的直径的 1.5 到 2 倍比较合适。网格太小每个单元格里的物体会被分散到很多格子哈希表的键数量激增网格太大筛选效果变差退化成接近暴力两两检测。3.4 Narrow Phase 碰撞检测实现这一阶段实现圆形与圆形、圆形与矩形、矩形与矩形的碰撞检测。圆形之间最简单圆心距离小于半径和即碰撞。我可以直接用平方距离避免做开方运算减少计算量。圆形与矩形的碰撞先找到圆心在矩形局部坐标系中的最近点然后计算距离。如果圆心本身在矩形内部直接判定碰撞否则计算圆心到最近点的距离是否小于半径。矩形与矩形用分离轴定理检查矩形四条边对应的法线方向的投影是否重叠。这里实现时可以简化一些如果矩形没有旋转可以直接用 AABB轴对齐包围盒判断也就是比较中心点距离与半宽半高之和的大小关系。# narrow_phase.py def circle_circle(a, b): dx a.position[0] - b.position[0] dy a.position[1] - b.position[1] r_sum a.radius b.radius dist_sq dx * dx dy * dy return dist_sq r_sum * r_sum def circle_rect(circle, rect): # 先做AABB粗判断 cx, cy circle.position closest_x max(rect.position[0] - rect.half_width, min(cx, rect.position[0] rect.half_width)) closest_y max(rect.position[1] - rect.half_height, min(cy, rect.position[1] rect.half_height)) dx cx - closest_x dy cy - closest_y return dx * dx dy * dy circle.radius * circle.radius def rect_rect(a, b): dx abs(a.position[0] - b.position[0]) dy abs(a.position[1] - b.position[1]) if dx a.half_width b.half_width and dy a.half_height b.half_height: return True return False矩形与矩形的分离轴判断在带旋转时会复杂很多第一版引擎暂时不处理旋转问题物体没有角速度就不涉及旋转碰撞检测这也是轻量引擎的取舍。后续如果要支持旋转需要引入变换矩阵和 SAT 算法扩展性我留在架构里了。3.5 冲量求解器的完整实现碰撞响应是整个引擎里最容易出细节问题的地方。我用一个Contact类来描述碰撞点数据包含法线方向、两个刚体的引用和恢复系数、摩擦系数。求解时在World中遍历所有接触点迭代 8 到 10 次。# solver.py class Contact: def __init__(self, a, b, normal_x, normal_y, penetration): self.a a self.b b self.normal_x normal_x / max(1e-6, math.hypot(normal_x, normal_y)) self.normal_y normal_y / max(1e-6, math.hypot(normal_x, normal_y)) self.penetration penetration def solve_contact(contact, dt): a, b contact.a, contact.b nx, ny contact.normal_x, contact.normal_y e min(a.restitution, b.restitution) # 相对速度在法线方向的分量 rvx b.velocity[0] - a.velocity[0] rvy b.velocity[1] - a.velocity[1] vel_dot_normal rvx * nx rvy * ny # 已经分离则不处理 if vel_dot_normal 0: return inv_mass_sum a.inv_mass b.inv_mass if inv_mass_sum 0: return j -(1 e) * vel_dot_normal / inv_mass_sum impulse_x j * nx impulse_y j * ny # 分别作用冲量注意静态物体inv_mass为0所以不会被推动 a.velocity[0] - impulse_x * a.inv_mass a.velocity[1] - impulse_y * a.inv_mass b.velocity[0] impulse_x * b.inv_mass b.velocity[1] impulse_y * b.inv_mass # 处理摩擦计算切向速度并施加摩擦冲量 tx, ty -ny, nx tangent_vel rvx * tx rvy * ty mu (a.friction b.friction) * 0.5 jt -tangent_vel / inv_mass_sum jt_clamped max(-mu * abs(j), min(mu * abs(j), jt)) friction_x jt_clamped * tx friction_y jt_clamped * ty a.velocity[0] - friction_x * a.inv_mass a.velocity[1] - friction_y * a.inv_mass b.velocity[0] friction_x * b.inv_mass b.velocity[1] friction_y * b.inv_mass这里有一个对抗穿透的重要技巧冲量只改变速度但如果物体已经互相嵌入仅仅改变速度不足以把它们分开。需要在求解后做位置校正把物体推出接触面。简单的做法是把 penetration渗透深度的一部分转化为位置修正量按质量比例移开两物体。这个比例通常取 0.2 到 0.8 之间取值太大容易引入能量太小无法有效分离。3.6 World 场景的组装和主循环物理引擎对外的主循环看起来非常清爽清空力、施加外力重力、检测碰撞、求解碰撞、积分更新位置。这个顺序是有讲究的。先检测碰撞用的位置是上一帧的但积分器会更新位置到新状态所以要在积分之前基于旧位置做碰撞检测。这在大多数帧率下都能接受但高速物体可能出现穿透后面的优化部分我会专门讲这个问题。# world.py class World: def __init__(self, gravity_y-9.8): self.bodies [] self.grid SpatialHashGrid(cell_size2.0) self.gravity_y gravity_y self.iterations 8 self.fixed_dt 1.0 / 60.0 def add_body(self, body): self.bodies.append(body) def step(self, dt): # 固定时间步长避免帧率波动影响物理稳定性 # 累积时间由调用方处理这里直接考虑单个dt # 1. 重力和其他力 for body in self.bodies: if body.inv_mass 0: body.force[1] body.mass * self.gravity_y # 2. 更新位置并同步碰撞体到空间哈希网格 self.grid.clear() for body in self.bodies: body.position[0] body.velocity[0] * dt body.position[1] body.velocity[1] * dt self.grid.insert(body) # 3. broad phase 查找碰撞候选 contacts [] for body in self.bodies: near self.grid.get_nearby_candidates(body) for other in near: if id(other) id(body): # 每个pair只处理一次 if body.body_type circle and other.body_type circle: if circle_circle(body, other): contacts.append(build_contact(body, other)) # 其他形状组合省略 # 4. 迭代求解碰撞 for _ in range(self.iterations): for contact in contacts: solve_contact(contact, dt) # 5. 积分位置在碰撞求解之后应用速度到位置 for body in self.bodies: ax body.force[0] * body.inv_mass ay body.force[1] * body.inv_mass body.velocity[0] ax * dt body.velocity[1] ay * dt body.position[0] body.velocity[0] * dt body.position[1] body.velocity[1] * dt body.force[0] 0.0 body.force[1] 0.0实际运行时发现这个主循环有个顺序问题位置更新了两次。一次在第 2 步用于碰撞检测一次在第 5 步用于积分。所以我在最终版本里调整成先把外力累积到速度再更新位置然后检测碰撞并求解求解后速度已经发生了变化但位置也变了。为了保证一致性应在积分后检测碰撞并用碰撞冲量修正速度后再次更新位置。简单处理方式是先积分速度再积分位置然后碰撞检测和求解求解后把位置按速度再更新一次。更规范的做法是把碰撞求解放在速度积分之后、位置积分之前。我这里分享一个经验不要过度追求标准答案物理引擎的“正确性”最终体现在视觉结果是否稳定、是否不发散。你可以在不同游戏里看到 Box2D 和 Bullet 的求解顺序细节其实也略有不同。关键是保证整个循环的自洽性——位置和速度不会互相打架。4. 优化实战性能瓶颈分析与针对性调优4.1 性能瓶颈的真实分布用纯 Python 完成第一版引擎后我做了基准测试。场景是一千个圆形物体从高处落下堆在地面上。用time.perf_counter统计每帧耗时结果让我很意外碰撞求解并不慢反而有两个地方耗掉了大量时间空间哈希网格的字典操作。每个物体插入多个网格每个网格的键是个元组(cx, cy)字典操作本身开销不小。物体对重复检测。get_nearby_candidates用集合去重时生成大量临时对象频繁分配内存。Python 里最怕的就是频繁创建和销毁对象。字典、集合、列表在一定规模后都会有明显的 GC 压力。4.2 优化一网格查询逻辑重写我重写了空间哈希网格把“每帧 clear 后重建”改成“预先分配网格键值”。具体做法是记录物体上一帧所在的网格键如果没变就不需要重复插入。这个优化对静止物体效果显著。一个堆叠稳定的场景里绝大多数物体位置不变省掉了大量的 insert 操作。4.3 优化二用数组替代字典做网格管理字典在这里虽然灵活但不是最高效的方案。进一步优化时我把网格键从元组改成了单个整数key (cx offset_y) * GRID_SIZE cy用整数当字典键比元组快不少内存消耗也更低。这个优化极其简单但效果明显。我在测试中发现整体速度提升了大约 15% 到 20%。4.4 优化三NumPy 向量化改造当场景里物体数量超过两千个纯 Python 循环就成了瓶颈。一个可行的方案是把所有刚体的速度、位置、质量属性组织成 NumPy 数组批量更新。import numpy as np class BodyBatch: def __init__(self, n): self.n n self.position np.zeros((n, 2), dtypenp.float64) self.velocity np.zeros((n, 2), dtypenp.float64) self.force np.zeros((n, 2), dtypenp.float64) self.inv_mass np.ones(n, dtypenp.float64) self.restitution np.ones(n, dtypenp.float64) * 0.5 def step(self, dt, gravity): self.force[:, 1] self.inv_mass * gravity accel self.force * self.inv_mass[:, np.newaxis] self.velocity accel * dt self.position self.velocity * dt self.force.fill(0.0)这种批处理方式把积分过程彻底向量化计算效率非常高。但碰撞检测和求解部分依然需要逐对处理因为碰撞对象是稀疏的。我的做法是维护一个 activity 列表只对发生碰撞的物体做标量求解。这个混合架构兼顾了性能和灵活性是我在实际项目里用得最顺手的方案。4.5 优化四控制迭代次数和时间步迭代求解器每轮都处理所有接触点迭代次数直接关系到堆叠稳定性但也直接影响性能。我做了实验对比迭代次数堆叠稳定性每帧耗时500物体2容易抖动3.2 ms5较稳定5.1 ms8稳定6.8 ms10非常稳定8.2 ms实际项目里我会根据物体堆叠层数动态调整迭代次数堆叠超过 5 层才提高到 10 次否则用 5 次就足够了。这个自适应策略可以在不明显影响稳定性的前提下省下不少计算。5. 常见问题与排查技巧实录5.1 物体穿过薄墙壁隧道效应与连续碰撞检测高速物体穿过薄墙是物理引擎最经典的问题。本质原因是物体在单帧内位移太大直接跳过了碰撞体。常见解决办法有三种。限制最大速度直接把速度钳制在最大位移小于碰撞体宽度的范围内最简单但不符合真实物理使用连续碰撞检测把物体的运动轨迹当作一条线段检测线段与碰撞体的相交Box2D 里叫 CCD动态时间步细分当物体速度超过一定阈值时把物理步长细分多次每次走一小步我在引擎里实现了第三种方案。在step方法里检查物体速度如果单帧位移超过网格边长的四分之一就把该物体的物理步长细分为 2 到 4 个子步。这个方案实现简单效果也不错。5.2 堆叠物体像弹簧一样抖动迭代求解与位置校正物体堆叠时抖动严重这是迭代次数不足或者没有做位置校正导致的。如果你的碰撞响应已经写对了先看看迭代次数是不是太少。另外冲量求解是速度级的速度修正完必须配合位置校正否则物体间的细微渗透会累积表现为持续的微小抖动。还有一种常见情况是恢复系数过大。堆叠问题中restitution 应该设置得很小接近零因为现实中堆叠物没有弹跳。把接触求解中的恢复系数取两物体的最小值可以显著改善堆叠稳定性。5.3 物体“爆炸”能量注入问题我自己调试时遇到过非常诡异的现象大量物体堆叠一段时间后突然整体飞散像爆炸一样。排查后发现问题出在位置校正上。位置校正在每次求解后把物体推回去推回去的量如果过大或者在校正后没有重新计算速度就会在系统中注入能量。特别是当大量物体互相挤压时位置校正会产生连锁效应最终导致能量爆发。解决方法是限制位置校正的推进距离并且在多轮迭代中均匀分配校正量而不是在一轮里一次性推到位。我的经验值是校正系数不超过 0.5且单次位移不超过物体尺寸的 10%。5.4 浮点误差与确定性物理引擎中浮点误差不可避免。如果多次运行同一场景你会得到微小但不同的轨迹这在游戏里往往无所谓但在某些虚拟仿真场景里可能是问题。比如做批处理测试或回放系统时需要确保同样输入产生同样输出。解决方案是在引擎内避免使用非确定性的运算。注意 Python 字典的遍历顺序在低版本和高版本之间可能不同集合的去重顺序也不保证一致。如果依赖遍历顺序计算结果输出就不可复现。我的解决办法是在构建接触列表时强制按物体 id 排序保证每次遍历顺序一致。6. 轻量物理引擎在游戏开发和虚拟仿真中的应用6.1 在游戏开发中的实践物理小游戏 demo完成引擎核心后我拿它做了一款 2D 弹球小游戏。玩法很简单屏幕底部一个挡板控制球的反弹方向上方一堆方块被球击中后掉落碰撞。这个 demo 麻雀虽小五脏俱全用到的功能包括圆形刚体、矩形刚体、重力、碰撞响应和位置校正。开发过程让我意识到物理引擎真正难的不是算法实现而是参数调试。同一个引擎重力设成 -9.8 和 -20手感完全不同球的恢复系数设成 0.8 和 0.95关卡难度差很多。所以在引擎里做了一个简单的参数配置文件所有的物理参数集中管理方便在不同关卡间切换。这也算一个实战中的设计经验。6.2 在虚拟仿真中的应用搭建一个机器人仿真环境另一个实际应用是做无人车避障仿真。场景里有一辆小车简化为矩形刚体若干障碍物圆形一个小车目标点。小车通过简单的传感器模型获取前方障碍物的距离然后根据距离决定转向和速度。这个仿真循环不需要照片级真实感重点是物理行为可信车辆不能穿过障碍物碰撞后的表现要合理。使用轻量物理引擎的最大好处是可控性强。我可以在仿真中加入自定义噪声、动态修改摩擦系数来模拟不同路面这些在封闭仿真软件里实现门槛较高。整个过程让我深刻体会到物理引擎本身不复杂复杂的是从需求到模型的抽象能力。6.3 后续扩展方向关节、3D 支持和性能优化这个引擎目前只是 2D 版本扩展方向其实很明确。如果做 3D碰撞检测和求解的数学会复杂不少但架构完全不用推翻。关节约束距离关节、旋转关节、鼠标关节是交互类游戏需求最高的功能实现思路是约束求解加上拉格朗日乘子法的变体和冲量求解器一脉相承。性能方面可以引入 Numba 把热点函数编译成本机代码不改动算法逻辑只需要加装饰器即可这是 Python 物理引擎进入高性能领域的捷径。最后再分享一个小技巧不管引擎写得多好都要配套一个可视化调试工具。我用的方案是 Tkinter 的 Canvas 画布简单场景足够用复杂场景用 Pygame需要远程部署到浏览器的时候用透明画布输出 JSON 状态数据到前端。成熟的引擎都有 debug draw 功能自己写引擎时也一定要留这么个接口排查问题能省大量时间。