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
Monday, June 30, 2008
Yet another update ;D
Endless updates eh? Anyway the medical news last week is not good. This activity will certainly continue albeit in a haphazard way for the time being. I have the same round of radio therapy and surgery ahead in the coming months as I had the last time. So I anticipate some therapuetic time dabbling in the CFS3 scenery SDK in the coming months.
In the meantime I've spent time over the last 3 weeks working on completing water and terrain meshes for the ETO. The verdict's out on whether they'll use it at the time of writing. The problem is that the existing data in CFS3 is quite old and out of alignment with the SRTM terrain mesh. The terrain mesh is the bottom layer upon which all other data, water, vector and gsl sits. There's no way in a 1000 years that any new terrain would line up with any existing CFS3 data including water. The new water generally appears ok in the areas I've checked. The lower level lods of the terrain push out under the water mesh causing spikes which disappear as one moves closer.
I've been checking some of NIMA's vmap0 vector data against the SRTM terrain in Global Mapper, and in the UK, at least, most of the vector data is slightly north west of where it should be. The roads appear very similar to those in CFS3, thus MS probably used that or similar data. The only way one could create a new theatre without these problems is to create one from scratch.... a massive undertaking, and probably beyond the scope of the ETO enhancement project.
I'll be experimenting in global mapper with CSV files. There could possibly be a way to display CFS3 facility locations in GM. It's hopefully just a matter of changing CFS3 data to the appropriate format.
Aircraft building continues and no doubt some of my earlier terrain dabbles, such as Spanish rivers and water bodies will also continue. I've overused my sitting allowance for this morning. Back to my bunker...... ;)
Cheers
Rob
In the meantime I've spent time over the last 3 weeks working on completing water and terrain meshes for the ETO. The verdict's out on whether they'll use it at the time of writing. The problem is that the existing data in CFS3 is quite old and out of alignment with the SRTM terrain mesh. The terrain mesh is the bottom layer upon which all other data, water, vector and gsl sits. There's no way in a 1000 years that any new terrain would line up with any existing CFS3 data including water. The new water generally appears ok in the areas I've checked. The lower level lods of the terrain push out under the water mesh causing spikes which disappear as one moves closer.
I've been checking some of NIMA's vmap0 vector data against the SRTM terrain in Global Mapper, and in the UK, at least, most of the vector data is slightly north west of where it should be. The roads appear very similar to those in CFS3, thus MS probably used that or similar data. The only way one could create a new theatre without these problems is to create one from scratch.... a massive undertaking, and probably beyond the scope of the ETO enhancement project.
I'll be experimenting in global mapper with CSV files. There could possibly be a way to display CFS3 facility locations in GM. It's hopefully just a matter of changing CFS3 data to the appropriate format.
Aircraft building continues and no doubt some of my earlier terrain dabbles, such as Spanish rivers and water bodies will also continue. I've overused my sitting allowance for this morning. Back to my bunker...... ;)
Cheers
Rob
Thursday, June 12, 2008
Another update
I seem to post nothing but updates here. Anyway the bottom line is that cancer is most likely back in my life again. New discomforting, and now painful symptoms came to my attention in April. They are gradually worsening and the doctors tell me it is most likely a re-occurrence and spread of liposarcoma. (I'm still hoping it's infection rather than sarcoma). Anyway with the likelihood that it's cancer which will involve some sort of treatment/surgery which may sideline me for a while, most of my efforts are presently devoted to surviving.
Creative efforts are focusing on getting my Sopwith Snipe ready for FSX before medical treatment begins. I probably won't have it complete by then but I'll give it a go anyway. Thus terrain for CFS3 will again have to take a back seat, with only a few minutes here and there to pursue. I'd like to post some pics and maybe more info on terrain creation, but no promises.
So if I disappear for a while... y'all know why. Hopefully I'll be back.
Cheers
Rob
Creative efforts are focusing on getting my Sopwith Snipe ready for FSX before medical treatment begins. I probably won't have it complete by then but I'll give it a go anyway. Thus terrain for CFS3 will again have to take a back seat, with only a few minutes here and there to pursue. I'd like to post some pics and maybe more info on terrain creation, but no promises.
So if I disappear for a while... y'all know why. Hopefully I'll be back.
Cheers
Rob
Friday, May 23, 2008
Quick Update
I will be updating the blog hopefully this coming weekend. I will further clarify and update my previous post and post some pics of my experiments.
To date I've only focussed on terrain and water and just touched on the landclass system. The test theatres look a bit boring with only one landclass, though there are some spectacular mountains in parts of the world. I've still attempt to use the CFS3 SDK vector data tools. The Terrain SDK is more than cryptic in places.
I have created a number of test theatres which appear to function, at least as far terrain mesh goes. I have chosen Spain as a theatre to develop right through, from terrain, water, vector data, land class etc., mainly as a learning exercise for myself. Right now I'm finding that the freely available vmap0 vector data is not all that accurate, with rivers running over the tops of mountains etc. In the instance of Spain I've chosen to create the river vector data by hand in Global Mapper. It's a slow task which I've only about 4+ hours a week to spare. I'll need to set aside some time to experiment and learn the landclass system. I have resumed aircraft modeling for FSX also... at long last after a 2 month break.
Anyway hopefully more on the weekend.
cheers
Rob
To date I've only focussed on terrain and water and just touched on the landclass system. The test theatres look a bit boring with only one landclass, though there are some spectacular mountains in parts of the world. I've still attempt to use the CFS3 SDK vector data tools. The Terrain SDK is more than cryptic in places.
I have created a number of test theatres which appear to function, at least as far terrain mesh goes. I have chosen Spain as a theatre to develop right through, from terrain, water, vector data, land class etc., mainly as a learning exercise for myself. Right now I'm finding that the freely available vmap0 vector data is not all that accurate, with rivers running over the tops of mountains etc. In the instance of Spain I've chosen to create the river vector data by hand in Global Mapper. It's a slow task which I've only about 4+ hours a week to spare. I'll need to set aside some time to experiment and learn the landclass system. I have resumed aircraft modeling for FSX also... at long last after a 2 month break.
Anyway hopefully more on the weekend.
cheers
Rob
Monday, April 7, 2008
Pushing the Boundaries - Slight Return :)
I can't stay away can I.....LOL? I've literally been pushing and testing the boundaries of the CFS3 terrain engine this past week. I've also been working on and off, in between times, these last couple of months on new terrain and water polygons for the new CFS3 ETO project. In the last week, with initiatives in the CFS3 forums at Sim-Outhouse, to create an Eastern Front add-on for CFS3 I decided experiment with a mesh for that. As the Eastern front covered a large geographic area I decided to test for myself just what could be achieved as to terrain size.
First up I created a dummy theatre the same size as CFS3 ETO, only moved east, using the paramaters in the terrain SDK examples. Using some test airbases in a simple gsl file, the theatre worked. Ok next up I decided to test a mega terrain. The terrain map stretched from S.E UK in the west, to Iraq in the east, southern Scandinavia in the north and the northern part of North Africa in the south. I fully expected CFS3 to croak, or rather not start. However CFS3 started as normal and I was able to fly from a couple of my test airfields. However optimism and satisfaction were short lived when I created further test airfields in the global scenery layer and attempted to fly from them, the game seemed to clip the theatre size by itself. However at that stage I did not create a new lcf (landclass) file for the appropriate theatre size and in my earlier experiments had made an error with the image and landclass stride parameters. I will redo the experiment later to make sure. I had been in the process of creating a large map of another geographical region before the Eastern Front project came up.
I would also emphasize that for test purposes, to speed things up, I was only compiling 1km resolution mesh down to a 1km stride. It only takes a few minutes to compile terrain at this resolution. Full resolution terrains can take hours (or days) of computer number crunching to compile.
On to my findings - firstly I would say that either that some of the terrain SDK examples are incorrect or there is a bug in the ers2tiff.exe tool. Creating a terrain mesh for CFS3 is relatively easy once you have source dem data. I use a spreadsheet to calculate the approximate bounds of the terrain data. The only numbers that ers2tiff.exe requires is the theatre origin, image pixel dim, image stride, max height, outX1, outY1 (terrain extents) and the number of images in the X and Y axes. The ers2tiff tool calculates the actual extents and theatre boundary from this information. This tool will automatically clip the supplied terrain to the appropriate size given the theatre minimum extent and the theatre origin.
In CFS3 geographical co-ordinates are relative to the theatre origin i.e. the theatre centre. The terrain SDK provides example parameters of minimum co-ordinate extents of the output data, in meters relative to the origin. The SDK further states that extent of the default ETO theatre is the rectangle (-786432,-786432) to (786432, 786432). However the output parameters that ers2tiff produces using appropriate dem data are (-786432,-786432) to (785408, 785408). (785408, 785408) is the north east co-ordinate of the terrain boundary in meters relative to the theatre origin. 785408 is 1024 meters less than 786432. In other words it truncates the data by approximately 1km in the North East. Further tests reveal that regardless of minimum terrain extent or theatre origin, the tool always outputs terrain extent parameters with the the NE parameters being 1024 meters less than the SW. I don't know whether this is a bug or by design. I do vaguely recall reading posts of a 1km srtm terrain bug in FS2004 & maybe FS2002, in forums in the past - maybe it's the SRTM data (or maybe it's my imaginative memory - someone may be able to clarify)?
This may be pertinent to one problem I have discovered. If we move the theatre origin north, or create a theatre larger than the default theatre, and fly into, or create an airfield in the NE corner of the theatre and fly from it, CFS3 crashes. Everything else appears to work correctly. One can only really test the bounds of CFS3 by flying in the game until one encounters the theatre boundary. The sim will soon let you know when you're leaving the theatre.
I cannot see any input in any of the xml files that tells cfs3 how large the theatre is apart from the files in the campaign's folder and mapdat.xml. CFS3 appears to ignore these as one can use any old numbers and the theatre will function ok in quick combat. The lcf file seems to have a bearing on theatre functionality in the sim and that may set boundaries, or CFS3 may determine theatre size from the terrain archives in the mesh zips.
Anyway after exploring boundaries by flying in the simulation, CFS3 appears to calculate its boundaries based on distances calculated from it's centre origin. As we know, the earth is round thus the distance per degree of longitude or latitude differs wherever we are on the planet. A degree of longitude (E/W) is 111.32km at the equator but 55.8km at a latitude of 60°N. CFS3 calculates its longitude boundaries using 1/2 the theatre dimension size east or west along the latitude at its origin, e.g. origin latitude of 50°N (approx 71.7km per °), 30°E gives 15°19′46″E in the west 44° 40' 14"E in the east. CFS3 calculates north and south from the centre in a similar manner (distance for degree of latitude varies from 110.57km to 111.69km). Having created these boundaries CFS3 then uses a rectangle based on these geographic co-ordinates as its theatre boundary, which is ok as long as it's primary reference is geographic latitude and longitude. It's paradoxical to a certain extent given that many of the SDK calculations are based on meters usually based to the power of 2 or divisible by numbers which are to the power of 2.
Anyway the exploration continues. I will continue some tests with ers2tiff to see if it can produce output whose extent boundaries line up with the SDK documentation. Perhaps using a geotiff dem will produce different results...maybe dted0 dems will produce different results? I'll also experiment again with a mega theatre. If the NE corner bug is the only problem then maybe we can put up with that and caution users to stay clear....maybe a giant smiley...danger Will Robinson...danger Lol? I also hope to explore CFS3's landclass system....more on that later.
All this is very addictive...I keep trying to escape CFS3. There's nothing like a puzzle to maintain one's interest.
cheers
Rob
First up I created a dummy theatre the same size as CFS3 ETO, only moved east, using the paramaters in the terrain SDK examples. Using some test airbases in a simple gsl file, the theatre worked. Ok next up I decided to test a mega terrain. The terrain map stretched from S.E UK in the west, to Iraq in the east, southern Scandinavia in the north and the northern part of North Africa in the south. I fully expected CFS3 to croak, or rather not start. However CFS3 started as normal and I was able to fly from a couple of my test airfields. However optimism and satisfaction were short lived when I created further test airfields in the global scenery layer and attempted to fly from them, the game seemed to clip the theatre size by itself. However at that stage I did not create a new lcf (landclass) file for the appropriate theatre size and in my earlier experiments had made an error with the image and landclass stride parameters. I will redo the experiment later to make sure. I had been in the process of creating a large map of another geographical region before the Eastern Front project came up.
I would also emphasize that for test purposes, to speed things up, I was only compiling 1km resolution mesh down to a 1km stride. It only takes a few minutes to compile terrain at this resolution. Full resolution terrains can take hours (or days) of computer number crunching to compile.
On to my findings - firstly I would say that either that some of the terrain SDK examples are incorrect or there is a bug in the ers2tiff.exe tool. Creating a terrain mesh for CFS3 is relatively easy once you have source dem data. I use a spreadsheet to calculate the approximate bounds of the terrain data. The only numbers that ers2tiff.exe requires is the theatre origin, image pixel dim, image stride, max height, outX1, outY1 (terrain extents) and the number of images in the X and Y axes. The ers2tiff tool calculates the actual extents and theatre boundary from this information. This tool will automatically clip the supplied terrain to the appropriate size given the theatre minimum extent and the theatre origin.
In CFS3 geographical co-ordinates are relative to the theatre origin i.e. the theatre centre. The terrain SDK provides example parameters of minimum co-ordinate extents of the output data, in meters relative to the origin. The SDK further states that extent of the default ETO theatre is the rectangle (-786432,-786432) to (786432, 786432). However the output parameters that ers2tiff produces using appropriate dem data are (-786432,-786432) to (785408, 785408). (785408, 785408) is the north east co-ordinate of the terrain boundary in meters relative to the theatre origin. 785408 is 1024 meters less than 786432. In other words it truncates the data by approximately 1km in the North East. Further tests reveal that regardless of minimum terrain extent or theatre origin, the tool always outputs terrain extent parameters with the the NE parameters being 1024 meters less than the SW. I don't know whether this is a bug or by design. I do vaguely recall reading posts of a 1km srtm terrain bug in FS2004 & maybe FS2002, in forums in the past - maybe it's the SRTM data (or maybe it's my imaginative memory - someone may be able to clarify)?
This may be pertinent to one problem I have discovered. If we move the theatre origin north, or create a theatre larger than the default theatre, and fly into, or create an airfield in the NE corner of the theatre and fly from it, CFS3 crashes. Everything else appears to work correctly. One can only really test the bounds of CFS3 by flying in the game until one encounters the theatre boundary. The sim will soon let you know when you're leaving the theatre.
I cannot see any input in any of the xml files that tells cfs3 how large the theatre is apart from the files in the campaign's folder and mapdat.xml. CFS3 appears to ignore these as one can use any old numbers and the theatre will function ok in quick combat. The lcf file seems to have a bearing on theatre functionality in the sim and that may set boundaries, or CFS3 may determine theatre size from the terrain archives in the mesh zips.
Anyway after exploring boundaries by flying in the simulation, CFS3 appears to calculate its boundaries based on distances calculated from it's centre origin. As we know, the earth is round thus the distance per degree of longitude or latitude differs wherever we are on the planet. A degree of longitude (E/W) is 111.32km at the equator but 55.8km at a latitude of 60°N. CFS3 calculates its longitude boundaries using 1/2 the theatre dimension size east or west along the latitude at its origin, e.g. origin latitude of 50°N (approx 71.7km per °), 30°E gives 15°19′46″E in the west 44° 40' 14"E in the east. CFS3 calculates north and south from the centre in a similar manner (distance for degree of latitude varies from 110.57km to 111.69km). Having created these boundaries CFS3 then uses a rectangle based on these geographic co-ordinates as its theatre boundary, which is ok as long as it's primary reference is geographic latitude and longitude. It's paradoxical to a certain extent given that many of the SDK calculations are based on meters usually based to the power of 2 or divisible by numbers which are to the power of 2.
Anyway the exploration continues. I will continue some tests with ers2tiff to see if it can produce output whose extent boundaries line up with the SDK documentation. Perhaps using a geotiff dem will produce different results...maybe dted0 dems will produce different results? I'll also experiment again with a mega theatre. If the NE corner bug is the only problem then maybe we can put up with that and caution users to stay clear....maybe a giant smiley...danger Will Robinson...danger Lol? I also hope to explore CFS3's landclass system....more on that later.
All this is very addictive...I keep trying to escape CFS3. There's nothing like a puzzle to maintain one's interest.
cheers
Rob
Wednesday, January 23, 2008
Last post on this blog for a while.
I'm rationalizing my blog activities somewhat. This blog was established to blog some of my activities in exploring CFS3 scenery creation, largely as a from of recreational activity while waiting for cancer treatment and surgery. Hopefully I am now on the recovery trail and I can now again focus on my core hobby activities such as virtual aircraft creation, and of course real life and ongoing cancer treatment.
I ended up creating a semi-functional Mariana Islands theatre (Guam, Saipan etc) but did not get time to create new land class or scenery objects. However I do hope to return to this someday. I'll be monitoring CFS3 PTO threads on the forums. I'm also looking for time to resume a F6F-3 model I started on last year along with a Helldiver. Hopefully I will have time to create versions for both FSX & CFS3...... sometime in 2008..... though don't hold your breath.
I will not close or delete this blog at this time for reasons mentioned in the previous paragraph. I may (probably will) dabble in FSX scenery creation.
Anyway for the time being.... all the best to my very few readers.
Rob
I ended up creating a semi-functional Mariana Islands theatre (Guam, Saipan etc) but did not get time to create new land class or scenery objects. However I do hope to return to this someday. I'll be monitoring CFS3 PTO threads on the forums. I'm also looking for time to resume a F6F-3 model I started on last year along with a Helldiver. Hopefully I will have time to create versions for both FSX & CFS3...... sometime in 2008..... though don't hold your breath.
I will not close or delete this blog at this time for reasons mentioned in the previous paragraph. I may (probably will) dabble in FSX scenery creation.
Anyway for the time being.... all the best to my very few readers.
Rob
Subscribe to:
Posts (Atom)
