VR movement component client-server prediction algorithm / bandwidth minimizer

Here is a rough explanation of my client-server prediction or bandwidth minimizer algorithm for replicating the movement of the VR components (HMD and hand controllers):

https://github.com/skoutroberson/Gunfight/commit/afd74636cf49b3968ede68b4186248bef6fe6129

VRComponent VR Movement server-client prediction algorithim (maybe the wrong term) or: bool ShouldSendRPCThisFrame()

Bandwidth Minimizer

- Save DeltaVector/DeltaRotator for each VR component; HMD and Motion Controllers.

- If the new DeltaVector/DeltaRotator is almost equal to the last frame, or the DeltaVector/DeltaRotator is

close to 0.f (less than MinMovementDelta, then don't send the RPC. In order to not keep doing this,

save a MaxPredictionTime and keep a CurrentPredictionTime that adds DeltaTime each frame if we predicted

last frame. If we didn't predict last frame: Set CurrentPredictionTime to 0.

- if(CurrentPredictionTime > MaxPredictionTime)

ServerVRMove_ClientSend(); CurrentPredictionTime = 0;

The parameters that can be changed with this solution is:

* MinMovementDelta - If DeltaVector/Rotator is less than this, don't send the RPC this frame.

* MaxPredictionTime - predict more often (don't send RPCs).

- My estimation is that this could save at least an average of 25% bandwidth over time for the clients/server

from the VRMovement Remote Procedural Calls (RPCs). (If a player is moving a lot and very active, then this

won't help unless we crank the numbers, which will mimimize movement accuracy on the server/other clients).

GAME GOAL BANDWIDTH: 0.5 Mbps

Bandwidth estimation upload/download for server with 10 players without ShouldSendRPCThisFrame():

60bits * 2vectors_netquantize * 3components * 25times/sec * 10players = 0.09 Mbps.

Bandwidth estimation with ShouldSendRPCThisFrame(): 0.09 - (0.09 * 0.25) = 0.0675 Mbps.

Average Saved bandwidth: 22500 bits/sec.