我最近比较了一些用于模拟和游戏开发的物理引擎。有些是免费的，有些是开源的，有些是商业的(1 甚至是非常商业的 $$$$)。 Havok、Ode、Newton(又名 oxNewton)、Bullet、PhysX 和某些 3D 引擎中的“原始”内置物理。
在某个阶段我得出结论或问题: 由于 GPU 处理，如果我可以利用其惊人的性能(如果我需要的话)，为什么我应该使用 NVidia PhysX 以外的任何东西？对于 future 的 NVidia 卡，我可以期待独立于常规 CPU 生成步骤的进一步改进。该 SDK 是免费的，也可用于 Linux。当然，这有点像供应商锁定，而且它不是开源的。
您的看法或经验是什么？如果您现在就开始开发，您会同意上述观点吗？
干杯
最佳答案
免责声明:我从未使用过 PhysX，我的专业经验仅限于 Bullet、Newton 和 ODE。在这三者中，ODE 无疑是我的最爱；它是数值上最稳定的，另外两个有成熟度问题(有用的关节没有实现，合法的关节/电机组合以未定义的方式运行，&c)。
您在问题中提到了供应商锁定问题，但值得重复:如果您使用 PhysX 作为唯一的物理解决方案，使用 AMD 卡的人将无法运行您的游戏(是的，我知道它可以be made to work ，但它不是官方的，也不受 NVIDIA 支持)。解决这个问题的一种方法是定义一个故障转移引擎，在带有 AMD 卡的系统上使用 ODE 或其他东西。这可行，但会使您的工作量加倍。认为您可以将两个引擎之间的差异隐藏在一个通用界面后面并一次编写大部分游戏物理代码是很诱人的，但是您在游戏物理方面的大部分困难将在于处理您特定的特性物理引擎，决定接触摩擦和恢复等事物的值(value)。这些值在物理引擎中没有一致的含义，并且(大部分)无法正式导出，因此您只能通过实验找到好看的、可玩的值。使用 PhysX 加上故障转移，您可以将所有 scut 工作做两次。
在更高的层面上，我不认为任何流处理 API 都已经完全成熟，而且我不愿意 promise ，至少在我们了解客户对英特尔的 Larrabee 的 react 之前塑造人们的设计。
到目前为止，PhysX 并没有被视为高端游戏开发的明显选择，我认为应该避免使用它，除非您认为拥有 AMD 卡的人在您的玩家群中所占比例不大(极不可能) 或者你有足够的编码和 QA 人力来测试两个物理引擎(更合理，但如果你的公司那么富有，我听说过关于 Havok 的好消息)。或者，我想，如果你设计的物理游戏对性能的要求如此之高，以至于只有流式物理才能满足你——但在这种情况下，我建议你组建一个乐队，让摩尔定律发挥一年的作用或两个。
关于comparison - PhysX 通过 GPU 实现大规模性能？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/939838/