Jitter Free Movement

[hvault]

Hi

Ive been working on implementing multiplayer movement using TNet and am having trouble with movement always beeing jittery.
After reading many posts and trying a few things, I went and purchased the Multi-Purpose Game Starter Kit from the asset store as was mentioned in quite a few threads.

Initially I copied the bits of the code I needed, and still have jittery movement.
So I opened, compiled and ran the kit (with no changes) on my two PCs (Core i7 and i5, nVidia graphics, lots of RAM, etc...) and still have jittery movement in the kit itself.
Its not so obvious with the helicopter, but very obvious with the tank.

Ive tried modifying a few of the hard coded values, but haven't had much luck.

The only way I worked out to remove the jitter is to diable the TNAuto Sync. However then the positions get out of sync and the tanks are in the wrong spot.
Dropping the updates per second to 1 also helps, but doesn't solve the problem.

The jitter movement occurs if I am running the client / host on different PCs, or the same PC.
Network is a local dual-N band wifi that works fine for other multiplayer games.

The kit seems to be great and covers many options, which will be handy in the future, but I want to get multiplayer movement working well before I move on to the next stages of development.

After 2 days of fiddeling around with everything I can think of, I can't think of anything else to try.
What are some steps I can try to remove this jittery movement ?


Thank you,
hvault

[ArenMook]

Dual-band router... hmm. This reminds me of an issue I had with a D-Link dual-band router. Connecting my computer via (5 Ghz) to a tablet (2.4 Ghz) would give insane ping delay... like 600-1500 ping. However if I would connect both via 5 Ghz or both via 2.4 Ghz, the delay wouldn't exist. What's your ping like?

[hvault]

It was a couple of days before I could isolate the network I needed to conduct more testing.

To be sure that nothing else was getting in the way, I also did the following:
- Disabled anti-virus
- Checked and updated drivers (including wifi)
- Removed Unity and all associated files, then re-installed Unity (note: I have the free version as Pro isn't in my budget for a few more months yet)
- Deleted project of game starter kit, re-imported and re-compiled
- Shut down all background processes and anything else that might get in the way

I usually have upnp disabled (as I prefer to map ports manually) but in this case also enabled it on the router.

The wifi network itself looked fine.
Windows ping over 500 requests showed an average ping of 4ms, with a max of 14ms and 1 dropped packet.

For cat5 cable tests I removed all other devices, so only desktop PC and laptop were connected to router. No internet access.
Over cat5, Windows ping over 500 requests was 1ms average, with a max of 4ms and no dropped packets.


I covered hosting the game on both PCs, with both the game, unity player and provided TNetServer.exe file.

The jittery problem was no different between wifi or cat5.

I'm not sure if the turret on the tank is supposed to be smooth, but it jerks a lot when driving in a circle, so I concentrated on the tanks main body only.
The jitter mainly seems to happen when things change like accelerating or stopping. Like someone's foot fell off the brake (if tanks have brakes), but then it jumps back in time to where it should have been.

Sorry that's a bit more than just the ping but I had the spare time today and wanted to cover as much as I could at once


EDIT:
Oh I just noticed Unity 4.5 is out and causing a few problems by the sounds of it with the serialization changes.

So I thought I should mention I'm running Unity 4.3.4f1.

[hvault]

After a bit more experimenting I noticed that the jitter could be reduced by lowering the multiplacation factor in VechicleRenderers.cs.
I.e.

1. float factor = Time.deltaTime * 15f;

Changing this to 5f or 3f really helped, and got me thinking about why there is the need to multiply by the elapsed time since last call to Update.
Also the use of mAlhpa is set to 0 to begin with, but then only changed based on itself for each update call.

So I put in a debug line just after the mAlpha set to check these values in further detail. Ran the game starter kit and drove around a bit.

1. Debug.Log ("factor = " + factor + " ;mAlpha = " + mAlpha);

After about 50 executions, mAlpha reaches 0.999999 and stays there for good.
The factor hovers arouns 0.022xxx to 0.026xxx, on the odd ocastion going up to 0.044xxxx when something happens like a turret firing.

So I could be way off here and please correct me if i a wrong.
But for each update the render game object is vector3.lerp-d to around 24% of its destination, with the local position after a few executions always set to 99%.
Same thing for the rotation.

Whilst investigating other options I stumbled upon this blog entry about using lerp and how the tutorial got it wrong.

http://www.blueraja.com/blog/404/how-to-use-unity-3ds-linear-interpolation-vector3-lerp-correctly


I need to run a few more simulations on this topic before Im happy with its contents (I always like to test things that I haven't used before much).


What are your thoughts on this ?

[ArenMook]

The renderer follows the rigidbody smoothly, and is in effect detached from the rigidbody. The smooth movement is a spring-type movement, not a lerp. Meaning the renderer always tries to follow the rigidbody, but never really reaches it. The alpha is there to make it possible to disable this behaviour, letting everything be based off of physics instead. This is good to have when there is a lot of abrupt movement happening, such as an explosion. Spring interpolation means abrupt movement gets smoothed out -- which isn't a good thing to have when you actually want abrupt movement.

[hvault]

Ah ha. That explains a few things thank you.
Nifty way of using lerp to allow the physics to work.
Plus I was wondering why the renderer kept 'moving' once stationary. 

Thanks for replying so quickly.


I'm still a bit stuck though as the only way I can find to completely remove all jitters is to set the factor multiplier to 5 and the auto sync to 10 times per second.
This auto sync update seems way too high though, and is probably related to me driving like a maniac looking for jittery movement.
The main jumps appear to be on a significant change, such as stopping whilst at full speed, and heading to full speed when starting from a stop.

I was considering adding something to stop the renderer going in the opposite direction of the force. I.e. if velocity is in direction A and sync sends a position in direction -A, ignore it until the velocity become near 0. I'm not sure if this would have any side effects (or if its even possible).

Time to do a bit more research and consider my options I think.