Quote:Original post by frob
The physics simulation and the rendering should be independant.

The player, terrain, and other objects in your game should have their own processing steps where you run your mechanics (physics or motion). This includes turning the player and AI input into forces and motion, collision detection and response, particle system updates, and anything else related to the management of the world.

You need a separate set of steps where your art assets are drawn to the screen at the positions computed by the mechanics engine. The only thing the graphics engine should know about are the location and orientation of objects, and the interpolation between mechanics steps (assuming they are running at different rates).


The mechanics engine should never need to make a call like glReadPixels.

Exactly. Maybe I can clarify. The rendering should not have anythig to do with the collision/physics. You already know how slow glReadPixels is. Instead, you should make it to where you can detect collisions without drawing anything. As in, you have in memory vectors for location, velocity, direction, size, etc... about each object, then using this info, detect whether the objects collide. The drawing may use the same info, but shouldn't change it. As in the above post, keep drawing and physics separate. For this case, I recommend a simple sphere collision if the action is relatively fast. Just use the two positions of two objects, get the distance, then add up the two sizes of the objects. Then if the distance is less than the two sizes they have collided. Say you have the Earth and the moon. The distance is 2000 m(These numbers are way off, just for examples), the earth's size is 1500 m and the moon's is 100 m, when added together get 1600 m, which is less than the distance of 2000 m, so you know they didn't collide.
To optimize this, don't do the square root in the distance part, rather do the square of the two sizes added together, that way you don't do the expensive square root, but still get the same accuracy. This collision detection is probably the quickest way, but isn't too accurate. If the game is slower moving, you need a more accurate method. If it is fast, usually objects collide or they don't collide. Due to the speed, you don't have many of the "close calls" so the user collides or doesn't and won't notice the inaccurate detection.