Blogs

Google post

  • Comments 64
  • Likes

I can't remember the most recent time I've seen this posted (or where), but I've seen it crop up a bit in the major Flight Sim forums:

Microsoft should use Google Earth for Flight Simulator.

 Leave aside for the moment the fact that Microsoft has a rival product gaining steam, the point is people like the idea of highly detailed and accurate satellite imagery-- especially of the sort Google Earth provides-- all streamed over the internet.

At first blush it sounds pretty cool, yeah?

"There's my house!" (speaking of the here's my house thing, check this link out for the ultimate in here's my houseness)

"There's Grandma's house!"

"There's the The Champs Elysées!"

"There's Yasgur's Farm!"

And so on.

I've been a fan of Google Earth when it was still Keyhole, and I think what we're doing here is pretty cool too. Having been involved with scenery/terrain design for multiple ACES games studios titles, I'd be really excited to see streamed satellite imagery appear in Flight Sim (although it could apply to just about anything if done right...), but truthfully I think people underestimate the problems the idea presents. To be clear, none of what I'm about to list are unsolvable, but they do present a barrier to implementation. The list below is not comprehensive, just what came off the top of my head:

1. There's not full coverage of the globe yet.

   True, you wouldn't need to have *everything* to make it happen, but I can already read the e-mails when it turns out (fill in the blank here of your favorite spot on Earth) isn't in the product... This means that you'd have to have some sort of hybrid between what you do have covered and some sort of generic default. This currently works in Flight Simulator (witness VFR scenery, here too, Megascenery, etc.), with specific locations, but not streaming. The progress on what is available changes daily, and I can say that I'm amazed at what's available now as opposed to even just 2-3 years ago...

2. What is covered is inconsistent in color, quality, and season.

I believe that the joy of flying over highly accurate real world imagery would be offset by the immersion break of flying from one inconsistent area to the next, and that it would happen pretty fast. I think people are way more forgiving of a how Google/MSFT might use imagery for mapping versus how they would view it's use in a game/sim. To get consistency you'd have to have a massive effort of color correction/adjustment, or a freakishly advanced automatic system.

3. No good night imagery exists.

At least that I'm aware of. And when I mean good, I mean same level of detail as day stuff. Which means that you'd have to come up with a good way to fake it. (like Megascenery)

4. All the time information is stamped into the image.

Flightsim, for example, ships with Spring, Summer, Fall, Winter, Hard Winter, and Night variations of our landclass textures. We drape these textures over DEM, light them, and render shadows into the terrain. Much aerial/satellite imagery has lighting from when the image was taken already present-- strong lighting too. This makes for great screenshots, but it does mean that you'd lose one of the neatest things about Flight Sim-- we model the march of time: leave your computer running Flight Sim, and you'll see seasons and time of day change. To replicate that with Google Earth Tech, you'd have to increase the amount of imagery by at least 5X, *and* start to track time of day/seasonal change.

5. Autogen tech isn't designed for massive aerial/sat scenery

Right now autogen tech works pretty well for what it was designed for: default scenery and small (100-400 tile) imagery areas. But as many 3rd party imagery people'll tell you, there's not enough "auto" in autogen. :)

There are mechanisms that can be used to generate buildings and the like, but designing and implementing such a system to do what is necessary in Flight Sim is not a small task.(scroll down the page)

6. Streaming, like that used in Google Earth is not a magic bullet approach for imagery display.

Even when all it's doing is displaying imagery, it's easy to get the "blurries" in Google Earth. Tack on a lot of other systems and simulation stuff, and... well... if you think it can get bad in Flight Sim...

 

Let me reiterate: I think the tech and potential results are very enticing, and the problems above are are solvable in one way or another.

I've linked throughout this post to some great large scale imagery solutions available already for Flight Sim, so you can see the possibilities in action. And I should note: this is something we look at periodically. Jason Dent and I talked a few years ago about what it would take to do aerial imagery for the planet at 8 meters per pixel (Flight Sim currently uses a resolution of approx 4.8 meters per pixel), and we came up with a figure of around a terrabyte (for just one season/time of day, if I remember right). Sounded pretty bluesky in 1999 (when Jason and I first talked about it), but way more doable now. Technology changes pretty rapidly these days, so who knows?

It would be neat to see my house...

 

Comments
  • Hmm ok, I wouldn't like Google watermarks on the terrain each and everywhere anyway.

    I don't think that the future of flightsimulation lies in sattellite imagery (SI).

    Well, I don't think though that seasons and night-lighting would be a big problem - I think you could simulate seasons with contrast/gamma/hue scrollbars, even in the pixel shader.
    The biggest problem for me is the fixed lighting. I mean - we have people toying around with things such as irradiance, GI, PhotonMapping and whatever in the shader, because PerPixelPhongShading isn't good enough any more. Now with SI, you don't even have correct phong shading. This simply doesn't sound like the long-term future.

    The vector-data approach has much more potential to beautify the long-term future.
    Imagine you had a very good ('perfect') road dataset: given the fact that every building can be reached by a road, you would result in pretty accurate building-placement, if you populated the road-edges with autogen-buildings (when combined with some other datas like population, so you don't have buildings in death valley). If you combined that with an accurate dataset of forrests and crops and SRTM3, you would result in a pretty perfect representation of the world, and much much smaller than SI.

    As slightly mentioned above, the trick lies in combining different datasets and stochastically analyze the environment at a given point. The textbook example is probably to convert a surface to rock/cliff when the terrain-slope exceeds a threshold, however one can take many many more factors into account. There is a <a href="http://www.global-scenery.org/" target="_blank">'rival product'</a>, which - honestly - does that in a very impressive way, at least according to the screenshots. Yeah, I'll still fly my PMDG738 in MSFS world, but honestly, I think this global scenery is some years ahead of MSFS.

    By the way: I think an important visual clue would the integration of normal maps into the terrain, look at <a href="http://www.airliners.net/open.file/915581/L/" target="_blank">this picture</a>. I always ask myself where the difference is, that the FS lacks when looking at real world pictures. In this shot - I think - it's pretty evident, that it's the complex curvature of the terrain and the corresponding lighting. Normal maps would help to reproduce this.
    Well, I know why there is no normal-/bumpmapping in MSFS: it would require a second render-to-texture for the textured ground-polygons when rendering to the tile-layers, and that would be overkill (yet).
    But as this is an important visual clue, this probably might be a medium-term feature to implement.
    It would be sufficient to render normal maps when flying at low altitudes and only for the tiles that are close to the PoV.
    Another shortcut would be to store terrain elevation pertubation in the alpha channel and extract the normal in the pixel shader by doing 5 alpha lookups and calculate the slope/normal from them.

    Looking at the short-term goals, I think one should introduce worldwide SRTM3 instead of GTOPO/SRTM30 in the default scenery. This is a little task compared to worldwide SI.
    Another goal is to find better solution for following puzzle:
    [x] Let river float uphill.
    [ ] Modify river to follow fixed terrain.
    [ ] Modify terrain to follow fixed river.


    Ok, never mind me spamming this blog. I'm myself much into programming/FS, so I'm used to spend sleepness nights on the technical future of flight sims.

  • Andreas,

    Thanks for the long thoughtful post.

    For those wondering what the acronyms are here's a quicky; (SRTM)= Shuttle Radar Topography Mission, and the various flavors reference detail: 3 is better than 30.



  • Hello,

    just thought I'd comment something about this post as well ;)

    I agree with Andreas that X-Plane's Global Scenery is awesome especially for the rocky, mountainous areas, but in the cities, it's still not that... Roads are cut in some places and even though the general impression is here, I don’t feel like it’s the actual thing…
    I mean, I fly a lot over Mega Scenery Titles (www.megascenery.com) and I just love it !
    I like to fly over scenery I can recognize, and I'm glad I can re-live the experience I had back in the Flight Unlimited days.
    Of course, like you say Jason, the imagery should NOT come from some raw data right from the satellites, but filtered data with the same shade of colors *everywhere*.
    About the size, sure, Mega Scenery titles make my FS directory weight something like 20/30GB of data but I don't care and below is why :)
    I think this Satellite Imagery / Generic Imagery is depending a lot on the way users fly. I like to fly short flights in Cessnas, Pipers, so a limited coverage of high detailed satellite imagery is just fine by me. On the other hand, I totally understand why generic textures are mandatory when flying heavies for long distance flights…

    Anyways, I sure hope that some day generic scenery will render something like the screenshots here : http://white-clouds.org/FlightSimulatorGallery.aspx?GalleryName=~/Gallery/FlightSimulator/MegaCity/

    Happy Landings and Happy New Year !

  • Hi Pixelpoke,

    here are my comments to your list of problems of a potential special VirtualEarh scenery server for FSX :

    1) No full globe coverage: The Server should have a map similar to the landclass info. Each square would have a number specifiying the qualitiy level of VirtualEarth images for that spot. The FSX user specifies at what qualitiy level the FSX engine switches from classic scenery to Virtual Earth scenery or back.

    2) Inconsistent qualitiy: See 1)

    3) No night images: i only fly during the day. When i fly during night its too dark anyway.

    4) No seasons: I prefer flying in spring or summer anyway. I can use classic scenery then.

    5) Autogen: is turned off anyway, until DX11, NVidia 9xxx ad Quadcore 5 GHz or so ..

    6) No magix bullet: Well, yes. But its sooo much fun. Its not about either classic scenery or VirtualEarth. FSX (or FS 11) should support both, and let the user decide when and where they want to use classic vs aerial photo scenery.

  • zaxos lopufulo gikma

    <a href="http://ze501693.yc4akly.info/sitemap18.html ">tihu</a> http://ze501693.yc4akly.info/sitemap18.html [url=http://ze501693.yc4akly.info/sitemap18.html ]kyvi[/url]  hulix

  • zosos xofejuxe gokma

    <a href="http://mu777388.gl1bdvd.info/sitemap14.html ">kecy</a> http://mu777388.gl1bdvd.info/sitemap14.html [url=http://mu777388.gl1bdvd.info/sitemap14.html ]puba[/url]  pavit

  • bupos juhygyzo gokma

    <a href="http://ga684545.yo1l9a8.info/sitemap4.html ">zuzy</a> http://ga684545.yo1l9a8.info/sitemap4.html [url=http://ga684545.yo1l9a8.info/sitemap4.html ]xytu[/url]  gogap

  • hugos punebuwo gakma

    <a href="http://xa364751.smlj3eb.info/sitemap5.html ">kulo</a> http://xa364751.smlj3eb.info/sitemap5.html [url=http://xa364751.smlj3eb.info/sitemap5.html ]gumy[/url]  kitiv

  • vikos kavicaxa gakma

    <a href="http://ly237231.yo1l9a8.info/sitemap10.html ">homa</a> http://ly237231.yo1l9a8.info/sitemap10.html [url=http://ly237231.yo1l9a8.info/sitemap10.html ]sose[/url]  mydug

  • renos pyvyfugi gekma

    <a href="http://gi569414.ocgwoc0.info/sitemap16.html ">sute</a> http://gi569414.ocgwoc0.info/sitemap16.html [url=http://gi569414.ocgwoc0.info/sitemap16.html ]vyxu[/url]  sidun

  • nysos hobaseco gikma

    <a href="http://ma412516.yc4akly.info/sitemap3.html ">nuju</a> http://ma412516.yc4akly.info/sitemap3.html [url=http://ma412516.yc4akly.info/sitemap3.html ]pive[/url]  xuzin

  • kucos xukebemy gekma

    <a href="http://ce833975.rfwoedc.info/sitemap6.html ">jyzu</a> http://ce833975.rfwoedc.info/sitemap6.html [url=http://ce833975.rfwoedc.info/sitemap6.html ]woba[/url]  syxyt

  • xezos gemawisa gikma

    <a href="http://cy270213.dicxekz.info/sitemap3.html ">vilu</a> http://cy270213.dicxekz.info/sitemap3.html [url=http://cy270213.dicxekz.info/sitemap3.html ]roxy[/url]  civex

  • gibos mihegete gukma

    <a href="http://fo945937.gl1bdvd.info/sitemap15.html ">xyge</a> http://fo945937.gl1bdvd.info/sitemap15.html [url=http://fo945937.gl1bdvd.info/sitemap15.html ]doze[/url]  nodyv

  • jucos goxifosa gukma

    <a href="http://xe496665.sgov5jk.info/sitemap12.html ">hugi</a> http://xe496665.sgov5jk.info/sitemap12.html [url=http://xe496665.sgov5jk.info/sitemap12.html ]gupo[/url]  cehib

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment