使用 Bullet3D 进行 2D 只会导致 Z 轴出现浮点数值误差吗？
我想可以在仅 2D 模式下使用bullet3D，但我担心的是浮点精度错误。如果Z轴的所有值和操作都为0，则Z值可能会受到其他轴操作的影响。如果累积起来，结果可能会出错。
不过我还没有使用bullet3d。如果您在纯 2D 模式下体验过Bullet3d，请告诉我您的意见。
I guess it's possible to use bullet3D in 2D only mode, but what I'm concerning is floating-point accuracy error. If all values and operations for Z axis are 0, the Z values may be influenced by operations for other axis. If this accumulated, the result may wrong.
However I didn't used bullet3d yet. If you experienced with bullet3d in 2D only mode, please let me know your opinion.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我现在正在将 Bullet 物理用于 2D 游戏，效果很好。 Bullet 提供了一个方法 btRigidBody::setLinearFactor ，它允许您强制 Z 轴位置恰好为 0，无论如何。您甚至可以通过仅在想要约束到平面的对象上设置线性因子来混合 2D 和 3D。
话虽这么说，我使用的是具有一定 Z 轴深度的形状（只是其位置被限制为 2D），因此它的厚度不是 0。即便如此，因为它很薄，我偶尔也会遇到它不应该滑过网格的问题。您可以使用 setMargin 来解决这个问题。
I'm using Bullet physics for a 2D game right now, it works just fine. Bullet provides a method btRigidBody::setLinearFactor that allows you to force the Z axis position to be exactly 0, no matter what. You can even mix 2D and 3D by setting the linear factor only on the objects you want constrained to the plane.
That being said, I am using a shape with some Z-axis depth (just its position is constrained to 2D) so it's not 0 thickness. And even so, because it is thin I do occasionally have problems with it slipping through meshes that it shouldn't. You can use setMargin to combat that.
我具体不了解 Bullet，但假设它是一个编写得相当好的库，这将不是问题。
浮点运算并不神秘。舍入误差不会神奇地发生，舍入也不是随机的、模糊的或人们用来描述他们不理解的现象的任何其他术语。
浮点运算是确定性的，就像计算机上的其他所有东西一样（除非宇宙射线随机翻转位）。正确表达的精确零计算可产生精确零结果。如果影响 Z 轴的所有操作都为零，则生成的 Z 坐标将恰好为零。如果不是，那么所使用的算法不合适，我不会信任它进行任何计算。
如果您对非零 Z 分量进行求和，而实际上这些分量的总和为零，那么您会遇到麻烦。在这种情况下，舍入误差可能会累积，导致 Z 分量较小但非零。然而，听起来你发现自己的处境并非如此。听起来所有涉及的量都应该具有零 Z 分量，并且这将被保留。
I don't know about Bullet specifically, but assuming that it's a reasonably well-written library, this will not be an issue.
Floating-point arithmetic is not mysticism. Rounding error does not magically occur, nor is rounding random, fuzzy, or any of the many other terms people use to describe phenomena that they do not understand.
Floating-point arithmetic is deterministic, like everything else on a computer (barring cosmic rays randomly flipping bits). Computations with exact zeros, properly formulated, produce exact zero results. If it is true that all the operations that effect the Z axis are zeros, then the resulting Z coordinate will be exactly zero. If it's not, then the algorithm being used is unsuitable, and I wouldn't trust it for any calculation.
The place where you would run into trouble would be if you were summing quantities with non-zero Z components that are physically supposed to sum to zero; in such a situation, rounding error could accumulate to result in a small, but non-zero Z component. However, it doesn't sound like that's the situation in which you find yourself. It sounds like all of the quantities involved should have zero Z components, and that will be preserved.