Search the Community

FreeMeshX Interview with Daniel Moser Conducted by Dominic Smith Hi Daniel, thank you so much for taking the time to be interviewed by FlightSim.Com. Could I begin in asking you where the original idea for FreeMeshX come from? Hi Dominic! Thanks for your interest and reaching out to interview me. FreeMeshX was originally conceived initially as a small investigation into improving the terrain of Great Britain. I am actually not British, but I've been to England several times as part of my scientific career, and I've always been fascinated with its landscapes. Whether it was cruising through the English countryside on a heritage-line steam train, or hiking through the beautiful hills of Dartmoor, or perhaps from watching Braveheart too many times, I've always been mesmerized by its landscapes. I began this small project with zero experience in scenery or terrain design. It started when I decided I should get a mesh to compliment my other terrain add-ons. I, of course, had looked into commercial options such as FS Global and FS Genesis, the big two names of mesh design (I'm not sure Toposim was around at this point), but the payware options were too expensive with respect to my meager PhD student stipend. Plus, I was more interested in spending money elsewhere. There were freeware options, but there were too scattered around the Internet into too many different packages, and usually the downloads were throttled to the point that it was just too unbearable to aggregate all the separate meshes together. So I looked into creating my own. After a few tutorials, I realized Microsoft made it very easy to compile existing digitized elevation data for use in Flight Simulator. You simply need elevation data in a popular file format, the Microsoft FS SDK, and a configuration file with instructions for the SDK on how you want to compile the data. The result would be a .BGL file that you could simply add to the Scenery Library, and then fly around your newly generated terrain. The project began to escalate rapidly. I started using ASTERv2 GDEM elevation data because of its fantastic global coverage and resolution, but I was unsatisfied with the amount of noise in the data which created far too many spurious terrain artifacts. I then found SRTM data (elevation data sampled by the Space Shuttle) which was much cleaner. And so I began to move beyond Great Britain into doing all of Europe with the SRTM data. Then NASA released their higher resolution version of the SRTM data, and I began building scripts to compile more of that data automatically over large sections of the globe. It just sort of snowballed, and I began to realize that perhaps the community would be interested in using some of this new, high resolution data as a mesh replacement. So we came up with a project name, and called it FreeMeshX. How many members are in the FreeMeshX team? The FreeMeshX team is currently two members strong. It consists of me, and my life-long friend David with whom I've bonded over our shared interests into aviation and other things. David titled our little group "Nine Two Productions" after our humble beginnings as a virtual tribute group for the RAF No. 92 squadron back in the days of Combat Flight Simulator and IL-2. David is mainly responsible for keeping tabs on our web site, www.ninetwopro.com while the mesh production and support is mainly my responsibility. What were the reasons behind releasing FreeMeshX as freeware? In our view, freeware is the foundation of the flight simulation community. For as long as I remember, content creators have shared add-ons in which they poured their love and passion into for the whole community to enjoy. This is the highest tradition of our hobby, and we greatly respect all freeware content authors who have preceded us. With that said, we briefly considered the possibility of a commercial release as the project escalated, but ultimately decided not to for several reasons. First, we are a new name to the community with nothing to show beforehand. Great development teams, such as those over at ORBX and others, are filled with big names that were once freeware developers. These developers had to build a trust and reputation with their audience before they went commercial. It did not feel right to immediately ask for cash as a newcomer, especially to a group that has been cheated by several snake oil salesmen, so we felt some ethical obligation to prove ourselves first if we ever decide to pursue some commercial venture. Second, the legal responsibilities of maintaining a commercial enterprise were just too much for us at this point in our lives. I am up to my neck in scientific research, and David has a budding career in finance, so we both felt we needed to be settled first to properly maintain a business. There are other reasons as well. How does one protect against piracy? How would we pay for all the bandwidth (FreeMeshX is about 50 GB in size)? Would we have to go with physical distribution? There were just too many headaches involved, and we weren't in a position to appropriately support that enterprise. Third, the existing competition is quite huge. How does one make a name for themselves in mesh design when the scene has been dominated by several companies for so many years? There was really only one option. Release our mesh for free, and if anything, just be satisfied that we were able to contribute something back to the community. Does FreeMeshX cover the entire world? FreeMeshX almost covers the entire world, with most of it covered at LOD10 (38-meter resolution). The USA is not included because it is already rendered at LOD10, quite beautifully I would say, and going to higher resolution in the USA would result in many unwanted side effects at thousands of airports - namely airport pits and plateaus - in one of the most popular countries to fly. We initially planned to release a higher-resolution LOD11 or LOD12 USA package, but with these unwanted side effects, why would we want to ruin an already great terrain with ugly airport artifacts just for the sake of going higher resolution? So we chose to delay the USA package until we are satisfied with some sort of solution to the plateau issue, and we are actively trying to develop our own solution as well, albeit slowly. Is the LOD for the different parts of the world the same, or is sampled at different levels? Between 60° S and 60° N, the terrain is sampled at LOD10. Higher latitudes are restricted to LOD9, with the exception of Antarctica which is LOD8. The higher level of detail is constrained to these lower latitudes because the source data was obtained by the Space Shuttle, and due to its orbital inclination during its topography sampling mission, it could not sample the higher polar latitudes. For many years, NASA had held back on releasing the higher resolution datasets to the public, but when they were released, FreeMeshX was the first terrain set to take advantage of this new, highly detailed source data. Without going into too much detail, would you be able to explain the process of how the mesh is created? As stated before, the mesh is created from real source data in the public domain. The vast majority is high-resolution data sampled by the Space Shuttle. These files are distributed online in little 1° latitude by 1° longitude "tiles", and you can feed them directly into the SDK to produce a terrain file which you can add to your Scenery Library. In essence, that is the minimum amount of work needed. However, it is inefficient to compile these small tiles at a time, so we actually compiled them in bulk by merging these smaller tiles into larger 10° latitude by 10° longitude tiles at time. I used some batch scripting and some programming in Python (with some nice free, open source GIS libraries) to streamline the process so most of that work would be done hands-off. We would generate a few of these large tiles at time in TmfViewer, provided by the SDK, and then spend time flying through these areas to see if we catch any widespread problems. If we were satisfied with the output, we would move on with the next batch of terrain tiles. However, we frequently did run into problems within the source data. I imagine most raw data sets do have their own host of problems. Many of the rugged, heavily forested areas of the world would have loads of sampling errors in the source data. In the simulator, this would often look like a hole in the ground that shouldn't be there, or a giant spike that can sometimes be miles high! Not good! So we had to develop some kind of error-correction method. And this took a lot of time and thought to create. Eventually, we settled on a method that would take older, lower-res SRTM data, corrected by the excellent Jonathan Ferrenti, upscale it to the same resolution as the new SRTM data, and then create a difference map between the two. We then designed an algorithm that would identify large differences between the two, which would indicate an error, and then erase those huge differences by substituting the corrected value from the older data into the newer source data. This actually works very well, and there is a lot more to say about it, but that is a basic summary of how it works. The result is a very clean, high-resolution representation of the Earth's topography. Many of the mesh products available for MSFS (both freeware and payware) can cause airports to lie on plateaus, or in valleys; is this the case with FreeMeshX? This is the case of any mesh, including FreeMeshX, unless the mesh was modified from its original data by hand to reduce these artifacts. I believe the latter method is often used in the extremely highly detailed FTX regions crafted by ORBX. However, the amount of work and time required is too prohibitive and impractical to apply handcrafted airport blending on a global scale. The stock mesh was designed to perfectly match up exactly with the elevation of each airport, and every airport must be perfectly flat. Any change in the mesh will quickly expose just how shortsighted this original approach by Microsoft was by producing an ugly airport plateau or valley. I plead with any team developing a new simulator based on the Microsoft ESP engine (I'm looking at you DoveTail or Lockheed Martin) to implement terrain-following airports so we can finally rid ourselves of these ugly artifacts. There are some partial solutions to the problem. One is to update the airport's elevation so that it better matches up with the more accurate mesh. Anyone who owns FTX Vectors will find this handy. But it's not perfect since airports are still forced to be perfectly flat. So while one side of an airport may be nicely aligned with the terrain, the other side could be forming a huge cliff. With that said, we found that FTX Vectors works very well with FreeMeshX and remedies many airports, so it is highly recommended by us. The other approach taken by PILOTS is to generate an airport flattening mesh that flattens the surrounding mesh around the airport. The problem with this method is that it will then flatten some of the nice topography around the airport, and if your airport is near a mountain, then a flattened mountain would be quite unsatisfying to a flyer. But for flatter environments around an airport, this solution would work nicely. We are researching and developing a better solution, but we aren't quite there yet, but if we can get it to work more consistently, then we may be able to greatly mitigate the airport plateau/valley issue. With such a large area covered, how do you go about error checking all the different meshes? Surely you don't fly over each square mile? No, we can't fly over every square mile. But we certainly have covered many! We didn't really have a comprehensive error-checking mechanism when we developed the 1.0 version of FreeMeshX. We had something that would correct errors when we identified where they were manually, but nothing of the sort that would identify where they were automatically. That's actually why the 1.0 release had some substantial problems. With the help of community feedback, we were quickly able to fix the most glaring problems in the first few following days and weeks. I think we released four updates FreeMeshX in the first month alone. In retrospect, I would have developed some sort of algorithm that would identify outliers in the source data from the start, but that still would not have excused some of the more blatant "user" errors we had slip through on the initial release. I remember southern Italy being quite FUBAR'ed; however I was able to fix that in a patch before anyone had the chance to notice! We are much more careful in examining our work these days when we do release updates. We are very happy with the quality of FreeMeshX as it stands today. Do you have a team of beta testers to help you with the development of FreeMeshX? Not an official beta team, but I do participate in a flying club called The Sky Lounge (theskylounge.tv) whose members quite often give me valuable feedback and any reports of terrain anomalies. They are incredibly enthusiastic about FreeMeshX, and their excitement always brings a smile to my face. When we feel the airport plateau issue can be worked around consistently, we plan to release FreeMeshX - USA as an open beta of some sort. However, this has to be done carefully. The community would probably not appreciate frequent updates with sizes of 10-15 GB at a time, so an open beta would have to be done when we feel confident about its quality. Is FreeMeshX compatible with the majority of MSFS add-ons? It is difficult to quantify compatibility, but as a mesh, it should be compatible with most add-ons. We can't promise whether a particular airport will blend in perfectly with the mesh. We though have received reports of users even using FS Global and FreeMeshX together successfully. The simulator will choose which mesh to use based on its LOD and scenery library priority, so most incompatibility issues are solved by the simulator itself. How would you say your mesh compares with paid alternatives? When FreeMeshX was released, it was the most comprehensive, high resolution global mesh available. What set our product apart from the paid alternatives, other than its price, was that we used the newest high resolution version of the SRTM data (from the Space Shuttle mission) as our base while most payware global meshes were still based on the older dataset. So we had that advantage straight out of the gate, and it was a major reason why FreeMeshX sort of took off. It also worked quite well with the popular FTX Global line of products which also helped. There are other payware meshes based on other source data formats, but I've never used them, and they are typically priced on a per-country basis which is just too cost-prohibitive for me. Many add-ons which improve on the default MSFS world come at a price in regards to performance. With this said, have you noticed any discernible impact on performance when using FreeMeshX? The terrain rendering in the ESP engine is quite efficient at streaming elevation data from the hard drive into the simulator. There is usually a small increase in your first initial load into a flight due to the higher density data associated with FreeMeshX, but unless your hard drive is very slow or highly fragmented, then the simulator should not fall behind on streaming that data as you fly. We've seen no substantial changes in frame rates or large increases in VAS either, nor do we expect that. FreeMeshX shares the same LOD as the stock USA mesh, so if you had no performance problems flying with the stock USA mesh, then you'll have no performance issue with FreeMeshX. As a team, what are your future plan for FreeMeshX? At the moment, we are keeping our eyes and ears open for more news about version 4 of Prepar3D. Rumors are circulating that it will be 64-bit which would be great news for users of highly detailed add-ons running into VAS-depletion problems. We have no insider information about the upcoming release, and are concerned whether or not 64-bit would require a complete recompilation of FreeMeshX. That would require a lot of work, and we are cautiously hoping that the new version will have backwards compatibility in that regard. Otherwise we are still researching and developing a solution to the airport plateau/valley problem in order to move forward with the USA expansion. If we can resolve that problem, then we will release that expansion as soon as possible. We care deeply about our users' experiences, and we don't want to create headaches by potentially causing artifacts at many of the U.S. airports. For those who don't care about those artifacts and just want to have sharper mountains and hills sooner than later, there are currently freeware and payware USA meshes available outside of FreeMeshX. We're also thinking about repackaging the 1.0 release into a 1.1 release with all the upgrades and bug fixes integrated into an easy to install package. At the moment, installing and being up to date with the patches may feel like a chore for the flight simulator novice, and we want to streamline that process. Finally Daniel, what would you like people to know most about FreeMeshX and also the work you and David do? FreeMeshX was created to do one thing, and I think we pulled it off. We were quite surprised by its positive reception by the community, and their gratitude and appreciation made the whole project worth it. We're so happy that people actively feature it in their screen shots, videos, and recommended lists of add-ons. As of now, we estimate that there has been approximately 20,000 - 25,000 downloads of the complete FreeMeshX set. That's somewhere in the neighborhood of 1.25 petabytes of data moved through BitTorrent and our MediaFire account! I had never dreamed it would be this successful, especially when it began as a personal, private project. And we'll continue to support it indefinitely. Thank you Dominic! FreeMeshX Web Site: ninetwopro.com