Terrain Jitter Bug...
by Quinton Delpeche · in Torque 3D Professional · 08/16/2014 (12:38 pm) · 5 replies
I have mentioned this bug before but I don't think it was looked at or people were not sure what I meant. This is the Bullet Physics issue with regards to a Player on the Terrain.
Previous Post: Linux Dedicated Server - PhysX
So what I did was create a new project with and without Bullet physics from the Development and Master branches of Torque 3D v3.5.1. I then did compiles of the Windows client and the dedicated Linux server of all 4 projects. I can confirm that this occurs in both the Master and Development branch but only in the Bullet enabled projects.
I tried with the "Empty Room", "Empty Terrain", and a newly created "Test Terrain", this issue occurs on all the maps. This however only occurs on a Linux dedicated server and a Windows client, a Windows dedicated server and a Windows client works properly.
Here is a video of the issue in question:
Has anyone experienced this?
Is there a fix that I am not aware of?
Does anyone know what is going on here?
Previous Post: Linux Dedicated Server - PhysX
So what I did was create a new project with and without Bullet physics from the Development and Master branches of Torque 3D v3.5.1. I then did compiles of the Windows client and the dedicated Linux server of all 4 projects. I can confirm that this occurs in both the Master and Development branch but only in the Bullet enabled projects.
I tried with the "Empty Room", "Empty Terrain", and a newly created "Test Terrain", this issue occurs on all the maps. This however only occurs on a Linux dedicated server and a Windows client, a Windows dedicated server and a Windows client works properly.
Here is a video of the issue in question:
Has anyone experienced this?
Is there a fix that I am not aware of?
Does anyone know what is going on here?
About the author
Gobbo Games is an Independent Games Development company operating from Durban in South Africa. We believe in creating high-quality cost-effective games that remain true to the belief of Independent Game Developers around the world.
#2
08/16/2014 (2:26 pm)
I do think there's some kind of issue with Bullet's heightmap collision or collision in general. I don't know if this would be related, though, since you said Windows works. Awhile ago I made a post about jump animation issues with Bullet and the ground plane. I've since encountered the same problem on both terrains and models. Haven't tried really looking into it yet, but in-case it helps... www.garagegames.com/community/forums/viewthread/135890.
#3
Running a Dedicated Windows Server and Windows Client on the same machine and different machines does not display this bug.
Machines are connected to each other via a local lan with no other connections being presented and these are standard builds with nothing custom added to them at all.
@Chad: yeah, it looks like these may be related.
08/16/2014 (9:58 pm)
@Lukas: It only happens on multiplayer connections. It happens on different computers because it is a Linux Dedicated Server and a Windows Client.Running a Dedicated Windows Server and Windows Client on the same machine and different machines does not display this bug.
Machines are connected to each other via a local lan with no other connections being presented and these are standard builds with nothing custom added to them at all.
@Chad: yeah, it looks like these may be related.
#4
Maybe in the Player::unpackUpdate you could try adding a check to see if the position is being corrected with more than 0.01 units and output the correction?
Maybe that will show something interesting.
08/17/2014 (9:31 am)
Oh sorry didn't catch that it only fails with a Linux dedicated.. So I'm thinking that it could be a problem with marshalling, thats the obvious one but I doubt thats the issue.Maybe in the Player::unpackUpdate you could try adding a check to see if the position is being corrected with more than 0.01 units and output the correction?
Maybe that will show something interesting.
#5
This results in writePacketData corrections every tick for all control objects that use physics reps to handle any aspect of their movement (Players do). That results in jitter since the client is constantly being corrected, but the amount of jitter will be hard to notice on low-latency connections (like local servers).
If anyone's dealing with something like this you might want to check if writePacketData corrections are going out constantly for your control objects. I never worked with the Bullet implementation, but it may have the same problem.
--
I had done all the core work for a PhysX-based Vehicle class before I noticed this issue. Unlike the stock physics shapes they were networking and interpolating correctly (could even stack them up in real-world multiplayer), but attempting to use them as a control object revealed the issue, at which point I realized that the Player class was having the same problem.
01/09/2015 (4:54 pm)
Old thread, may not be relevant, but I wanted to mention that at least the PhysX implementation does not work with the client-predictive networking. Because the physics scene sims forward as a unit it's not possible to have control objects wait for the arrival of move packets before simming (well, I'm sure you could come up with some tricks to make this work, but it doesn't out of the box).This results in writePacketData corrections every tick for all control objects that use physics reps to handle any aspect of their movement (Players do). That results in jitter since the client is constantly being corrected, but the amount of jitter will be hard to notice on low-latency connections (like local servers).
If anyone's dealing with something like this you might want to check if writePacketData corrections are going out constantly for your control objects. I never worked with the Bullet implementation, but it may have the same problem.
--
I had done all the core work for a PhysX-based Vehicle class before I noticed this issue. Unlike the stock physics shapes they were networking and interpolating correctly (could even stack them up in real-world multiplayer), but attempting to use them as a control object revealed the issue, at which point I realized that the Player class was having the same problem.
Torque Owner Lukas Joergensen
WinterLeaf Entertainment
Also does it also happen if the same computer runs both the client and the dedicated server?
Could be that the server thinks the terrain a little above the clients terrain and keep adjusting it but the client thinks it's below so he falls down.
Or simply that client terrain collision is disabled altogether.