Q: Implementating a Physics System,
Members - Reputation: 631
Posted 17 August 2001 - 08:44 AM
Members - Reputation: 340
Posted 19 August 2001 - 10:00 AM
if (bottom of box <= top of collision object) &&
(top of box >= top of collision object) &&
(left side of box is within horizontal range of collision object) ||
(right side of box is within horizontal range of collision object)
// Collide objects here
Otherwise, a circle test should work just fine. It''s like the sphere test but without the z-value. Note that you must constrain your objects'' speed per step or else use a trace-style intersection wherein you test the volume through which an object moves rather than the object itself. This applies to collision volumes as well.
A good physics engine will have a clock independent of (but preferably as fast as or faster than) its graphical counterpart. Testing collisions in the immediate area only (and, if you want, in "action areas", ie areas where interesting things are happening) will reduce the required processing power. I would suggest to you that you try using a graph of objects and a list of active objects. Populate the list with all active objects within the graph, and if a particular interaction affects a deactivated object, reactivate it, but wait until the next time step to work out the effect. Make sure that all your reactions are constrained, if possible, since you otherwise will get perpetual rattling, by which I mean objects will interact every frame and will not settle.
If you take a look at many last-generation FPS engines, a box or cylinder test is all that is used - no triangle intersection is calculated. Of course, for a physics-heavy game (see Hitman), triangle intersection is more important.
As to the V arrangement, use the circle test and use a physics clock to run your system. Run the clock at all times, of course.