- Home /
Networked Movement Jitter
myTransform.position = Vector3.Lerp(myTransform.position, syncPos, Time.deltaTime * lerpRate);
lerpRate is set at 15, although fluctuating this number doesn't appear to make any difference. Removing the deltaTime thing also doesn't seem to make any difference. syncPos is the position the vehicle should be, a SyncVar being updated on FixedUpdate by the owner of the vehicle.
I have a similar system set up for rotation which I'm perfectly content with. At (very) slow speeds, I'm happy with the system outlined above. However, for medium/high speed, the vehicle jitters a lot, despite the lerp.
I'm not pretending to have a true understanding of what is going on, but I think it's to do with this:
Let's pretend it's not a Vector3. Let's pretend it's just a straight line. Let's also assume the vehicle is travelling at a constant speed.
FixedUpdate is running on the owner of the vehicle, but netlag and other things result in the information from the FixedUpdates not landing on the target client's computers at the same rate they left the owner's.
So, if the locations of this imaginary linear line were 3, 6, 9, 12, 15 and 18, representing a fixed rate of updating across a fixed space at a constant speed, but land in the target game instance in realtime, there's two options:
(This is based on the assumption of | 3, 3, 3 | 6, 6, 9 | 9, 9, 9 | 9, 12, 12 | 12, 15, 15 | 18, 18, 18 | being the syncPos in real time, and assuming there's exactly three updates for each fixedupdate.)
Run the lerp in FixedUpdate: The positions are read as 3, 6, 9, 9, 12, 18 - causing a stop between the two 9's and a jump between 12-18.
Run the lerp in Update: The entire lerp is at the mercy of netlag fluidly.
Both these options are awful. Of course, I may be entirely misunderstanding the situation.
So, I did plenty of reading before posting this about network prediction, particularly the type used in FPS games. The only conclusion I could draw, aside from that I didn't totally understand how to do any of it in UNET, was it was well above what is neccessary for this game and not exactly fit for purpose.
What I would like to do, is run each client 1/2 a second behind, giving time for the FixedUpdates to catch up and run the lerping between positions at the same constant rate they were sent, just, y'know, slightly late.
Smoothness between objects is much more important that half a second of lag, in this instance.
I don't thoroughly understand how to do what I want to achieve, but I suspect I could code this system through brute force using either SyncVar Hooks or replacing the SyncVars with ClientRPC's. Before I attempt this, could somebody with knowledge either shoot down the nonsense I've free-associated is going on, or reassure me what I want to attempt will fix the problem?
Of course, any better solutions/suggestions/workarounds would be incredible.
I am in the same situation so I would love to hear peoples opinions on how to solve this using UNET.
Your answer
Follow this Question
Related Questions
How can I avoid jitter of house? 0 Answers
Airplane smooth acceleration problem 0 Answers
How to get transform.Translate to work with rigidbodies 2 Answers
Network rigidbody synchronize 0 Answers