So, I made some calculations on the bandwidth required to stream orthoscenery in real time, given the following hypothesis:

.) At initial loading, the scenery is loaded in rings of decreasing resolution. The inner ring has a given resolution (e.g. ZL18, ZL17, etc.) and a radius of 5000ft (about 1 mi / 1.5 km), and outer rings have progressively lower zoom levels; the radii of outer rings have been chosen to ensure a roughly constant visual resolution (i.e. skewed, distant terrain requires progressively lower ZL than the terrain underneath the aircraft, for a given visual resolution).

https://drive.google.com/file/d/1-dPBW4CWwDPiQgHTEJEIfkbCMiwyjeGT/view?usp=drivesdk

.) After the aircraft takes off and moves in space, slices of new scenery are loaded (in different resolutions) along the route.

https://drive.google.com/file/d/1-ZswSGsOOjPYFeHtY_cOZUTvRRZ6J-z9/view?usp=drivesdk

.) Above 5000 ft, all the rings expand in radius (to account for increased visibility), but the zoom level used in each ring decreases one step (to account for increased altitude). So the inner ring goes e.g. from ZL18 to ZL17, the next ring goes from ZL17 to ZL16, and so on.

https://drive.google.com/file/d/1-Z2NKqanBOqBEiq6QzBZ3C9qTHjw-NhX/view?usp=drivesdk

.) The ZL of each ring decreases once more above 10000 ft, and then again above 20000 ft, to account for increased altitude (i.e. you don't need ZL19 when flying at 20000ft).

.) The required bandwidth is calculated on these flight profiles (figures are rounded to simplify calculations):

5000 ft, 85 ktas (low and slow aircraft, helicopter);

10000 ft, 170 ktas (fast GA);

20000 ft, 340 ktas (turboprop);

40000 ft, 680 ktas (airliner with very strong tailwind);

Given these hypothesis, here are the results:

.) About 26 Mbps are required to have an inner ring resolution of:

ZL19 up to 5000 ft
ZL18 between 5000 and 10000 ft
ZL17 between 10000 and 20000 ft
ZL16 above 20000 ft.

.) About 6.5 Mbps are required to have an inner ring resolution of:

ZL18 up to 5000 ft
ZL17 between 5000 and 10000 ft
ZL16 between 10000 and 20000 ft
ZL15 above 20000 ft.

In both cases, the initial loading of the scenery in the sim should take around 60 seconds.

Some important points:

.) I only accounted for the streaming of terrain textures (orthophotos). Other elements (3D objects, terrain mesh) are not accounted for. However, mesh can be already stored locally. And 3D objects (trees, buildings) should have a required streaming bandwidth that is an order of magnitude less than terrain textures. If you think about it, most of the pixels of what you see in the sim are terrain; and the most part of orthophoto packages of current sims, in terms of disk space, is terrain textures.

.) The above mentioned rings would actually be made of many little square tiles approximating the shape of a circle (infact orthophotos are square tiles), so they are not perfectly circular rings, and this inefficiency would increase a little bit the actual required bandwidth.

.) The bandwidth/zoom levels data are valid when flying near the equator; for higher latitudes, the bandwidth increases for a given zoom level, or equivalently the attainable zoom level decreases for a given bandwidth; so, e.g. at +/-60 degrees latitudes, the attainable zoom level is one notch down (26 Mbps: ZL18 up to 5000 ft; 6.5 Mbps: ZL17 up to 5000 ft, etc.).

.) The calculations are valid for the mentioned flight profiles; higher speeds, zoom climbs or rapid descents would require a higher bandwidth.

Given these findings, I think there is the possibility that MFS will allow real time streaming of orthophoto scenery.

Or maybe I made some big blunder in some calculation and MS will disprove all of this in the next update. 😉

Edited September 6, 20196 yr by Murmur

10 minutes ago, Murmur said:

I only accounted for the streaming of terrain textures (orthophotos). Other elements (3D objects, terrain mesh) are not accounted for. However, mesh can be already stored locally.

Could be, but that's still a lot of data if the mesh is high resolution. Which I think we want. 

For example, consider the the optional/free HD terrain mesh for X-Plane. I have 19 of those HD files on my drive, averaging 0.8 GB per file. They're not all the same size, some have more water area but that's an average.

The HD files aren't available for the whole world, but they do cover the popular flying areas of North and South America, Europe, Northern India, and Japan. If I had the entire package, and based on that average file size, it would come to something like 80 GB stored locally. If the HD files covered the rest of the world -- New Zealand, Greenland, sub-Saharan Africa, the Middle East, China, Russia, and part of Southeast Asia, it could possibly double to 160 GB. That's a pretty big file size for a local installation.

Of course the MSFS scenery mesh may not be comparable, but data can only be compressed so far, and I'm hoping the terrain mesh in the new sim as at least as good as the optional HD mesh in XP11. It does make a difference in accuracy of coastlines, riverbanks, and detailed mountains. If it were as tight as the optional UHD mesh it would be even better! But there are RAM considerations there, with 32 GB of system RAM recommended for the UHD mesh. 

Anyway, this is a long-winded way of saying that if we assume the new MSFS uses a streaming model for scenery, I think the terrain mesh data would probably be streamed along with it, and not part of the local client installation. Which of course will affect bandwidth requirements.

I spent months running tests of server based flight sim data (everything, and I do mean EVERYTHING) transmission from various places around the planet, for a service that never came to be because it was eclipsed by Microsoft's Announcement.  The only time I started to see issues was streaming from Germany to South Florida (which would not normally be done), and that was likely a brief Internet issue. MFS2020 Servers are going to be located most everywhere (they already are), eliminating the issue I saw - and saw only once.

It's just not a problem guys, and if it was, MS wouldn't have announced it.

My very best wishes.

 

Thanks for working on this and sharing it.  I'm not familiar with the ZL resolutions so not sure if ZL18 up to 5000ft would be good enough, but if it is then streaming this would be feasible for most folks I think.

It's also possible that the new sim will simply adjust the resolution dynamically based on the connection speed, much like some video streaming devices and services do now.  So those with slower internet connection speeds will be able to use the sim albeit with lower resolution terrain textures.

Dave

2 hours ago, Paraffin said:

Anyway, this is a long-winded way of saying that if we assume the new MSFS uses a streaming model for scenery, I think the terrain mesh data would probably be streamed along with it, and not part of the local client installation. Which of course will affect bandwidth requirements.

I doubt MFS will have a mesh resolution comparable to UHD for XP. I still think that a good worldwide resolution can be stored locally. But maybe you are right and it will be streamed instead. Even a high mesh resolution will still be about an order of magnitude less than textures in size though. So it could increase the bandwidth requirements, but not very much.

14 hours ago, DaveCT2003 said:

MFS2020 Servers are going to be located most everywhere (they already are), eliminating the issue I saw - and saw only once.

Having local servers would only affect latency. Bandwidth is still probably the major factor even if you're next door to the server. 

Edited September 7, 20196 yr by vortex681