-
Notifications
You must be signed in to change notification settings - Fork 240
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Different simulation results (speeds) across Linux & Windows. #181
Comments
I doubt that 12% is result of floating point. I remember you previously reported an issue which was related to different game loop frame rates in different environments, have you checked if that's also the issue in this case? |
The mentioned issue was regarding an irregular refresh rate (300.180hz) that only caused problems on the testbed. This is an issue that occurs in production (on the server) and as such there is no refresh rate that can be the issue, the server is manually configured to run at 60hz although I have also done tests at 50hz and 30hz. I've run this simulation using other implementations (external to Javascript) without any difference in timing. The server has been debugging on both Windows & Linux to ensure that they are running at the proper hz/intervals. I will be writing a test using a different implementation of Box2D after the weekend and logging the results as well, although I have never seen any differences. |
@ChristianTucker did you ever get a solution on this? And if not, did you find another suitable JS physics engine? |
I'm currently trying to resolve known issues before releasing v1. I wonder if you could provide any code example to reproduce this issue? |
-- Background --
I've used Box2D for a long time now, without even realizing I was using it. Various Game Engines and SDKs utilize Box2D under the hood and as such I know that Box2D is deterministic in nature, but suffers from the same floating-point precision errors as any other floating-point physics library. However, these errors are very insignificant when used in combination with things such as reconciliation with tolerations slightly above an Epsilon.
I developed a project for a client using Planck over the last few weeks as they wanted a JavaScript based server & client that could easily implement things such as prediction & reconciliation. These are fairly trivial and simple tasks.
-- Environmental Information --
However, while everything was working fine for us inside of our windows environments, once we moved the server to Ubuntu 20.04 we noticed from fairly serious issues in how things are simulated. (Ubuntu client & server) I've used Node 12.22.1, Node 14.16.1, and Node 16.0.0 to test this issue.
-- Issue Information --
When two objects are given an exactly similar Linear Velocity and Spawn Location they take completely different amount of time to traverse the same amount of space. Tests indicate that the difference in object speed is roughly 12%. These tests run on the same codebase in both environments and can be replicated as simply as creating an Object/Fixture. Setting normal gravitational forces (x0, y9.82), and creating a Dynamic Rigidbody w/ a Box Fixture and setting the Linear velocity directly to any number. For our tests we used
x:-1, y:-0.5
. We then timed the amount of time it took for each object to move across the screen. Each object moved consistently inside of its own operating system, but inconsistently (by a rather large margin) between multiple systems.The text was updated successfully, but these errors were encountered: