有效使用 iPhone OpenGl ES 进行 2d（和碰撞检测）
这可能是一个更普遍的 opengl 问题。使用 OpenGL ES for 2d 并阅读教程，我学会了如何进行基本的矩阵变换，例如在屏幕上旋转和移动对象。到目前为止，一切顺利 - 我有一些物体在移动和旋转。
我的下一步是进行碰撞检测。像检查边界框之间的交集这样简单的事情可能就可以了。但是，我陷入困境，因为为了知道边界框何时相交，我必须知道对象的平移、旋转坐标。但我找不到从 OpenGL 获取这些数字的方法。
那么除了让 OpenGL 执行这些操作之外，我是否真的必须自己执行旋转和变换才能获得转换后的坐标？或者有什么方法可以将当前矩阵应用于顶点并获得结果？ OpenGL 不能比我快得多吗？
感谢您的任何帮助，我将不胜感激关于通常如何完成此类事情的一些一般性建议。
this may be a more general opengl question. using OpenGL ES for 2d, and reading through the tutorials, I learned how to do the basic matrix transformations like rotating and moving an object around the screen. so far, so good - I have some objects moving around and rotating.
the next step for me is to do collision detection. something simple like checking for intersection between bounding boxes would probably be ok. however, I'm stuck because in order to know when the bounding boxes intersect, I have to know the translated, rotated coordinates of my objects. but I can't find a way to get those numbers from OpenGL.
so do I really have to do the rotations and transformations myself, in addition to having OpenGL do them, just to get the translated coordinates? or is there some way to apply the current matrices to a vertex and get the results? couldn't OpenGL do the math much faster than me?
thanks for any help, I would appreciate some general advice on how this kind of thing is usually done.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
视觉信息和碰撞信息通常在游戏中单独处理。请注意，您应该重用物理代码中的所有变换信息（即所有矩阵），而不是顶点信息。一开始这听起来确实有点低效并且违反直觉。
原因之一是要求以多边形精度进行碰撞检测的情况并不常见。相反，大约的体积通常就足够了。
因此，您很少会将一组多边形与另一组多边形碰撞 - 事实上，您应该尽最大努力不这样做。您应该使球体与自身、盒子、线或“扫掠”球体（胶囊）碰撞。较大的非凸模型可以分解为多个凸体积并单独处理。
因此，如果您直接使用视觉网格进行碰撞，您的物理代码将比使用较低细节的网格或球体或盒子等近似体积慢得多。这有点痛苦，但碰撞的缓慢部分不是变换，而是实际的检测 - 所以这种方法实际上运行得更快。
根据您的游戏，我会考虑尽可能多地使用球体 - 它们不需要旋转，并且测试很容易。在模型加载时，在几何体消失到 GPU 区域之前，也可以轻松生成边界球体。
这本书是一个非常好的资源，并且还有很多在线信息。
Visual information and collision information are usually treated individually in games. Note that you should reuse all your transform information in your physics code (that is all your matrices), not the vertex information. It does sound a bit inefficient and counter intuitive at first.
One of the reasons is that it is unusual to require collision detection at polygon accuracy. Instead, approximate volumes are usually sufficient.
So you're rarely ever going to collide a set of polygons with another set of polygons - in fact you should be trying your hardest not to. You should be colliding spheres against themselves, boxes, lines or "swept" spheres (capsules). Larger non-convex models can be broken into multiple convex volumes and treated separately.
So if you were using the visual mesh directly for collision, your physics code would be much slower than using a lower-detail mesh, or approximate volume like a sphere or a box. It is a bit more of a pain, but the slow part of collision isn't the transforms, its the actual detection - so this method actually works out faster.
Depending on your game, I'd consider using spheres as much as possible - they don't need to be rotated, and tests are easy. Its also easy to generate a bounding sphere at model load time, before the geometry disappears into GPU land.
This book is a very good resource, and there is lots of online information as well.
您应该自己进行平移和旋转。向 OpenGL 请求数据是相当低效的。图形引擎通常保留 OpenGL 数据（尤其是状态数据），并且只告诉 OpenGL 状态机它需要的最少信息。
You should do the translations and rotations yourself. It's quite inefficient to ask OpenGL for data. Graphics engines often keep the OpenGL data (especially state data) and only tell the OpenGL state machine the minimal information it needs.