Discussion Continuation of 'Any Plans for Supporting Large Worlds'

From Any plans for supporting Large Worlds? - Unity Forum

@alsharefeeee

I came across your post and it's definitely a worthwhile topic of discussion, as many users are interested in large world coordinate support. Unreal's support for large coordinates is now enabled by default.

Having used it briefly, my understanding is that it uses native 64-bit values on the CPU, which is then passed as two 32-bit Vector3 values to the GPU. The first vector is a grid position, and the second vector is a position within the grid. In terms of performance, overhead appears to be minimal and it works in a way that is mostly transparent to the end user.

I believe it would be a great addition to Unity, especially for procedurally generated worlds.

While the floating camera design works it is substantially more difficult to implement compared to Unreal's solution.

Honestly, your post received undue criticism. Thanks for sharing your thoughts around the importance of this capability.

 

Oh thank you @stonstad . For some reason some of Unity hardcore fans hate the Large Worlds support idea and I guess this speaks a lot about the older generation of Unity developers whose main focus was 2D and mobile (I am one of them, my focus was mobile).

By the way, since my post Godot engine seems to have somewhat implemented LW support. That means almost all major game engines now somewhat support LW. I also discovered that indeed DOTS do support Large Worlds (with a lot of bugs, of course) and we all know that DOTS is hard to use compared to the normal Unity. Though, it does seems to becoming easier. Hopefully in the near future @Joachim_Ante will consider to add it, maybe as a package for Gameobjects!

For now I just decided to work with the smaller areas of my project until some day where me + DOTS + Unity is ready for LW.

What I didn't like is the mentality of some, "If I am not going to use LW then I don't want any other Unity developers to use it too.". They are afraid that it will be too heavy on the current Unity, completely forgetting that it could be a package for those who want it.

Oh and I did as @hippocoder advised and tried out Unreal Engine 5 and I hated it. Because I have been a Unity guy for more than 10 years, but if I was younger, and had very little experience in Unity, I would have definitely jumped the ship just like I did with UDK and CryEngine many years ago.

 

https://forum.unity.com/threads/large-world-coordinates-double-precision-data.1371378/

That's not it. Having double precision and all those jazz requires deep engine changes and many paths inside the engine because many of the platforms Unity's supporting cannot ever be supporting huge worlds. The implementation is long and messy, all those manhours could be spend on features more people would use, often more basic features. Like decent animation system and whatnot.

 

50km as stated by unity official is way above functional. I would say it starts to jitter at around 2km. Though that is in frist person VR

 

I thought Unity already did it O.O this is pretty standard

 

I initially thought the same. But Unreal's approach of passing two Vectors instead of one ... doesn't seem like a deal breaker for most platforms. I understand what you are saying about Unity's delivery cadence and prioritization of features.

 

The needs vary based on the game. I am currently working on an open world 3rd person HDRP in Unity, and I can get pretty far from the origin without any jitter. I have not tested at 50km, but it would not surprise me if that mostly worked. My map size is an 8x8km.

By contrast, I worked on a URP first person VR in Unity a few years ago and the jitter was a serious problem past about 1-2km. I resolved that issue by stacking the camera and setting up a VR cockpit camera that stayed at the origin (0,0,0) and simply rotated to match the rotation of the spaceship as it flew around.

One thing to note is that a lot of 3rd party assets for building open worlds in Unity already support a floating origin. Terrain building, world streaming, and even vegetation rendering systems all support floating origin. Game developers can build large open worlds in Unity right now without waiting for 64 bit Vecter3.

 

Did you run into precision problems with either Allspace or Disputed Space? In a space sim, I'm seeing precision issues at around 5000 units, when a player walks across the bridge of a starship in flight. I'm just curious to understand what your experience was.

 

I see problems already at 2k. Multiplayer game so i don't think there is a easy fix. We are on built in but tried a POC on HDRP midigated some of the jitter. But not all I guess it's because of single precision on transforms and Physx

 

And if you want to add multiplayer to it?

 

Yepp we need native origin shifting. I wonder have Rust solved it. Maybe they have smaller worlds than 2k?

 

Another issue is that most third party assets use different systems or bad systems for performing origin shifting. For instance, Vegetation Studio uses a reference Transform object to measure the origin offset, which will introduce large floating point numbers into its calculation eventually. I'm not positive but I would imagine this will introduce errors at some point.

Without 64 bit numbers, in my opinion the best approach is to use a grid based system where all objects in the scene have a coordinate (representing a cell on the grid that they fall within) and relative location in reference to this same cell. The coordinate positions can be stored using 64 bit values. Then you can origin shift by changing the "origin" cell on the grid. There are basically three different types of position values in this type of system:

1. Unity Scene Relative position used to position objects.
2. Grid Relative position (in reference to whatever cell the object falls within on the grid).
3. Raw position of objects in reference to the total size of the game map.

Converting between the three types of positions is relatively easy.

 

Yeah, we've got maps of similar size, also with no noticable physics jitter. Our scale is pretty big, though,by which I mean the player is controlling and interacting with objects bigger than a person. I imagine if we dropped a VR rig into the edge of one of our worlds it might not appear so stable any more!

Our world overall is closer to 50x50km, but is designed such that we can just origin shift when transitioning to a new area. Of course that solution wouldn't work for all game types, though.

 

Calculate the relative difference of the two players respective origins and add that offset when you transfer across network to transpose a position from the world in one game instance to the other.

By the way, for a part of the whole issue - the part that cannot be worked around so "easily" with the origin-shift trick - Unity has introduced a feature to HDRP: https://docs.unity3d.com/Packages/c...ion@7.1/manual/Camera-Relative-Rendering.html

 

Both of those needed a stacked camera to eliminate the flicker in the cockpit. Allspace included a VR option, and the VR cockpit jittered a lot without the stacked camera solution. With a stacked camera and the VR cockpit at the origin, there was no jitter at all.

With Disputed Space, I ran into a movement problem at one point caused by precision. I wrote my own movement controller for all of the ships, so I could get the kind of movement I wanted for that game. When I ran into a precision issue with that movement system, I rewrote some of my movement code. Basically I re-ordered the math operation so less precision would be lost. After I did that, the movement was fine even at really large distances.

Neither of my space games have a bridge for players to walk around on. Animation systems have problems doing math on skeletons at high distances from the origin. Even a simple idle animation on typical humanoid can get jittery after some distance. If you need to see humans walking around inside your spaceship, then I would suggest placing the ship at the origin and moving everything else around relative to that ship. That way, your humanoid animations can be run near the scene origin.

 

You can write your own code to do what ever you want on the client and server of any game you develop. For a huge open world multiplayer game, you will likely need to build your own custom server solution to handle everything. I don't know if any off the shelf multiplayer solution would handle it. Even if some existing off the shelf multiplayer code could do it, who knows if it would be performant in the exact ways that your game needed. Each multiplayer game has unique needs, so off the shelf multiplayer code is usually not the best idea.

 

One thing to keep in mind when talking about camera relative rendering in HDRP is that it helps with static objects but not animated things. HDRP can do a great job with mountains, buildings, rocks, and so on. But when animated people and animated creatures are running around, the animator system itself can still jitter. What this means is that origin shifting is usually still needed, even with HDRP, if you want to have animated characters on a 50x50km map. On a 8x8km map, origin shifting is not really needed.

 

Have you actually seen any problems using Vegetation Studio with a floating origin using Gaia or World Streamer? I use Vegetation Studio Pro. I have not seen any problem yet like that. But I have not intentionally tried to cause the problem and then carefully measure to see if anything moved. I am interested to see if anybody has seen that issue.

 

I am currently doing an 8x8km island surrounded by water, and then the player character is normal sized. I have messed around with and without origin shifting, and it was not a benefit for my 8x8km map. On a 50x50km map, I can definitely see a huge benefit for origin shifting.

 

after 999 meters you get 3 decimal digits. Are your game third person. Even if you use HDRP with local camera space rendering I cant see how physics and transforms can be smooth at 8km

 

They're binary numbers, not decimal. Even with that example, that's 1mm precision, which would be plenty for many games and sims.

 

The numbers are binary, and "decimal" is an approximation. Also, IT is 6 to 9 decimal digits and not three, and at 999 meters you'd get at least millimeter precision, the actual would be sub-millimeter. (IIRC 1/(2^23) from 1km will give you 0.1192 mm)

At 8192 meters from origin, you'd have 1 millimeter precision (0.9766...), and that will give you a cube with with 16 kilometer edge (because it is +/- from origin). Which is 256 square kilometers. Witcher 3 is smaller than that.

 

At 999 you get sub millimeter. At > 1000 you get millimeter (You stil get sub millimeter but without any sort of precision, thus jitter)

 

I appreciate your insight. Something that I thought was insurmountable now appears like a solvable task. Thank you!

Did you encounter any challenges moving rigid bodies? I'm thinking I have to enumerate all RBs and use MovePosition on each instead of changing a parent transform position... I'm testing this now to compare results.

*Edited. Don't use MovePosition -- that interpolates between frames.

 

Thank you!

 

Floating point has significantly more precision than you are assuming. Here is a link about single precision floating point:
https://en.wikipedia.org/wiki/Single-precision_floating-point_format

The game I am working on currently with an 8x8km map is 3rd person. At the edge of the land area in my map, I should have precision of about 1mm.

Both of the first person 3D space games I have on Steam use stacked cameras. In those, the space ship flies around in the scene, but the cockpit stays at the origin.

 

Neither of my 3D space games used rigid bodies and physics to move around. I wrote a class for handling the ship movement, and the ship movement code directly adjusted the transforms for the ships.

The only time I used physics in those space games was with the asteroid field in Disputed Space. The asteroids could bounce off each other using physics. There probably was some jitter in the asteroid movement at large distances, but it was not noticeable to the player, because the player was usually focused on ships and lasers.

 

1mm precision jitter as hell. At least for my first person VR game. Might work for less precise applications

 

URP needs camera-relative rendering badly.

If you have a player in a moving vehicle, with a detailed dashboard, or worse, a helmet-like mesh around the camera (even smaller details, even closer) , you can run into rendering 'wobble' at under 2000 units from the origin.

I had an initial attempt to hack the feature into URP based on the HDRP implementation, but ran into some issues (particularly around editor rendering of selection highlights/outlines, and a fair bit of shadow-related debugging still to do) and haven't revisited it yet.

May have to give it another try soon though, as a 'floating origin' by actually shifting the entire world during gameplay is a huge pain in other ways, some resolvable, some maybe not (e.g. not being able to use world-space particles/trails)

But URP is still changing too rapidly with Unity updates to make heavily-edited versions of it practical. (<moan>I'm working on projects in 2021.3, and there'e enough pain ahead updating them to 2022.2 even with unmodified URP packages... custom shaders and render features rendered incompatible, including un-updated asset store packages...</moan>)

 

Several years ago I had to make a VR prototype for cars that drove around a city, and generated content based on your gps position, and moved the content 1:1 with real movement to not puke using a hardware harness with gyro, accelerometer, high end gps, cellular board for internet, etc. streaming to the headset.

I never could figure out why it'd start jittering towards the end, only right now I realize we drove several miles from origin in RL in the same scene throughout the demo and that must have been the issue.

 

It's typically unity that one of the pipelines get a useful feature and not the other. Though if you move transforms with physics you still will end up with jitter.

 

Anyone tried world streamer 2? It could possibly help at least for non multiplayer games

 

Bullet physics supports double precision, but in the end it is kinda too small as for a space game, double precision will limit you to solar system scale.

For a space game without trickery you'll need quad precision floats. 16 bytes per float.
https://en.wikipedia.org/wiki/Quadruple-precision_floating-point_format

You can forget about acceleration (as even CPU has no instructions for those), but that'll give you 5900 times distance of observable universe, with 1 millimeter precision at the edges.

In the end, however, that'll be a waste, and it'll be easier to use sectors and simulation bubbles. As in a real world scenario you rarely ever need to calculate forces and interactions between objects positioned thousands of kilometers apart.

 

I agree that first person VR is much more sensitive to jitter. In a VR game with a cockpit, that jitter is very easy to see. In a 3rd person camera non-VR game, 1mm precision does not cause noticeable jitter.

 

You don't need a cockpit even, you can just look at your hands or items in the world.

 

It possible on Unity now. Look at this 1:1 scale world with physics. Zoom in and out really smooth.

And yes, Earth2 use Unity. They're hiring too. https://earth2.io/virtual-world

 

The point though when using game engines is not if it's possible, it's if it's easily possible and which engine allows you to get to where you want better and faster.

Otherwise, sure, you could circumvent and re-write most of Unity's systems and have it do things that aren't easy now, but then, why are you using Unity?

 

Totally agree, workflow is always forgotten in these discussions which is interesting. Same in the nantine/lumen thread.

I have gone close to insane trying to get performant lightmapping for example. Just the fact that you still in 2020 LTS need to manually assign bake tags to meshes to get them spacially grouped on the lightmap is insane.

 

How would you program the procedural laying out of lightmaps so they were performant and fit everybody's use case?

 

I use Unity because it allows me to do things the engine was not specifically written to do.

 

Well, most people render their game using a camera and since you can't batch two meshes that are on seperate lightmaps you want spatial grouping.

 

I mean there are many methods and all of them are more effective than current Unity solution of doing almost nothing. In fact, some of those possible solutions and improvements are actually on Unity's roadmap and will come to Unity soon (tm).

None of them are new methods btw, they have been around for many years now. Efficient packing that makes sense is not an unsolved problem, it is just one Unity didn't want to tackle in the last 10 years because of "architectural issues".

I mean it is a bummer that the only thing you can make in Unreal is Fortnite and absolutely nothing else. You can add completely different graphics and mechanics and everything, but once you click build, boom, Fortnite.

And I guess I do appreciate all the knowledge Unity has graciously granted me. Like, I wanted to make a game and not bother learning the inner workings of UI systems, but with all of Unity's UI systems being complete dumpster fires, I had no choice but to make my own basic UI system. It was then that I realised the genius of Unity: my problem was wanting to make a game, while the true bliss is in re-solving problems that the engine supposedly already solves for you, which makes the engine seem kind of redundant. Thanks Unity.

 

so your UI system is better than unity's new UI system?

 

Thanks to the helpful feedback shared here, I am starting the process of implementing a shifting origin. But it isn't always straightforward. While I can adjust for rigid bodies, particle systems, and cinemachine, I'm still trying to work through quirks with trail renderers and I haven't tackled multiplayer yet.

When we talk about how easy it is to implement origin shift or whether Unity has some kind of responsibility to provide built-in support... we should think about the complex use-case involving multiple Unity systems -- particles, nav mesh, line renderers, trail renderers, rigid bodies, vfx graph. Not everyone intends to use the HDRP pipeline.

While Unity may not want to provide double precision transform support out-of-the-box (unlike UE 5.1), at minimum, they could support a consistent workflow across Unity subsystems , i.e. TrailRenderer.GlobalTranslation(...), or even provide prescriptive guidance.

 

Let me know what you come up with regarding MP i really cant come up with something. One idea I had was to stack the slices on top of each other on the server. But you would run out of precision pretty fast on that axis too.

 

@Max-om - responded here Multiplayer and Double Precision Coordinates Discussion - Unity Forum

 

Assuming you have hands, or view objects from close enough that 1mm is noticable while they're not at rest, and a bunch of other assumptions.

- - -

More broadly for the discussion, also, just as important as data types is algorithm stability. Bruce Dawson explains it well in his post, Don't Store That In A Float.

 

This is a fair assumption to make in VR, honestly. VR's application of scale and the increasingly dominant control methods involving hand/finger tracking controllers does mean that these considerations are more likely than not in that space.

 

Yeah, as explicitly mentioned one post back along that tangent.

 

One thing we should all keep in mind when we ask for large world support at the engine level is the concept of performance tradeoffs. On modern CPUs, we can quickly do both 64 bit and 32 bit math operations. At an initial glance, that would seem to suggest that we should all switch to doubles for everything, but there is more to the subject. Storing and accessing doubles instead of floats will reduce cache performance in certain algorithms.

For example, the laser projectiles in my space games are drawn using DrawMeshInstanced and the data is stored in an array of structs. An array of structs can be extremely efficient, and can lead to extremely high performance. However, if you add a bunch of additional data to the structs, you can greatly reduce the performance because fewer array items will fit into the CPU caches at the same time. When using an array of structs, simply changing the floats to doubles will reduce cache efficiency quite a bit.

Anyway, I wanted to mention this, because there are some performance tradeoffs that are less obvious when discussing floats vs doubles in games and game engines. I would still like to see some methods added to the engine to help make large worlds easier to work with, but I don't personally want to see the entire engine changed in a way that hurts performance in other smaller games.