Announcement

Collapse
No announcement yet.

Double-Precision Positionning support WIP : Continuing Effort thread

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

    Double-Precision Positionning support WIP : Continuing Effort thread

    Last edit: 9/27/2019

    The context:

    Currently using Origin Rebasing you can expand your worlds to the box of +-21 000 km in each direction.
    We don't have the tool to position assets at this scope.

    What I've developped since the opening of this thread is library of unreal engine vectors, transforms, rotations mostly converting FVector, FVector2D, FVector 3, FTransform, FQuat, but also some geometric assets like box, sphere (for intersection computation etc..) etc... to use and operate using double precision.

    In its current form, those modification are engine modifications, not a plugin i could easily share.


    To fully use World Origin Rebasing you first need to change the Unreal Engine 4 Variable WORLD_MAX to go beyond the base +-20km of playable area.
    Below i'm playing around at (21 000km,21 000km,0).


    ~~~~~Origin Post Below ~~~~


    UPDATE:
    • FDVector - Double Precision Vectors
    • FDVector4 - Double Precision Vector4
    • FDTransform - Double Precision position Transforms
    • Math operation - Cross compatibility whenever possible
    • ExtraMath: CosDouble(), SqrtDouble(),....
    • Couple FMatrix operations available
    • SceneComponentDouble
    • PrimitiveComponentDouble
    Extra explanation:

    SceneComponentDouble and PrimitiveComponentDouble are only available in C++, still figuring out a way to hook them into the Actor class in the best way possible.
    Last edited by MaximeDupart; 09-27-2019, 01:35 PM.
    LinkedIn | Link custom Shaders | Atmosphere Modelisation & Procedural Planets | Distance Matching Locomotion | Nvidia GameWorks builds - 4.19.2 : VXGI2.0, Blast, HairWorks, Flow - Plugins: VictoryBP

    #2
    It's worth noting that there's absolutely no point using double-precision vectors unless you're doing *all* of your movement code and game code in double-precision as well. Floating point can actually support huge numbers, but it's the constant multiplying/dividing large numbers by small numbers that creates error.

    I had the same issue in Satellite Command. Even with a world that's much smaller than reality, our movement component does a lot of floating point operations and led to a really unstable final result. The only solution was to completely rewrite the movement component to use double-precision, and then convert back to a standard FVector at the very last minute to tell unreal where in the world to place the object. That did the job fine!

    Comment


      #3
      Originally posted by TheJamsh View Post
      It's worth noting that there's absolutely no point using double-precision vectors unless you're doing *all* of your movement code and game code in double-precision as well. Floating point can actually support huge numbers, but it's the constant multiplying/dividing large numbers by small numbers that creates error.

      I had the same issue in Satellite Command. Even with a world that's much smaller than reality, our movement component does a lot of floating point operations and led to a really unstable final result. The only solution was to completely rewrite the movement component to use double-precision, and then convert back to a standard FVector at the very last minute to tell unreal where in the world to place the object. That did the job fine!
      Doing the movement code entirely in double is indeed the plan.
      Thank for your feedback !
      Last edited by MaximeDupart; 07-29-2018, 07:14 PM.
      LinkedIn | Link custom Shaders | Atmosphere Modelisation & Procedural Planets | Distance Matching Locomotion | Nvidia GameWorks builds - 4.19.2 : VXGI2.0, Blast, HairWorks, Flow - Plugins: VictoryBP

      Comment


        #4
        Originally posted by TheJamsh View Post
        It's worth noting that there's absolutely no point using double-precision vectors unless you're doing *all* of your movement code and game code in double-precision as well. Floating point can actually support huge numbers, but it's the constant multiplying/dividing large numbers by small numbers that creates error.

        I had the same issue in Satellite Command. Even with a world that's much smaller than reality, our movement component does a lot of floating point operations and led to a really unstable final result. The only solution was to completely rewrite the movement component to use double-precision, and then convert back to a standard FVector at the very last minute to tell unreal where in the world to place the object. That did the job fine!
        Have you done working double precision flosting point to Unreal Engine in Satellite Command ?

        Comment


          #5
          Originally posted by Masakralny View Post
          Have you done working double precision flosting point to Unreal Engine in Satellite Command ?
          All I did was write the movement code in double-precision (this meant creating a custom Vector and Quat type, and rewriting some of Epics FMath library to use double precision). With Kepler orbits you usually have very large numbers (mass of the earth) mixed with very small numbers (delta time), and that's where we lost precision - the solution was to just convert it all to doubles.

          All of this can be done without any mods to the engine, we shipped on the launcher version of 4.12 - but I created a custom maths library and you have to write the movement component entirely on your own and not use any existing code in the engine. This is only possible of course for certain types of movement.

          The movement component converts back to default precision only at the last moment, where it calls SetActorLocation() with a vector created from doubles. The key difference however is that all the maths operations are done in double-precision, that's how you avoid the error.
          Last edited by TheJamsh; 08-07-2018, 01:31 PM.

          Comment


            #6
            Updated original post with an update:

            I've added 3 main new class for Double precision Vectors, Transforms with double precision positionning, and a new SceneComponent using double precision position.
            LinkedIn | Link custom Shaders | Atmosphere Modelisation & Procedural Planets | Distance Matching Locomotion | Nvidia GameWorks builds - 4.19.2 : VXGI2.0, Blast, HairWorks, Flow - Plugins: VictoryBP

            Comment


              #7
              Bear in mind that PhysX uses float-precision. Any collision handling you try to do for your movement component will result in loss of precision.

              Nothing you can do about that, other than to find a double-precision physics library or write your own (and integrate it into unreal). This is a lot easier said than done, it might not be evident yet, but you are fighting an uphill battle!

              Comment


                #8
                Noted. I'm just a space and physic fanatic, i want things at the proper scale with their proper physic unit.

                Was working on the atmosphere scaterring earlier and using doubles was actually fairly useful to solve the rendering equation keeping relevant particle density or light wavelength to modelize the interfering medium.

                My goal is to be able to push the origin rebasing beyond its current limitation, and i wonder if PhysX will benefit from it or not. If i really want the full physic collision i'll most likely swap the physic engine anyway, but that's out of the scope for now.

                Spent the last couple days working on double precision support for editor viewport, think i'm gonna need a break after that!
                LinkedIn | Link custom Shaders | Atmosphere Modelisation & Procedural Planets | Distance Matching Locomotion | Nvidia GameWorks builds - 4.19.2 : VXGI2.0, Blast, HairWorks, Flow - Plugins: VictoryBP

                Comment


                  #9
                  New update on main post, a lot has been done towards deeper integration of FDVector/FDVector4/FDTransform whenever possible for positionning only, keeping as much as possible of the original code and original class/structure. Normals for instance would have been a waste of space to store in doubles.

                  Edit: added a lot more explanation if anyone is interested in the topic
                  Last edited by MaximeDupart; 08-13-2018, 10:35 PM.
                  LinkedIn | Link custom Shaders | Atmosphere Modelisation & Procedural Planets | Distance Matching Locomotion | Nvidia GameWorks builds - 4.19.2 : VXGI2.0, Blast, HairWorks, Flow - Plugins: VictoryBP

                  Comment


                    #10
                    MaximumDup, I'm sorry if I missed the obvious but is this something you will be releasing to the public or what exactly? Many of us have been waiting a very long time to have double point precision in our projects.

                    Comment


                      #11
                      It's a lot of experimentation at this point. I've a custom 4.20 with a lot of double precision experiments but it's mixed with custom code for my game. Doubt i'll released it as it is.

                      I should be able to extract some useful bits like double precision vector math, but this plugin does it without any engine modification (note that i haven't tested it) :
                      https://forums.unrealengine.com/unre...sion-utilities
                      LinkedIn | Link custom Shaders | Atmosphere Modelisation & Procedural Planets | Distance Matching Locomotion | Nvidia GameWorks builds - 4.19.2 : VXGI2.0, Blast, HairWorks, Flow - Plugins: VictoryBP

                      Comment


                        #12
                        Originally posted by MaximeDupart View Post
                        Noted. I'm just a space and physic fanatic, i want things at the proper scale with their proper physic unit.

                        Was working on the atmosphere scaterring earlier and using doubles was actually fairly useful to solve the rendering equation keeping relevant particle density or light wavelength to modelize the interfering medium.

                        My goal is to be able to push the origin rebasing beyond its current limitation, and i wonder if PhysX will benefit from it or not. If i really want the full physic collision i'll most likely swap the physic engine anyway, but that's out of the scope for now.

                        Spent the last couple days working on double precision support for editor viewport, think i'm gonna need a break after that!
                        Hi there.

                        i have the same problem, being a persistent physic fan. You can develop things without it, but double precision would be a great next step in game development. And the reason is very easy. Precision reduces dramatically after already 1km away from the origin. If you want correct calculations in an open world with a wide field of vision, you have to do workarounds with distant objects.

                        Are there any plans to implement double precision within the life time of ue4? Or do we have to wait for ue5?

                        Thanks and cheers

                        Comment


                          #13
                          To be honest, you can already achieve really large scale if you're computing on double precision your world element position and moving a virtual world origin around.

                          Largest i achieved was this 1185km radius planet:





                          Beside Space Sims i doubt there's any need for double precision, but it would open up a nice range of opportunities !
                          LinkedIn | Link custom Shaders | Atmosphere Modelisation & Procedural Planets | Distance Matching Locomotion | Nvidia GameWorks builds - 4.19.2 : VXGI2.0, Blast, HairWorks, Flow - Plugins: VictoryBP

                          Comment


                            #14
                            How's the work going to bring double precision to UE4? Been trying to find ways to do it (completely new to UE and C++), but haven't had much luck myself beyond realising that it'd likely require a rebuild of the maths functions to use double precision, and not sure that'd let me use double precision in the blueprint editor.

                            Comment


                              #15
                              I would love to know as well.

                              Comment

                              Working...
                              X