我最近比较了一些用于模拟和游戏开发的物理引擎。有些是免费的，有些是开源的，有些是商业的（1 甚至是非常商业的 $$$$）。Havok、Ode、Newton（又名 oxNewton）、Bullet、PhysX 和一些 3D 引擎中的“原始”内置物理。
在某个阶段，我得出了结论或问题：如果我可以利用 GPU 处理带来的惊人性能（如果我需要），我为什么要使用除 NVidia PhysX 之外的任何东西？使用未来的 NVidia 卡，我可以期待独立于常规 CPU 生成步骤的进一步改进。SDK 是免费的，它也可用于 Linux。当然，这有点锁定供应商，而且它不是开源的。
你的观点或经验是什么？如果您现在就开始开发，您是否同意上述观点？
干杯
免责声明：我从未使用过 PhysX，我的专业经验仅限于 Bullet、Newton 和 ODE。在这三个中，ODE 是我的最爱。它在数值上是最稳定的，另外两个有成熟度问题（有用的关节没有实现，合法的关节/运动组合以未定义的方式表现，&c）。
您在问题中提到了供应商锁定问题，但值得重复一遍：如果您使用 PhysX 作为唯一的物理解决方案，使用 AMD 卡的人将无法运行您的游戏（是的，我知道它可以工作，但它不是官方的，也不是 NVIDIA 支持的）。解决此问题的一种方法是定义故障转移引擎，在带有 AMD 卡的系统上使用 ODE 或其他东西。这行得通，但它会使您的工作量增加一倍。认为您将能够将两个引擎之间的差异隐藏在一个通用界面后面并编写大量游戏物理代码是很诱人的，但是您在游戏物理方面的大部分困难将在于处理您特定的特质物理引擎，决定接触摩擦和恢复等事物的值。这些值在物理引擎中没有一致的含义，并且（大部分）不能正式推导出来，所以你只能通过实验来寻找好看的、可玩的值。使用 PhysX 加上故障转移，您将完成所有这些简单的工作两次。
在更高的层次上，我认为任何流处理 API 都还没有完全成熟，我不愿意承诺一个，至少，我们知道客户的反应英特尔的 Larrabee 是如何塑造人们的设计。
到目前为止，我没有将 PhysX 视为高端游戏开发的明显选择，我认为应该避免使用它，除非您认为拥有 AMD 卡的人在您的玩家群中占很大比例（极不可能）或者您有足够的编码和 QA 人力来测试两个物理引擎（更合理，但如果你的公司那么富有，我听说过关于 Havok 的好消息）。或者，我想，如果你设计的物理游戏对性能的要求如此之高，以至于只有流式物理才能满足你——但在这种情况下，我建议你组建一个乐队，让摩尔定律在一年内完成它或两个。
2013 年初的更新答案：我为我认为的三大操作系统开发：Linux、OS X、MS。我还使用三大物理库进行开发：PhysX、Havok、Bullet。
关于 PhysX，我最近做了一些测试，在撰写本文时最新版本是 3.2.2。在我看来，nVidia 确实降低了库的有效性。最大的问题是刚体缺乏加速度。lib 只加速粒子和布料。即使是那些不与一般刚体接口。我对 nVidia 这样做完全感到困惑，因为他们有巨大的营销推动力来推动 GPU 加速应用程序，专注于科学计算，其中很大的推动力是物理模拟。
因此，虽然我对物理模拟之王的期望是 PhysX、Havok 和 Bullet，但实际上却相反。Bullet 发布了带有 OpenCL 支持样本的 lib 2.8.1。Bullet 是一个相对较小的库，具有大量许可。他们的目标是让第 3 版完全集成 OpenCL 刚体加速。
部分评论讨论了多个代码路径。我的意见是这没什么大不了的。我已经支持三个操作系统，只支持最少的硬代码（大部分是线程，不使用操作系统特定的代码；使用 C++ 和标准库模板）。物理库也是如此。我使用共享库并抽象出一个通用接口。这很好，因为物理变化不大；）您仍然需要设置模拟环境，管理对象，在环境中渲染迭代，完成后进行清理。其余的都是flash，在闲暇时实施。
随着主流库中 OpenCL 的出现（nVidia Cuda 非常接近 - 请参阅 Bullet OpenCL 演示），物理插件的工作将缩小。
那么，从头开始，只关心物理建模？Bullet 不会出错。小而灵活的许可证（免费），非常接近生产就绪的 OpenCL，它将跨平台跨越三大操作系统和 GPU 解决方案。
祝你好运 ！
你可能会觉得这很有趣：
http://www.xbitlabs.com/news/video/display/20091001171332_AMD_Nvidia_PhysX_Will_Be_Irrelevant.html
这是有偏见的……它基本上是对 AMD 的采访……但它提出了一些我认为在你的情况下值得考虑的观点。
由于 David Seiler 指出的问题，在未来某个时间切换物理引擎可能是一个巨大/无法克服的问题……特别是如果游戏玩法与物理紧密相关。
因此，如果您现在真的想在引擎中使用硬件加速物理，请选择 Physx，但请注意，当 AMD 在本文中假设的解决方案可用时（它们绝对会，但它们还没有出现），您将面临不愉快的选择：
1）重写你的引擎以使用（插入新的跨平台硬件加速物理引擎的名称），可能会以一种不好的方式改变你的游戏动态
2) 继续只使用 Physx，完全忽略 AMD 用户
3) 尝试让 Physx 在 AMD GPU 上工作 (blech...)
除了大卫使用 CPU 物理引擎作为后备的想法（做两倍的工作并产生 2 个行为不同的引擎）之外，您唯一的其他选择是使用纯 CPU 物理。
然而，随着 OpenCL 之类的东西成为主流，我们可能会看到 ODE/Bullet/kin 开始整合它…… IOW 如果您现在使用 ODE/Bullet/kin 对其进行编码，您可能（可能最终会）“免费”获得 GPU 加速稍后（不更改您的代码）。GPU 版本的行为仍然会略有不同（由于蝴蝶效应和浮点实现的差异，这是一个不可避免的问题），但至少你会让 ODE/Bullet/kin 社区与你合作以缩小差距.
这是我的建议：使用目前只使用 CPU 的开源物理库，并等待它通过 OpenCL、CUDA、ATI 的流语言等使用 GPU。当这种情况发生时，性能会非常快，你会免得自己头疼。
我使用过ODE，现在使用PhysX。PhysX使构建场景更容易并且（我个人认为）看起来更真实，但是， PhysX没有足够的文档；实际上几乎没有任何文档。另一方面，ODE是开源的，有很多文档、教程等。 PS：使用 GPU 加速对我和我的同事有很大帮助；我们正在使用APEX破坏和PhysX粒子。
未来 gfx 卡的假设性好处非常好，但未来也会从额外的 CPU 内核中获益。您能确定未来的 gfx 卡将始终为您的物理提供备用容量吗？
但可能最好的原因是，尽管在这种情况下有点模糊，但性能并不是一切。与任何 3rd 方库一样，您可能需要在未来几年内支持和升级该代码，并且您需要确保接口合理、文档良好，并且它具有您所需要的功能要求。
可能还有更多的数学问题，例如一些提供更稳定方程求解的 API 等，但我将对此发表评论给专家。
PhysX 适用于非 nVidia 卡，只是无法加速。将其留在与其他引擎相同的位置。问题是如果你有一个物理模拟，它只适用于硬件物理加速。
如果您的所有代码都可以大量并行化，那就去吧！
对于其他一切，GPU 都严重不足。