One thing about being virtually the only person presently 'dabbling' in CFS3 terrain creation is the frustration I experience in getting others to apprehend exactly how the terrain system works.
Firstly having participated in the ETO expansion project there was a misconception that the mesh is incorrect or problematic. Actually the SRTM terrain mesh was probably the only geographically correct data in the project. SRTM 90m version 3 finished data, was downloaded from CGIAR. This data was derived the Shuttle Radar Topography Mission, an 11 day shuttle mission in 2000.
The only problems that can occur with this data are voids or the occasional spike. However as CGIAR's data is version 3, these problems have been largely corrected. Global mapper was used to compile the relevant SRTM files into one large DEM file for the ETO geographic area. Global Mapper is limited in it's terrain editing abilities. One can flatten certain areas by creating a vector polygon and assigning an altitude to it. This is useful for getting rid of features such as breakwaters etc., that may not have existed during WW2 or perhaps creating ones that did. There were a number of negative elevations in the SRTM data for the ETO area, for below sea level areas. I did change minimum elevation to 0 metres in the master DEM as the CFS3 SDK tools calculate all mesh elevations in the final CFS3 mesh between 0 and the maximum elevation specified on the command line input. Apart from that there was little adjustment to carry out. I did carry out a number of experiments in scaling the elevations in the mesh slightly and also experimented by flattening the terrain mesh under the water bodies to make the terrain match the mesh in certain area. However the result was very artificial looking and not proceeded with.
The DEM meshes were exported from Global Mapper as a large *.bil file. When exporting a series of SRTM dem tiles into a single large DEM in GM I find it is best to leave interpolate unchecked in the export options. Leaving this checked causes seams and ridges in CFS3. This is about the only thing that could possibly go wrong.
The the end result was virtually an un modified SRTM V3 90M mesh, processed in accordance with CFS3 terrain SDK guidelines. Once decisions have been made it takes my computer approximately 6 hours to compile a terrain mesh, apart from experiments there is very little else to do. Apart from experimentation, and computer time compiling a very easy task. Water on the other hand is a very different story.
In previous posts I explained the problems in using the newer and more complex SRTM V3 data with old data in CFS3. Essentially an ETO terrain mesh revision was doomed from the start, without changing all other data ie roads, railways, rivers, water bodies. Nothing will line up. These were not terrain mesh problems. For everything to work correctly everything would have to be redone. Also GSL facilities of various types placed close to the coast distorted the mesh and warped the water polygons. Airfields with incorrect altitudes on the gsl caused mounds, dips and spikes in the terrain. Invariably the 'nasty' mesh (LOL) was blamed for this. GSL problems could possibly have been easily fixed using Global Mapper to import CSV data from the GSL worksheet and re-exporting as text csv files and back into Excel. I'll be using GM to map the GSL on my own projects (if I get around to them LOL).
I did create new water body mesh which was still WIP at decision time. I've described problems in doing so elsewhere. The linked PDF verifies what I have found http://www.scenerysolutions.com/doc/SRTMData.pdf Essentially any water bodies have to be hand modified or created. I was in the process of doing so. Unfortunately the shorelines had yet to be created leaving a jaggy water mesh interfacing with the terrain. There was also misconception that the rivers and water bodies were not correctly placed. The same goes for them as the SRTM data. The data on top of them were incorrect rather then the WB's themselves.
I do think at the end of the day the ETO team were correct not to go ahead in using the SRTM3 mesh given all the problems and time available. I fully agree with that decision and am glad to be relieved of the pressure in my current circumstances. A revised terrain project requires that everything be built from the ground up i.e. terrain mesh, water mesh, river, road, railway vectors, terrain textures, landclass, vector data for ai vehicles and terrain exclusions, and the global scenery layer on top of everything else. Realistically speaking an effort exceeding a year and more than one person. If I were to go through all that I would probably choose a new area. Hopefully if I do involve myself in a future project the guys I work with will have a clearer understanding of the CFS3 terrain system and how everything intermeshes.
Now that the ETO team have decided not to use my mesh, whether and how I'll tackle water is a decision for the future and I will be concentrating on my own projects if do proceed ie different areas from the CFS3 ETO. The number one problem is to find a cure for water spikes in headlands etc, which are caused by lower terrain lods poping in and out as one approaches them. I have a few experiments in mind. Also smoothed matching coastline data is worth big $ - another consideration. One could earn a bit of money if one were to do this for other markets. If I were to spend time and do that, should I do that for CFS3 or some other product(s)? Payware is unlikely to be viable for CFS3 and this a lot of time for a freeware project - when I should be focussing on aircraft, where at least I have had some offers from publishers in the past. I tend to think that CFS3 will have problems with complex coastlines and high resolution meshs regardless - however I'll experiment further.
Sadly Ed Wilson the only other person that I know of, apart from Microsoft and myself, to work with terrain mesh in CFS3, recently passed away after a long battle with cancer. Ed created the terrain for the MAW project (a massive task), Korean Skies and more recently the Solomons PTO. I'll be having a look at how Ed tackled the shoreline issue in these projects, especially in complex areas. I'll have a look at bridges and rivers in the projects too to see how they were tackled. I do know that he encountered the same problems I have with water mesh spiking, in the PTO project though I can recall reading that he solved it. It will be nice to spend a bit of time flying in these addons.
Rob
Links:
CGIAR SRTM details and links http://srtm.csi.cgiar.org/
NASA SRTM home - http://www2.jpl.nasa.gov/srtm/
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment