Announcement

Collapse
No announcement yet.

What happened to the "large world coordinate system" feature, the highest voted in the roadmap?

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

    #16
    I think one problem is that the thing where you notice the precision issues most (physics) is done by PhysX, and Nvidia does not have a double precision version of PhysX as far as I know. So even if UE4 would support double precision for everything it does, that would only affect rendering stuff, but nothing that's related to physics (traces, collision, overlaps etc) since that will still run with single precision unfortunately.

    https://forums.unrealengine.com/show...64-bit-Physics
    Easy to use UMG Mini Map on the UE4 Marketplace.
    Forum thread: https://forums.unrealengine.com/show...-Plug-and-Play

    Comment


      #17
      It's worth noting, in that thread:

      Scott, I just talked to NVIDIA about this and it sounds like there are plans for supporting higher precision in future PhysX release. I'll keep you posted if more details arise.
      That was three years ago now, and with how ambitious games are getting in terms of scale it's only a matter of time. I would be very surprised if PhysX didn't either already support it in the current version, or wouldn't add it in the next year. Since there were already plans for it back in 2014, I'm actually pretty curious if anyone would be able to find out if it turned into anything.

      Comment


        #18
        I honestly don't think that adding double precision is solving problem. It just moves it further in space. But it's still not enough precision to simulate ie, solar system. I know that's pretty "WTF entire solar system !?", but still.
        Of course it would still help to have high precision margin before things will start to fall apart.
        But we still need proper solution on top of it, like hierarchical coordinates or spatially tiled world.
        Tiled world still will be limited to the top coordinate system (like int64), but it will be much, much bigger than what doubles will give you.
        https://github.com/iniside/ActionRPGGame - Action RPG Starter kit. Work in Progress. You can use it in whatever way you wish.

        Comment


          #19
          Large world Coordinate system is back but is on the 2017 backlog.

          https://trello.com/c/M4LgGSUW/118-la...rdinate-system

          Comment


            #20
            Doesn't double precision mean that every calculation gets slower due to the transport of 64bit instead of 32? Not to mention that double is not supported on many GPUs yet. It would mean the calculations would run on the CPU.

            Comment


              #21
              Originally posted by Raildex_ View Post
              Doesn't double precision mean that every calculation gets slower due to the transport of 64bit instead of 32? Not to mention that double is not supported on many GPUs yet. It would mean the calculations would run on the CPU.
              For CPUs difference is marginal. for GPUs it is literally 2 times slower.
              For rendering performance, you would still need to convert doubles to floats.
              https://github.com/iniside/ActionRPGGame - Action RPG Starter kit. Work in Progress. You can use it in whatever way you wish.

              Comment


                #22
                Yeah, for rendering you can always shift the origin for the player around locally so that the player is in the center of a 10km radius where single precision is enough. Only on the server where multiple players are connected in different regions of the world you definitely need double precision.
                Easy to use UMG Mini Map on the UE4 Marketplace.
                Forum thread: https://forums.unrealengine.com/show...-Plug-and-Play

                Comment


                  #23
                  You can use double-precision in your engine and do origin shifting before converting to float for the GPU. I did it back in the XNA days and it worked beautifully. The precision errors get pushed away from the camera in proportion to their imprecision. What you can't prevent is the extra data which must be sent to the clients. I should note that by "origin shifting" I mean using the camera's position as the origin.
                  Last edited by Jin_VE; 04-13-2017, 03:32 PM.

                  Comment


                    #24
                    Originally posted by TheJamsh View Post
                    I recieved a PM asking how we did our stuff in double-precision. It's very easy so I'll repost here.

                    Essentially the first thing I did (because we knew we'd need it), was create a new math library (FMathD) and a new Vector class (DVector, but should have been FVectorD or something) - which is essentially a carbon-copy of the FMath and FVector classes from the engine, but replaces all the non-templated functions with doubles instead of floats. Most of the std math functions that are called under the hood natively handle doubles and floats so this was very easy. The thing to remember is to REMOVE all of the
                    Code:
                    .f
                    's from the end of your numbers and replace with
                    Code:
                    .0
                    instead, to ensure the compiler knows to use doubles.
                    First of all apologize for quoting an almost 1 year old post.. but I cannot help to ask this: Does this mean all the positions + rotations need to be calculated manually (using DVector) ? How about the objects which have submeshes or animations (that get calculated automatically deep inside the engine using float)?

                    Comment


                      #25
                      Originally posted by Syed View Post
                      First of all apologize for quoting an almost 1 year old post.. but I cannot help to ask this: Does this mean all the positions + rotations need to be calculated manually (using DVector) ? How about the objects which have submeshes or animations (that get calculated automatically deep inside the engine using float)?
                      You have to do those calculation within camera space.
                      You have position in doubles, in simplest case you just
                      ObjectPosition - CameraPositon = LocalPosition and you pass this as float to rendering engine.
                      In Unreal you cloud probabaly use Origin Rebasing to do all visual calculations and use doubles to calculate positions within world space, but then still you need to transform world space in doubles into local space floats.
                      Haven't done it, so IDK about implementation details, but that's high level overview, how to do it.
                      https://github.com/iniside/ActionRPGGame - Action RPG Starter kit. Work in Progress. You can use it in whatever way you wish.

                      Comment


                        #26
                        Originally posted by Syed View Post
                        First of all apologize for quoting an almost 1 year old post.. but I cannot help to ask this: Does this mean all the positions + rotations need to be calculated manually (using DVector) ? How about the objects which have submeshes or animations (that get calculated automatically deep inside the engine using float)?
                        Essentially you calculate all of your movement manually, then you call "Set World Location and Rotation" or whatever function you need from the engine, and you just convert back to a Vector. For example.

                        Code:
                        FVector UnrealLocation = GetActorLocation();
                        DVector MyDoubleVector = DVector(UnrealLocation);
                        
                        // Calculate All Movement using Doubles ONLY. Cast any floats like 'DeltaTime' to doubles. 'MovementSpeed. is a double, for example.
                        DVector NewVelocity = DVector::ForwardVector * MovementSpeed * (double)DeltaTime;
                        MyDoubleVector += NewVelocity;
                        
                        // Convert back to FVector
                        FVector NewUnrealLocation = FVector(MyDoubleVector.X, MyDoubleVector.Y, MyDoubleVector.Z);
                        SetWorldLocation(NewUnrealLocation);
                        This gave us the precision we needed. Some caveats however, are that you need to calculate collision rejection yourself (not a problem for us, we don't have any collision) - and PhysX etc. won't work this way either (not a problem for us, we don't have any). They key take away is that all math operations need to be performed as doubles at all stages - or you will lose precision. Lot's of multiplication and division in our case eventually degraded the accuracy of floats enough to cause jitter. Doing all the math in doubles and converting back fixed that for us.

                        This approach worked for us because it's a unique use-case, it won't work for everyone.

                        The best way to achieve large-world precision in a typical game would be to set the camera at world origin, and rotate the contents of the world around it. This is what Kerbal Space Program does btw, and it disguises the problem enough for them to get away with it.
                        Last edited by TheJamsh; 04-17-2017, 07:56 AM.

                        Comment


                          #27
                          Originally posted by TheJamsh View Post
                          The best way to achieve large-world precision in a typical game would be to set the camera at world origin, and rotate the contents of the world around it. This is what Kerbal Space Program does btw, and it disguises the problem enough for them to get away with it.
                          That's how I did it when XNA was a thing. You use doubles in your engine, translate to camera-as-origin, and then cast down to floats for the GPU. The problem is disguised because the precision errors grow with distance, but so does visual significance. IMO you don't just get away with it, it works flawlessly.

                          Edit Oh, I already said this in a post above. Apologies.

                          Comment


                            #28
                            Originally posted by JamesG View Post
                            That card did not refer to 'origin rebasing' (which is already supporting) but actually changing the engine to use double precision for world positions. After doing some investigation, this just doesn't seem like the right thing for us to work on at the moment. It would be a HUGE amount of work (basically every FVector and FTransform could potentially change), and would probably make upgrading rather painful for users.
                            What have you actually done that we voted on?

                            Comment


                              #29
                              Seems Unigine support large world system(Unbounded Worlds)

                              Really need this.

                              Comment


                                #30
                                Curious if there are any updates from Epic regarding this, it is still a highly requested issue.

                                Both Unigine and Star Citizen are able to support 64 bit positions and physics, in fact one team swapped from UE4 to Unigine for this reason: https://devblog.dualthegame.com/2016...-to-unigine-2/.

                                Can we reconsider such an addition in principle? what are the bare minimum modules that would need to be updated to support 64 bit positions? Even just highlighting the systems that would likely need changing could open the door for smart pull requests. If done right with code architecture, this feature could be toggle-able for other platforms that may not benefit from it (that said even mobile phones are 64bit natives these days).

                                Regarding 64bit physics, Has NVidia provided an update on 64-bit calculations in physx for CPU?

                                It would also certainly enhance the case for using UE4 in simulation environments.
                                Last edited by getnamo; 10-21-2017, 03:08 PM.
                                Plugins: GES - Node.js - TensorFlow - Socket.io Client - ZipUtility - Leap Motion - Hydra - Myo

                                Comment

                                Working...
                                X