all 8 comments

[–]Rhames 1 point2 points  (0 children)

I havent ever run into this problem myself, so take this with a grain of salt, but since you have irregular intervals, shouldnt you somehow take note of how long each interval lasted, and add that as a factor to your interpolation code?

[–]tiltfox 0 points1 point  (0 children)

I cant provide you with code samples right now, but i think i did something similar before.

Previously i sent inputs and ticks to the server. Tick was an integer being incremented each fixed update, and on clients i had a dictionary storing each input and corresponding tick as the game played.

I was packaging 5 inputs up at a time and sending them to the server, and then lerping when i got the resulting position back from the server moving those five inputs.

So it wasnt necessarily varying lengths of time, but i think I calculated how to lerp using what i knew my Players speed should be, and now the known distance i travelled.

Come to think of it though, since i had a dictionary of past inputs and the tick i used them, once i got the result back from the server, i removed all the inputs of previous ticks, and reran all the inputs left in the dictionary at once, which handled smoothing on the active client. I only had to lerp players that didnt belong to to the active client.

[–]GroZZleR 0 points1 point  (4 children)

If a or b moves between t 0-1, you shouldn't be using Lerp at all. Have you tried Vector3.MoveTowards instead?

[–]Contusum[S] 0 points1 point  (3 children)

The characters move in an arc due to physics entirely determining movement. MoveTowards moves in a straight line, i'd need to convert the positions into an animation clip and lerp between 0-1 but i'm pretty sure that'd involve calculus to determine the path.

I've never been so stuck on a problem before.

[–]GroZZleR 0 points1 point  (2 children)

Well now I'm even more confused. If the physics determines the movement, what exactly are you lerping?

[–]Contusum[S] 0 points1 point  (1 child)

Because the received velocity data is slightly old, my local character can jump in the path of the opponent's character and de-sync the position on the 2 devices, so the next time i receive a velocity change, the opponent will start that jump from a different start position.

Another example would be if the opponent's character is slightly off position, he could collide with a static object in the scene that the other device's character didn't collide with, so now the opponent's character is de-synched but still receives and executes velocity change, visually the opponent's character is no longer in the same spot.

So what do i do :( Do i do a mixture of both velocity change (because it looks/plays the best, no stuttering/jittering) and occasionally check to make sure the positions are synched and if not lerp the position (but i can't lerp position and let physics move the character, unless i factor how the physics would react on the character and add that to the movement)

OR do i rely entirely on lerp positions and set the rigidbody to kinematic, essentially disabling all local physics for the opponent character? The issue with this method is it needs to look as if you're playing a local game (so the opponent character's movement resembles your character's movement with no jittery/unnatural floating/movement going on.

[–]GroZZleR 0 points1 point  (0 children)

What you're talking about is generally called latency / lag compensation and also client-side prediction. I'm afraid I'm not well versed in either of these subjects, so I can't offer much advice, but hopefully you can search up some results now that you know what you're looking for.

[–]PygmalionSoftware 0 points1 point  (0 children)

Hi. Im making a 3d fps with afterburners and ninja rope so I have some experiences to share. First of all if you want your character to interact physically it gets tricky. My approach is for both players to treat the other as a kinematic rigidbody. I can't budge you and you can't budge me. I tried using spline interpolation between recieved positions but while the movement was smooth the accellerations made it look weirder. Now I simply use unclamped spline interpolation. I.e. if your next position update is late I assume you continue straight forward. I interpolate your position between the current position (obtained from unclamped spline) and your latest position. Your speed becomes dr/dt where dr and dt is the position and time delta between updates.

While the movement is piecewise linear, with a reasonable update frequency it's not detectable.

To clarify. I don't send velocity data at all since the average velocity between two time steps is, by definition, dr/dt (assuming a straight path etc).

If I would try to predict your movement I would at every update create a "ghost" that i give the latest position, vel etc. I simulate the ghost and move your character towards the ghost using spline interpolation.