32 bit float offers us only 7 non zero digits in a row, so we got only 20 kilometers (from -10 to +10) of space before precision drops from 1 millimeter to 1 centimeter. 20 kilometers is only 1 minute worth of jet flight (Think of Battlefield series).
1 centimeter precision is unacceptable because camera starts to shake.
(look at “1234,567” digits, they pretty much explain the situation).
64 bit would offer us 15-17 digits in a row, which is 200,000,000,000,000 kilometers with 1 millimeter positioning precision.
(123456789|10|11|12|13|14|,15|16|17)
Earth radius is 6,370 kilometers.
Maximum distance from Pluto to sun is 7,311,000,000 kilometers. And still we got 4 more digits free.
That makes me think that we live in ~128 bit world lol, since we need only ~35 digits to fully generate our universe (if you do not believe in infinity, but I do)
Conclusion:
This will allow us to procedurally generate entire Solar System in a single instance with 1 millimeter positioning precision.
DO WANT
I’d really question why you need micrometer precision in the first place. Secondly - it’s not just a matter of “increasing” the precision used by the Transform class because the physics engine also uses 32bit.
well look at Kerbal Space Programm. They have a huge world (solar system) and the Game is done in Unity. 32 bit are enough. You just need to be tricky/clever.
i agree that this would be a huge waste of time for UT and has little to no gain for the average programmer. “unlimited” space games are very few and the only reason to use higher precision and the for rest of the world unity games require more memory without a gain.
why would you want to “simulate” the whole universe/solar system in unity anyway? usually a game is centered around the player so when the player is in one solar system there don’t need to be an accurate simulation of an asteroid in a star system 5 light years away. you run into performance problems really quickly when you handle it like this. instead you provide the player the impression of accuracy with simulating that what he can see so you have some kind of spatial partitioning. fe when you look at stars in the starmap one unity unit could be 1 light year, in the system map 1 astronomical unit, in a local map 10000 km and so on. so you can use the same small float range for the independant simulation of different magnitutes. you need such a system anyway to omit simulation of processes that are not visible/relevant for the current position of the player. and i doubt that your game increases fun significantly by simulation of the relative movement of stars as it can’t be noticed by the player on any scale.
space is empty to a very high percentage and usually the interesting part is the not emtpy stuff. by simulating this emptyness you only gain boringness.
another problem that arises is that when you have double precision and you “use” it you still have only float precision for the depth buffer so your objects near the far clipping plane will not necessarily look better with doubles as the longer range cannot be rendered properly (z fighting).
and usually the players don’t care for a realistic simulation when the game mechanics are full of unrealistic stuff like faster than light travels, wormholes, sound in space, visible laser beams etc… game development is not providing the player reality, its providing the player a fantasy with high imersion that it is believeable in the game. when he is busy shooting enemies he will not notice that he really approaches the planet by 5 km what is something like 0.01 % so why simulating it? simply put the planet on the background/skysphere and save lots of effort, worry and resources.
64 bit transform component is needed for Unity server instance because all existing workarounds for it will dramatically limit your abilities, create a lot of additional code work and create seams between instances (Unity servers could not connect to each other in order to communicate with default networking).
So just the additional Transform64 component will be enough without physics adjustments.
Scaling wouldn’t help, you can’t scale the precision.
And yes it will be quite easy to design the game play to fit within limitations, but server crossing will cripple the whole thing or wouldn’t allow to design it at all. (Ever compared Battlefield 2 vs Battlefield 3 jet speed ? That’s ridiculous)
Update 1: Oh and by the way, camera starts to shake back and forth when we go over 9999 meters, so practically we are limited to 20 kilometers, which is worth only 1 minute of jet flight. I didn’t think it’s that bad, situation is kinda critical for open-world online games.
A 64bit Editor doesn’t mean you’re going to get a 64bit Transform component out of the box. You’d also, at that point, have something that worked on 64bit systems but didn’t work on 32bit systems which is completely antithetical to Unity’s design philosophy.
In terms of client/server you don’t need a 64bit Transform for that. There is nothing saying that the client simulation can’t run completely different than the server’s data handling.
why is this a problem? after 30 seconds you unload the fartest terrain patches and load new ones in front of the player. so there are many “tricks” to allow everything you could imagine with the floats. if thats still not enough for you you could simply switch to another engine if there is any which uses double precision out of the box.
the most important point not to switch to a double vector3 is that it would break backward compatibility. so everyone who already have a project could not simply update unity or would have to change his project code to use Vector3d(ouble) or however it is called then. and thats quite a dealbreaker for many customers and again you gain nothing. so changing to a double transform would turn the inconvenience of a few people who need double precision into the inconvenience of many people who don’t need it but only have the effort.
and the 64 bit editor only means that it uses 64 bit for adressing memory so it is not limited to the 3 GB memory of a 32 bit application. it does not automatically turns floats into doubles.
But this has nothing to do with his issue. He’s after the ability to accurately model detailed motion over areas greater than 20km squared. Like has been said, try to move a camera out to say (50000, 50000, 50000) and then move it smoothly and slowly along the X axis. This isn’t a problem with Unity, it’s the nature of how floating point values work.
shame, since it’s server side, can you overcome the limitation by breaking your game into 10km cells and having special logic to handle motion near / overlapping the edges?
thats why i suggested the op to use an engine which supports this right now.
i know about the inaccuracy of large float values but you may admit this is a rather rare case and there are techniques to deal with it WHEN you need it. create all the mentioned disadvantages for all users by force and have UT spend lots of $ to change this is in my opinion not worth the time and effort saved for few users.
i think when you are indie/hobby developer you come rarely across the real limitations of the engine and hardware. and you already (should) know them in advance and design your game/system accordingly. ignoring those limitations and simply “DO WANT” others to remove them is like thinking world rotates around you. there may come a time when things wich are “cool” today are standard or even outdated but i think there are other issues to be changed before this one simply because they serve more people. think of the documentation, built in gui and a bunch of issues been there for years. as stated its not simply exchanging float for double and done there have to be changed the renderer, physics, math library etc so its more like a complete rewrite of large parts of unity engine.
also i don’t understand why this is posted in scripting section. should have been in gossip or suggestions.
So 8-bit elite needed 64 bit transform components?
The old 8/16 bit way was to just add a number to say, miles, and offset the local world so the player and interactive elements were within the required numerical fidelity.
You cannot compare a space sim with a planet side flight simulator. Space is generally empty which makes it much easier to apply tricks. A planet however, is not-so-empty. You will get all sorts of problems like z-fighting of mountains in the distance, see the blog here (that is a z-buffer issue by the way): http://outerra.blogspot.com/2012/11/maximizing-depth-buffer-range-and.html
Also, no need the mention the unity physics engine as that doesn’t support fight dynamics anyway.
Another way would be to keep your plane in the origin and move the terrain around you, but that still limits the maximum altitude you can go to.
This is a complicated issue and can’t be dismissed by a simple “just use some tricks”. If you can show me a program like Outerra in Unity, I would be impressed. Not just some space sim.
Sorry to dig up an old post but cant you just create regions? and transfer between those regions once you reach the boundaries … using the local space to determine the position etc?
First this is an old, dead thread. Not sure on the revival neccesity to repeat the same info but…
I get the workarounds and suggestions. But why not just make the game engine better and add the small bit of functionality?
It seems to me the content of this thread is bigger than the effort of just extending the transform class. Chances are just position and rotation information in 64 would give him enough to work with. He hasn’t said he can’t work around it, he’s just making a request.
I agree about the request, the issues aren’t even too noticeable with positions but I did some measurements with rotations and the smallest angle difference unity can handle at any distance is 0.02 degrees… This sounds great but when you scale the distance to something like 1000 meters this already is off by 34 cm even if you’re at origin, plus there’s no real workaround to this.
Very unlikely we will see this anytime soon. For this to work I can imagine that a large portion of the rendering engine has to be rewritten because it uses floats instead of doubles. The physics engine also needs to be supporting this, and who knows what else more. From my limited understanding on why rendering engines typically use floats is because GPU’s are optimized to work with them, so I think it makes a lot of sense to cater to the hardware when rendering.
Last time I saw this brought up there were two big blockers. First was PhysX, the physics engine in Unity, did not support double precision. I don’t know if that has changed. Second is GPU performance in double precision is terrible, from some quick googlefu it appears that has not changed.
Here’s some info I found where you can click on any graphics card and see theoretical max performance for single precision and double precision. I don’t know how that translates to real world performance.
In this RX 6800 example, supposedly the card has just 1/16th the performance with doubles vs floats. Even if real world performance in game were just half the speed, that would still be horrible.
Funny thing is, the RX 6800 appears to actually be pretty good compared to what Nvidia is offering. The RTX 3080 supposedly has 1/64th the performance with doubles vs floats. Ouch!
