为什么图形引擎中的碰撞难以有效计算？
从最古老的游戏到非常现代的游戏，您似乎仍然可以在某些相机位置透过墙壁或大多数情况下看到地面。 为什么图形引擎中的碰撞难以有效计算？ 舍入/精度损失累积是否会导致错误渲染视图？
From the oldest games to the very modern, it seems like you can still see through walls or most often the ground in some camera positions.
Why is collision difficult to effectively compute in graphics engines?
Is it rounding/loss of precision accumulating leading to a mis-rendered view?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这实际上并不是明确意义上的碰撞。在这些情况下，摄像机位置实际上可能并不在墙壁或地面“内部”，但它只是非常接近它。
在计算机 3D 图形中，相机具有近平面和远平面的概念。只有位于这两个平面之间的几何体才是可见的，而其余的将被剪裁。如果您离某物太近并且正确对齐相机，那么几何体的某些部分很可能会离近平面定义的相机太近，从而导致几何体不会被渲染。
现在，到这个近平面的距离可以由开发者设定，而且可以设定得很短——短到足以确保不会发生这样的情况。然而，深度缓冲区或 z 缓冲区用于确定渲染期间哪些对象最接近相机，从而确定哪些对象要渲染、哪些不渲染。与近、远平面距离密切相关。
在图形硬件中，深度缓冲区使用每个像素的固定位数表示，例如 32 位。这 32 位必须足以准确表示近平面和远平面之间的整个跨度。它也不是线性的，但会使用更接近相机的精度。因此，选择非常小的近平面距离将大大降低深度缓冲区的整体精度。当两个物体彼此非常接近时，这可能会导致整个场景中出现烦人的闪烁。
您可以在此处以及此处第 12.040 节。
This is not actually collision in the explicit sense. The camera position is probably not actually "inside" the wall or the ground in those situations, but it is simply very close to it.
In computer 3D graphics the camera has a concept of a near plane and a far plane. Only geometry located between these two planes will be visible, while the rest will be clipped. If you are too close to something and align the camera correctly, then chances are that some parts of the geometry will be too close to the camera as defined by the near plane and as a result that geometry will not be rendered.
Now, the distance to this near plane can be set by the developers, and it can be set to be very short - short enough to ensure that situations like these cannot occur. However, the depth buffer or z buffer that is used to determine which objects are closest to the camera during rendering, and thus which objects to render and which not to render, is closely related to the near and far plane distances.
In graphics hardware the depth buffer is represented using a fixed amount of bits for each pixel, for example 32 bits. These 32 bits must be enough to accurately represent the entire span between the near plane and the far plane. It is also not linear, but will use more precision closer to the camera. As a result, choosing a very small near plane distance will greatly reduce the overall precision of the depth buffer. This can cause annoying flickering throughout the entire scene wherever two objects are very close to each others.
You can read more about this issue here as well as section 12.040 here.
这不是困难的问题（当然，计算非凸对象的碰撞/剪切并不容易），但你仍然只有大约 33ms 来计算整个帧，所以必须做出一些妥协（碰撞网格不一样）就像你真正看到的网格一样）。如果没有时间进行精确的解决方案（满足所有条件 - 相机距离、必须看到的物体、避免碰撞），您必须退回到一些“简单”的解决方案，例如看穿墙壁。
It's not about difficulty (of course, it's not easy to compute collision/clipping of non-convex object), but you still have only like ~33ms to compute whole frame, so some compromise have to be made (collision mesh is not the same like mesh you really see). If there is no time for precise solution (to fulfill all conditions - camera distance, object which have to be seen, collision avoidance), you have to fallback to some "easy" solution like see through the wall.