Friday, June 4, 2010 at 10:27 AM |  
Just a day before I tried back network play of aftershock and to my dismay the jittering issue came back. I thought I had nailed it but apparently I did not. So I delved more into the design of my code and did tons of debugging again. After a few test cases, I finally found out the issue. It was two fold.

Firstly, there was an issue where my client side's simulation was shifting farther and farther away from the server's simulation due to time discrepancies between both systems. Secondly, my camera simulation code was not entirely in sync with the physics simulation code when applying frame smoothing.

After some tinkering, I managed to fix both issue. For the first issue, I kept a 5 frame buffer of frame latency to get the average latency across snapshots. From there, I use it to cap the frame difference between the current physics frame and the given server physics frame.

Now everything works like a charm and no more jittering from my test case. In fact it's so smooth compared to my last work that I'm mightily proud of it! :-) I do know that I'm not revealing much of how I did my network syncing here. I'm rather busy working on many things right now. But I promise I'll put up a post with some diagrams some time later to explain the approach I used. In short it's what Gaffer suggested for the server client approach though like I found out as I did this, it's not as simple as it sounds. There's slightly more to it than just sync and smooth.

Aside from that, I wish that bullet provides a proper method for me to selectively simulate a group of rigid bodies. This would help a lot for the prediction simulation after snapping of server update state; we don't want to end up wrongly simulating non networked local rigid bodies or non important rigid bodies that are not part of the network update snapshot.
Posted by Lf3T-Hn4D


Syed said...

Can you provide more info on the implementation? AFAIK, bullet physics is deterministic - did you use this for network code purposes?

I read in, one way to do vehicle client-server is for server transmit the 'extrapolated' position, and the vehicle at client should be able to target toward this position (steering, braking, accelerating etc).

June 9, 2010 at 4:28 AM  
Lf3T-Hn4D said...

Hey, the basic gist is to always keep your client time in sync with the server. The trick here is that instead of just snapping your rigid bodies during snapshot update, you fast forward the simulation to sever_sync_sim_time + network_latency. This way, the client extrapolates whatever the server sent in with the account of network lags. If time permits, I will write a blog post on the details of how I managed it. ;-)

Bullet is only deterministic when the whole simulation setup is exactly the same. This unfortunately is impossible in a network environment where server only sends enough of what client can see base from client's camera.

As I mentioned that bullet doesn't allow me to isolate and simulate a group of rigid body island, it's quite difficult to properly use bullet in an environment where we have local and remote physics going around.

June 10, 2010 at 3:24 AM  
Syed said...

"If time permits, I will write a blog post on the details of how I managed it. ;-)"

Yes please.. it will be rgeately appreciated.. :)

I have done the network part, it is not that smooth (you may notice jittery). I am using hplus' EPIC, and synchronise the client & server time too.

June 11, 2010 at 11:43 PM  

Post a Comment

Liquid Rock Games and Project Aftershock. All Rights Reserved.