Integrating physics system w/ graphics engine
Author
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
i''m coding in vc++, and i use global variables for like, position[xyz], orientation[xyz], etc.
a2k
a2k
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)
Author
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.
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
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
I also forgot to add that most of the time the physics engine "owns" the objects, as it needs more control over them.
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).
Author
Maybe that''s my problem. I''m coming from Java and I don''t think you can do that in Java (the friend thing).
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.
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.
Author
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
