Shortcomings of base rotation support

[Baker]

NetQuake engine rotation support: viewtopic.php?t=2376

Well ... 2 problems with this.

1. Rotating objects look jerky. This is easily solved with brush model interpolation (which smooths the angles).
2. However getting pushed by a rotating brush model, makes the view look jerky. So "view interpolation" is needed too. Again to smooth the angles.

Funny stuff.

[Baker]

Actually I'm all wrong about this. I swear I solved this problem once but maybe not as fully as I imagined. (Cause my attempts to solving this are failing and now I'm just confused).

Back to the drawing board, recognizing that QuakeC's 10 FPS is probably the cause of jerkiness (onground, not, onground, not) and maybe I fix some other jerkiness but not this?

[Baker]

Ok ... my memory must suck. After a waste of an 1.5 hours, I've discovered even with Fitz 666 that interpolating angles is purely futile.

The reason is that the angles are sent as bytes (except for the client view). These are rounded ("256 degrees".)

This means the angle differences from update to update are going to be inconsistent and trying to interpolate them is going to be jerky because one update might have rounded in a way that makes it signifcantly higher. Oddly enough, the ancient NetQuake protocol with just sending a truncated byte is going to be more consistent.

Maybe I was experimenting with short angles (which are smooth).

[goldenboy]

By the way,

is it possible to have an engine extension that makes the player rotate properly when standing on a rotating entity?

Carousel-like.

Or is this best done via qc.

[Spike]

gb, that's best done clientside tbh
spamming svc_setangles to the client is basically suicidal.

[mankrip]

However, the physics are server-side.

Thankfully, the only thing I ever wanted to use rotation for are stuff like doors.

[qbism]

I guess this is a problem for multiplayer with varying lag from packet to packet? Doesn't seem like it's an issue for single player or local network.

Anyway, let the client interpolate bmodel rotation over several packets, should be fine for brushmodels with constant rotation (or minor angular acceleration).

It might be nice if the server could somehow clue-in a client that the player is on a particular rotating bmodel, so that the client could add the exact interpolated rotation delta for that frame to the view direction.

[Baker]

I guess this is a problem for multiplayer with varying lag from packet to packet? Doesn't seem like it'an issue for single player or local network.

It is absolutely a problem in single player. 360 degrees cannot consistently be truncated to a single 0-255 range byte.

Anyway, let the client interpolate bmodel rotation over several packets, should be fine for brushmodels with constant rotation (or minor angular acceleration).

Not really. The server will be sending angle information every packet, not angular momentum. If you knew an object was rotating for sure, that'd be one thing. But you can't distinguish between something rotating or turning. Sure you could do a clever hack and I was so frustrated for a moment I was considering the same thought you had.

[ceriux]

baker i may be wrong, but i think even in half-life (1) that when you're pushed by a rotating brush your view is jerky. maybe ill do some experiments and let you know?

apparently i was wrong, i just tried DoD and it seemed pretty smooth.

how fast are your brushes rotating? maybe it has to do with the players max speed?

[qbism]

It is absolutely a problem in single player. 360 degrees cannot consistently be truncated to a single 0-255 range byte.

Angles should be sent as shorts. With shorts, engine rotation and physics fixes, the ride seems smooth enough. Protocols that can only send bytes should be discarded from consideration for "ridable" rotation, except for purposes of mental anguish. Can't send something so grainy to the client to interpolate out... with slow rotation, some packets will duplicate the values if rotation hasn't increased more than 1/255 circumference. And little lag variations are killer. 0 0 1 2 2 3 4 4 4 5 6 ....

[mh]

I don't think that QC should be directly controlling the rotation. Look at rotating pickups - they're smooth; QC just isn't up to the job here (plus there's angle quantization to deal with - yuck).

A proper interface for rotation would consist of StartRotating (speed, vector) and StopRotating (speed, vector) and the engine can work everything else out. Both the client and the server can simulate the rotation separately to avoid sending angles over the wire. Yes, it means a cheating client could simulate a different rotation, but it can already do that anyway - just put different values into glRotatef (or don't bother calling it at all) so that's no big deal.

Watch out for values of angles[1] of 1 or 2 - they have special meaning in QC (evil evil evil - and all the more reason to keep QC away from it).

[Spike]

csqc?

[Baker]

It is absolutely a problem in single player. 360 degrees cannot consistently be truncated to a single 0-255 range byte.

Angles should be sent as shorts. With shorts, engine rotation and physics fixes, the ride seems smooth enough.

That's what I did to fix the problem. Remake Quake probably did that with the 999 protocol (haven't checked).

But still neither NQ or Fitz 666 support short angles for entities (Fitz 666 does for the player view), so that means a non-standard protocol. But it is smooth.

Maybe last year I was doing a test that had some magical rotation speed that rounded well for byte angles and tricked myself into thinking bmodel rotation interpolation could solve the trick.

[Still might need bmodel interpolation for proper presentation over a network .... I hope not, but I've grown to expect inconveniences.]

[mh]

CSQC: Probably, but if a much simpler solution exists why go to all the bother?

I'm fairly certain that a major potential problem with any QC-based rotation update is that an entity can be thinking out of step with CL_LerpPoint updates.

Even with shorts - or pure floats across the wire - Hipnotic rotation messes up. RMQ can select from 3 different precisions (quantized to byte, quantized to short or full float) which exists just for testing and evaluating the tradeoff between more data and smoother rotations. Shorts are good enough for avelocity-based rotation.

[mh]

bmodel interpolation actually doesn't work - it really screws with plats. CL_LerpPoint interpolation is better here.