Newton and networking

[PJani]

I'm planning to write server-client interface for newton but here some things are getting kind of blurry.
Ok networking, here is no problem... UDP+TCP hybrid UDP for updating bodies at client side heavy - heavy duty, TCP for high reliability jobs(creating, destroying, etc.).

Client would act as a physic player...if you dont understand me i will explain now.

Newton on both sides(client and server)...Server should have full control over all world and doing all serious calculations in newton and sending update packets to all clients, but only for bodies that are in visible range on client, client will use newton for smooth play, but in very small region.

Copying data and updating physic bodies is no problem, but what about joints?? Joints are making me go crazy...

[Carli]

well, networking is a great problem.
i'm solving it in having the calculation on serverside and the graphic on client side. the server is streaming the object matrices.

there are only two things that cause problems:
- dynamic meshes in destructible bodies
- the ammount of data (a matrix is 16*4 bytes)

[agi_shi]

- the ammount of data (a matrix is 16*4 bytes)

You can lower that to 7*4 bytes by using a 3D vector for position and a quaternion for scale/orientation.

[PJani]

Jeah im not so much concerned about network bottle necks i will solve them with time, i dont know how to stream two bodies that are connected together... .
About destructable bodies hmm maybe server should rise event when some body is breaking and then sync all new parts with server .

[aqnuep]

i'm solving it in having the calculation on serverside and the graphic on client side. the server is streaming the object matrices.

Is this working in practice? Isn't it causing too high latency? The client observes the changes much-much frames later.
Also for UDP based networking: does it often produce popping artifacts? How you improve data consistency?

[Carli]

i did not test it in practise but i can imagine to get better results through the following improvements:
- give a quaternion instead of a matrix
- broadcast velocity for pre-simulating
- update far-away-objects with a lower frequency
With a Bandwith of DSL 2000 (the minimum you can accept) you could send 30 position updates each second, that's not that much.
A server should at least be able to send 300 position updates per second, that means ~7 updates per second.
Just enough to have 3 moving objects and 2 characters plus the camera matrix plus some extra information
should be enough for a racing game but it's too less for a strategy game.

Edit:
my other idea was to stream the moving images - with todays broadband connections no problem.

[aqnuep]

With a Bandwith of DSL 2000 (the minimum you can accept) you could send 30 position updates each second, that's not that much.

I am much more afraid of latency than bandwidth, because that makes people much more annoyed

... should be enough for a racing game but it's too less for a strategy game.

I am working on a general purpose game engine, so I am concerned about both situations. However, higher bandwidth requirements are acceptable for strategy games.

my other idea was to stream the moving images - with todays broadband connections no problem.

Yes, this is the way in which things are going nowadays, but I'm not really pleased with the idea

I would be interested in those guys' opinions who made network based games with Newton. I know that there are a few people who made such thing so I hope they'll find this topic

Btw thanks for your thoughts.