Your physcics structure ?

mrmclovin

01-09-2008 20:35:57

Hi!

Im into a project building a game. First time building a 3d game. However, I'm intrested in how You construct and put all pieces together to interact with eachother. Of cource im not into any details. So my keyquestions:

How do you build your bodies (physics+graphics)?
What does your collision model for, lets say, a simple human look like? A simple box or diff. shapes glued together?

How does your relationship between classes (physics+gfx) look like? Which are "has-a" and which "is-a" ?

Thank you!

maroxe

01-09-2008 21:25:24


What does your collision model for, lets say, a simple human look like? A simple box or diff. shapes glued together?

How does your relationship between classes (physics+gfx) look like? Which are "has-a" and which "is-a" ?

i've just started my first 3D game, i will try to answer your questions:
"How do you build your bodies (physics+graphics)? "
i inherit my Player class from Actor(or Character) and Renderable source class.
"What does your collision model for, lets say, a simple human look like? A simple box or diff. shapes glued together?"i use a covex mesh built with "flour" software
"How does your relationship between classes (physics+gfx) look like? Which are "has-a" and which "is-a" ?"i implemented a scene class that hastwo attributes: mNxScene and mOgreScene.

mrmclovin

01-09-2008 22:20:19

Thanks for your answer but I was thinking in a higher level such as inheritance and other relationships between classes with physical and graphical representation. I have no experience in this and I want to build as best as a can. I'll show you my diagram.
Diagram

Black lines shows "is-a" and red "has-a" relation. I suspect I might use the inheritance bad. The "top"-class 'Object' has all gfx like entity, a root scenenode etc. As you go down the heirachy you extend to physical properties and add shapes and put them together to a proper "uni-shape".
But as I said, Im too new to this and Im looking for directions to not get lost and waste time on unnessesary work.

betajaen

01-09-2008 22:30:02

This is probably the closest you'll get from the documentation from http://nxogre.org/Core_Hierarchy_Diagram, Along with the diagram from http://nxogre.org/How_the_Rendersystem_works

I can't see your image to clearly, but I would make your top-most object; is-a: "Actor", "RenderableSource" and has-a: "OgreNodeRenderable". You also should have a read of "Inheriting the Actor" to understand how it's approached in NxOgre.

mrmclovin

05-09-2008 21:40:21

I was thinking more of how you design your classes and link physics and gfx together. However, I did some re-thinking and came up with this new design:

red: has-a
black: is-a

betajaen

05-09-2008 21:47:03

I still can't see the images you post. Can you use imageshack or something.

maroxe

05-09-2008 21:51:38

i'll give you some help:

betajaen

05-09-2008 21:56:10

I assume PhysicsObject is a class that inherits Actor from NxOgre? Your wrapping some of the functions right? I think it's way over-kill, and totally ignores the NxOgre Rendering system. If you use the NxOgre Rendering system; PhysicsObject and GraphicsObject can be the same thing.

mrmclovin

12-09-2008 16:14:23

Yes, PhysicsObject inherits from actor. The reason I have one gfx class and one physics class is that some objects in the game don't nesseasary need physical representation. Instead my thought is to pick the nessesary pieces for my object and put them together just like I do with the Item-class. I'm also able to have more then one physics-shape per mesh and vice verse.

I think it's way over-kill, and totally ignores the NxOgre Rendering system.

I don't quite understand you. What am I ignoring? (I'm not sure I know the 100% meaning of NxOgre Rendering System) I'm still using Actor methods etc. for physicsobjects. As I'm thinking of it I'm just trying to do a more functional and complex NxOgre::Body.

It's my first time making a game of this size and I need more feedback on how I should make a blueprint of it (the Physics/Gfx aspect).

Thanks again for your answers Betajaen!

betajaen

12-09-2008 16:32:41

The NxOgre rendersystem tells your rendersystem (Ogre) to place things in the Scene.

This is done by a RenderableSource periodically (this is called a render other people call it a positional update) being quizzed by NxOgre to send an update of it's position to it's Renderable (usually a Node, Point based (or what ever you want to call it) based one), most of the time that position is adjusted for smoothing. If the Actor is a static one - then it's only "rendered" once (at the start), or if it's a dynamic; it's only rendered when it's moving.

From what I can see; your getting a list of Actors and quizzing them (probably every frame render) for a position, then using your own setup telling that the new/same locations for each one. This is bad for a few reasons; it doesn't take account for interpolation (smoothing), your setting the position of each PhysicsObject everytime regardless if it has moved or not and you don't take advantage of all wonderful classes I wrote so you don't have to.


I hate all this diagram rubbish, it's terriably inefficient and just does not convey any real information at all.

So this what I mean in code:

class PhysicsObject : public NxOgre::Actor, public NxOgre::RenderableSource, public MyGame::SoundEmitter, public MyGame::EventCaster
{

public:

PhysicsObject(...);
~PhysicsObject();

NxOgre::Pose() getPose();

protected:

NxOgre::Renderable* mRenderable;
NxOgre::NodeRenderable* mNodeRenderable;

};

mrmclovin

13-09-2008 18:21:22

If I understand you right, then you've misunderstood me :). I'm not trying to write a new/extended wrap of NxOgre/PhysX. I'm more of asking how to wrap NxOgre, Ogre and other libs to a game engine.

I'm having a feeling that I may have a hard time to express my problem :). I have a new plan, and I will write it down and then post it here so you can take a look at it and we'll take it from there.