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

[Paril]

Another video:

http://www.youtube.com/watch?v=lruTzz3iMh4

This one has a special announcement at the end.

-P

[yahoo]

vey nice indeed.. Too bad my hardware cant handle it. But its really good though.

[Paril]

I'm sure it'll be fine on your machine. The physics aren't too intensive. The bloom is just an extra effect, without radial on it's not that bad

-P

[kren.Z]

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

[VaeVictis]

im actually really excited bout this

you should add chaingun partical effects similar to q2evolved q2e has BEAUTIFUL chain imo...

also.. you have water splash for stuff like bullets and gibs?

and will this client be compatible with normal 3.20 or r1q2 servers?

can you make it anticheat friendly (im assuming its based off of egl so good posibility)

did you take a look at the thread squarehimself made ages ago where a few people made a lot of suggestions for an ideal client?

are you considering making a mini campaign with your new kickass engine? id play it...

[Paril]

Perhaps, I'll look into it.

Not for entities, but bullets always have.

No, as said before the network protocol has been mutilated and enhanced quite a bit. Backwards compatibility was not a concern to me.

No.

Most of the features suggested EGL already had, but I'll have to take another look.

No, it's intended to be played multiplayer - a lot of the features I added in the networking code is aimed at improving efficiency and prediction.

-P

[Jay Dolan]

Yes, hence why I want to move them to the client-side

Or at least make a special ragdoll entity type that lets me encode each body part as one entity and cull it from the chest. That seems more like a hack to me than anything though, and it wouldn't really improve the netcode a lot because the game still has to send at the most 7 shorts (three for origin, four for quaternion rotation) for each part. The other option is rather than sending the parts, send over the joint rotation data and calculate that on the client side, but my math experience is quite limited. Have a better idea?

-P

With Quake2's delta compression, I honestly wouldn't worry about the bandwidth used to send a few entities for each rag doll.  You're only transmitting data for them when they move; if they're just laying there on the ground, they're "free."  Quake2's network protocol was designed for 1997, when more than half of the population was still on dialup!.  You should add a bps counter to your client so you can see what you're actually using.  My guess is you're well under 5KBps per client.  And since you've increased the server frame rate to 30Hz, that will help keep the average packet size down so that you don't run into overflow conditions.

Bottom line; I wouldn't sweat it from a bandwidth perspective.  You might want to think about updating the protocol to cope with > 1024 entites, tho.  But that's a pretty painless enhancement.

[Paril]

The problem is once you have about six ragdolls, the clients' message buffers begin to overflow. This was before a lot of client-side prediction, but it does have to do with the fact that there's quite a bit moving around. When one ragdoll piece moves it's almost guaranteed the others will too (there are 11 pieces per ragdoll, and all-together there'd be about 4(bits)+1(type)+(1/2, depends on number)+6(origin)+8(quat angles) per entity.

I did add the ZPACKET from R1Q2 lately though, that might help a bit.

Moving into a new area that may have several ragdolls is also a concern because the entities will be transmitted as "new", causing each bit of unchanged baseline data to be sent.

However, I'm not sure if this will be solved by just increasing the max buffer size - is the ~1400 limit still pertinent to today's technology? I really don't know a lot about networking, your input would be highly appreciated.

-P

[QwazyWabbit]

Yes, the 1400 limit is still pertinent. The frames are UDP and fragmentation would mean potential lost portions.
Would it be worthwhile to enhance the protocol and have some kind of retry/reassembly going on in the application layer? I don't know.

[Paril]

More or less I'm looking at the Quake 3 source. It uses fragmentation for snapshots.

Kind of difficult to figure out what exactly I want or need to do about it.

-p

[Jay Dolan]

I'm really surprised that you're hitting those limits already.  6 entities per rag doll should not incur a tremendous amount of data -- or not so much that the protocol starts breaking.  Truly shocked.

Anyway, R1Q2 has some mechanisms to help avoid overflows, right?  I don't suppose you started with his code base..

[Paril]

No, EGL, but I did steal a few things over from R1Q2.

I also made several other enhancements to the protocol, but like I said I limited the ragdolls to 4 way before I did these enhancements - I have not tested lately what the limit would be (it was in the middle of q2dm1). Temporary entities were removed and replaced with events, and several other small enhancements.

My big issue is more or less the baseline problem when you move into a new area. Delta compression may help with if you're already in that area, but if you're not, there's an issue. My guess is that's how Quake 3 gets around it is by transmitting snapshots of the entities to each player (fragmented) which replaces the baselines. That's something I can think about too.

EDIT: It's not 6 entities per ragdoll, it's 11 (head, chest, pelvis, two upper/lower arms, two upper/lower legs). Each piece takes up 29 bytes, so 29 * 11 = 319. When you think about it, that's a quick overflow on a 1400 byte limit. So then here's my idea: use one single invisible entity to encode the ragdoll to each player. In the entity, send the number & the type (ET_RAGDOLL, that's 5 bytes so far); in the delta part, use some pointer magic to get the ragdoll piece structure. In each piece, if it's both there (gibbing ragdolls removes pieces) and in player's PVS (would need separate culling due to invisible entity) encode the visible ragdoll pieces in a short (up to 11 bits; 7 bytes now). For each piece visible, send compressed changed origin (6 bytes) and quaternion changed values (8 bytes on baseline, depends on which values changed enough on a delta). That's where the data gets a bit heavy; 161 is the worst-case/baseline scenario. And this doesn't include other ragdolls or entities in the area. That's about 1/8th of the entire buffer that I can send to the client.

My best option is still to move ragdolls to the client side.

-P

[Irritant]

Client side ragdolls are not hard to implement, that is how we did it in Alien Arena.  The basic idea is when a mesh reaches it's death frames, the ragdoll is spawned and takes over.

[Paril]

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

I already do client-side integration for a lot of things, moving the ragdolls won't be hard - the only thing is I'd rather not have to run two simulations for listen servers. 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.

However this would also give me a chance to implement cloth physics to replace those stupid banner models.

I might be able to hijack the server's physics world in the case of listen servers so that I don't have to run two..

-P

[VaeVictis]

if you implement ragdolls client side wouldnt that make them all screwy between different users on the server? one users sees one thing, another user sees something completely different