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]

[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]

[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]

[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.