The difference double precision will make on map sizes

[danredda]

So coming home from PAX on the bus (free WiFi), and browsing the Star Citizen subreddit I came across a post where someone asked what difference 64 bit floating point precision will make to the map sizes compared to the current 32 bit. I decided after being fooled once by someone, to actually investigate a little, and now I thought I'd post it here for those interested. I have changed the numbers I'm using (8k radius to 4k) just because I feel that 8k radius just seems too big for AC - and even 4k was pushing it IMO, as I haven't played AC om so long I'm not even sure if it might be too big too, but the general idea is the same.

 

 

Read in the spoiler for the text - contained it in there so the OP isn't massively long. Beware though, it is a wall.

 

First off, 32 bit (2³²) and 64 bit (2⁶⁴) IS the big difference you'd expect. In 32 bit floating point, values are made up of a sign bit, 8 bits for the exponent, and 23 bits for the fraction. General convention is to imply a leading 1 for the fraction. The image below does a good job showing this.
 
 

I'm not going to go about explaining how to convert this to a decimal value, there are plenty of Wikipedia articles and other sources where this can be explained properly if you're curious. The key thing to notice here is the range of values for the exponent of normal numbers is -126 to 127. This gives a signed range of integer values that can be stored of -2,147,483,648 to 2,147,483,647. Now I'm not going to go into the complexities of the actual issues, but with the map size limits ATM the judder on the controls CIG talks about when at the boundaries of the maps can be explained by not having enough extra bits to store precision, and when calculations are performed the answers aren't entirely accurate (missing some precision) because all the bits are being used already effectively (simple way of explaining). Now what is the advantage of 64 bit?

 

Similar to 32 bit, 64 bit floating point stores data with a leading sign bit, but it has 11 exponent bits, and 52 fraction bits. Just as with 32 bit, a leading 1 is implied for the fraction.

Due to the increase in bit size of both the exponent and the fraction, the range of values for the exponent of 64 bit normal numbers is -1022 to 1023. The signed range of integer values however is even crazier. It can range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807 otherwise known as pretty bloody huge. Now what does this mean for the maps?

 

Well if we look at the numbers we have, and the data that can be stored by the floats, we're looking at around 4,294,967,296 times the current map dimensions once the change happens, and a hell of a lot more space. If we take the general idea that the Cryengine is designed to support 8km diameter (4km from origin), and that's large enough to JUST fit Shubin ATM, then ROUGHLY the diameter of the 64 bit maps will be 34,359,738,638km (WTFBBQ!!!). Quite a jump. Now if we halve that to get the MAX radius, we still get 3x the distance from the sun to Pluto. So what will this do? It will allow CIG to create maps that are massive, and have plenty of room left to keep those calculations precise and accurate up to at least twice the distance of pluto from the sun (around 10b Km).

 

So lets assume now that they cut the world off at just over twice plutos distance, 12b km. This would still leave plenty of room for precision calculations. Also assuming they create space as a sphere, we would have a total volume of space at 7.24x10³⁰km³ or around 7,240,000,000,000,000,000,000,000,000,000km³. Now I don't think that CIG will make the space areas that large, and will probably make them significantly smaller seeing as hardware probably can't keep up. But the potential exists under 64bit to make the world so huge that they could simulate everything at scale sizes in 1 map if a computer could handle it. My guess for size is around 100,000km in length boxes all seamlessly joining together, but who knows... And this is just 1 system...

 

 

Do keep in mind that I am in no way an expert in this information, but that the general idea is that the maps can be bloody huge after 64 bit conversion of the engine is done and STILL maintain precision in calculations etc.

 

If I did something wrong, don't hate. I did most of the calculations on a bus bouncing on the road, after I'd been on it for 5 hrs already, after getting up at 5am, the morning after the SC event at PAX, and rewrote it just now at 11pm... so exhaustion. Plus I could just delete it all...

 

 

EDIT: Addendum to explain precision a little

Imagine you want to multiply 2 numbers. 1 is 1.5, and the other is 1.7. The way you store the variable to display, automatically shows only 1 decimal place and round the shown variable to the nearest position. So while the answer is 2.55, you'll see 2.6 (assume round up on 5). Well then what happens if you want to then divide that number by 1.6. If you don't store precision, you will divide 2.6 by 1.6 and get 1.6 rounded from 1.625. If you do use some extra bits to store precision, you will get 2.55/1.6 and get 1.6 still but the precise data is actually 1.59375. While this seems small, when you start working with really large numbers it becomes an issue. This is what can cause the judder as the calculations are causing numbers to be out because the precision data cannot be stored.

[Bambaataa]

 

So coming home from PAX on the bus (free WiFi), and browsing the Star Citizen subreddit I came across a post where someone asked what difference 64 bit floating point precision will make to the map sizes compared to the current 32 bit. I decided after being fooled once by someone, to actually investigate a little, and now I thought I'd post it here for those interested. I have changed the numbers I'm using (8k radius to 4k) just because I feel that 8k radius just seems too big for AC - and even 4k was pushing it IMO, as I haven't played AC om so long I'm not even sure if it might be too big too, but the general idea is the same.

 

 

Read in the spoiler for the text - contained it in there so the OP isn't massively long. Beware though, it is a wall.

 

First off, 32 bit (2³²) and 64 bit (2⁶⁴) IS the big difference you'd expect. In 32 bit floating point, values are made up of a sign bit, 8 bits for the exponent, and 23 bits for the fraction. General convention is to imply a leading 1 for the fraction. The image below does a good job showing this.

 

 

I'm not going to go about explaining how to convert this to a decimal value, there are plenty of Wikipedia articles and other sources where this can be explained properly if you're curious. The key thing to notice here is the range of values for the exponent of normal numbers is -126 to 127. This gives a signed range of integer values that can be stored of -2,147,483,648 to 2,147,483,647. Now I'm not going to go into the complexities of the actual issues, but with the map size limits ATM the judder on the controls CIG talks about when at the boundaries of the maps can be explained by not having enough extra bits to store precision, and when calculations are performed the answers aren't entirely accurate (missing some precision) because all the bits are being used already effectively (simple way of explaining). Now what is the advantage of 64 bit?

 

Similar to 32 bit, 64 bit floating point stores data with a leading sign bit, but it has 11 exponent bits, and 52 fraction bits. Just as with 32 bit, a leading 1 is implied for the fraction.

Due to the increase in bit size of both the exponent and the fraction, the range of values for the exponent of 64 bit normal numbers is -1022 to 1023. The signed range of integer values however is even crazier. It can range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807 otherwise known as pretty bloody huge. Now what does this mean for the maps?

 

Well if we look at the numbers we have, and the data that can be stored by the floats, we're looking at around 4,294,967,296 times the current map dimensions once the change happens, and a hell of a lot more space. If we take the general idea that the Cryengine is designed to support 8km diameter (4km from origin), and that's large enough to JUST fit Shubin ATM, then ROUGHLY the diameter of the 64 bit maps will be 34,359,738,638km (WTFBBQ!!!). Quite a jump. Now if we halve that to get the MAX radius, we still get 3x the distance from the sun to Pluto. So what will this do? It will allow CIG to create maps that are massive, and have plenty of room left to keep those calculations precise and accurate up to at least twice the distance of pluto from the sun (around 10b Km).

 

So lets assume now that they cut the world off at just over twice plutos distance, 12b km. This would still leave plenty of room for precision calculations. Also assuming they create space as a sphere, we would have a total volume of space at 7.24x10³⁰km³ or around 7,240,000,000,000,000,000,000,000,000,000km³. Now I don't think that CIG will make the space areas that large, and will probably make them significantly smaller seeing as hardware probably can't keep up. But the potential exists under 64bit to make the world so huge that they could simulate everything at scale sizes in 1 map if a computer could handle it. My guess for size is around 100,000km in length boxes all seamlessly joining together, but who knows... And this is just 1 system...

 

 

Do keep in mind that I am in no way an expert in this information, but that the general idea is that the maps can be bloody huge after 64 bit conversion of the engine is done and STILL maintain precision in calculations etc.

 

If I did something wrong, don't hate. I did most of the calculations on a bus bouncing on the road, after I'd been on it for 5 hrs already, after getting up at 5am, the morning after the SC event at PAX, and rewrote it just now at 11pm... so exhaustion. Plus I could just delete it all...

 

 

Very impressive math skills @danredda

 

Is there a bottom line or summary of your results for those of us who are mathematically challenged?  I read it 2x and still not sure I understand how big it is now and how big it will be after?

[danredda]

Very impressive math skills @danredda

 

Is there a bottom line or summary of your results for those of us who are mathematically challenged?  I read it 2x and still not sure I understand how big it is now and how big it will be after?

the general idea is that the maps can be bloody huge after 64 bit conversion of the engine is done and STILL maintain precision in calculations etc.

 

about a maximum of 4,294,967,296 times larger in each coordinate direction (X,Y,Z etc.) - That's if I did my sums right - although that would have quite some precision loss so they'd be likely to come in from that figure a bit to leave some padding for precision calculations.

[Valenquo]

Which is why CR talked about having a million kilometer wide maps. Because we can have coordinates in that order of magnitude right?

[Tallhart]

Very impressive math skills @danredda

 

Is there a bottom line or summary of your results for those of us who are mathematically challenged?  I read it 2x and still not sure I understand how big it is now and how big it will be after?

 

It's exponentially bigger. The maps at the moment are like a single drop of water compared to the ocean that will be unleashed with 64bit. 

[danredda]

Which is why CR talked about having a million kilometer wide maps. Because we can have coordinates in that order of magnitude right?

easily

[Bambaataa]

easily

 

Ah hahhhh, that huge number you threw out, i didn't understand if that was the max size or a multiplier.  Truly mind boggling to try and wrap my head around.  I thought the maps would be huge, but that sort of size is just.  Its just awe-inspiring.  

[Xenxs]

I didn't really have a good grasp on what the difference was between 32 and 64 bit. I knew the basic idea, but being mathematically challenged, it was hard to visualise it.

Untill now.

Mind = blown.

[danredda]

I didn't really have a good grasp on what the difference was between 32 and 64 bit. I knew the basic idea, but being mathematically challenged, it was hard to visualise it.

Untill now.

Mind = blown.

I was the same. I was curious in the past, and knew there was quite a difference (2³² vs 2⁶⁴), but I didn't think it would be THAT much of a difference when I did some sums. I ended up triple checking the numbers because I thought I did something wrong as I couldn't imagine it being that much. Again all this is potential sizes though, and will bring alone its own set of issues regarding hardware etc. among other things.

[Morgen Black]

Uhhhh.. from what I gathered with my primitive "rock throwing" brain is that it will get really, really big. Yeah.

 

That sort of thinking and math makes my brain hurt and my eyes bleed. Make it stop, oh make it stop.

 

Zero Null Cero

[WarWulf]

Very excited for double precision too, maps so huge that you could fit a moon or more.

 

Don't forget that the area will be cubic, which means we're talking volume rather than area for the size (ideally) many of you will know that 600 square metres is a much bigger area than 600 cubic metres (but it's still f***ing big!). Kinda. You know what I mean.

 

Great work Dan, great to see you at PAX mate, and looking forward to some insider news when you get back (?)

[Nevermore]

Think is most mmo's do the whole we need to make this run on as many computers as possible and it usually fails because you start to limit your self and cannot innovate 

 

where as SC/CR wants  somethings that WOW's you and shows "this is the future of gaming" 

 

Thanks for the post @danredda