1. Trouble with the game?
    Try the troubleshooter!

    Dismiss Notice
  2. Issues with the game?
    Check the Known Issues list before reporting!

    Dismiss Notice
  3. Before reporting issues or bugs, please check the up-to-date Bug Reporting Thread for the current version.
    0.36 Bug Reporting thread
    Solutions and more information may already be available.

Physics consistency....far from being consistent

Discussion in 'Troubleshooting: Bugs, Questions and Support' started by driverx, Feb 27, 2016.

  1. driverx

    driverx
    Expand Collapse

    Joined:
    Oct 10, 2013
    Messages:
    8
    Hi BeamNG team,

    First of all, I really want to thank you for creating such a wonderful product. I have it for years and it is a pleasure to see how this is evolving.

    Really, I really love this game. However, in the about us section there is a statement about striving to be "accurate". I'm testing some scenarios and unfortunately BeamNG is very far from being consistent. I'm doing some simple crashes and each time the end result is VERY different. I don't expect that repeatability is 100%, but the my tests shows that the end results of the same crash with same pre-condition ends up with very different behavior of the cars involved in the crash.

    Please let me provide some details about my tests:
    - Intel i7 4710 HQ running constantly at 3.49 GHz. 4 cores, 8 threads
    - Nvidia 840M
    - A simple map with 3 cars on it
    - Test is about having a van crashing into a truck
    - For making sure things are repeatable under the same conditions, the truck has parking space on and the van always with throttle on. Basically the tests are not relying at all on user input apart from doing a reset on the two cars when the tests starts again.
    - CPU affinity set to 3 cores. This creates some controllable conditions where the CPU utilization gets very steady, Also with this setting I'm making sure the CPU does not get very hot and to risk throttling and under clocking. CPU was monitored with "Intel Extreme Tuning Utility". Usually I found that several tests are more consistent having BeamNG running in a single core. Strange, but especially on Grid Map BeamNG behaves much more consistent on single core rather than on all cores.
    - Graphics details set to lowest so that graphics do not introduce more details.
    - CPU utilization quite constant at 26-27%

    Here is a recorded video with several tests and just see the end results for each of the tests:



    I also did some similar tests on an Amazon Web Services g2.2xlarge server which I expect that it should be much more reliable than my laptop and again I got pretty different results on each run.

    Can you please help me to make BeamNG behave consistently in such simple situations?

    Thank you,
    Attila
     
  2. BlueScreen

    BlueScreen
    Expand Collapse

    Joined:
    Apr 5, 2014
    Messages:
    624
    If you're the same guy that posted this in some other thread, I already said this. I'm not a dev, but 99% sure it's the reason.

    Floating point errors. BeamNG uses floating point math and does 2000 calculations per second. FP error is usually very small, but with so many calculations it stacks up and might produce very different results in only a few seconds.

    There might be other factors - Input variation on controllers, for example. The way physics work can also cause a very small difference - such as what might be caused by floating point math error - to make a much bigger difference in an event such as an impact.

    It would be interesting to have a dev's answer to this, but I'm 99% sure it's due to floating point error.
     
    • Like Like x 1
  3. Dudeman

    Dudeman
    Expand Collapse

    Joined:
    Jan 27, 2016
    Messages:
    424
    I think doing the tests in slow motion would more consistent results
     
  4. randomshortguy

    randomshortguy
    Expand Collapse

    Joined:
    Aug 9, 2013
    Messages:
    1,562
    The devs actually answered this question > http://www.beamng.com/threads/instant-replay-w-video-editor.17281/page-2

    TL;DR: the physics engine itself is built to be consistent (deterministic), but the graphics engine isn't: and since the physics engine is tied to the graphics engine, it becomes imperfect.

    However, as far as I know accuracy =/= consistency.
     
    • Like Like x 1
  5. driverx

    driverx
    Expand Collapse

    Joined:
    Oct 10, 2013
    Messages:
    8
    I'm the same guy. I also think the same but I wanted a more official answer since the devs I'm pretty sure have a clear view on this. :) It is pretty frustrating because on 10 runs, 2-3 are exactly the same while the others are all over the place :)

    Did that. Got different results every time. Even on 16x.

    Thanks. I'll review that thread.

    My understanding was the the physics engine is independent running at 2000 FPS (Saw this in some thread, also in the LUA). However, during the tests I made I saw that this is not actually true. I also discovered that limiting the frame rate at 5FPS for example the time in the physics engine behaves differently which I think should not happen. If physics engine runs independently and CPU can handle some many computations, displaying only 5 FPS should not be a problem.

    Indeed accuracy =/= consistency., but if something is not accurate in the computations, probably will not be consistent as well.
     
  6. estama

    estama
    Expand Collapse
    Developer
    BeamNG Team

    Joined:
    Aug 7, 2012
    Messages:
    268
    The physics are deterministic. So for the same input they'll produce the same output [1]. The problem is that gfx frame timing is also a part of the input, and it is nearly impossible to have a fixed gfx frame timing under normal conditions.

    Apart from that, even with a fixed gfx frame timing (hard fixing it in the code), there will be some communication delays between the gfx threads and the physics threads. So in our internal tests, even with a fixed gfx step, the delays when the gfx threads initialized/reset the physics threads, could affect the final outcome. So small changes producing widely different end results is essentially the "butterfly effect" happening in the simulated world.

    The reason that we are investing work towards visual mesh compression/saving is due to above reasons. Our initial plan was to do replays by making all the engine interactions/timings deterministic. That has proven to be very hard, so our current plan is to save the visual mesh (compressed) state, essentially creating something akin to a 3d movie.

    [1] Floating point errors do not affect determinism because if the same calculations happen in exactly the same way then the errors will be exactly the same too.
     
    • Like Like x 8
  7. SixSixSevenSeven

    SixSixSevenSeven
    Expand Collapse

    Joined:
    Sep 13, 2013
    Messages:
    6,958
    Side note. The windows thread pool isnt necessarily deterministic. Heck thats what the realtime priority setting is for when changing a process priority.
     
  8. driverx

    driverx
    Expand Collapse

    Joined:
    Oct 10, 2013
    Messages:
    8
    Thanks for the details. Is there anything I can do to increase the consistency? I don't care about how unplayable becomes or if it is damn slow. :)
     
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice