Probably, but this is a really good starting point in physics simulation.

Many thanks,
Alex

but yeah, pretty good example of the reason why physics engines don’t use penalty methods for collision response these days (eg. spring forces) — it’s hard to tune and dependent on the mass of objects, amount of gravity etc.

bottom line: use ODE or Bullet instead

I’ve been playing around with your sample code, and I noticed that after changing cube’s mass (e.g. to 5.0), it started to look like gravitational acceleration has been reduced. Bug somewhere, perhaps?

Thanks for this great article series.

Alex.

but i know the fact about floating points across multiple platforms, systems,… you name it. i had the problem with syncing server with the client’s web application. simple solution step up the precision on every individual calculation and round it down again; or you can tie multiple calculations together, as long as it dose not affect the initial precision. i have used it with floats and doubles; floats and 5 digit round numbers. the result was always the same.

and there is always the way to use bit level calculations. after all a 1 is a 1 and a 0 is a 0. it might not be as fast though. but, any way, this is useless in networking with approximation and smoothing involved. but it is good for syncing sensitive data, like bank balance.

The authority scheme is no good as I am targeting competetive gaming.

This also makes latency a problem.

I have got collisions working fine where the server has the final say, but the client predicts them, using collision detection in the replay. My problem is that in the scenario (may not actually be a big issue in real situations):

I simulate about 1 second of latency
On the client simulation, the owned player runs through a section of empty space, a new entity is crosses paths anywhere the player passed through less than a second ago.

As the client is receiving state from 1 second ago from the server. It saves the current time, loads the state from the update into the player.

Making the player have a time of 1 second in the past, and having a position before the new entity that spawned.

The correction then replays the input of the player for the last second, causing it to collide only on the client with the other entity.

This causes the client to snap back for about half a second, then towards where the original position should have been. So in the end the server predicts correctly, and the client ends up in the correct state, but it suffers some nasty visual flicker.

I Guess 1 second latency is not realistic anyway, but as you can see, its not a problem of clients being in different timestreams, but multiple entities on 1 client being in different timestreams.

It might be nice to know that limitation of the client input replay method. That it creates a CLIENT SIDE only collision field of the movement in the last seconds. The only solution being that each entity exists in the same time stream in the whole scene which is not practical.

Cheers,

Speno

one option is to just accept the lag. the server runs the simulation only, and the clients are dumb, perhaps interpolating between position/orientation samples using a hermite spline. in this case because the simulation runs on the server only, the interactions between players are all well defined. but of course, the players movement is all lagged.

if you cannot accept latency, another option is to use an authority scheme. you can find a quick overview of this technique here – http://developer.nvidia.com/object/physx_tips.html#Network. in an authority scheme, the collisions between players are still somewhat undefined, due to different time streams, but because you are not ever rewinding and replaying, it is cheaper to simulate and the result is much better.

just be aware that the authority scheme prone to cheating so it’s best used for COOP games only.

cheers

This article has been very useful in my understanding of networked physics, and has helped me build a game engine that supports multiple entities that follow your principals of state synchronisation.

However I am currently trying to fix a problem I am having with collision between 2 entities owned by different clients.

My collision detection works fine, but I started running into problems when I simulate high latency.

High latency is causing a client’s player collide in their “Replay” period in the client prediction when it should not have.

As you only have 1 entitiy on your sample, and static collision planes you dont deal with this.

I understand the problem arrises from one entity being rewinded back in time to receive a correction, while other entities stay at the latest time.

If I rewinded everything in my scene when I do a client owned player state correction I could solve this problem, but this is going to get costly on the CPU time with any decent number of entities in my scene. Not to mention memory keeping a state history of all entities in my scene instead of the owned player.

I have tried removing collision detection during replay, but as a player with any real latency will be replayed every frame for the last / frames of movement, collisions need to also happen in replay.

Is there a simpler way to solve this than rewinding my entire scene by the latency amount for each client owned player update(ie every frame)?

(just to clarify if its not clear, by “Replay” I mean when the server sends out a sync update to a client regarding the player it owns, it rewinds to update time, then replays the input to current time)