I have changed the title of the blog as I am moving the focus away from CFS3. I still have a long term project in mind for CFS3. However as I have mentioned in previous blogs, water body data matching coastlines is a bit of a problem with higher resolution terrain mesh. Presently the only solution is hand editing water body data. As to CFS3 it may be best to use lower resolution mesh. That will be determined by experimentation. MAW looks as if it used SRTM 30 or early SRTM 90M interpolated with GTOPO30 dem data. The islands are much smoother than SRTM 90M v3, as are the coasts. Thus mesh at a lower resolution may work a little better.
Anyway I have started a Europe2 project for CFS3 with a rough timetable of approximately one year. I have already created a mesh sans water bodies, land class and vector data. It is slightly larger, about the same size as MAW, and a little bit further north of the current ETO theatre and will accommodate mainland Britain and Denmark, plus little bits of Norway & Sweden (no Orkney Islands unfortunately). Any water body editing that I do will be useful in other projects in the world of GIS.... not necessarily flight simulations. A couple of hours every other day is planned for coastline editing.
I have other simulations in mind in addition to or instead of CFS3. In the meantime personal circumstances take precedence. When I discover something of note or have something to show I will post. But I anticipate posts will be somewhat haphazard. I am in quite a bit of pain with cancer which is affecting my ability to sit at a computer at present.
Until then....
cheers
Rob
Sunday, July 6, 2008
Wednesday, July 2, 2008
CFS3 Terrain Mesh - Myths, Misconceptions & Problems: Part 1
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/
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/
Tuesday, July 1, 2008
Water Body post script
Looking around the web I have come to the conclusion that using hand edited SWBD data for water mesh is the best way to go. That's what I have done already. The other alternative was NGA's Global Shoreline data which is currently WIP. The NGA data is pretty good, though unfinished in places. I did find that it overlapped the coast on the SRTM data. There is very little that does not, though in CFS3 that may cause spiking. The CFS3 terrain engine was designed with much lower res data in mind.
In tonight's 2 hours, I re-edited NE England. I find it easier to delete the vertices and re-do, tracing along the caostline. The quest for software to simplify and smooth the vector shorelines continues. Map Shaper either over does or under does the smoothing though it is a good start. Unfortunately at times, it chooses not to work and does not work on my Vista 64 PC. Tomorrow I resume the texture work on the Sopwith Snipe for FSX. On the terrain front I'll experiment with CSV exchange between Global Mapper and Excel.
Rob
PS - Just found a PDF that illustrates what I am finding with SWBD data. http://www.scenerysolutions.com/doc/SRTMData.pdf
In tonight's 2 hours, I re-edited NE England. I find it easier to delete the vertices and re-do, tracing along the caostline. The quest for software to simplify and smooth the vector shorelines continues. Map Shaper either over does or under does the smoothing though it is a good start. Unfortunately at times, it chooses not to work and does not work on my Vista 64 PC. Tomorrow I resume the texture work on the Sopwith Snipe for FSX. On the terrain front I'll experiment with CSV exchange between Global Mapper and Excel.
Rob
PS - Just found a PDF that illustrates what I am finding with SWBD data. http://www.scenerysolutions.com/doc/SRTMData.pdf
Subscribe to:
Posts (Atom)
