Mesh: Underlying FS Mesh Quadrants

[Guest]

Steve wrote a couple of weeks ago in this forum>... any replacement mesh must cover a full quadrant> of the underlying fs mesh; otherwise it will not be used...This could be the solution to a problem I encountered and therefore I'd like to know how to find out how big the quadrants of the underlying fs mesh are and where they are exactly located.Thanks, SaintX

[Guest sgreenwood]

Hello SaintX,The sizes of the quadrants are provided in the MS Terrain SDK - p. 9. For example:[table border=1" width="350][tr][td]

[Guest]

That's a good explanation Steve! However, after reviewing Christian Stocks information on flattening polygons, I've found that it seems that the quadrant latitude numbers run north to south starting at the north pole and longitude numbers run west to east starting at the 180 degree meridian. This is just speculation on my part at this point as I am working on verifying this now. And again, this is for flattening polys, elevation quadrants may be defined differently, but I would be surprised if they were. ;-)But your quandrant boundries are correct and your method works very well to determine them correctly.Leland Steffensen

[Guest]

Hi Steve,thanks for your quick reply. Perhaps you can help me, but I surely understand this may overstrech your patience or resources. If so do not hesitate to tell me.I'm living near Frankfurt/Germany and I'm addicted to the US southwest landscape, especially to Utah. I once visited the Kennecott (spelling?) open pit copper mine a few miles southwest of Salt Lake City which is said to be the (or one of the) biggest hole on earth, one of the largest man made structures and one of a few man made structures which are even visible from space with plain eyes. It should be visible in FS2002, and indeed it is somewhere near N 40' 32'' W 112' 8'', but due to its low resolution and inappropriate texture it's nearly undetectable. (If I figure out how to use the screenshot forum I might post a real life/FS2002 comparison there.) That's why I selected this piece of earth as my first attempt with mesh scenery. Unfortunately, this attempt was a failure, and I don't know why.Perhaps you or someone else could comment whether generation of the mesh was correct so far.1) I downloaded a 1:250,000 dem file from USGS (tooele-e.gz), unzipped it to tooele-e.dem, and converted it into a binary (dem_tooele.dem) using read_dem.exe2) I created the following *.inf file:[Destination]LOD = 10DestDir = "dest"DestBaseFileName = "Tooele"UseSourceDimensions = 1[source]Type = ElevS16LSBSourceDir = "d:simsdk"SourceFile = "dem_tooele.dem"Lat = 41Lon = -113NumOfCellsPerLine = 1200NumOfLines = 1201CellXDimensionDeg = 8.33333333333333333333333333333333e-4CellYDimensionDeg = 8.33333333333333333333333333333333e-4ScaleinMeters = 1I'm not sure whether LOD=10 is correct, nor whether NumOfCells... and NumOfLines... are correct, and I don't know how to figure out whether the Type (ElevS16LSB?) is correct for the raw data I choose.I use points <.> instead of colons <,> since this is the country specific Windows configuration to display a decimal separator for my country.3) I resampled the binary *.dem with this *.inf, compressed the resulting *.tmf and converted it to a *.bgl without merging anything. The result was a 2,196KB *bgl file.4) I created a ...tooelescenery and ...tooeletexture folder, copied the *.bgl into the scenery folder, started FS2002 and entered the new *.bgl into the scenery data base.The results were: Mountains popping up and disappearing suddenly, some steep cliffs, wrong textures in places were they were correct in the default scenery, >>> and no additional detail at all <<<.I didn't care for any underlying default mesh quadrants, should I? If I understand your previous post correctly, there should be most of the default quadrants completely covered by my new mesh with problems only around the borders, but can this explain all abovementioned erratic behaviour?I didn't care for any changes in any of FS2002 config files, should I?I'm aware that higher resolution dem's are available, but even with the choosen 1:250,000 data the mesh should be more detailed than the default mesh, shouldn't it?Thanks for your help and hints, Yours,Chris aka SaintX

[Guest sgreenwood]

Thanks Lee,I will have to look into this a bit further.Steve

[Guest]

LOD 10 provides a high oversampling for that resoulution of data. I would use LOD 8 or 9 instead.ELEVS16LSB - binary data is a 16 bit word (two bytes) with the least significant byte being the higher order. You need to know how your ASCII to binary converter creates the data. If it is using the most significant byte as the high order byte (Motorola processors use this) then use ELEVS16MSB.NumOfCellsPerLine = columns in your binary file.NumOfLines = rows in your binary file.Your cell dimensions need to be accurate. If you don't know the distance between points, you can use the following...CellXDimensionDeg = (East Lon - West Lon) / (NumOfCellsPerLine - 1)CellYDimensionDeg = (North Lat - South Lat) / (NumOfLines - 1)The bottom line is that you need to know exactly how that binary file is set up. The Northwest coordinates has to be exact along with the other data. The erratic behaviour could be due to any of data elements in your INF file not matching the exact dimensions of your binary file.Shameless Plug follows....If your interested in Utah, you might want to go to www.fsgenesis.com. Justin Tyme and I have provided a series of high detailed mesh sceneries for the USA. Also, his Mesh Central site has lots of freeware mesh for the taking.Lee.

[Guest sgreenwood]

Hi Chris,I'm glad to help if I can. I've certainly seen my share of the results you describe.I have the tooele-e.gz data, so I ran it through my conversion process and got essentially the same inf file as you, except I use exact coordinates for the destination location (instead of "UseSourceDimensions = 1"). ----------------------------------------LOD=10DestDir="."DestBaseFileName="tooele-e"NorthLat= 40.95703125SouthLat= 40.078125WestLong=-112.96875EastLong=-112.03125Type=ElevS16LSBNullCellValue=32767SourceDir="."SourceFile="tooele-e.bsq"Lat= 41Lon=-113NumOfLines= 1201NumOfCellsPerLine= 1201CellYdimensionDeg= 8.33333333333333E-04CellXdimensionDeg= 8.33333333333333E-04ScaleinMeters= 1----------------------------------------LOD 10 is ok, but I prefer LOD 9 for this lower resolution source data. It will work, just larger files, and almost no improvement in detail."I use points <.> instead of colons <,> since this is the countryspecific Windows configuration to display a decimal separator for my country." - I doubt the SDK understands "," as a decimal separator, but I never tested it; your inf file above uses ".". Was that how you ran it?You do not need to worry about the underlying quadrants with this data. The SDK will trim off the borders that extend beyond the LOD grid, so there should be no problem because of imperfect fit.The mesh you are using is much better than the default for most, but not all, of the US. I just took a look at the pit mine using the data you are working with at LOD10, then with 30m LOD10. There is a bit more detail in the 30mLOD10 mesh - you can even see where the roads spiral down into the pit! I am sure you will be happy with your results. I changed the season to winter, and time to 4:00pm to enhance the contours. Your are right, I can't see much either with the summer textures.Conclusion:My final bgl file size was a little larger than yours, perhaps because I used 1201x1201? I would try changing your inf to match mine, using the US decimal separator, precise output coordinates, and NumOfCellsPerLine=1201. I am not sure any of this is enough to help. You can e-mail me at support@fs-traveler.com if you would like to continue this discussion off-line.Good luck, Stevewww.fs-traveler.com

[Guest]

your answers come faster than I can read! It's mother's day, so I'll spend the evening with my family. Later I'll give the mesh another try and report the results.You guys do a wonderful job here and it really is a great pleasure to post on one of the AVSIM forums!Yours,Chris

[Guest sgreenwood]

Lee,I took a quick look at Christian's notes and MASM code for flattening polygons. He does claim that the LOD quadrants are numbered as you describe. This is curious, perhaps it is because he is working in the Southern Hemisphere. :) The number I calculated was not intended to serve as an official LOD quadrant identifier, it is merely an offset (in LOD units) from the geographic grid references - the equator and prime meridian. That is why the calculations are correct. I believe you can easily reconcile my number with his. For example, to convert to his LOD 9 row: there are 90 degrees/(2^9) = 512 LOD 9 quadrants from the equator to the north pole, so 512 - 239 = 273 - the official LOD grid identifier for his purposes?Stevewww.fs-traveler.com

[Guest]

SaintX,That would be great if you or someone could make an authentic looking mine.I live just about ten-minutes from the mine, I use to ride my bike up those mountains all the time. It is truley amazing what man did to that whole side of the mountain.I was thinking about taking a ride up there to get some pictures, I could post them here in jpeg format if you would like to get a good look at what the mine looks like.Lee,Thanks for the link, you guys did some great Mesh Terrain !!LOL !! How did you guys get a 35M mesh going, WOW !! Just might have to scrap the piggy bank for that one !! LOL !!Steve,Great tips, I will use those, this has been a very helpful thread to read.Many Cheers Jackknife.............

[Guest sgreenwood]

Lee, my equation above - "90 degrees/(2^9) = 512" should read "90 degrees/0.17578125 = (2^9) = 512"Steve

[Guest]

Hello folks,thanks to your support, 250K DEM data seem to work for me now. But now I've difficulties to produce a mesh scenery from 24K DEM data.I understand, that 24K DEM's are available in 30m and 10m resolution. I got mine from www.mapmart.com.This is what I did to convert the 30m data:1) unzip2) run sdts2dem.exe (newest version I found, approximately 3/2002). With the 30m SDTS for bingham canyon / UT (215 kb) I got a *.dem of 1066 kb.3) run read_dem.exe to convert this 1066 kb *.dem into a binary, which resultet in a 328 kb file.4) write an *.inf file:[Destination]LOD = 10DestDir = "dest"DestBaseFileName = "bc"NorthLat= 40.625SouthLat= 40.5WestLong=-112.25EastLong=-112.125[source]Type = ElevS16LSBSourceDir = "d:simsdk"SourceFile = "dem_bc.dem"NullCellValue=32767Lat = 40.625Lon = -112.25NumOfCellsPerLine = 359NumOfLines = 467CellXDimensionDeg = 3.49162011173184357541899441340782e-4CellYDimensionDeg = 2.68240343347639484978540772532189e-4ScaleinMeters = 15) run resample with this *.inf to get a *.tmf file. This tmf is 1 kb small (which probably is far too small), and the further steps (tmfcompress, tmf2bgl) produce a bgl in the end without any visible impact in FS2002.What went wrong? I suspect the error is in the conversion to a binary. Or is it my *.inf again?Of course I'd be intereseted in using the 10m SDTS also. I learned from the old forum that these data can be converted into the binary using microdem and mdem6bsq.exe. Microdem reads the data, converts them to the mdem format, mdem6bsq converts them into the binary format, but from that point on I get the same problems listed above. Any ideas?Yours, Chris

[Guest sgreenwood]

Hi Chris,I am pleased to hear of your success, although you say it "seems" to work. I recommend using screen captures to compare your results with the default/alternatives. I use FSScreen to capture the screens to .bmp files. Here is a link: I am not familiar with the tools you are using, but I have a few suggestions.1) You will probably need to use LOD 11 for a single 7.5 minute SDTS grid; LOD 10 will not create a large enough area to cover an LOD 10 quadrant.2) Microdem creates a proprietary DEM file. MDEM2DEM was written specifically for MSFS. It strips the header off the file, then "rotates" the data matrix to the arrangement the SDK requires. I am not sure mdem6bsq performs this "rotation". This is available at: [link:www.terrainmap.com|mdem2dem]3) I prefer to use Microdem because if can be configured to translate the SDTS data from NAD 27 to WGS84 when saving as a DEM, as required by the SDK. You will also have to make a subset of the data, to produce a rectangular sample.4) There are other challenges with the SDTS format. There are often gaps in the data, along the borders when you merge multiple files. For this reason, I suggest you experiment with some relatively "clean" 30m data from the USGS NED site. You can get free data for areas equivalent to about 16 SDTS Dems in a single file. [link:edcnts14.cr.usgs.gov/Website/seamless.htm]NED DataGet the DEM data in BIL format.Import the BIL file into Microdem and save as DEM.You can easily use Microdem to merge several of these before proceeding.5) I converted the Bingham Canyon SDTS to DEM in Microdem. 328K with header and margins, so I am concerned with the 1066kb file you report. We used different processes, but the files should be closer to the same size. The binary does seem to be about the right size.So, a few Suggestions:1) try LOD 112) use mdem2dem to do the conversion3) try NED dataGood Luck,Stevewww.fs-traveler.com

[Guest]

Hi Steve,thanks again for your suggestions. I wrote the 250K mesh "seems" to work because I actually am still not sure whether they are more detailed than the default mesh. Perhaps I expected to much, perhaps my FS2002 directories are 'contaminated' with a mesh I may have downloaded before and forgot meanwhile.... nevertheless, all above reported visual errors are gone with my last 250K based meshes.Yesterday your link to fsscene was not working for me, but I found it elsewhere.I wasn't successful with the NED data. I didn't receive my confirmation email with the downloading instructions so far, and today the NED website apparently doesn't work at all.In microdem I indeed observed large gaps along some, but not all borders along merged 10m STDS files. If I load and merge the same files into dlgv32pro there are no gaps, so this might be a microdem related problem. Unfortunately, the freeware version of dlgv32pro does not allow to save the merged files.You mention a 'rectangular sample' of SDTS data. Does this mean that a single SDTS file connot be used without clipping the borders? How do I achieve a truely rectangular sample? Does the grid overlay of the microdem screen provide any orientation? By the way, which version of microdem would you recommend?...just got a call from the hospital I work for, so I'll have to go for a while.Yours, Chris

[Guest sgreenwood]

Hi Chris,The 250k data provides a considerable improvement in most areas, but is most obvious where the terrain features are small. The mountains around your open-pit mine are pretty good in the default mesh, the improvements with the 250k data here are nice, but subtle. There are a pair of 1000' hills near me that don't show up at all in the default mesh, but are quite nice with 250k data, and even more detailed with 30m data.You should find fsscreen helpful for comparing mesh file effects. I feel it is essential for developers to store mesh files in separate scenery folders so you can activate/deactivate known areas.(I changed the link for fsscreen to another source so it works now; I believe my hosting server may have to be reconfigured. Thanks for the note.)The NED server is somewhat unreliable, especially on weekends. It also seems to be unavailable for a short time each morning about 5:00am EST. Service also slows down noticeably from 8:00am on; early mornings are best for ordering. You should get your confirmation soon, however. They lose only a very few. When I placed orders before 5:00am, I sometimes had notifications start arriving (and data available) within a couple hours!I don't have much experience with dlgv32pro, because it could not save the files. This is not a trivial issue; I suspect this is at least part of the reason why the NED service exists.When I import a sample SDTS ddf file and Calculate-Map Window Corners I get the following:N 40.62483