Question on Networked Physics Article by Gaffer

Typically, each player controls one object at a time. The stream of input from one player is to control that object alone. Then the object's forces get updated, ect...

hi oliii,
ok i think this is the point where i'm missing something...

from what i understand, the client makes an rpc call to the server with the new input



what i thought is that updatePhysics() would step the physical simulation. like calling dWorldQuickStep in ODE. am I just plain wrong?

maybe i'm to focused on the physics engine i'm using (ODE)

this is done on the objects that receive the inputs. I think in his example, there is only one object in the physical world (a box that you tumble). If you had say, other boxes lying around, these boxes would get updated every frame, while the box receiving iinputs from a player would get updated only when inputs for that box are received. That's how we do it too. Player entities, which are controlled remotely by a client, update their physics when receiving inputs from the player, whereas the other objects update every frame like normal physical entities would.

please don't lose your patience :) maybe it's a language thing or i'am just... dull is the word?

ok, in gaffer sample, there is indeed only one box.
every time the server receives some 'input update' it steps the simulation forward using this input.
this means he calculates gravity, damping, collision and forces from user input and integrates an RK4.

but suppose there are two players. player1 controls box1 and player2 controls box2
how it is supposed to manage different input updates from different players?

this was the original doubt, and i can think of two ways to solve:
1) the server keeps different simulations for every client
or
2) the server keeps only one big simulation

in case 1) when the server receives update from player1 it steps the box1 simulation, and when it receives update from player2 it steps the box2 simulation.
in this case, in order to manage collisions between box1 and box2, each simulation needs to advise each other for the entity states. this means every time the box1 simulation is stepped, the box1 position has to be notified to the box2 simulation. so when box2 simulation will step, it will know the box1 position.
this seems to me over complicated and too cpu costly.

case 2) seems more simple. but it's not what gaffen was proposing (i think). the server is just stepping this unque simulation, maybe using the 'latest user input arrived' from every clients.

i'm sure i'm not grasping something

cheers

right, I could be totally wrong. I haven;t read the article in full, but keeping a copy of the simulation for each client is a bit extreme, and overly complicated, as you said. I don't know, I should read the article properly.

thanks anyway oliii :) i remember there was a huge thread on gdalgorithms-list on this article but the main topic was tcp vs udp (and a that time i wasnt very interested) so a just quit reading it

ciao

right. 32 player = 32 simulations. 32 times the memory, the processing, and 32 times updating the all of the object's positions. That's extreme.

Quote:

Original post by oliii right. 32 player = 32 simulations. 32 times the memory, the processing, and 32 times updating the all of the object's positions. That's extreme.

if your game engine cant handle simulating physics for 32 players simultaneously then you have much more to worry about than "extreme" physics netcode techniques.

must be some misunderstandinging here...

32 simulations means 32 different physics world to update. Not 32 objects to update. If each phyiscs world has 100 objects to update, that's 3,200 objects, to update and store. Dunno, but keeping a whole physics world for each player seems OTT. Then you have to sync each simulation with each other.


I guess it's partly feasable. Quake3 uses a copy of the update packet of each object for each players for delta-compression.

Quote:

Original post by oliii must be some misunderstandinging here... 32 simulations means 32 different physics world to update. Not 32 objects to update. If each phyiscs world has 100 objects to update, that's 3,200 objects, to update and store. Dunno, but keeping a whole physics world for each player seems OTT. Then you have to sync each simulation with each other. I guess it's partly feasable. Quake3 uses a copy of the update packet of each object for each players for delta-compression.

why the hell would you need to update 32 different physics simulations?!!

what article have you guys been reading, it certainly must not be mine...

that's the OP question. that's why I was dubious about it.

Quote:

Original post by oliii that's the OP question. that's why I was dubious about it.

yeah, its wierd. i guess i need to rewrite the article so people dont go around writing n seperate simulations, one for each player?! heheh ;)

seriously tho, that networking article is only a draft, i wrote it *before* i had completed coding of the zen of networked physics presentation for AGDC

anybody wanting to understand my technique should look for the source code here, and press escape inside the exe to see my presentation

http://69.55.229.29/downloads/NetworkedPhysics.zip

i'll update my networking article on gaffer.org shortly so it is better written and more up to date with the source code in the networked physics demo

cheers all

hi gaffer, thanks for answering, i'm the original poster
before starting this thread i've taken a look at your sorces. i was sure it was my failure in understanding, keeping a simulation for each player sounded weird, and so i posted.

in Cube.update, the physical state of the cube is stepped. i fail to see how two instances of Cube (two players) will talk each other.

one problem could be that my concept of 'advancing the simulation' is tightly coupled with the library i'm using (ODE) where there is a method WorldStep(dt) wich steps every object in the world.

anyway, you answered to my original post, so i will re-read your sources and articles and see if i've missed something.
and above all, thankyou very much for sharing your knowledge

cheers,
ettore