Bullet 时代的 Godot 3D 物理：被诟病的历史积累

在 Jolt Physics 引入之前，Godot 的 3D 物理系统经历了一段较为曲折的发展历程，留下了大量被开发者广为讨论的痛点，理解这段历史有助于准确评估 Jolt 引入的实际价值。

Godot 3.x：Bullet Physics 的工程局限

Godot 3.x 时代使用 Bullet Physics Library 作为 3D 物理后端，这是一个在业界有广泛应用的开源物理引擎（同期也被 Unity 的 PhysX 之前的版本和众多独立游戏引擎采用）。然而，Bullet 在 Godot 项目的使用场景中暴露了若干显著问题。

首先是复杂碰撞场景下的抖动问题：多个刚体堆叠或接触时，物体会出现不自然的微振动，影响游戏体验，且难以通过参数调整完全消除。其次是角色控制器的稳定性：KinematicBody（即 Godot 4 的 CharacterBody3D 前身）在斜面、台阶和边缘处的行为不一致，开发者需要编写大量补丁代码处理各种边缘情况。第三是关节系统的约束漂移：物理关节（铰链、弹簧等）在长时间运行后出现数值漂移，导致复杂物理装置的行为逐渐偏离设计意图。

Godot 4.0-4.1：自研物理后端的过渡期

Godot 4 发布时，Bullet Physics 被替换为 Godot 自研的 3D 物理引擎（GodotPhysics3D）。自研的战略意图是获得对物理行为的完整控制权，但初期版本在某些场景下的性能和稳定性不及成熟的 Bullet，且 CharacterBody3D 在特定平台行为（爬坡、挤压、CCD 连续碰撞检测）方面存在已知 Bug。这一时期的开发者体验是颇为令人沮丧的：Godot 4 带来了渲染层的质变升级，但 3D 物理系统却在某些方面出现了体验回退，加剧了社区对 Godot 3D 成熟度的质疑声音。

Jolt Physics 的技术特性：为什么它不一样

Jolt Physics 是由 Guerrilla Games（《地平线：零之曙光》开发商）的工程师 Jorrit Rouwe 开发的高性能物理引擎，以 MIT 协议开源。它的设计目标从一开始便针对 AAA 级商业游戏的物理需求，这与 Bullet 最初作为通用物理模拟库的设计目标存在本质差异。

多线程与 SIMD 优化的原生设计

Jolt 从设计之初便以充分利用多核 CPU 和 SIMD（单指令多数据流）指令集为目标，物理计算在多个工作线程上并行执行，任务调度系统允许细粒度的计算负载分配。这一架构在大量动态物体同时运动的场景下，相较于以单线程为主的传统物理引擎具有显著的性能优势。在现代多核 CPU 上，Jolt 在高物体密度场景下的帧时间表现优于 Godot 自研物理后端，部分社区测试显示在特定密集场景下可达 2-4 倍的性能提升。

确定性与跨平台一致性

Jolt 的另一项工程特性是高度可重现的物理计算结果：相同输入条件下，在不同硬件和操作系统上的物理模拟结果高度一致（通过 SIMD 指令的标准化实现）。这一特性对于网络多人游戏中的物理同步（Deterministic Lockstep 模式）具有重要工程价值，是 Godot 自研物理后端目前尚未全面达到的能力目标。

改进的约束求解器与稳定性

Jolt 采用了改进的约束求解算法，在刚体堆叠、关节约束和碰撞连续检测（CCD）场景下的数值稳定性优于 Bullet 和 Godot 初期自研后端。这直接改善了开发者反映最集中的抖动问题——多数用户在切换至 Jolt 后端后报告物体堆叠稳定性有显著提升，关节漂移问题得到改善，角色控制器在斜面和边缘的行为更为一致。

两个后端的实际差异：性能、稳定性与边缘案例

Godot 4.2+ 提供了 GodotPhysics3D（默认后端）和 Jolt Physics（可选后端）两个选择，两者并不是在所有场景下 Jolt 都优于 GodotPhysics3D，理解具体差异对于做出合理的项目选型至关重要。

何时 Jolt 带来的改善最为显著

Jolt 的优势在以下场景最为突出：同屏存在大量（数十到数百个）刚体同时运动的场景（如箱子堆、碎片效果、物理驱动的环境）；角色控制器需要在复杂几何体（不规则斜面、楼梯、凹凸地形）上可靠移动的场景；需要物理关节系统保持长期稳定的场景（如绳索、钟摆、铰接结构）。

何时 GodotPhysics3D 可能是更安全的选择

如果项目对物理功能的需求较为基础（常规碰撞检测、少量动态物体）；如果项目需要依赖物理层面的某些 Godot 特有 API 并需要最高的兼容性保证；或者如果团队对引入社区维护的扩展插件持审慎态度，GodotPhysics3D 作为官方维护的默认选项提供了最稳定的长期保障。

物理体类型选型：CharacterBody3D vs RigidBody3D vs StaticBody3D

Godot 的 3D 物理体类型选型是影响游戏手感和性能的关键决策，各类型的设计意图与适用场景需要清晰理解。

StaticBody3D：零开销的环境基础

StaticBody3D 用于表示不会移动的物理体——地形、建筑、固定障碍物。它不参与物理模拟的动态更新，因此几乎不产生物理计算开销，是环境几何体的标准选择。唯一需要注意的是：StaticBody3D 的碰撞体（CollisionShape）应当尽可能使用简单几何体（Box、Sphere、Capsule）而非复杂网格（Concave Polygon），后者在实时碰撞检测中性能开销极高。

CharacterBody3D：玩家和可控 AI 的首选

CharacterBody3D 是为手动控制的运动角色（玩家角色、可控 NPC）设计的物理体类型，提供了精确的运动控制接口（move_and_slide、move_and_collide），允许开发者通过代码精确控制每一帧的移动向量，而物理引擎负责碰撞检测和响应。CharacterBody3D 不受重力和质量等物理属性的自动影响，移动完全由代码驱动，这种"手动物理"方式在游戏手感调优上比 RigidBody 更为可控和直接。

CharacterBody3D 内置了 floor_normal、is_on_floor、is_on_wall 等实用的碰撞状态查询接口，是实现平台类角色控制器的最高效路径。

RigidBody3D：物理驱动的动态对象

RigidBody3D 完全由物理引擎驱动——重力、碰撞冲量、质量、摩擦力均自动参与计算，开发者只需施加力（apply_force、apply_impulse）而非直接设置位置。适用场景包括：可被物理影响的道具（箱子、桶）、抛射物、布娃娃部件、可破坏物体。

RigidBody3D 的常见误用是将其用于玩家角色控制——在对手感有精确要求的游戏中，物理模拟的惯性和力的叠加往往会产生不符合设计预期的手感，调优成本通常高于直接使用 CharacterBody3D 实现的成本。仅在游戏设计本身需要物理感手感（如赛车游戏、弹球游戏）时，才推荐将 RigidBody3D 用于玩家控制的对象。

物理层（Layer）与遮罩（Mask）的设计重要性

Godot 的碰撞层与碰撞遮罩系统提供了细粒度的碰撞过滤机制，合理使用这一系统是避免不必要碰撞检测开销的关键优化手段。建议在项目初期就建立一个明确的层级分配方案（如第1层用于环境几何，第2层用于玩家，第3层用于敌人，第4层用于子弹等），并严格按照此方案配置每个物理体的碰撞层和遮罩，避免默认的"全部层相互碰撞"配置带来的无效计算开销。

大规模动态物体场景的优化策略

当场景中同时存在大量动态物理体时（如物理驱动的破碎系统、粒子物理、大量 NPC 的碰撞体），物理计算成本可能迅速成为性能瓶颈。以下策略提供了系统性的应对方案。

休眠机制的正确使用

Godot 的 RigidBody3D 在物体长时间静止后会自动进入休眠状态（Sleeping），暂停物理更新以减少计算开销。这一机制默认启用，开发者需要避免意外阻止物体进入休眠——例如，持续向静止物体施加微小力，或在 _physics_process 中每帧检查物体位置（某些实现模式会隐式阻止休眠）。

对于场景中大量预期会静止的物理物体（如已落地稳定的物品），可以考虑在它们稳定后手动调用 freeze() 方法将其冻结为静态体，彻底移出物理计算队列，比依赖自动休眠更为彻底和可控。

碰撞体形状优化：简单化原则

碰撞体形状的复杂度直接决定碰撞检测的计算成本。规则是：永远使用能够满足设计需求的最简单形状。Box、Sphere、Capsule 的碰撞检测是解析计算，速度极快；ConvexHullShape 的计算成本中等，适用于中等复杂度的非规则对象；ConcavePolygonShape（凹多边形，即完整网格形状）的计算成本极高，只应用于静态环境几何体（StaticBody3D），绝对不应用于动态物理体。

分层物理更新：非关键物体降频

对于远离玩家或当前游戏焦点的动态物理体，可以通过降低其物理更新频率（或暂停其物理处理）来减少计算负载。Godot 的 VisibilityNotifier 节点可以检测物体是否在视锥之内，结合自定义的距离检测逻辑，可以实现一套"近处全频更新、远处低频或暂停"的分层物理策略。这一策略在大型场景中对物理性能的改善效果可以是量级级别的。

Jolt Physics 的多线程特性在此策略下进一步发挥优势：大量分布在不同空间区域的物理体可以分配到不同工作线程并行处理，空间局部性好的场景从中受益尤为明显。

布娃娃系统与物理动画的实现方案

布娃娃（Ragdoll）系统是 3D 游戏中创造真实角色死亡和受击反馈的重要技术，在 Godot 中的实现方式有几种不同的路径，各有工程权衡。

基于 RigidBody3D 链的传统布娃娃

最直接的布娃娃实现方式是为角色的每一段骨骼创建对应的 RigidBody3D 节点，通过 Generic6DOFJoint 或 HingeJoint3D 连接相邻骨骼节点，并在游戏逻辑层实现从动画控制（CharacterBody3D + AnimationPlayer）到物理控制（RigidBody3D 链）的状态切换。这一实现路径的优点是完全基于 Godot 原生节点，可控性高；缺点是节点数量众多，在有大量同屏死亡角色时性能开销显著，且关节参数调优（限制角度范围、摩擦力）需要较多迭代工作。

物理骨骼（Physical Bone）的混合动画方案

Godot 4 提供了 PhysicalBone3D 节点，可以将物理模拟直接与骨骼动画系统集成，实现动画与物理的混合权重控制。这允许实现"中弹后身体局部受物理影响但整体仍保持动画控制"的混合效果（类似于现代射击游戏中的命中反应），以及程序化的二次动画（如斗篷、飘带、头发的物理模拟）。

PhysicalBone3D 方案的工程复杂度高于简单布娃娃，需要对骨骼动画系统有深入理解，且在 Godot 4 中该功能的稳定性和文档完整性仍在持续改善中，建议在实现前先构建专项技术原型验证可行性。

初级用户路径：启用 Jolt 并配置基础角色控制器

如果你是 Godot 3D 开发的初学者，以下步骤将帮助你快速建立一个使用 Jolt 后端的基础可控角色，无需深入理解物理引擎的底层细节。

第一步：安装 godot-jolt 扩展

在 Godot 编辑器的 AssetLib 面板中搜索"Jolt Physics"，或从 godot-jolt 的 GitHub 发布页面下载对应版本的插件包。将插件文件放置于项目的 addons 目录下，在项目设置的"插件"选项卡中启用该插件。插件启用后，在项目设置的"物理"分类中，将"3D 物理引擎"选项从"GodotPhysics3D"切换为"JoltPhysics3D"，重新启动编辑器使设置生效。

第二步：基础角色控制器节点树

一个最小化可用的 3D 角色控制器节点结构如下：CharacterBody3D 作为根节点（附加角色控制脚本）；CollisionShape3D 作为子节点（形状通常选择 CapsuleShape3D）；MeshInstance3D 或骨骼模型节点作为视觉表现层；Camera3D 作为摄像机（可以是角色的子节点，也可以独立控制）。

第三步：地板法线设置与重力配置

CharacterBody3D 的 up_direction（向上方向，通常为 Vector3.UP）、floor_max_angle（最大可爬坡角度，45 度是常用起点）、floor_snap_length（地面吸附距离，防止从斜面离地时飘浮）是影响角色移动手感的核心参数。在代码中，通过 move_and_slide() 方法执行实际移动，该方法内置了斜面处理、台阶吸附和碰撞响应逻辑，是独立游戏角色控制的推荐起点。

从 Godot 4.3 起，官方提供了一个功能完整的 3D 角色控制器示例项目（Character Controller Demo），可在 AssetLib 中免费下载，包含完整的跳跃、斜面、斜坡处理实现，是学习 CharacterBody3D 最直接的参考材料。

中级用户路径：物理性能调优五步法

当项目出现明显的物理性能问题时，系统性的调优流程比盲目尝试更能高效定位瓶颈。以下五步法提供了从问题定位到解决方案落地的完整框架。

第一步：使用 Godot Profiler 量化物理耗时

打开 Godot 调试器的 Profiler 面板，在游戏运行时记录物理帧时间。关注"Physics Process"分类下的各项子指标，特别是碰撞检测（Collision Detection）和约束求解（Constraint Solving）的耗时占比。通过实际数据确认物理系统是否是当前帧率瓶颈，在不是的情况下不应将优化资源浪费在物理层。

第二步：识别高代价碰撞体形状

使用 Godot 的物理调试可视化模式（在编辑器的"调试"菜单中启用"可见碰撞形状"）检查场景中所有物理体的碰撞形状，识别不必要的复杂网格碰撞体（ConcavePolygonShape 用于动态体），并替换为等效的简单形状。单项优化中，将一个不必要的网格碰撞体替换为几个基础几何体的组合，有时可以带来数倍的碰撞检测性能提升。

第三步：审查物理体更新频率与休眠配置

确认所有不需要高频物理更新的 RigidBody3D 的休眠设置（can_sleep）处于启用状态。检查脚本逻辑中是否有无意中阻止物体进入休眠的操作（如在每帧 _physics_process 中对所有物体施加微小影响力）。对于大型场景，实施基于距离的物理体激活/休眠管理策略。

第四步：评估 Jolt Physics 切换的收益

如果当前使用 GodotPhysics3D，且性能瓶颈主要集中在大量刚体的碰撞检测和约束求解阶段，此时可以测试切换至 Jolt Physics 后端的实际性能收益。建议通过在相同场景下的 A/B 测试，以 Profiler 数据为依据做出客观的后端选择决策，而非仅依据主观体验或社区传闻。

第五步：考虑物理层与游戏逻辑层的解耦

物理更新频率（physics_ticks_per_second，默认 60Hz）并非一定需要等于游戏逻辑更新频率。对于不需要精确物理同步的游戏类型，适当降低物理更新频率（如降至 30Hz），或将非关键物理逻辑从 _physics_process 迁移至低频的 _process 回调，可以在不明显影响游戏体验的前提下显著降低物理计算的 CPU 时间占用。

争议地带：Jolt 应当成为 Godot 的默认 3D 物理后端吗

在 Godot 社区的 GitHub 提案和 Reddit 讨论中，"将 Jolt 设为 Godot 默认 3D 物理后端"的提案积累了数百条讨论，代表了目前 Godot 技术社区中热度最高的引擎架构争议之一。

支持"应当设为默认"的论据

支持方的核心论据是：Jolt 在几乎所有主要评估维度上的表现均优于或不劣于 GodotPhysics3D，包括数值稳定性、大规模场景性能、CharacterBody3D 一致性，以及（通过 godot-jolt 项目的持续完善）API 覆盖率。将 Jolt 设为默认后端可以使新用户默认获得更好的物理体验，减少"为什么我的物理有抖动"类问题在社区中的重复出现，并推动 godot-jolt 项目获得更多官方资源投入。

此外，Jolt 本身的技术成熟度已经在商业 3A 级游戏（《地平线》系列）中经过验证，代码质量和工程规范远超一般社区项目，是被审慎工程师认可的高质量依赖。

持"应当保持现状"立场的论据

官方核心团队对此议题的审慎态度主要基于几个工程原则：首先，godot-jolt 是社区扩展项目而非官方维护模块，将其升为默认后端意味着需要承担更高的官方维护责任和兼容性保证义务；其次，改变默认物理后端会影响所有现有项目的行为——即使 Jolt 在多数场景下更优，但 API 行为的细微差异可能导致部分现有项目的物理表现发生意外变化；第三，GodotPhysics3D 的官方路线图中有明确的持续改善计划，部分当前的差距预计会在未来版本中缩小。

现实的工程建议

对于新项目，在完成物理功能需求评估后，建议主动测试 Jolt 后端的实际表现，如果项目有大量刚体或对物理稳定性要求较高，Jolt 是值得优先采用的选项。对于现有项目，在切换后端之前务必构建完整的物理场景测试矩阵，验证所有关键物理交互的行为一致性，而不是在没有系统测试的前提下直接切换——Jolt 与 GodotPhysics3D 在某些边缘案例下的行为差异真实存在，并非所有差异都是"更好"的改变。