Real (Bullet) Physics in Quake 2 - Take Two!

[Paril]

Yes, something like the death ragdolls in HL2 (not the ones you spawn in GMod as actual ragdolls, but the ones that appear when people die).

It would be impossible to sync them up 100% with just client-side prediction.

-P

[Paril]

Hi paril, cool stuff. You get on IRC at all? quakedev seems dead

Hey Kren, sorry I completely skipped over your post.

I don't very often, just MSN and Skype. I frequent #reactionquake3 and #wirehead in EnterTheGame, though.

-P

[VaeVictis]

Yes, something like the death ragdolls in HL2 (not the ones you spawn in GMod as actual ragdolls, but the ones that appear when people die).

It would be impossible to sync them up 100% with just client-side prediction.

-P

so... like an origin point for the rag doll and then it can behave however it wants with all the limbs and such on the client?

[Paril]

Yeah. The server would just say "ragdoll spawns here at these angles, have fun".

-P

[Irritant]

Yes, this is how it is done on the server as well; thank you for your godly insight

Well that was kind of uncalled for   Since I haven't seen your code I wasn't sure if you weren't well, like maybe spawning them from player_die, or something along those lines

I had trouble with Bullet on the client side due to it running at a variable FPS, so I have to see what I can do to make it run at a fixed 30 or 60 like the game DLL.

There should be ways to deal with the variable framerate in Bullet.  We used ODE, but I'm sure there are similar functions in Bullet since it was built from ODE.  Darkplaces also does something similar.  This is our little block of code, not sure if it'll help or not..

Code: [Select]

int ODEIterationsPerFrame;
int frametime = Sys_Milliseconds() - lastODEUpdate;

//iterations need to be adjusted for framerate.
ODEIterationsPerFrame = frametime;

//clamp it
if(ODEIterationsPerFrame > MAX_ODESTEPS)
ODEIterationsPerFrame = MAX_ODESTEPS;
if(ODEIterationsPerFrame < MIN_ODESTEPS)
ODEIterationsPerFrame = MIN_ODESTEPS;

dSpaceCollide(RagDollSpace, 0, &near_callback);

dWorldStepFast1(RagDollWorld, (float)(frametime/1000.0f), ODEIterationsPerFrame);

// Remove all temporary collision joints now that the world has been stepped
dJointGroupEmpty(contactGroup);

lastODEUpdate = Sys_Milliseconds();

Excuse the formatting, this board seems to get wonky when posts are longer than the window.

[quadz]

Yeah. The server would just say "ragdoll spawns here at these angles, have fun".

My presumption would be that in multiplayer, a lot of the potential fun of ragdolls would be diminished if players were seeing dissimilar orientations of the model.

player1: haha!
player2: what?
player1: did you see the corpse arm get caught and the body get dragged up the lift??
player2: ...no :(  mine's on the floor over here


Maybe the client could treat its local modeling of the ragdoll as a prediction, and the server could periodically send a low-res snapshot of its 'master' ragdoll position to the client.  If the client's ragdoll state has drifted from the server's, the client would be responsible for interpolating over some number of frames to put its position back in line with the server's snapshot.

If we've got 10 potentially visible moving ragdolls, and the server were sending just one ragdoll snapshot per frame, then each ragdoll would still be receiving a snapshot every 0.3 seconds given your 30Hz framerate...  The fewer ragdolls moving, the more rapidly snapshots could be sent.

If the PVS changes and new ragdolls become potentially visible which haven't received snapshots in awhile, their snapshot would be scheduled to be sent ASAP; and presumably the client wouldn't bother interpolating, but would just accept the server's positioning immediately.


Dunno... Just a thought. . .


Regards,

quadz

[VaeVictis]

Yeah. The server would just say "ragdoll spawns here at these angles, have fun".

My presumption would be that in multiplayer, a lot of the potential fun of ragdolls would be diminished if players were seeing dissimilar orientations of the model.

player1: haha!
player2: what?
player1: did you see the corpse arm get caught and the body get dragged up the lift??
player2: ...no   mine's on the floor over here


Maybe the client could treat its local modeling of the ragdoll as a prediction, and the server could periodically send a low-res snapshot of its 'master' ragdoll position to the client.  If the client's ragdoll state has drifted from the server's, the client would be responsible for interpolating over some number of frames to put its position back in line with the server's snapshot.

If we've got 10 potentially visible moving ragdolls, and the server were sending just one ragdoll snapshot per frame, then each ragdoll would still be receiving a snapshot every 0.3 seconds given your 30Hz framerate...  The fewer ragdolls moving, the more rapidly snapshots could be sent.

If the PVS changes and new ragdolls become potentially visible which haven't received snapshots in awhile, their snapshot would be scheduled to be sent ASAP; and presumably the client wouldn't bother interpolating, but would just accept the server's positioning immediately.


Dunno... Just a thought. . .


Regards,

quadz

the funny aspect was kinda what i was thinking

thats the whole point in having rag doll physics... lawl factor would make them worth it, otherwise they might just be annoying...

PLUS gameplay problem, if the rag dolls are in a different place to the server vs the client, a rocket could hit a rag doll on the server and explode, but just explode randomly on the client... or even explode in some ones face cause they are standing next to a rag doll... it has a practical gameplay aspect, good to aim for dead bodies with nades and stuff to gib them and get a nice splash damage explosion

[Acer]

Excuse the formatting, this board seems to get wonky when posts are longer than the window.

Internet Explorer 8?  Tools ->Compatibility View Settings and add "tastyspleen.net" to the list, seems to fix it.

[[BTF] Reflex]

Quake only lets you have 8 bodies,  ragdolls have different/same limit?


It game hitting a body can be a tactic.

    Barton is heading across megaroom in dm1,  I'm around the stairs waiting with my grenade launcher.
  A body is just on this side of the corner and I shoot the body right as Barton comes into view.

 
Be neat to "nudge" a body into position for some ploy.

Finally gets rid of the "floating in midair" corpse bug. 

[Paril]

Due to the network inefficiency of ragdolls (read up), I capped the limit to 4, which seems to be the lowest I can go without overflowing everybody.

Well that was kind of uncalled for   Since I haven't seen your code I wasn't sure if you weren't well, like maybe spawning them from player_die, or something along those lines

Oh I know, it just sounded a bit patronizing; I was kidding . Anyways, they are indeed being spawned from player_die, just replacing the bodyqueue portion, although if I did move them to the client side I would most likely do it in the EV_DEATH event. I don't use frames anymore for animation, I use animation files (to account for the 30 fps change but still using our 10 fps files).

Quadz, your long and inspiring post is nice, but too much work for something so simple as ragdolls. If I was going to implement snapshots, I would end up doing it for every entity while I had the system in place, and that's somewhat of a large change to replace the stupid baselines that Quake 2 attempts to delta from in a new PVS. Also, slight flaw in your idea: what happens if a player gibs a ragdoll piece while it's out of sync?

if the rag dolls are in a different place to the server vs the client, a rocket could hit a rag doll on the server and explode,

They aren't "in a different place", the server doesn't have them at all. Besides, ragdolls are not solid.

All-in-all, I think leaving them where they are now is the best option. A max of 4 is quite limiting, but because of how much space they eat I can't really go up anymore (~200 bytes per ragdoll, 1400 byte limit, do the math people!)

-P