A Question no one can answer... (Game object controllers and physics system)
Author
I''m trying to figure out how to impliment a decent physics system making sure to use the principles of OOP and finding the correct relationships and implimentations is becomiing quite difficult. Let me be breif,
In my game engine, I have objects managed by a scene graph and thier positions are managed by a controller that modifiys any time varing data. I recently attempted to created a physics controller that would update the object taking natual physics in account. But a problem arises, where and how should I impliment a general collision detection and responce system and be able to use a physics system as well. I haven''t really decided on how to impliment the physics system either. I''m relly waiting for the new Game Physics book to come out to answer these system relation ships.
Perhaps one of you may have conqured the physics-game object relationship and maybe, you could enlighten me?
Well, anything helps as I''m making this engine for fun, basically in hopes that I may one day create a game of my own, maybe.
You don''t really need books to do it. They will show you some basic ideas (comparitively basic anyway) that you can use, but if you know the back ground behind it (ie; study mechanics and physics at the university level) then you should be fine.
The computing side can be a little trickier. Fixed time intervals are very easy, but varying time intervals involve a little bit more maths (not much at all). You can use things like the Runge-Kutta method which can use adaptive time steps to get your results.
My way when rebuilding a mechanics engine is to first get the graphics drawing (saves arseing around later on) then stick in all of the physics behind it. I use ordinary differential method to get the results at first, then change it to the variants of runge-kutta to get it a little more accurate.
The models are all done using dynamics. This way when you need to add in a new feature (eg gravity and wind resistence) it is all ready for it.
The computing side can be a little trickier. Fixed time intervals are very easy, but varying time intervals involve a little bit more maths (not much at all). You can use things like the Runge-Kutta method which can use adaptive time steps to get your results.
My way when rebuilding a mechanics engine is to first get the graphics drawing (saves arseing around later on) then stick in all of the physics behind it. I use ordinary differential method to get the results at first, then change it to the variants of runge-kutta to get it a little more accurate.
The models are all done using dynamics. This way when you need to add in a new feature (eg gravity and wind resistence) it is all ready for it.
Author
I realize and can understand the physics but that''s not the issue. The problem lies in the stucture of my code. You see, I can throw a quick half assed progam together but it goes aganst the reason I''m coding this engine, to make it reusable in all the projects I do. I''m trying to program a physics/collision system in an object oriented manner and thats what I''m failing to do.
it shouldn''t be that hard.
Aslong as you can give the engine all the forces that effect it, contact friction and the fluid it is moving in, then all you should have to do after that is give it at minimum the shape of each object and its material (density, hardness, ductility etc).
Oh and how the object is connected to other objects and how it is able to react to the enviromnent.
The engine should be able to find all of the different moments of inertia and gyration from the shape of the object by itself. My ones all do this at loading time, and after that only when the object become deformed.
Aslong as you can give the engine all the forces that effect it, contact friction and the fluid it is moving in, then all you should have to do after that is give it at minimum the shape of each object and its material (density, hardness, ductility etc).
Oh and how the object is connected to other objects and how it is able to react to the enviromnent.
The engine should be able to find all of the different moments of inertia and gyration from the shape of the object by itself. My ones all do this at loading time, and after that only when the object become deformed.
oh, as a side note:
I keep my model formats the same between the graphics and the mechanics engine.
The graphcs engine is seperate, but can be controlled by the mechanics engine, so if a model is loaded in the graphics part, the mechanics part tells the graphics side where it is and so forth. This is because I set up some of my programs in two seperate programs, so if I absolutely have to I can have the renderer on one machine, and the mechanics part on another machine using a tcp/ip connection.
I keep my model formats the same between the graphics and the mechanics engine.
The graphcs engine is seperate, but can be controlled by the mechanics engine, so if a model is loaded in the graphics part, the mechanics part tells the graphics side where it is and so forth. This is because I set up some of my programs in two seperate programs, so if I absolutely have to I can have the renderer on one machine, and the mechanics part on another machine using a tcp/ip connection.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement