3D Unity world w/ 100,000 units without lagging

Best method for massive worlds beyond 100,000 unity without lagging

Hi there!

I want to start a discussion about the best methods to create colossal 3D worlds in Unity that go beyond the 100,000-unit limit without lagging. As many of you know, Unity’s floating-point precision starts to cause issues with rendering and physics when objects are positioned far from the origin.

Lets use as reference planet earth 1:1 ratio size :earth_americas:

these are my commonly heard approaches to resolve this limitation:

  1. Floating Origin:

    • The world shifts dynamically around the player, keeping them near the origin.
    • Commonly used in open-world games and space simulations.
    • is this option good? If yes, thus it have down sides.
  2. World Streaming:

    • Dividing the world into chunks and loading/unloading them dynamically.
    • Great for memory management and performance, but how do you handle transitions?
  3. Custom Coordinate Systems (I really don’t know about this method at all):

    • Using double-precision or custom math libraries to track world positions beyond Unity’s default float range.
    • Is this practical for large-scale games (for moving around without lagging), and how the best way implement it efficiently? (overall, is it efficient or even recommended??)
  4. Combination of Techniques:

    • Is it a good idea to combine all the best method available?
  5. Tools and Assets:

    • Are there any tools, scripts, or Unity assets you recommend for handling massive worlds?

I’d love to hear your thoughts on these methods or any other strategies to use and expand the world size.

What is your Unity / game dev experience?

Look into DOTS.

But main point is, does 100, 1000, or even mln makes fun in terms of gameplay. Or it is just a gimmick to have large number?

My experience since April last year includes working on smaller projects, focusing on gameplay mechanics and optimizations for mid-sized worlds. However, I’m currently aiming to scale up to much larger worlds and explore techniques like Floating Origin, World Streaming, and now DOTS (your recommendation ;D).

Good point! To be honest, part of this is just for fun.

Exploring the challenge of creating a planet-sized environment (Earth 1:1 ratio) in Unity and seeing how far I can push the engine’s limits. That said, I also plan to test games at this scale for a future projects and now just focusing on getting the basis.

Would you recommend starting directly with DOTS, or exploring other options like Floating Origin and World Streaming?

None of these things are mutually exclusive.

1 Like

So, you’re saying that if I study one, I’ll eventually end up studying all of them?

1 Like

Floating Origin is the most performant and works with gameObjects and PhysX. The downside is that you may experience a stutter every time the world is shifted. And distant objects can’t be moved precisely.

ECS and DOTS should be more performant but then you should consider whether it’s worth learning C++ or using another game engine. Because ECS and DOTS are basically another game engine and will require just as much time to learn.

1 Like

No, I’m saying that none of these things exclude each other. You can use DOTS with floating origin and world streaming.

1 Like

Would even say they don’t solve the same problem at all.

DOTS is to support a large number of active objects in the scene and it will run into the floating point inaccuracy the same way as Gameobjects do.

Floating origin solves the inaccuracy problem.

And World Streaming becomes necessary when even with DOTS there’d be too much stuff loaded in memory which the player does not see or interact with at a particular moment in time.

LOD mechanics are another solution by the way. E.g. how the game Spore has economics and local actions on individual planets but when you zoom out, they are just a single entity that calculates a couple values for the whole planet.

True, but players are used to lag :wink: At least if it does not put them in danger.
Therefore if you really wanna be smart, you can delay the shift artificially if the player is currently e.g. in combat, so the lag only happens when they are boringly traversing the world.
Or preferably do it when they are not moving e.g. while the inventory is open etc.

Continuous Floating Origin (as opposed to origin-shifting that many call “Floating Origin”) is a fully-relative navigation/motion method to optimise fidelity around the player. It has nothing to do with solving lag.

Floating Origin can be used for 1:1 Worlds Earth size and larger, and for continuous travel of a full-scale Solar system.

Streaming, managing data in chunks, etc is needed for any large-scale open World regardless of whether you use Floating Origin or not. However, movement and streaming need to be combined with a solution to Distant Relative jitter that works with Floating Origin if you want to handle large open worlds with smooth motion - assuming you also solve unrelated causes of lag.

1 Like

There is one indirect way that Continuous Floating Origin can reduce lag.
Many developers opt for double precision for large-scale worlds to increase accuracy. The downside is that doubles require twice as much bandwidth compared to floats. So, if you are streaming doubles a network, it takes longer than floats.

Continuous Floating Origin (as opposed to origin-shifting that many call “Floating Origin”) maximises the fidelity around the player, allowing larger worlds without the bandwidth cost of doubles. This bandwidth advantage applies for all data transfers including network, disk I/O, bus I/O and CPU-Cache transfers.

No serious developer should ever create a game (whether in Unity or any other engine) that uses a double-precision floating-point coordinate system for large worlds. This is because operations with double-precision calculations must be executed on the GPU for the rendering of the world.

The bottleneck here is not bandwidth but the performance of these operations. Even in a single-player game, developers should not be using double-precision calculations for graphics, as these operations can take 30 to 60 times longer (and sometimes even more) than their single-precision counterparts.

1 Like

Good to know. Can you point to documented measurements on these performance stats? I would like to be able to reference them.

NVIDIA: https://en.wikipedia.org/wiki/List_of_Nvidia_graphics_processing_units

AMD: List of AMD graphics processing units - Wikipedia

Look at the GFLOPS column for single and double precision. Officially this happens because gpu companies “optimize” their hardware for single-precision.

Unofficially, they are hampering the double-precision performance because, double precision operation speed is an advantage of the data center gpu’s and if they had optimized for that, they would loose a lot of money from anyone that could use consumer gpu’s instead of data center gpus for calculations.

That’s really interesting. The differences are much more than I expected.

Uhm, Unreal Engine literally has a double precision mode. They call it LWC “Large World Coordinates”: https://dev.epicgames.com/documentation/en-us/unreal-engine/large-world-coordinates-in-unreal-engine-5

What’s up with the disucssion of floating origin countering lag? It causes lag (under certain ciecumstances) due to the large number of objects moved suddenly requiring recaclulation of the transform hierarchy. Shouldn’t be a real problem though as I mentioned.

Unreal Engine is being used for much more than just games, so it offers the option for double-precision operations for the gpu’s that support fast operations in doubles. While version 5 introduces support for double-precision, this does not mean it should be used in performance-critical projects.

The approximately 60x performance difference is due to hardware limitations and cannot be mitigated through software, unless your project targets hardware that uses data center gpu’s where this difference doesn’t exist.

Of course, in projects where performance is not a priority and higher precision is desirable, double precision can be utilized. However, even in such cases, Unreal will downcast to single precision for performance-intensive operations like particle systems. As stated in the link you provided:

Blockquote
In Niagara, the implementation is different from the main engine. To keep particle effects performant, the data is stored as a set of floats instead of using doubles.

1 Like