Archived

This topic is now archived and is closed to further replies.

BMason

Integrating physics system w/ graphics engine

Recommended Posts

Hi. I'm in college right now taking computer science 2 and we're using Java right now, and in my free time I just sit down and think about how I would do various things in a game (non-language-specific) and one of the things I'm interested in is physics systems (especially real-world rigid body dynamics). I read a 4-part editorial on implementing a rigid body dynamic system from Game Developer magazine and the author said that you needed to integrate the graphics system and the physics system, which I understand because they both need to access the same data. The question I'm wondering is how you go about doing that? I'm coming from the Java perspective so I'm just trying to think this out. Lets consider a 2D graphics engine for simplicity. If you have a graphics engine class and a physics engine class and they both need to access the same data then obviously neither of them would be able to "own" the data. It would have to be external from those two objects. I'm thinking what you would have to do is create an array of "2D objects" and pass them in as an array. But if you had a huge 3D scene like in a computer game that seems like it would use up a huge amount of memory. I'm just wondering how most programmers would integrate the two? Edited by - BMason on 4/8/00 7:01:00 PM

Share this post


Link to post
Share on other sites

Maybe I don''t quite understand what you are trying to do, but why have them seperate?

Say you''re writing a game. You have an Actor class with member function Draw() and member function Move(). The Actor class owns the physics and location data, and the member functions access said data to do what they want to do. I suppose, if you really wanted to abstract your GraphicActorClass and PhysicActorClass, you could have Actor multiply inherited from the two, but that seems unneccesary to me, and the solution that is both intuitive and "correct" is to have the Actor know how to both draw itself and move itself.

Alternatively, you could have Actor befriend ActorPhysics and ActorDraw, so that those two could access Actor''s variables. but why seperate them?

Let me know if this is what you were asking about.

-- Remnant


- Remnant
- (Steve Schmitt)

Share this post


Link to post
Share on other sites
The object can certainly move and draw itself, but how does it collide? In order to collide it has to be able to get data from other objects of its type, which it doesn''t know about. So that has to be handled from the next level up. Which means that the physics world has to be able to own the objects, but that doesn''t seem right to me. I think that by thinking about it I just confused myself. I just don''t see how you can do it very well without making that information public, and we don''t want to do that.

Share this post


Link to post
Share on other sites
just keep all of the information in one class. a function called draw and move. this way, both functions can access information in the "private:" part of the class. alternativly, you could have two classes, and a function in each that will transfer private data. an example:

class Cphysics {
public:
float GetSomeData(Cphysics &physics);

private:
float SomeData;
}

float Cphysics::GetSomeData(Cphysics &physics) {
return physics->SomeData;
}

you see? there probably should be a "*" before the "physics->SomeData", but i''m not sure (god i hate pointers)

MENTAL

Share this post


Link to post
Share on other sites
I''m not sure what the big deal is here. Classes have to be able to know about each other to some extent or you can''t write programs. The trick is to expose as little as is necessary to allow the classes to be functional. Just cos 2 classes need access to the same ''data'', it doesn''t always mean they need direct access to the member variables themselves. There''s no reason why a game-based system for storing objects shouldn''t incorporate accessor functions for physics purposes. In C++ I would store the data in the graphics side and declare the graphics and physics classes as mutual ''friends'' to allow them access to each other (although I would still conduct most operations via private member functions, to enforce bounds checking, validation, etc).

Share this post


Link to post
Share on other sites
No, but you can have public accessor functions, no? There''s nothing wrong with exposing a clean interface where it is needed. You need classes to be able to talk to each other somehow.

Is there no sort of ''package scope'' in Java? I thought there was some way of allowing only certain groups of classes to use certain functions, but I could be wrong.

Share this post


Link to post
Share on other sites
I don''t think there is. I''m pretty sure everything is either private or public. Things can''t be public to only certain things. Well, that''s not entirely true. You can deem something as protected and then if you inherit the class you will get access to anything that is protected or public. But that''s through inheritance only.

Share this post


Link to post
Share on other sites
I would subclass the actor object within the physics object. That way you can still move the actor but you go through the physics part first, which makes sense since all actors are affected by the same gravity/physics.

float gravity = 9.81f;

CEarthPhysics on_earth;
on_earth.create_system(gravity);
on_earth.create_john();
on_earth.john.walks();

walk is physical property for all actors, and john is a specific actor, one of many that are tied to the same physics system.

Then you could make another physics class, like no gravity and give that system to all its sub actors. Or maybe I don't know what I'm talking about

Jerry

Edited by - JD on 4/10/00 4:05:51 AM

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
If you''re going to be rendering at a reasonable framerate the timestep on the physics will be considerably larger than a rendering timestep. [maybe linearly interpolating, the values for rendering?]
Similarly the models you use for rendering and collision detection are likely to be quite different; most 3d rigid body demos use highly simplified geometry for collisions.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
people.. this is like.. engine design 101.. have a Scene class that encapsulates a set of Object classes. Objects check for collisions with other Objects and either draw themselves or pass the transformed data to the parent Scene, depending on the application. the Scene instance, when rendered, determines which objects can potentially collide (Object::CheckBoundingBoxForCollision(BoundingBox *)) and then calls each Object''s collision detection method for the potential colliding Object. Object::CheckForCollision(Object *).

-goltrpoat

Share this post


Link to post
Share on other sites
But if you''re going to encapsulate the objects then each object doesn''t know about eachother, only the scene class would know about each object. So the object wouldn''t be able to apply its own collision detection. That''s what I''m getting hung up on.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
The above anonymous guy is right, its the way that I ended up working things in my engine as well.

On an abstract level, your scene owns all actors. Every actor has a public member function CheckCollide(Actor *other), that checks its bounding box against another actor''s bounding box.

Your scene has a function, say, CheckWorldCollide() that loops through all your actors, calling CheckCollide() for TotalNumObjects/2 (/2 because if you check collision for one pair, you eliminate the inverse check, obj1->obj2 is same as obj2->obj1).

Forgive me if this is a stupid question, but it seems from your question as if in Java an object can''t access another object''s private data even if its the same type. This isn''t the case in C++, which is why your object''s CheckCollide(Actor *other) can "get at" all the needed physics info for Actor other.

-- Remnant (at the Uni)

Share this post


Link to post
Share on other sites
No, it can''t access another objects data even if it''s the same type of object. The only way to make the private data available is by creating a function that returns that private data, but you can''t let that function give the data to only a certain type of object (as in you can''t limit what objects are allowed to access that method). It''s either totally public to everyone or totally private to everyone.

Share this post


Link to post
Share on other sites

Hrmm. Sounds to me like Java isn''t the best language to be developing in. [I''ll stop before I start a holy war here]

Perhaps you should go ahead and give up public methods to access the private data. Most of what a (simple) collision detect algorithm will need is stuff like position and velocity -- things that someone outside the class could reasonably expect to request from an Actor. For example, if you have your physics data isolated inside a struct inside your Actor class, you could have the following :

struct physic_state;

physic_state *Actor.RequestPhysics();
Actor.SetPhysics(physic_state *newstate);

then :

Actor.CheckBoundingCollision(physic_state *other);

That is, unless Java doesn''t have structs either?
Not having friendship or private-access to your own object type makes it more difficult.

- Remnant
- (Steve Schmitt)

Share this post


Link to post
Share on other sites