Announcement

Collapse
No announcement yet.

64-bit Physics?

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

    #16
    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.
    Last edited by Ori Cohen; 03-25-2014, 02:49 PM.

    Comment


      #17
      Originally posted by Ori Cohen View Post
      ddvlost, 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.
      Thanks for the reply Ori. Do you know what kind of timeline they might be working on there?

      Comment


        #18
        I don't have a timeline right now. I'd say it's safe to say it'll be a few months at least.

        Comment


          #19
          awesome thread. i am working on a titan based "open world" console and our launch title is using unreal engine 4 and i am interested in double precision as well. Scoot, I think you would also have to convert the coordinates system to double precision? [not just physics]. i would be interested in talking to you about your fork.

          Comment


            #20
            Even if PhysX does support double precision, as was mentioned earlier, it doesn't actually help unless all 'world positions' in the whole engine are converted to double precision as well. I'm afraid we don't have any plans to do this at the moment.
            Lead Programmer - UE4 Animation/Physics/Audio Team - Epic Games
            Twitter: @EpicJamesG

            Comment


              #21
              Originally posted by Scott Richmond View Post
              Unfortunately those hacks do not work when you add multiplayer to the mix. Are you saying the PhysX component already in UE4 is not 64bit capable?
              That's not true. It becomes more difficult, but it certainly still works. I believe lots of open-world titles do this exact thing, and don't have too much trouble with networking. It gets more complex, but at this point it's your best bet.

              Comment


                #22
                Originally posted by thavlik View Post
                That's not true. It becomes more difficult, but it certainly still works. I believe lots of open-world titles do this exact thing, and don't have too much trouble with networking. It gets more complex, but at this point it's your best bet.
                Can you provide some evidence or deeper explanation of this? Most games such as MMOs are in fact are 'hard-zoned' where players must pass through loading checkpoints to pass from one zone to another. Games like DayZ use double coordinates.

                Comment


                  #23
                  Originally posted by JamesG View Post
                  Even if PhysX does support double precision, as was mentioned earlier, it doesn't actually help unless all 'world positions' in the whole engine are converted to double precision as well. I'm afraid we don't have any plans to do this at the moment.
                  The biggest problem would be rendering. You could do it within the camera's reference frame (subtracting its 64 bit position from the physics body's 64 bit position). The only objects that would have precision problems would be ones too far away to even see. As for Z fighting and other Z buffering issues, you could have the camera use logarithmic Z instead, giving you a lot more precision in your Z Buffer.

                  Other than that, you'd probably have to convert all of the actor's transforms to either use doubles or calculate their world positions based on the current camera's viewpoint using the method described above. Not easy at all.

                  And then you could end up making something of this scale.

                  Comment


                    #24
                    Originally posted by JamesG View Post
                    Even if PhysX does support double precision, as was mentioned earlier, it doesn't actually help unless all 'world positions' in the whole engine are converted to double precision as well. I'm afraid we don't have any plans to do this at the moment.
                    i just said that in my previous post (except i called 'world positions' "world coordinates"). wouldn't it be possible for someone to make a fork and use visual studio to assist in going through all of the code and manually as well in some places, to convert the world coordinates system to double precision? without that happening, if someone wanted to do a huge huge world, they wouldn't be able to have it be multiplayer. so double precision is necessary for certain users.

                    im sure it is not trivial to make the change, but it would be doable by outside parties not too hard, right? just tedious to convert the position system to double precision?

                    Comment


                      #25
                      Originally posted by neopangaia View Post
                      i just said that in my previous post (except i called 'world positions' "world coordinates"). wouldn't it be possible for someone to make a fork and use visual studio to assist in going through all of the code and manually as well in some places, to convert the world coordinates system to double precision? without that happening, if someone wanted to do a huge huge world, they wouldn't be able to have it be multiplayer. so double precision is necessary for certain users.

                      im sure it is not trivial to make the change, but it would be doable by outside parties not too hard, right? just tedious to convert the position system to double precision?
                      I think there are a few more elements to it:
                      1. You will need to rewrite all the math libraries and functions to support double calc. Not hard at all but probably fairly tedious.
                      2. From Epic's point of view they will effectively need to manage and maintain two different codebases across features, bugfixes, etc - Its not so easy to simply write some C++ macros to compile for float/double. I can understand why they might not want to officially support it right now. Though that said the simulation market can be fairly lucrative and I'm a little surprised they aren't actively targeting it. I suppose they want to focus for now.

                      Comment


                        #26
                        I have run into the big problem in other engines when using single floats. Objects start to jitter around and geometry curves get stepped, or legoed as we call it. Im interested in possible work arounds or double precision code.

                        Comment


                          #27
                          our lead coder alerted me yesterday that there is already double precision support for depth buffers in the engine..

                          Comment


                            #28
                            I'm very interested in this. I want to do a huge open world (multiplayer) driving simulator, as well as a huge open world (multiplayer) RPG, both with UE4 graphics. So I do need this. Though I don't know if I would be of much help...

                            So, if I replace the physics engine with Bullet, set for double precision, I also need to change all floats in UE4 to doubles? Is that all? Or I misunderstood?
                            Last edited by Takumi Fujiwara; 07-02-2014, 01:17 PM.

                            Comment


                              #29
                              The real way to do this is origin rebasing, as mentioned. It may seem like a hack, but unless you're interested in essentially rewriting the engine as mentioned so that everything uses double precision, it's useless to use double precision in PhysX. Precision issues would just creep up in the rendering anyway.

                              Origin rebasing can work just fine with multiplayer, though its more complex. Typically what you do is make it so that each grid cell is run by a zone server, and players are handed off between them (or maybe a collection of grid cells to one zone server). That way you don't have 10 areas loaded on the server because 10 players are each in a separate one.

                              That sounds like work, but it's still less than rewriting the engine to use double everywhere (which IMO would still have issues).

                              Regarding Infinity, I believe they too use origin rebasing, and don't use double precision for rendering either, so that scale is possible quite without an engine rewrite.
                              Storyteller - An immersive VR audiobook player

                              Dungeon Survival - WIP First person dungeon crawler with a focus on survival and environmental gameplay ala roguelikes

                              Comment


                                #30
                                One way to do it would be to express the positions of each actor relative to the given chunk.

                                Say one actor walks out of the chunk it is currently in, and into another chunk. You allow everything to behave as per normal UE4 behavior - but then at some point in the next frame you relocate the actor's position to expressed relative to the new chunk. This ensures there are no per-actor hickups over multiplayer.

                                It gets tricky. I think there might be no way to do this without modding the engine a good amount. You'd have to modify functions that do things such as find nearby actors to account for the different chunks, amongst other things. Then the physics would have to be modified to work with it as well.

                                Client-side using floats with origin rebasing is actually superior, because double support on video hardware is pretty dodgy. Those gpu registers are 128 bit for a reason (though newer hardware uses 256 bit registers, and efficiently support doubles.)

                                Comment

                                Working...
                                X