Where does the Physics engine fit?
Author
Hey mates,
I hope this question is not too trivial or stupid... also, i hope this is not a repeat of another question that had been asked & answered here before... i tried as much as i could to search but couldnt find an answer...
My question is actually 2 parts:
A- where does the physics engine (or libs) fit in the general overall game loop? I mean, as far as i understand, the basic loop goes something like:
1 take input from player
2 take NPC move from AI engine
3 apply action effects (hit damage, animations, etc)
4 draw on screen & sound using GFx & Audio engines
5 check for game over conditions, if not
6 repeat
so in this basic context, where would the physics engine libs be called upon?
B- my second question is specific to a particular lib... i wanted to ask, what exactly is the difference between the Bullet physics libs, and the ODE (http://ode.org)? i mean, as far as i can see, they're just two different physics engines, right?
thank you
At an abstract level, your physics system (as long as its a discrete component) should be the same regardless of what physics libraries you are using. My method is to have a list of the bodies being controlled by the physics engine, and a list of the static geometry (i.e. the scenery). When an object collides with another, I use a callback function to tell the appropriate object what has just happened.
Objects in your game should be unaware of the particulars of the physics engine you are using. For example, I have some movable objects which are attached to the bodies in the physics engine, and they "draw" themselves by calling the renderer, in the position they have been allocated by the physics library. All they do is keep a link to a "physics body handle" which contains the library specific stuff, and returns a translation matrix.
Objects in your game should be unaware of the particulars of the physics engine you are using. For example, I have some movable objects which are attached to the bodies in the physics engine, and they "draw" themselves by calling the renderer, in the position they have been allocated by the physics library. All they do is keep a link to a "physics body handle" which contains the library specific stuff, and returns a translation matrix.
Author
thanks for the quick reply mate...
so, if i understand you correctly, then what should happen is, every object in the universe should contain some sort of GFx object & Phzx object... after the actions are applied, the physics engine takes its turn and calculates where everything should be, and then the returned translation matrix would change the position where the GFx engine would be rendered...
did i read you correctly?
Quote:Original post by speciesUnknown
At an abstract level, your physics system (as long as its a discrete component) should be the same regardless of what physics libraries you are using. My method is to have a list of the bodies being controlled by the physics engine, and a list of the static geometry (i.e. the scenery). When an object collides with another, I use a callback function to tell the appropriate object what has just happened.
Objects in your game should be unaware of the particulars of the physics engine you are using. For example, I have some movable objects which are attached to the bodies in the physics engine, and they "draw" themselves by calling the renderer, in the position they have been allocated by the physics library. All they do is keep a link to a "physics body handle" which contains the library specific stuff, and returns a translation matrix.
so, if i understand you correctly, then what should happen is, every object in the universe should contain some sort of GFx object & Phzx object... after the actions are applied, the physics engine takes its turn and calculates where everything should be, and then the returned translation matrix would change the position where the GFx engine would be rendered...
did i read you correctly?
Thats it. For example, here is my physics_cube object:
You will see that the base class, and therefore all objects that inherit it, have a pointer to the NewtonBody they are controlled by.
To test it, I have the debug renderer for my game, which uses OpenGL. Here is the draw() member function:
the function NewtonBodyGetMatrix gives me the translation matrix for that particular cube. Then, for debugging purposes, I directly send the matrix to OpenGL with the function glMultMatrix(). I then call the function renderSolidBox, which does what it says on the tin. The physics engine used here is Newton GD.
I must note that the alternative to this is to have a single body which contains both the drawing data for the object and the links to the physics system, but I chose not to do it this way as I might want to change graphics API or the Physics engine at a later date, and because I want reusable components rather than ones specific to a particular platform.
//base class for all physics objects:class physics_object{private:protected: NewtonWorld* nWorld; NewtonBody* phyBody;public: physics_object(){}; virtual ~physics_object(); virtual void draw(renderer * r){}; void set_matrix(float *m); void get_matrix(float *m); NewtonBody * get_body() const {return phyBody;}};//physics_cube object:class physics_cube: public physics_object{private: float width,height,depth;public: physics_cube::physics_cube(float W, float H, float D, float X, float Y, float Z, NewtonWorld * w); ~physics_cube(){}; void draw(renderer * r); //draw cube in current position};You will see that the base class, and therefore all objects that inherit it, have a pointer to the NewtonBody they are controlled by.
To test it, I have the debug renderer for my game, which uses OpenGL. Here is the draw() member function:
void physics_cube::draw(renderer * r){ dMatrix position; NewtonBodyGetMatrix(phyBody, &position[0][0]); glEnable(GL_TEXTURE_2D); int mindex = 0; GLfloat m[16]; //turn the 4x4 matrix into a One D array, as used by OpenGL for(int x=0; x<4; x++) for(int y=0; y<4; y++){ m[mindex++] = position[x][y]; } r->pushMatrix(); r->multiply_matrix(m); r->renderSolidBox(width,height,depth); r->popMatrix();}the function NewtonBodyGetMatrix gives me the translation matrix for that particular cube. Then, for debugging purposes, I directly send the matrix to OpenGL with the function glMultMatrix(). I then call the function renderSolidBox, which does what it says on the tin. The physics engine used here is Newton GD.
I must note that the alternative to this is to have a single body which contains both the drawing data for the object and the links to the physics system, but I chose not to do it this way as I might want to change graphics API or the Physics engine at a later date, and because I want reusable components rather than ones specific to a particular platform.
Original post by speciesUnknown
Why does your physics object have anything related to rendering? This seems to be creating some tight coupling.
Shouldn't your game objects contain data about their position/rotation/orientation/mesh and be able to provide the information to the physics engine. Once the physics engine has control of this, it will adjust the values accordingly.
Then, you would pass this information on to the rendering engine to draw the physics-updated objects.
The physics engine doesn't need to know about actually rendering objects, does it?
class physics_object{private:protected: NewtonWorld* nWorld; NewtonBody* phyBody;public: physics_object(){}; virtual ~physics_object(); virtual void draw(renderer * r){}; void set_matrix(float *m); void get_matrix(float *m); NewtonBody * get_body() const {return phyBody;}};Why does your physics object have anything related to rendering? This seems to be creating some tight coupling.
Shouldn't your game objects contain data about their position/rotation/orientation/mesh and be able to provide the information to the physics engine. Once the physics engine has control of this, it will adjust the values accordingly.
Then, you would pass this information on to the rendering engine to draw the physics-updated objects.
The physics engine doesn't need to know about actually rendering objects, does it?
Quote:Original post by Shakedown
Original post by speciesUnknown
*** Source Snippet Removed ***
Why does your physics object have anything related to rendering? This seems to be creating some tight coupling.
The physics engine doesn't need to know about actually rendering objects, does it?
It only knows how to render a debug view of itself (probably a wireframe of the collision volume).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
