Announcement

Collapse
No announcement yet.

Physics simulation fixed time step and enhanced determinism settings, pull request

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

    Physics simulation fixed time step and enhanced determinism settings, pull request

    I've implemented, the possibility to activate fixed delta time of Physics simulation directly in the project editor.

    The code written is an extension of Snowcrash5 work https://forums.unrealengine.com/show...ysics-approach

    I've also implemented the possibility to activate the enhanced determinism using the project settings.

    Pull Request: https://github.com/EpicGames/UnrealEngine/pull/3633

    Click image for larger version

Name:	Untitled.png
Views:	1
Size:	124.5 KB
ID:	1221100
    Last edited by B1TZ3R0; 05-30-2017, 11:32 AM.

    #2
    Originally posted by B1TZ3R0 View Post
    I've implemented, the possibility to activate fixed delta time of Physics simulation directly in the project editor.

    As shown in the picture above:
    [ATTACH=CONFIG]142965[/ATTACH]

    The Pull Request to this feature is: https://github.com/EpicGames/UnrealE...ull/3632/files

    The code written is an extension of Snowcrash5 work https://forums.unrealengine.com/show...ysics-approach

    I've also implemented the possibility to activate the enhanced determinism directly using the project settings.

    Pull Request: https://github.com/EpicGames/UnrealEngine/pull/3633
    I reviewed the code and it did have issues. I've solved those mentioned things in past on my UE4 fork (https://github.com/0lento/UnrealEngi...imestep/Engine). The reason I never made a PR for it was that I wasn't happy with some of the approaches there (they worked good enough for the test project but wouldn't have been clean enough code for epics codebase IMO). Just implementing interpolation itself is a huge task. I know your PR didn't do it but I feel like feat like this should implement it as it's crucial part of the feature.
    https://github.com/0lento/UnrealEngine (GameWorks tech merges & upgrades, UE4 physics modifications)

    Comment


      #3
      As I've written in a GitHub comment, Thanks to your opinion I will improve the code with a file safe.

      However even if the implementation is not the best, I think it's always a good starting point. If we don't insert as feature on the release code this feature will be never supported or improved.

      Comment


        #4
        I feel quite the contrary because for epic to approve the PR, it has to be good. Ori described how to make the change years ago, he could have made a quick implementation back then if it would have been up to Epics standards but it was never done (I'd guess mainly because proper implementation takes more time, I know my fork took more than week of work to get even in the state it's currently in).

        There's an issue if you put an implementation in the engine and want to change it afterwards as Epic wants to keep backwards compatibility -> initial implementation can't get in the way.
        https://github.com/0lento/UnrealEngine (GameWorks tech merges & upgrades, UE4 physics modifications)

        Comment


          #5
          I've implemented the fail safe check, I committed the change.

          However I don't think my approach is so dirty that can't be accepted. I've added a comment on GitHub that explain (in short) how it works.

          I left the original substepping algorithm working, I've written new class to handle the fixed delta time.

          Let me know what's wrong.

          Comment


            #6
            Originally posted by B1TZ3R0 View Post
            I've implemented the fail safe check, I committed the change.

            However I don't think my approach is so dirty that can't be accepted. I've added a comment on GitHub that explain (in short) how it works.

            I left the original substepping algorithm working, I've written new class to handle the fixed delta time.

            Let me know what's wrong.
            It's way more readable now but you still have issue with SubTime math. You introduce a possibility where you divide by zero when there are no substeps:
            Code:
            SubTime = DeltaSeconds / NumSubsteps;
            and you also do unnecessary math as you already know that Subtime is FrameRate in all situations but when you have zero substeps, this is how I solved that on my fork:
            Code:
            SubTime = NumSubsteps ? FrameRate : 0.f;
            https://github.com/0lento/UnrealEngine (GameWorks tech merges & upgrades, UE4 physics modifications)

            Comment


              #7
              I've fixed it, Thanks you

              Comment


                #8
                Hi,
                Does this fix deterministic physics problem in multiplayer too? Specifically joints and rigid bodies.

                Thanks.

                Comment


                  #9
                  It helps on determinism for sure but there are still some issues related to that which are hard to solve. In my testing, if you truly fix the timestep for physx on UE4, you get deterministic sim at least on same computer (would assume it would be same on all computers that run the same CPU architecture at least). But.. that only applies when you start the whole sim at the same point.

                  In multiplayer this isn't true and even resetting the rigidbody to exact same location during the sim (even if you did it directly from physx) will somehow throw the determinism off on collisions. It's enough that the values are off by the last digit (single precision floats used by ue4/physx are accurate to ~7.25 digits) and then the objects can bounce in completely different way. I never found the core reason why physx can't set the exact same values (it you run set and get few times, they start to drift). Also since it's multiplayer you are talking about, you'd usually want to quantize the transforms you send, which will be way worse than just losing the last digit. I'm not sure if you can even get the multiplayer collisions fully deterministic with physx unless you sacrifice some of the simulation fidelity or use lots of bandwidth.

                  And since we are talking about determinism.. about that enhanced determinism flag. It doesn't make things more precise, it only guarantees the physics engine's internal solving order to remain the same between the rigidbodies if you add more rigidbodies to the sim while the sim is running. If you start the sim the same way on each computer, that setting probably does nothing (other than consume more CPU).
                  https://github.com/0lento/UnrealEngine (GameWorks tech merges & upgrades, UE4 physics modifications)

                  Comment


                    #10
                    There's also another thing that throws the determinism off and it's in the substepping code itself. The line that will throw the determinism off is here:
                    https://github.com/AndreaCatania/Unr...Tasks.cpp#L389

                    and this is how I solved it:
                    https://github.com/0lento/UnrealEngi...Tasks.cpp#L423

                    The issue is that while the math is right, since it's floats we are talking about that value will have precision issues if you run the project at low framerates where you get a lot of substeps. Since fixed timesteps don't need that math anyway, you can just assign the same subtime for the last substep anyway.
                    https://github.com/0lento/UnrealEngine (GameWorks tech merges & upgrades, UE4 physics modifications)

                    Comment


                      #11
                      Also worth mentioning, I strongly feel that enhanced determinism flag should go under advanced settings, it does more bad than good and shouldn't be shown in the main list like that.
                      https://github.com/0lento/UnrealEngine (GameWorks tech merges & upgrades, UE4 physics modifications)

                      Comment


                        #12
                        Originally posted by 0lento View Post
                        There's also another thing that throws the determinism off and it's in the substepping code itself. The line that will throw the determinism off is here:
                        https://github.com/AndreaCatania/Unr...Tasks.cpp#L389

                        and this is how I solved it:
                        https://github.com/0lento/UnrealEngi...Tasks.cpp#L423

                        The issue is that while the math is right, since it's floats we are talking about that value will have precision issues if you run the project at low framerates where you get a lot of substeps. Since fixed timesteps don't need that math anyway, you can just assign the same subtime for the last substep anyway.
                        Very nice hint, I've added it: https://github.com/AndreaCatania/Unr...Tasks.cpp#L389

                        I also moved enhanced determinism setting into advanced section.

                        Do you have another advices about determinism PhysX?

                        Comment


                          #13
                          Originally posted by B1TZ3R0 View Post
                          Do you have another advices about determinism PhysX?
                          There nothing else I found on UE4 side that hurted the determinism on my test project besides the mentioned things. I compiled and debugged physx code a bit to find out where it messed up with the transforms when you set them but there were just too many places it could have happened (physx does many math operations for the tranform before it gets stored anywhere internally) and there could also be some other internal physx cache scenario that caused things to get altered too. I'm now talking about not being able to reset the transform to exact same value it was between physics steps without it starting to drift slightly. This is probably not huge issue but more like something to keep in mind if you wonder when results are not 1:1.

                          All in all, just running physx at fixed timesteps guarantees that simulation itself runs the physics equations the same way so you'll not get physics objects that move faster on other clients (like could happen on variable timesteps).
                          https://github.com/0lento/UnrealEngine (GameWorks tech merges & upgrades, UE4 physics modifications)

                          Comment


                            #14
                            Those are very good advises, thanks a lot Olento.

                            To be honest, I am quite disappointed that UE4 out of the box (actually Physx 3.x) is not really deterministic but I am also aware that what may seem trivial on the surface can actually be very complicated.

                            Btw I searched around and go this:-
                            yeah!re-initialize the SDK and scene before simulate ,i got same result.
                            from here:
                            https://devtalk.nvidia.com/default/t...-results-why-/

                            I have got custom UE4 compiled in my computer and wonder if I provide a BP node called 'Reset physx', will it work? It will do what it says above - reinitialize physx SDK and also scene.

                            Edit: The other approach I may take is to modify Physx code where all the physcs calculations are done - convert all of them from float to double, and then have them stored back as float. This way, the calculation is more precise and the precision issues will be solved once for all. I know this sounds like a bit too optimistic. lol, but I think it definitely result in better deterministic..
                            Last edited by Syed; 05-31-2017, 11:31 PM.

                            Comment


                              #15
                              The problem is that there's no such thing as "better" determinism. If it's not 100% deterministic the simulation will break down eventually. There's also the whole problem of floating point determinism.

                              I think your PR will have a much greater chance of being accepted if you split it into two focused branches: one focusing on fixed step physics with interpolation (which solves the problem of variable physics on variable framerate and is a problem that can be solved in reasonable time) and keep other one for determinism experiments.

                              Comment

                              Working...
                              X