using iPhone OpenGl ES effectively for 2d (and collision detection)

Question

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.

Answer 1

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.

Answer 2

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.