Search Unity

  1. Improved Prefab workflow (includes Nested Prefabs!), 2D isometric Tilemap and more! Get the 2018.3 Beta now.
    Dismiss Notice
  2. The Unity Pro & Visual Studio Professional Bundle gives you the tools you need to develop faster & collaborate more efficiently. Learn more.
    Dismiss Notice
  3. Improve your Unity skills with a certified instructor in a private, interactive classroom. Watch the overview now.
    Dismiss Notice
  4. Want to see the most recent patch releases? Take a peek at the patch release page.
    Dismiss Notice

Floating Point Errors and Large Scale Worlds

Discussion in 'World Building' started by Phelan-Simpson, Apr 15, 2018.

  1. Phelan-Simpson

    Phelan-Simpson

    Joined:
    Jan 1, 2014
    Posts:
    27
    Hello,

    I am currently working with a team on a project involving a large scale world.

    I currently believe Unity supports anything up to 99,999.99 meters away from the origin point (1 Meter = 1 Unity unit). This size gives precision up to 1cm, if I am thinking of this correctly. Up to 9999.999 meters away from origin gives you 1 millimeter precision. I am looking for conformation that this is in fact how it works, and to be informed if I am missing something in the calculations.

    Thank you in advance,
     
  2. Peter77

    Peter77

    Joined:
    Jun 12, 2013
    Posts:
    2,519
    I remember the following post, where an animated model has been placed at different positions and starts to jitter/whobble quite noticeable around 5000 units away from the world origin.
    https://forum.unity.com/threads/making-an-open-world-map-could-use-some-input.484643/#post-3164102

    The forum contains tons of large world related posts and floating point accuracy as well as origin shifting comes up every time and then as well.

    I believe, the ultimate conclusion is:
    As of April 2018, there are other game engines that would be a better match for creating large worlds.
     
    wcoastsands likes this.
  3. Thrawn75

    Thrawn75

    Joined:
    Nov 16, 2014
    Posts:
    1,878
    Agreed. Basically operating just beyond 5km mark will produce issues, depending on what you do. Knowing this limitation you put in place some world shifting when the action moves beyond certain threshold.

    I wonder if Unity has plans for 64 bit engine.
     
  4. dadude123

    dadude123

    Joined:
    Feb 26, 2014
    Posts:
    661
    That does not mean what you think it means.

    64bit precision transforms is what you mean.

    The engine itself already supports 64bit architectures and did so for a long time.
     
  5. Thrawn75

    Thrawn75

    Joined:
    Nov 16, 2014
    Posts:
    1,878
    Sure, that’s what I meant.
     
  6. Thrawn75

    Thrawn75

    Joined:
    Nov 16, 2014
    Posts:
    1,878
    There’s a video of Starship Citizen that illustrate what you can get with 64bit math. I’ll post it here if I find it.
     
  7. Thrawn75

    Thrawn75

    Joined:
    Nov 16, 2014
    Posts:
    1,878

     
    Last edited: Apr 15, 2018
    Rodolfo-Rubens and rakkarage like this.
  8. buFFalo94

    buFFalo94

    Joined:
    Sep 14, 2015
    Posts:
    155
  9. Thrawn75

    Thrawn75

    Joined:
    Nov 16, 2014
    Posts:
    1,878
    Yeah, it depends on the operation as well. For instance make a sphere of scale 5000 and move the camera near the surface and do a raycast on the mouse position. The hitPosition won’t be very accurate or if you do a Transform.TransformPoint it will just suffer or augment the precision issue.

    The 32 bit limitation makes you look for creative options which can work but well, make the system more complex to develop, maintain and prone to side effects in a large scale environment

    I wonder what prevents Unity to add support for 64 bit fields in Mesh, Transform and Vector structures - is it an underline platform compatibility issue?
     
    Last edited: Apr 15, 2018
    rakkarage likes this.
  10. buFFalo94

    buFFalo94

    Joined:
    Sep 14, 2015
    Posts:
    155
    Probably platform compatibility as you say. Since Unity support too many platforms I think it's hard for them to make such huge change I honestly think this will happen but we just need wait. Just look at how Unity evolved from 5.6 to 2018.1 that's a huge step they added some good features. And there's always solution like world origin shift if I don't mistaken UE4 use the same work around but it's built-in I guess.
     
    rakkarage likes this.
  11. Phelan-Simpson

    Phelan-Simpson

    Joined:
    Jan 1, 2014
    Posts:
    27
    I replicated the test, I whipped up a animation and a character mesh with decently high vertex count. The mesh is around 1.5 meters in height. I tested the mesh at 100, 1000, 2000, 3000, 4000, 5000, 6000, 7000, 8000, 9000, 10000, then 50000 and then 100000 units (Meters in this case).

    For close up shots on animated meshes there is visible vertex jitters at around 2000-3000 units. However, the jitters would be unnoticeable in medium and long range shot all the way to 10,000 units. Close range shots would be around 3000 units. Extreme close range shots would be around 1000 units.

    Although Star Citizen does have some very impressive tech, a similar multiplayer implementation has been around since, early 2000's when Guild Wars was in production.
     
  12. Peter77

    Peter77

    Joined:
    Jun 12, 2013
    Posts:
    2,519
    From the top of my head...

    64 bit floating point operations are maybe not hardware-supported by all platforms they target, so it would get software emulated and this is slow.

    The "double" type consumes twice as much memory as "float". So every Vector3 would increase from 3*4=12 to 3*8=24 bytes. Which would render every existing Unity data format that currently contains these types, e.g. asset bundles, saved games, etc... incompatible.

    Larger data types causes more band-width usage as well. With all the cache-line optimization talks going on here lately, using larger data types is probably also counter-productive in this regard.
     
    Last edited: Apr 16, 2018
  13. Thrawn75

    Thrawn75

    Joined:
    Nov 16, 2014
    Posts:
    1,878
    Yep, I can understand the trade off in performance though for some applications we’re already abusing of double data types. And it’s no fun to ping pong to float every time you need to translate the data to graphic entities.

    My question was more about the cost of adding native double precision as an option in the engine - I guess any change at so low level components will quickly trigger lot of dependency issues.

    A zero shifting builtin solution can help some scenarios but it’s kind of hack that works for some, but not ideal when you really need that precision in your data.
     
  14. buFFalo94

    buFFalo94

    Joined:
    Sep 14, 2015
    Posts:
    155
    I really think a well implemented zero shifting can work perfectly since many open world uses UE4 which use that's hack
     
  15. Thrawn75

    Thrawn75

    Joined:
    Nov 16, 2014
    Posts:
    1,878
    Agreed, better than no support at all.
     
  16. sanjaykseriouslabs

    sanjaykseriouslabs

    Joined:
    Dec 4, 2017
    Posts:
    4
    Hello Guys,

    I am an Environment modeler, and I had a discussion with my level designer. He said that " I need to make stuff in clean number. For Example, If I am making a cube, it has to be in 1M in Height and Width. So he can use Grid snap" So the snap value will be 1M inside of unity because in unity 1 Unit = 1M.

    Which I understand. And I am fine with it. But he refuses to use vertex snap, I asked him why and he said: "Vertex snap give a value of 1.9899(just example -not exact number) which is bad for the game engine in terms of programming issues and it is also a bad level design to have unclean numbers".

    Unity created Vertex Snapping for a reason, to snap. It is just another snapping option to me. I see that there going to be an issue in a huge open world. But what we are doing here is a closed indoor environment.

    #Does this affect level design in any way?

    #Using Vertex snapping is a bad practice as he says??

    #If assets don't align using grid snapping, is it really bad to use vertex snapping??

    #So even if a real-world asset is 1.78 meter, should I have to round to 1.5M or 2M just to satisfy the need of Grid snapping?

    Please throw some light here. I am really tired of this argument with people around me about this whole conversation. IF there a best practices guide, that will be helpful.

    I also do understand the importance of Grid snapping when I do modular asset pieces or tilling assets. I make them in the increments of 1M grid's. But other than that I really need a clarification on this.

    Thank you.
    SK
     
  17. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    1,702
    Your designer should have been able to provide a better explanation. There are a lot of possible reasons why uniform sizing would be good. But absent any of those, it doesn't really matter.

    It's only bad for programming if you actually have a case where you have to deal with it in code. If that doesn't exist, then the argument is a red herring.
     
  18. Joe-Censored

    Joe-Censored

    Joined:
    Mar 26, 2013
    Posts:
    3,361
  19. Peter77

    Peter77

    Joined:
    Jun 12, 2013
    Posts:
    2,519
  20. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    12,192
    To my knowledge double precision is supported by every major platform (at the very least that's all three desktop platforms as well as the consoles). ARM has had hardware support since ARMv6 which means mobile devices as far back as the original iPhone.

    Performance is a completely different story. You'd have to translate from double precision to single precision before you sent the data to the graphics card as even the most recent graphics cards are 32 times slower with doubles than they are with singles. Processors are generally at least half as fast with doubles.
     
    Last edited: Apr 20, 2018
  21. Chris-Foster

    Chris-Foster

    Joined:
    Jun 30, 2015
    Posts:
    6
    I don't know if its been posted yet but here's what I use. Its a simplified version of a solution I found after hours of searching. I tested it with 5000+ simple objects with a handful of physics objects and it seems to do the trick. Can't promise it will work for everyone, but its worth a shot. Slap it on your camera and set the threshold to the max distance you want.

    using System.Collections;
    using System.Collections.Generic;
    using UnityEngine;
    using UnityEngine.SceneManagement;

    [RequireComponent(typeof(Camera))]
    public class FloatingOrigin : MonoBehaviour {

    public float threshold = 5000.0f;

    void LateUpdate () {
    Vector3 cameraPos = gameObject.transform.position;
    cameraPos.y = 0f;
    if (cameraPos.magnitude > threshold) {
    foreach (GameObject go in SceneManager.GetActiveScene().GetRootGameObjects()) {
    go.transform.position -= cameraPos;
    }
    }
    }
    }
     
    Marcos-Elias likes this.
  22. buFFalo94

    buFFalo94

    Joined:
    Sep 14, 2015
    Posts:
    155
    First of all thanks for sharing!
    1. About your scene setup : is there any static collider in the scene?
    2. Is Static batching work with this setup?
    3. Can you do benchmarks and post result here?
     
  23. Marcos-Elias

    Marcos-Elias

    Joined:
    Nov 1, 2014
    Posts:
    73
    Floating origin in Unity may work:

    http://wiki.unity3d.com/index.php/Floating_Origin

    But it is not well integrated with physics and other stuff. They should implement a native origin shifter (like Unreal does) to better support open world maps. Unfortunately Unity does not care about this so requested feature...

    After 4 years trying to make a driving Simulator in Unity I am almost giving up and going to Unreal just because of this problem. A native, physics integrated origin shifter. Same 32-bit float but with a native solution to move everything without interruption.

    Floating origin on Update (Late or Fixed) may work for simpler games but it will cause issues if you have lots of colliders or moving objects with physics (like cars in my project). The time to move everything may become many milliseconds, giving a temporary stop for the player, so bad for the overall experience... Also you may not use anything that depends on static flag. Navmesh does not work (even dynamic Navmesh, at least a few months ago when I tried). Lots of drawbacks.

    Also creating a system to handle scene loading is not that easy, Unity gives us a function (Load Level Async) but each game must implement its own solution. I managed to do that, but got stuck with floating origin limitations (user interruption to move everything in a single frame).
     
    Last edited: Sep 2, 2018
    Joe-Censored likes this.