what's the prefered way to apply physics to objects

Started by
2 comments, last by NegativeGeForce 17 years, 6 months ago
I'm curious now in my design process, I'm trying to come up with an easy and quick way to apply my physics to my objects. currently my arrange of classes is similar to this.

class CMap  // is my major class it contains all tile information
class CObject // is just the abstract of an object that keeps basic info
              // like position, bounding box, velocity
class CObject_Manager // manages all objects, and deals with collision detection

then theres my physics class, that I want to be able to apply, friction, force, gravity, density, weight. and several other basic physics ideas to my objects. I know the basics of calculating these formulas, but I can't get a grasp on how to gather the needed info then applying it. i.e. when applying friction, I'd need info from the surface the object is moving across. but I want to keep the major instance seperate from each other or atleast they shouldn't rely on each other. oh yeah, this is all 2D.
-----------------------------------------------The ZoloProject
Advertisement
Quote:Original post by speedie
i.e. when applying friction, I'd need info from the surface the object is moving across. but I want to keep the major instance seperate from each other or atleast they shouldn't rely on each other.

oh yeah, this is all 2D.


It's hard to provide specific ideas or examples without knowing more about your code structure, however in general you could provide lookup functions for applicable objects, these could be either implemented natively as methods or as separate helpers, i.e. assuming that the friction coefficients for all objects available via the tile map you could do something along the lines of:

typedef tile unsigned int; //assuming tiles can be represented as pos intstile getTileFromPos(unsigned int global_x, unsigned int global_y) {//return tile id based on position in map}double lookupFriction(unsigned int x, unsigned int y){//tile t=getTileFromPos(x,y)//check tile (i.e. load from resource pool)//lookup friction//return friction for tile t at position x/y}class CRedBall : public CObject {public:// overload all virtual member functions as requireddouble lookupFriction() {return lookupFriction(pos_x,pos_y);}private:unsigned int pos_x,pos_y; //position};


Something like this could keep everything apart, so you wouldn't have to make Map or Objects become members of eachother.

However, as I said it's really hard to provide anything useful without having had a look at your current source layout
I'd say a good way to start thinking about how to tie physics in with everything else might be to look at how big physics engines do it. Your design may be significantly different, especially if the physics will be tied in to game logic, but perhaps not.

Here's the documentation for ODE, a very popular open-source physics engine. Maybe take a look at how it ties things together? http://www.ode.org/ode-latest-userguide.html
from my understanding most physics engines have widets like mass points, ropes and you add them to your simulation container like a car or character and the widgets handle themselves based on the attributes you give the widgets (mass, friction ect). You also have global constants like gravity that apply to everything

This topic is closed to new replies.

Advertisement