So after a lot of work I got a smooth physics based network transform working using UNET and I thought I'd share. What I did -Used MessageBase to send all information (No NetworkTransform or SyncVars) -All physics calcs are performed locally on each client in-between network updates. -The client "owns" it's own players motion, and the server owns everything else. It's not cheat proof. -If owned by server the data is sent server --> all clients -If owned by Client2 the data is sent Client2 --> Server (Client1) --> Other Clients (Client3 & Client4 etc.) -Anything that applies a persistent force is applied locally on all clients. Like the chain harpoons in the videos. Force information is synced by not syncing the actual force, but things like spring rate or spring free length so force can be calculated locally & target information are synced via ID's. -Anything that applies an instant (impulse) force is only applied on the owners client only. For example if there is an explosion the server applies the explosion impulse to all server owned objects, but sends a ClientRpc to the owner with impulse info. Although this creates a delay for client-owned objects it prevents an object from being double/triple impulse (i.e. if the explosion impulse was instantly applied on the server, and then also on the client owner later, it would "reset" and snap back momentarily due to latency) -All physics object is broken up into 2 objects. I instantly snap the rigidbody & collider to the position sent by the owner. This would look jittery, so I LERP the visual aspects of the object. I do this because you can't LERP a rigidbody otherwise it wouldn't be physics based. -For a player object the information that is sent is ---Position ---Rotation (only Yrot is sent for the player since X and Z are locked) ---Rigidbody velocity ---Commanded angle/velocity (this is important... and allows physics to be performed locally in-between network updates) -The network send interval gets reduced for off-screen objects (it looks for the closest player). -If values have not changed then information is not sent (i.e. a wooden crate at rest) -For objects like arrows (or harpoons in the video) only speed, angle, and initial position is sent once. Since there is no way it can change trajectory there is no need to send periodic updates. -Data is compressed. i.e. angles use 12bits which gives 0.09deg resolution. -Another layer was added on top of the UNET HLAPI. This allows me to send data in both directions. For example position information for the player is controlled by the player Client2 --> Server (Client1) --> Client3&4 but animation data is sent from Server --> Client. The default UNET HLAPI does not allow data to travel both directions. Anyhow it took a long time but it finally seems to be working well. Any questions just let me know.