2

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.

Ali Abedi
  • 41
  • 1
  • 4
  • Considering a simple sphere meets your requirements, can you be more specific as to your goals? – House Feb 05 '16 at 22:20
  • UE can probably do it ... but the pc you'd need could be insane, as byte says ... more details are needed here – War Feb 05 '16 at 22:21
  • 1
    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 – MAnd Feb 05 '16 at 22:40
  • Sorry for not being specific. The context is creating a flight simulator. So we are talking about centimeter granularity simulation of Earth. – Ali Abedi Feb 05 '16 at 23:20
  • @MAnd It is actually about game development. The context I am talking about is flight simulation such as war thunder. – Ali Abedi Feb 05 '16 at 23:24
  • 1
    earth to 1cm precision ... you got a spare few petabytes of ram to store that then have ya? – War Feb 06 '16 at 00:38
  • @Wardy it is not needed to load the entire Earth from the disk, just the area the aircraft is at now. – Ali Abedi Feb 06 '16 at 02:33
  • @AliAbedi I answer what the biggest UE4-related limitation is. Considering you comment above, you should also look for the method for loading/tessellating chunks of terrain on the fly, a technique usually used for LOD, but that might be helpful in what you seem to be searching for/ – MAnd Feb 06 '16 at 02:56
  • @Ali i don't want to sound negative here but I don't think you realise that the problem is not the rendering it's gettting the data there in the first place (see my answer for more details) – War Feb 07 '16 at 11:24
  • Unreal uses 32-bit float single-precision numbers which can only go up to a few km without losing acceptable precision. For modeling the surface of a planet with high precision, you need 64-bit double-precision numbers. – Aaron Franke Nov 19 '18 at 19:24

3 Answers3

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.

Community
  • 1
MAnd
  • 4,887
  • 3
  • 22
  • 42
  • Thank you for your comprehensive answer. I just wait a little to see if anyone else can think of any other limitation. – Ali Abedi Feb 06 '16 at 14:14
  • 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. – War Feb 07 '16 at 11:29
  • @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. – MAnd Feb 07 '16 at 16:57
  • @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. – MAnd Feb 07 '16 at 17:05
  • @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. – War Feb 08 '16 at 15:51
  • Maybe this explains it better: http://gamedev.stackexchange.com/questions/110335/overcoming-float-limitations-for-planet-sized-worlds-in-unity?lq=1 <-- im saying this is not the problem – War Feb 08 '16 at 16:15
  • @Wardy At this point it's clear that you didn't read my answer carefully. In my answer above, I myself linked to the same link you now sent me (and btw I have an answer at that link too...). It means, I myself have pointed to the exact same solution (among others) you now seem to wanna make me aware of. That said, of course floating inaccuracy is the big issue in almost any engine when it comes to creating huge worlds. It just does not mean that work-arounds are not available: again, as I myself have pointed before you and you didn't read with due attention. – MAnd Feb 08 '16 at 18:14
  • @MAnd as I said in my last comment ... floating inaccuracy is NOT the big issue here, you point at my lack of attention to detail then fail to read literally the last 3 words I wrote ... you're completely focused on the wrong problem here – War Feb 08 '16 at 19:53
  • @Wardy Again: trying to prove your point, you linked to a question that I had already linked and to which I had an answer saying the same! And you mention a solution that I myself have linked to before in my answer here! Lastly, it's so clear I read those 3 words of yours, that I even addressed then: I disagreed. Besides hardware (which I mentioned too), floating inaccuracy is, yes, one of the biggest software-related issues (which is what OP asked about). But it surely can be dealt with, as I have also made clear in my original answer from the beginning. – MAnd Feb 08 '16 at 20:08
  • Let us continue this discussion in chat. – War Feb 08 '16 at 20:14
  • Never mind ... well done for solving a problem that Ali didn't ask about nor does he have. – War Feb 08 '16 at 20:17
  • @Wardy I disagree. Dealing well with floating inaccuracy is an important subject on how to tackle software-limitations when implementing large environments. To the point that there is nice literature on that. One of the academic references I pointed to in my answer. I recommend people to read the links I linked to. That said, I very much think the OP was referring to those software-related issues, rather than hardware-related issues, when asking "Does UE4 have a limitation, such as maximum map size, that limits modeling the entire Earth?". But we both already made our points. – MAnd Feb 08 '16 at 20:35
  • He already stated he had no intention to get the whole model in memory / in scene so the problem was how to render a cut of the data, taking that in to consideration the question was about building an area of terrain from the larger dataset, in such a situation you would (if designed right) never have any need for floating point values so high as to hit your problem ... thus ... you solved a problem he didn't have. – War Feb 08 '16 at 20:38
  • @Wardy I answered what OP asked for, not what someone thinks OP should'd asked for. And I don't think you both quite understand how this implementation works or read what I've linked to. Even reading only chunks of the data, he would have problem because floating inaccuracy results not from distance only but from discrepancies in scale (and OP mentions tiny granularity). Not to mention the problem of how to only work with 1 chunk without caring with distant scenery. So, yes, 1 of the software-related issues the OP might need to handle is floating inaccuracy. But again, we've made our points – MAnd Feb 08 '16 at 20:49
0

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.

Bálint
  • 14,887
  • 2
  • 34
  • 55
  • 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. – Ali Abedi Feb 06 '16 at 21:54
  • @AliAbedi Also, google earth has one. But let's be honest. That requires a pretty high internet usage, and that's not always available. – Bálint Feb 06 '16 at 22:15
  • Sure the amount of data is huge. Flight simulators are 10GB+ most of which is terrain data I think – Ali Abedi Feb 06 '16 at 23:16
0

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 ...

https://en.wikipedia.org/wiki/Boeing_747

... 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?

EDIT:

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.

War
  • 1,683
  • 1
  • 18
  • 33