Physics Engine Interface
Moderator: PPS-Leaders
Update:
We've been working on implementing the Bullet physics engine without using OgreBullet. For our design, OgreBullet would not have any significant advantage over using Bullet directly.
Currently we're concerned about how to do physics with network support, because whatever concept I think of, there's a significant flaw in it.
That leads me a suggestion: Server only physics. We can still have a physics engine on the client but rather as an option to improve the game feeling than as a real engine. What I want to say is that we could simulate smaller objects, that have no effect on the gameplay, like shrapnels, on the client.
This would also mean that we don't need physics on the client at all for the moment (testing phase).
My suggestion however does have a great impact on how to synchronise client objects on the server. Currently, afaik, we simply network the position, velocity and orientation to the server. So the client has full authority over his ControllableEntity.
I would like to constrain that behavior a little bit. For that we only synchronise an applied force that was induced by the steering.
What do you think about my suggestion?
A side note:
When thinking about client physics I caught myself up into lots of trouble:
- What happens when two ships run into each other? Do the two clients have to calculate the new velocity each for themselves without the server at all?
- The physics engine, as we know, delivers you the new position each frame. But with our model, we set that position ourselves every now and then.
- If a ship collides into another ship and the user accelerates, we've got two contradicting velocities, positions and orientations (one from the physics engine because of the collision, and one from the accelerator)
- Resetting the position of a physical object is considered bad practice because any precalculated data might be wrong then. Maybe the physics engine assumes finite velocities and can therefore do some optimisations.
We've been working on implementing the Bullet physics engine without using OgreBullet. For our design, OgreBullet would not have any significant advantage over using Bullet directly.
Currently we're concerned about how to do physics with network support, because whatever concept I think of, there's a significant flaw in it.
That leads me a suggestion: Server only physics. We can still have a physics engine on the client but rather as an option to improve the game feeling than as a real engine. What I want to say is that we could simulate smaller objects, that have no effect on the gameplay, like shrapnels, on the client.
This would also mean that we don't need physics on the client at all for the moment (testing phase).
My suggestion however does have a great impact on how to synchronise client objects on the server. Currently, afaik, we simply network the position, velocity and orientation to the server. So the client has full authority over his ControllableEntity.
I would like to constrain that behavior a little bit. For that we only synchronise an applied force that was induced by the steering.
What do you think about my suggestion?
A side note:
When thinking about client physics I caught myself up into lots of trouble:
- What happens when two ships run into each other? Do the two clients have to calculate the new velocity each for themselves without the server at all?
- The physics engine, as we know, delivers you the new position each frame. But with our model, we set that position ourselves every now and then.
- If a ship collides into another ship and the user accelerates, we've got two contradicting velocities, positions and orientations (one from the physics engine because of the collision, and one from the accelerator)
- Resetting the position of a physical object is considered bad practice because any precalculated data might be wrong then. Maybe the physics engine assumes finite velocities and can therefore do some optimisations.
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.
A webcomic of romance, sarcasm, math, and language.
I have found a very interesting article about the network concept in half life 2:
http://developer.valvesoftware.com/wiki ... Networking
http://developer.valvesoftware.com/wiki ... r_&_Client
http://developer.valvesoftware.com/wiki ... Networking
http://developer.valvesoftware.com/wiki ... r_&_Client
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.
A webcomic of romance, sarcasm, math, and language.
Who is online
Users browsing this forum: No registered users and 6 guests