New project: Tile server for MS FSX based on Google Map...

[Guest cbuchner1]

Hi everyone!I had a cute idea that I decided to try to "make it happen". I am going to implement a tile server for Flight Simulator X in the form of a proxy that mediates between Google Maps satellite imagery and FSX. FSX will use some predefined custom scenery that points to tiles on a mounted network drive. All tiles are assumed to have known filenames from which the coordinates can be derived. I will start out with a very limited, rectangular area first. Later I might try to cover larger areas, maybe even whole continents.The network drive serving out tiles is connected through the SMB protocol and is provided by a Linux or Mac. I currently use a Mac Mini because I have one available. The Mac Mini runs a Samba server, compiled from source code. It provides read-only access to a volume initially containing just an empty folder. Samba will be configured to use a Virtual File System (VFS) driver that intercepts incoming file I/O operations. When a tile filename corresponding to a certain coordinate is first opened, it will open a HTTP connection to the Google Maps tile server and download the resulting 256x256 pixel image. This image would be converted into a format suitable for Microsoft Flight Simulator X and then is served like a regular file. It will also be cached in that folder such that subsequent read operations do not have to load this data again from Google.I see the following issues popping up:* the VFS driver for Samba has to be developed (C/C++) and tested* the initial transfer from google would drastically delay the MS FSX loading of the scenery. I assume MS FSX reads sequentially, not multiple tiles in parallel.* how can I align the Google tiles at various zoom levels with the coordinate system of MS FS X?* what is the best tile format to use? Megascenery used uncompressed BMP images, is that feasible?* a 1 GBit/s LAN would be nice to get good throughput between Tile Server and simulator PC once the tiles are cached.* One season of the year only. Google-season!* No night scenery available also.I will keep everyone posted on the progress of this project. So far I have Samba compiled and working on a Mac Mini (which is quite an achievement on its own). Will start experimenting with VFS drivers soon.Christian Buchner

[Guest Derek D]

Interesting, but how will you get around FS's inability to update its scenery while it's running?

[mgh 89]

And how will you get round the legal restrictions on the use of Google images?

[Guest cbuchner1]

FSX would first load all tiles to form the Quadtree of various detail levels around the user. see this link for a visualization of the Quadtree:http://www.fsinsider.com/NR/rdonlyres/5D22...alTerrain04.jpgWhen you move around, it re-loads existing tiles at different detail levels (LOD mipmaps). And this would result in more hits to my network drive - probably loading from cached data if it's just a higher detail version of an existing tile.

[Guest cbuchner1]

I will build a prototype first (for limited personal use), but not publicly release it without actually clarifying the legality aspects.If you understand FSX as a "web browser", the network drive as a "proxy server", it would not appear illegal. In fact, there should be some gauges out there that provide web browsing ability in the glass cockpit. And a true web browser is built right into the FSX shell - when you access the fsinsider.com from the main menu!As far as I understand, Google Maps explicitly prohibits the use of "robots" to access the data. The flight simulator does not constitute a robot because it provides interactivity. It only loads tiles around your current location - not the entire world.enjoy the following legal (!) Google Maps Flight simulatorshttp://www.isoma.net/games/goggles.htmlhttp://www.markfennell.com/flash/wings/index.phpI understand this thing as a proof of concept - and a lot of technical issues have to be solved before even the first HTTP request to Google's servers is made. Initially I might even use my own HTTP server to make sure I don't put load on Google's servers during development.

[Guest cbuchner1]

Allright folks! Progress on this project!So I completely dumped the new RESAMPLE tool from the FSX SDK. Too complex, no way to change the textures on the fly inside the generated BGL file!The .bmp phototerrain texture tiles used in many FS2002 and FS2004 addons however are in DXT1 format and contain 7 mipmap levels. I figured out the file format and I also found a fast (and free) DXT1 encoder source code which is very fast (Intel SSE2 optimized)The file naming scheme of the BMP tiles of these photo terrains is based on a quadtree notation, and I found a way to convert these filenames back into lat/long coordinates. The resolution (for now) is limited to 4.75m/Pixel (LOD 13)I figured out a way to tap into the Google Earth tile server by means of "libgefetch", part of the open source GAIA project, a reverse engineering project by a Russian programmer. This gives me "on demand" access to tiles without any Google imprint or logo. I wrote some code to retrieve the correct Google Earth tiles (based on lat/long coordinates) which then have to be concatenated, then cropped out and scaled to become a photo scenery tile for FS X (or 2004).The major work that remains is:Decoding of downloaded Google JPEG imagery in RAM using libjpeg, concatenate, crop out and stretch tiles, downsample to various mipmap levels, DXT1 encode and write out to file. This is a proof of concept hack only and will probably not see public release anytime soon. That Russian dude already got threats by Google Inc. - because they are not evil! I will post screenshots though of me flying over the Google Earth, promised ;-)Christian

[Guest cbuchner1]

Here is a side by side comparison of a MegaScenery LA tile and one which I downloaded, cropped and compressed using my project. Note the difference in quality, allthough the resolution in pixels is identical (~4.75 m /pixel). The top image is MegaScenery LA, the bottom one is Google Earth. Both tiles are already DXT1 compressed, ready for use in FS 2002, 2004 and FSX

[Guest cbuchner1]

Mission accomplished! Flying over the Google Earth in a Mooney Bravo. The location is San Diego, you see the old baseball stadium (Qualcomm Stadium) in Mission Valley and a shot of Mission Bay in the images. The freeway below would be Interstate 8.The tiles are loaded *on demand* when you move around. Loading of tiles IS TERRIBLY SLOW. Before the simulation started I had to wait for one hour downloading tiles. The tile resolution is 4.75m/pixel (LOD 13). Tiles are automatically downloaded and converted to DXT1 compressed BMP by a virtual file system layer inside Samba.http://forums.avsim.net/user_files/162129.jpghttp://forums.avsim.net/user_files/162130.jpgNow I understand that the russian dude got served a nastygram by Google because no-one else is allowed to interface with the Google Earth imagery with a client other than the official Google Earth software. It is simply a licensing restriction imposed by the providers of the sattelite imagery. Bummer!So I am going to write different backend modules for my Samba based tileserver - for example USGS data or maybe I can even switch to Google Maps (not Earth). I can't keep using Google Earth, although it was fun while it lasted ;)Christian

[Guest KaelOost]

Hang on.So you've made a program that replaces default texutres with Google Earth satelite immages? Is that correct? Thats fantastic!!! Actually flying over things that actually exist!! I can spot my own house?I'm all for it. How bad is the loading time in flight? What sort of internet bandwidtg would that use??

[byork 2,258]

Wow, this certainly makes things interesting.Bryan

[Guest cbuchner1]

Well, after about an hour of flight I can say "I love it". The quality of the imagery beats the MegaScenery package hands down. I marvel at the beauty ;-)The link between the tile server and MS FSX is a 100 MBit/s ethernet and it keeps pushing tiles at a rate between 4-10 MBytes/s while flying. These tiles are mostly cached on hard drive already. The download from the Google site is much slower ( my DSL caps out at 3 Mbit/s and each HTTP request has to cross the Atlantic - the ping time appears to be ~25 ms - likely by sea cable ). When I fly within a region that has already been cached by my tile server, Google barely gets any HTTP requests for new tiles. I think I can say that the bandwidth I have used on google's servers today is less than if I would be watching a 90 minute movie off video.google.com.The problem I currently face is that I have to stay within the region for which I already own (commercial) photoscenery based on 256x256 pixel BMP tiles. I have no BGL scenery files that tell the simulator that there is photoscenery outside the region. So I will have to create some photo scenery definitions of my own to cover the entire globe - or at least the continents I want to fly on.I wonder if a fully global coverage of photoscenery would slow down the flight simulator to a crawl? I shall test that soon!Christian

[MillKa 0]

Hi Christian,a few links that might be useful ...- NASA Worldwind is similar to GoogleEarth, but its open source and uses public data: http://worldwind.arc.nasa.gov/- Google Maps SDK: http://www.google.com/apis/maps/- Microsoft Virtual Earth SDK: http://dev.live.com/virtualearth/sdk/I would try MS Virtual Earth first, cause maybe you can talk MS into giving you a special license for MS VE access if its used for an addon to MS FSX ...Maybe a different approach for loading the tiles would be faster:Instead of hooking into the load file calls of FSX, you could monitor the aircrafts position and heading using SimConnect to retrieve and convert the tiles even before FSX actually loads them.

[Guest cbuchner1]

Thanks for your insights!One question though: Is the SimConnect SDK already providing position and heading data when the simulation first loads (the black screen with the "Loading Scenery..." dialog box) ?The one major problem that I was facing is that FSX loads tiles FAR OUT from the viewer position where it would typically only access the lowest mipmap levels (e.g. 4x4 pixels). However my Samba server cannot possibly know that only a low detail level is required and it would load the entire 256x256 full resolution tile of the Internet. In practice, loading a zoomed out version of this tile would provide the required mipmap level AND THAT OF MANY MORE NEIGHBOR TILES in one go, saving a lot of bandwidth in the process.I could possibly estimate the required LOD level based on the distance from the aircraft, but that would not be a very precise estimate, as it depends heavily on the selected viewing distance and on other graphics settings as well.Christian

[MillKa 0]

I dont know exactly when position info is set, but since FSX needs the position to know which part of scenery to load, i bet that it is set pretty early.Via Simconnect, you could monitor aircraft position, heading, speed and altitude. Using the SysinternalsTools ProcessMonitor and FileMonitor ( http://www.microsoft.com/technet/sysinternals/default.mspx ) it should be possible to figure out how FSX loads the individual tiles. You could use fake tiles (e.g. red for MIB/LOD level x, blue for level y and so on) to analyze what resolution FSX actually uses depending on the distance from the aircrafts position. Using the heading and possible GPS / flight plan info it might be possible to make educated guesses what tiles and resolutions FSX will load next.Instead of hooking the file access via Linux/Samba you could use the MS IFS Kit ( http://www.microsoft.com/whdc/DevTools/IFSKit/default.mspx ). One of the samples in that kit simply monitors all file access nd redirects access to the real file system (FAT/NTFS). Maybe the SysinternalsTools use the same trick to monitor file access.To avoid the need for a second PC, you could use VmWare or MS Virtual PC - there are free versions available for both - finally the second core would be less bored then ..I wouldnt mind if i have to tell your scenery loader before start, where i want to fly. I think preloading and caching instead of load-on-demand would simplify the whole architecture of your tool (no file access hooks needed). I think you could get rid of all speed problems during flight with that architecture, cause all required scenery (tiles, bgl, etc) could be generated before flight.What are your future plans for your tool ? Will it be a payware or freeware addon ?

[Guest cbuchner1]

Technical update: I just blew up the tile size from 256x256 to 1024x1024, going from 4.75m/pixel to 1.1m/pixel. Initially I didn't think this would work, but actually MS FSX accepted this readily. The tile size grew from 44kb to ~650kb PER TILE. Needless to say that my 100 Mbit/s LAN is outgrown by this massive bandwidth requirement.So in fact, you can use RESAMPLE.EXE to generate 4.75m photoscenery and then you can later simply replace the tiles with higher resolution versions - this works in FSX, I haven't tested in FS 2004...I am currently flying over 1m/pixel scenery and looks georgeous, however I have to put the simulator into pause mode to allow it to catch up loading tiles. Duh.I dont think this "addon" will be available publicly anytime soon, especially not with a tile backend that is an open invitation to sue ;-). I am just a hobbyist experimenting and my code is neither clean, nor easy to install nor easy to use - and the concept currently requires two PCs connected through a fast LAN connection.Speaking of FAST. I should try some IE1394 networking instead of the Ethernet LAN. At least my PC offers an IE1394 network connection, maybe my Mac does also.Christian