Sign in to follow this  
dlhusk

Yet another tool available: FSDEM

Recommended Posts

FSDEM 1.0 has been uploaded to AVSIM library.Search for the file "fsdem_1_0.zip".I have been using this program since last year, to build terrain meshes for South America and Africa, using SRTM as source data.A brief description of the program:FSDEM is a graphical tool designed to help on the editing and correction of NASA SRTM (Shuttle Radar Topography Mission) terrain elevation meshes, and to create terrain mesh scenery to be used in Microsoft Flight Simulator 2002/2004. FSDEM can read/write generic raster files as well.The program has an integrated help (context help).I hope there are no bugs in the program, but if you find one, I will be grateful if you report it to me.>>> VERY IMPORTANT : Check the program requirements (in README.TXT) before install.The program needs Resample version 1.0.0.2 (FS2002), or newer, in order to create BGL files.The Resample utility is not included in the FSDEM distribution package. This utility is distributed along the Terrain SDK, available on Flight Simulator official web site.Enjoy the program!Emerson de OliveiraPorto Alegre - Brazil

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

Hello Emerson,Thank you for developing such a tool and share it.I tried to load a raster file.But in the bounding rectangle, it is not possible for me to put in decimals.i.e only 46 instead of 46.7359684.So I can not georeference the data accurate.Should it be possible to use decimals?Kind regardsHorst

Share this post


Link to post
Share on other sites

>Should it be possible to use decimals?Hello Horst,Unfortunately, you can

Share this post


Link to post
Share on other sites

Hi Emerson,I too would like to thank you very much for making FSDEM available for all! I haven't had a chance to "test-drive" it yet (and apologize for not getting back to you sonner) but I did have a look at the help section and was very impressed by its detail. Great job and a big difference to SRTM2BGL's limited read-me.Cheers, Holger

Share this post


Link to post
Share on other sites

Hello Holger,You and everybody are welcome for comments, criticism, bug reports and new ideas!Remember that FSDEM was not released to replace any already available tool. It's a different tool, that use different approaches, and that has specific requirements and limitations.Actually, the program was released to public because I have seen, several times, on internet forums, specific problems in FS mesh design that I think this utility could help.I have not released the program before because it had no documentation at all. In fact, the documentation and the context help were finished only some weeks ago. By the way, the context help feature was a suggestion of a beta tester.FSDEM should not be used on low-end computers to edit large meshes (with several tiles), because the program will run slow as a turtle. It's very demanding regarding RAM memory. However, if your system has the recommended specs, the program runs fine, smooth as silk, even with large areas loaded into memory.[]sEmerson

Share this post


Link to post
Share on other sites

I just started with creating mesh sceneries for my FS2002. I detected your tool FSDEM yesterday and this is really great! Thank you for sharing this tool with the FS community.I used the .hgt file from the SRTM mission and wanted to improve the scenery in Flight Simulator.I did a little test using your tool with crating a mesh for a region in the alps using the SRTM data and the effect is ... wow!!!Your tool is exactly what I was looking at. A nice feature would be to be able to save the data again as .hgt file after one has interpolated the wholes.What I do not understand (but I am currently only a beginner):1) Why do you generate a .ras temporary file. It should be possible to use the .hgt file directly as I understood the file format spec. Is it only because of the interpolation I did or is there really any conversion required?2) In the generated.inf file is set:NumOfCellsPerLine=1200NumOfLines=1200Why is this not 1201 as documented in .hgt file spec?3) For my sample file N47E011.hgt in the .inf is written:Lat=48.0000000000Lon=11.0000000000I understood this file contains the data from 47 deg to 48 deg latitude and from 11 deg to 12 deg longitude. So I would expect this to be in the inf file: Lat=47.0000000000Lon=11.0000000000Does FS count backwards here? Anyway the result seems to be fine. Jens

Share this post


Link to post
Share on other sites

Hi Jens!Thanks for the feedback!>A nice feature would be to be able to save the data again as>.hgt file after one has interpolated the wholes.There is a "workaround" solution for this lacking feature.You can load the HGT file as a raster file using the following parameters:1201 rows, 1201 columns, MSB first, void as -32768.Edit/interpolate the data as needed, then save it back as a raster file using the same parameters.Remember to keep the original HGT file name.>Why do you generate a .ras temporary file. It should be>possible to use the .hgt file directly as I understood the>file format spec. Is it only because of the interpolation I>did or is there really any conversion required?The temporary raster file is just the input elevation data required by Resample. FSDEM doesn't send HGT files directly to Resample because it's not suitable, considering the way FSDEM works.It's possible to feed Resample with HGT files (directly, by command-line), with the proper INF file(s). However, to construct a mesh assembled from several tiles (a mosaic), you should cut off the redundant rows/columns prior to call Resample.>For my sample file N47E011.hgt in the .inf is written:>Lat=48.0000000000>Lon=11.0000000000>>I understood this file contains the data from 47 deg to 48 deg>latitude and from 11 deg to 12 deg longitude. So I would>expect this to be in the inf file: >Lat=47.0000000000>Lon=11.0000000000This is because there is a difference regarding the geographic reference of the origin of the quadrant, between the HGT file and the Resample input mesh.The origin of the quadrant in HGT files is the lower left corner of the tile. By the other hand, Resample requires the origin to be the upper left corner of the mesh.>>In the generated.inf file is set:>NumOfCellsPerLine=1200>NumOfLines=1200>>Why is this not 1201 as documented in .hgt file spec?>This is a "program limitation", and will be changed in the next version.To understand the program behavior, see the following excerpt from the SRTM documentation:"The rows at the north and south edges as well as the columns at the east and west edges of each cell overlap and are identical to the edge rows and columns in the adjacent cell."Regardless of the number of 1-degree tiles loaded into FSDEM memory, the program always clip the north row and the east column of every tile loaded from disk.The program performs this clipping in order to avoid row and columnduplication when the tiles are joined to construct the mosaic.Unfortunately, when you "Load a Single HGT", the program is actually using the same clipping routines from "Load Multiple HGT", i.e., the program processes the single HGT like a mosaic of a single tile.The next FSDEM version, which is under testing, is going to keep the north row and the east column from the outer north and outer east tiles. This will give one more row and one more column of elevation data per mesh. I hope to release this version soon.Best Regards,Emerson

Share this post


Link to post
Share on other sites

Hi Emerson."The rows at the north and south edges as well as the columns at the east and west edges of each cell overlap and are identical to the edge rows and columns in the adjacent cell."This is correct, and exactly what resample would want. The cells are actually tranlated to verticies by the sim. If you eliminate verticies, then you'll have a defective mesh.Are you are trying to precombine HGT data? This is unnecessary.The best way to combine HGT files would be to let resample do it by declaring the INF TYPE as MultiSource, then adding the various HGT tiles as the sources. The area covered should be a rectanqular array of HGT files. The Destination must declare the bounds.The "NiagaraWithSeasons" found with the latest version of resample gives a multisource example ( using CUSTOM as the indivdual types ).The version of resample doesn't seem to matter.Dick

Share this post


Link to post
Share on other sites

Hi Emerson,thanks for the detailed answer. Now the behavior for me is much clearer. The 1200 / 1201 problem is not a real problem in my eyes. I just wanted to understand what is going on there.What I really would like MS to improve are the error messages of resample.exe....Jens

Share this post


Link to post
Share on other sites

Hello Dick,>The best way to combine HGT files would be to let resample do it>by declaring the INF TYPE as MultiSource, then adding the various>HGT tiles as the sources. The area covered should be a rectanqular>array of HGT files. The Destination must declare the bounds.I understand this concept and agree this is the best way in terms of simplicity.However, I don't recommend this approach when the output meshencompasses multiple source tiles, i.e., when the targetBGL is a rectangular area made from several adjoining HGTs.Working with individual SRTM tiles usually means that each tile is interpolated individually, prior to be submited to Resample.This method leads to poor and "distorted" interpolation results for voids located at or near the borders of the tiles. Poor because there might be not enough non void data in the neighbourhood to participate in the interpolation, and distorted because the availability of non void data is unbalanced in location, i.e., the data is restricted to the same tile from the void. Regards,Emerson

Share this post


Link to post
Share on other sites

Hi Emerson.I have not used your program, so I can't continue a discussion about it's benefits or problems. I'll download it and see what I can do.I've never noted resample ever distorting mesh... multisourcing or not... if the source data was good.Eliminating voids and flattening oceans for SRTM tiles can be done by other programs, and that output, multisourced, produces as good a mesh as can be made for most of the world. Use can be made of STRM30 data to also fill the voids or aid in ocean flattening.Regardless of the type of void or flattening manipulation, SRTM data will have problems with distortion. Mechanically bouncing radar off the earth from a space shuttle was never meant to produce an accurate DEM, but rather a base for which scientific manipulation could eventually produce better elevational data than which we now have. In this sense, it would be a little odd to think resample would add to any distortion, as plenty is already present in the source data. The enduser of SRTM mesh should be aware he is getting a rather rough approximation of the elevations... and if care is used by the mesh-maker, it'll be better, and more interesting than the default mesh. I actually believe SRTM data should be resampled at LOD7, because that will help hide the errors!Problems with mesh ( and landclass ) have been created by inexperienced mesh-makers not taking the time to learn resample, or how their manipulations of the source data affect the output. Similar problems can arise with the use of tools to make VTP or LWM polys and lines. The end result can often be a mess for endusers, sometimes even causing crashes of the sim.Nothing wrong with better tools, but the "democratization" of terrain creation can lead to many problems... 90% of terrain creation should be done between the ears, and 10% done by the tools.Dick

Share this post


Link to post
Share on other sites

>I've never noted resample ever distorting mesh...>multisourcing or not... if the source data was good.Dick,I think you have misunderstood my previous post when I used the term "distortion". I should have used some other term like "induced tendencies caused by lack of data".I've never said that Resample distorts the mesh.What I was trying to say is that better results can be produced if adjoining tiles are included in the interpolation process, performed in a single step, rather than interpolate each tile separately.Just to clear it up: the interpolation process i've mentioned is performed by GIS applications, not by Resample.Regards,Emerson

Share this post


Link to post
Share on other sites

Dear EmersonI've download and tested your tool FSDEM. It's a good tool for creation of meshes :-jumpy. Previously I've worked with SRTM_TO_BGL. Your tool is a step beyond: graphical interface, hgt voids filling, etc...Comparing (in some specific locations on tile N42W2) the BGLs of both tools, there're some differences. Also I've worked with microdem to get information from the raw HGT data. I've found one small difference (but maybe important if you're doing a photorealistic texture, as in my case) in the BGL by FSDEM compared to raw HGT data (microdem) and STRM_TO_BGL mesh: it seems that the FSDEM generated mesh is shifted about (I can't say exactly) 3" (one row in the HGT) to the north. I realise that when comparing the situation of mountain peaks with my photorealistic texture over the mesh.I don't know if this is systematic or I've made some mistake in the process.Anyway thank you for your tool.

Share this post


Link to post
Share on other sites

Hi Carlos,Thanks for the feedback!>I've found one small difference (but maybe important if you're>doing a photorealistic texture, as in my case) in the BGL by>FSDEM compared to raw HGT data (microdem) and STRM_TO_BGL>mesh: it seems that the FSDEM generated mesh is shifted about>(I can't say exactly) 3" (one row in the HGT) to the north. I>realise that when comparing the situation of mountain peaks>with my photorealistic texture over the mesh.>>I don't know if this is systematic or I've made some mistake>in the process.Yes, I'm already aware of the 1-row shifting in latitude.This has been fixed in the 1.1 version, which is under testing and is going to be released this week (I hope).This shifting is a collateral effect caused by the north row clipping (explained in a previous post), which is not compensated in the LAT parameter of the program generated INF file. :(If you'd like to help me on the 1.1 testing, then you may send me a private message with an e-mail address. :-rollRegards,Emerson

Share this post


Link to post
Share on other sites

Hi Emerson. The shifting is caused because the SRTM never needed to be clipped in the first place. That was the point of my first reply.SRTM is a grid of 1201x1201 verticies. There is no need to clip anything...resample will process it just fine if you use a multisource of SRTM blocks to create your final mesh.The only resaon I am cautioning here, is that by altering the number of verticies, or the bounds of the source data, you are in danger of further removing the accuracy of the mesh. If that proves to be the case in the future, many novice mesh-makers will be releasing less than quality mesh, and not have a clue how to fix it... the same problem SRTM2BGL caused.Dick

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this