Hello as you already know unity works with float precision because of that very large maps are totally unfeasible
I know that there are solutions to solve this, but they are not so good solutions…
Now with the launch of unity dots, you will be able to expand your game too much…, but what really limits is this float precision
Will unity ever implement double precision? This is extremely useful but so far no internal solution, so I could see 3000x3000 is where the physics behaves well
Greater than that = bugs
Today it is frustrating to be limited because of simple precision…
Maps like Gta V, which is approximately 49km2, are totally unviable at unity with this float precision…
I highly doubt it. Graphics hardware is very heavily optimized for single precision math so even if it were to be implemented it would likely be as a translation layer where the game world is stored as double precision but the actual underlying code is sectioning off the world and processing it with single precision math.
There is nothing further from the truth. For someone just getting started it can definitely look unfeasible but the truth is very very few games out there are using double precision. Kerbal Space Program uses it thanks to its reliance on highly complex physics but nearly every massive game out there is using a translation layer rather than true double precision.
For a beginner I recommend reading up on techniques like floating origin. The technique keeps the active section of the world centered around origin (0,0,0) to prevent the problems that come with single precision math. This is one of the key techniques used to support massive worlds.
Edit: Correction (striked text) by @Kiwasi below.
1 Like
Kerbal Space Program was done on unity, how did they use double precision on something with float precision on unity??
Unigine is an engine that when creating a project it allows you to choose between double precision, or float precision, even if unity optimized for float precision, having this option would be very good
The float origin techniques, do not fit into something like “multiplayer”, … I believe, unity is very good but it score -100 for this situation that I have been asking for years
Unite 2013 - Building a new universe in Kerbal Space Program
I’d love to know where you’re getting all of this information from because it’s not accurate at all. For the player running the client you shift them and the world to origin. Every other player is simply shifted with the world. This happens for everyone in every copy of the client running.
Just in case the above is confusing it’s important to understand that you’re not altering the world itself when you shift it to origin. Rather you’re simply positioning a section of it near origin before you start processing the world at that section. At best double precision would only serve to eliminate this one very minor step of processing an entire world.
Floating point precision is only an issue if you need very large numbers and very small numbers together. So for example you need millimetre precise physics on two objects that are hundreds of kilometres apart. This almost never happens in actual games.
It will help your thinking if you break this down into systems, and figure out how each one is going to work. Smoke and mirrors is a big part of game development, and will be for decades to come.
Graphics
Your screen physically doesn’t have enough pixels to represent mm resolution of an object 100 km away. Your graphics card can’t handle that many polygons. And you don’t have the memory to store it all.
So don’t try. The standard solution to this is to use LOD. Basically the models are kept very simple at a distance, and get more and more detailed as you move closer. For very distant models, use a 2D billboard instead of a model.
Physics
Again, you simply don’t have the processing power to handle physics for every possible object in your game world. The good news is the player can’t actually see most of your game world. So simply run local physics for objects near the player, and turn physics off for everything else.
World position
This is one where you might want to roll your own 64 bit system. At least for all of the key objects like distant players. It really doesn’t take much to build this on your own.
Multiplayer
Just do local simulations for graphics and physics above. If players get close enough to physically interact, then you can bring them into the same instance and sync up physics. But otherwise its not worth the effort.
1 Like
Just saying it’s “optimized” isn’t doing it justice. CPU-based double precision takes only twice as long to process as single precision math, but GPU-based double precision takes around 32 times longer to process on non-workstation GPUs. You’d either have to translate from double to single or you’d have to live with graphics from a very old era.
While it’s common to point to Unigine due to it having double precision it’s important to understand it doesn’t have that feature for games. It has that feature for enterprise-level simulations and visualizations because a workstation with the power to handle the simulation is far below the cost of the actual equipment you’re designing in the simulation.
https://unigine.com/products/engineering/advantages/
https://unigine.com/products/sim/advantages/
It doesn’t, at least not in a way that is fundamentally different from any other translation layer solution.
Kerball uses double precision and a custom deterministic physics solution to calculate the position and rotation of all orbiting bodies. (As an interesting side note, everything in Kerball is simulated as part of a two body simulation, so the actual physics is low complexity).
But everything else is done with regular floating point precision. Kerball turns off physics for an object when its not the players focus. It also turns off physics for objects more than 2km away from the player. All the cool stuff you see while actually flying a spaceship is vanilla Unity physics.
Its the same with rendering. Kerball uses a multiple camera setup for rendering close and distant objects. But items like distant planets are rendered as billboards in a fairly standard fashion.
2 Likes
Each game is a little different, so each game different needs. If you want to build a massive open world, you need to roll your own custom solution for handling each aspect of the massive open world. If a game engine tries to do that for you, it would lock you into what ever design decisions and compromises that were made for that support. If you build your own solution, you can do exactly what is best for your specific game. Simply changing the locations to use 64 bit vectors is not really enough to do it.
If you design your game so the player is always at the origin in the scene, then you can move the entire universe around the player without any limits. You could set up several layers of 64 bit Vectors and then nest those as you needed without any regard for the typical engine limits. You could build your entire game using arrays of custom 64 bit structs, and then you could render the nearby objects using normal 32 bit tech. Your game could run on normal computer hardware while having a completely massive open world. But if you demand a game engine company to make all of that for you, they will most likely build it different than what you needed.
2 Likes
Please don’t use allcaps and all bold text…
Use origin shifting or other approaches.
“Perfect is the enemy of good”. If it works, it is good enough.
No. It is highly unlikely that they’ll implement double precision, because physical library and graphical hardware wants single precision floats. It is not a trivial task.
For the recrod, very few engines support double precision. Unreal doesn’t support it for example.
GTA 5 fits into single precision limit.
Single precision float retains sufficient precision within roughly ± 8 kilometers from origin. That gives you a CUBE with size of 16 kilometers. Because there are 16 kilometers between -8 and +8. That gives you 256 square kilometers to play with. (16x16 km square). If you want to play it safe, you could use smaller square. For example ±4 km limit gives you 64 square kilometers. That’s enough for a city.
The situation when you need double precision occurs when you start implementing space travel on solar system scale, while maintaining 1 millimeter precision along the way…
Also see:
1 Like
I’m curious whether anyone has used Camera Relative Rendering in HDRP, which I think is Unity’s attempt at addressing at least some of the problems associated with floating point precision in large worlds.
I guess you know that the ‘Community SDK’ version of Unigine does not support double precision. The version that does costs a slim 6000 bucks per year.
I haven’t used that, but i was under the impression that this is only helping with things like z-fighting. So you would still require origin shifting for larger scenes.
Yeah I imagine that fixes the problems associated with rendering such as lighting and animation glitches, but wont address any issues associated with physics simulation.