I could not find a game that has modeled Earth completely (i.e., The entire planet and full round model). Does UE4 have a limitation, such as maximum map size, that limits modeling the entire Earth?

Edit: Context: The goal is to create a flight simulator using UE4 with centimeter granularity for modeling earth.

  • \$\begingroup\$ Considering a simple sphere meets your requirements, can you be more specific as to your goals? \$\endgroup\$
    – House
    Feb 5, 2016 at 22:20
  • \$\begingroup\$ UE can probably do it ... but the pc you'd need could be insane, as byte says ... more details are needed here \$\endgroup\$
    – War
    Feb 5, 2016 at 22:21
  • 1
    \$\begingroup\$ I'm voting to close this question as off-topic because it's not about game-development, but rather just about a functionality of a software \$\endgroup\$
    – MAnd
    Feb 5, 2016 at 22:40
  • \$\begingroup\$ Sorry for not being specific. The context is creating a flight simulator. So we are talking about centimeter granularity simulation of Earth. \$\endgroup\$
    – Ali Abedi
    Feb 5, 2016 at 23:20
  • 1
    \$\begingroup\$ earth to 1cm precision ... you got a spare few petabytes of ram to store that then have ya? \$\endgroup\$
    – War
    Feb 6, 2016 at 0:38

3 Answers 3


UE4 does not have exactly an inherent limit to what you can simulate at the engine. Nothing like a map size limit or something. However, besides the obvious memory and CPU hardware-limitations that a huge simulation might face, at least another indirect partial limitation related to software, i.e. in this case to UE4, does apply.

It is the fact that most engines like UE4 and Unity use float precision, instead of double precision, to calculate the position of vertices. That is one of the big difficulties in having large worlds. Very roughly speaking, as you move farther from the origin, the float variables that store X, Y and X loose precision. At the beginning, the result is negligible. When something (like a vertex of a mesh or an entire object) goes farther, the positional calculations get very noticeable, causing jittering.

To better understand why floats loose precision, read Why Floating-Point Numbers May Lose Precision and What Every Computer Scientist Should Know About Floating-Point Arithmetic. For a very introductory blog entry on how that affects the building of huge worlds in video games, read Size matters, and precision too. There are ways to circumvent parts of that problem. For more details on that, see my answers to questions Overcoming float limitations for planet-sized worlds in Unity and Is a custom coordinate system possible in Unity. Specially, see this academic article: Using a Floating Origin to Improve Fidelity and Performance of Large, Distributed Virtual Worlds for a quick review of both the problem and the possible ways to handle it.

  • \$\begingroup\$ Thank you for your comprehensive answer. I just wait a little to see if anyone else can think of any other limitation. \$\endgroup\$
    – Ali Abedi
    Feb 6, 2016 at 14:14
  • \$\begingroup\$ You can offset the precision problem by never using screen space coords in high ranges, basically "translate" from raw data position to a "relative to camera" position. \$\endgroup\$
    – War
    Feb 7, 2016 at 11:29
  • \$\begingroup\$ @AliAbedi Not a problem at all. Hope this was helpful in any way for you to grasp the main software-related issue for huge simulations. \$\endgroup\$
    – MAnd
    Feb 7, 2016 at 16:57
  • \$\begingroup\$ @Wardy that is pretty much the idea of the so called floating origin approach, described in the paper that I've linked to in the answer. It's indeed a good solution for many cases. \$\endgroup\$
    – MAnd
    Feb 7, 2016 at 17:05
  • \$\begingroup\$ @MAnd my point was that you talk about loss of precision which is basically a non issue if the coordinates in use are relative to the camera as opposed to the origin of the planet / dataset ... in other words your answer is simply "this can't be done accurately if done a particular way", i was just stating that the way you imply is not the only way to visualise the data ... think games like no mans sky, elite dangerous, ect ... they don't suffer from floating point precision issues when you go long distances because the rendered scene never needs such large numbers. \$\endgroup\$
    – War
    Feb 8, 2016 at 15:51

Let's see how big the heightmap of the earth would be.

For simplicity reasons, we assume, that the earth is a square, and has no overhangs.

The earths surface is 510 million km². If you only have 1 pixel for 1 km² (wich is not very much), then you would have an image with 510 million pixel, so a 22000 by 22000 image. That takes up quite a lot of space.

If you convert it to a mesh, then you have 510 million vertices, each has an x, y and z position. Both of hem are floats, so they take up 96 bit, 12 bytes. I don't think I need to do the math, to understand it.

  • \$\begingroup\$ Thanks for your answer. Current flight simulators such as Microsoft flight simulator model the entire earth with a resolution much better than a pixel per KM and they can do it. The trick is that only a very very very small portion of the entire earth is loaded for the current position of the aircraft. The model is defiantly at least 10s of GBs for sure, but it resides on disk not memory. \$\endgroup\$
    – Ali Abedi
    Feb 6, 2016 at 21:54
  • \$\begingroup\$ @AliAbedi Also, google earth has one. But let's be honest. That requires a pretty high internet usage, and that's not always available. \$\endgroup\$
    – Bálint
    Feb 6, 2016 at 22:15
  • \$\begingroup\$ Sure the amount of data is huge. Flight simulators are 10GB+ most of which is terrain data I think \$\endgroup\$
    – Ali Abedi
    Feb 6, 2016 at 23:16

This isn't feasible on todays hardware the main reason being the sheer amount of data.

Lets say for arguments sake that you only hold heightmap data and "on the fly" load texturing information from another source like google maps (assuming thats even possible) ... based on what wolfram alpha has to say ... https://www.wolframalpha.com/input/?i=surface+area+of+earth

... earth is roughly 510 million square kilometers ...

So lets assume at any point in time you only need to render about 1 km square (extremely low distance range for a plane in the real world) from your height map at any point in time ... what is your resolution of the height map?

assuming 1 point every km2 we would be storing 510 million y values (floats) then we just map as a uniform grid ... that's a reasonable set of data, 510 million x 4 bytes = 2.2 billion bytes so you need 4 points just to get the area you plan to draw and you need to query a set of data roughly 2GB in size "realtime".

Ok I've seen some smart querying before stuff like Unlimited detail engine can do something like that, but that's only getting us the 4 corners of our map.

Now lets add some detail:

realistically for our flight sim we want at least a detail level of say 1 height point every 10 meters so that 1km height map now becomes 100 times bigger.

so ... for a very (and i mean VERY) low poly representation of earth we need about 200GB of data stored on our hard drive then a search algorithm that can pull a roughly 100 x 100 grid from that low res data in realtime to support the high speed moving of the aircraft.

DISCLAIMER: i don't what you want to build exactly but here goes an assumption ...

Taking a typical plane in to consideration air speeds will be for a boeing 747 about mach 0.8 or 920 km/h according to wikipedia ...


... so doing the math thats about 255 meters per second so you are crossing over a single 10 meter square quad in your extremely low res heightmap about every 0.025 seconds.

A typical game needs to render a frame every 0.016 seconds to achieve a frame rate of 60 fps.

So as a minimum you need to be able to do the following every 0.016 seconds to render a view of earth at a resolution of 10 square meters per point and keep up with your aircraft ...

  1. flush out data no longer needed because its behind your plane
  2. lookup from a subset of 200GB of height map points on a hard drive the set of points you need to populate the new edge verts of your map.
  3. build the new mesh info
  4. query google for new image data
  5. upload the new data to your gpu
  6. render the frame


A typical web request on a very good internet connect for a texture will come in at around 100ms so using google as a source of the texture data is not an option.

So how good you want your game to look, at resolution of 1 pixel per meter you need to store a colour value for 10X the number of points in your map, colour values are usually 3 floats so 12 bytes so 200GB x 10 x 3 is the amount of storage space you need locally to store your textures ...

so lets assume you have the 6TB needed to store your 1 pixel per meter textures to really get down to the final solution ...

using caching and read aheads to prevent bottlenecking in this whole process you're going to need to be able to build data for at least 2 edge rows of your map every frame with no latency across a dataset of 6.2TB to get the worst looking flight sim on the market up and running.

Oh dear ...

Now assuming your aircraft only ever flys at a height of say 10km up this might be considered reasonable but then for the plane to even see any ground you need to render further out to the horizon so the problem then gets worse.

How the big guys do it ....

They cheat, they only have data for key objects like central city areas or around major airports, in between all that is just "noise" or a repeated "green texture".

They also just provide maps for a small area.

So ... taking your question, how feasible do you think this is at 1cm accuracy?


That said, i'm trying to do similar with voxels (think minecraft) but my advantage is im using the gpu to automatically generate a portion of a random planet using noise functions, which actually is possible on todays hardware for example: http://libnoise.sourceforge.net/tutorials/tutorial8.html

Given that a typical GPU these days has a throughput of terabytes every second all is good but getting raw static data from hard drive to the screen when the static dataset is so large will most definitely require hardware way better than what is typically available today.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .