Skip to content
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

Open
ChristianTucker opened this issue Apr 23, 2021 · 4 comments
Open

Comments

@ChristianTucker
Copy link

-- 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.

@shakiba
Copy link
Collaborator

shakiba commented Apr 24, 2021

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?

@ChristianTucker
Copy link
Author

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.

@reececomo
Copy link

@ChristianTucker did you ever get a solution on this? And if not, did you find another suitable JS physics engine?

@shakiba
Copy link
Collaborator

shakiba commented Aug 26, 2023

I'm currently trying to resolve known issues before releasing v1. I wonder if you could provide any code example to reproduce this issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants