• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

FS2004 Multilines in setup.ini for Resample.exe

Messages
258
Country
luxembourg
Hey guys I have a question about the setup.ini-file for the Resample.exe file. I have 12 files. Here a screenshot of the source files:


Now I'll come to the problem. The setup.ini file and the setup of that file makes me mad. I read the document from the SDK Creating Terrain that I need to add the line CellXdimensionDeg and the line CellYdimensionDeg to that setup.ini so that resample can locate the mesh. My problem is that I have no clue from where I get that CellXdimensionDeg and CellYdimensionDeg value.

Then I have my next problem with my source files. In which format do they need to be so that resample.exe can use them for FS2004. (For FSX I have them done already, however FS2004 is a bit tricky in my opinion)

In addition I wanted to ask you if my setup.ini file is complete in this status:
Code:
[Source]
Type = MultiSource
NumberOfSources = 3


[Source1]
Type = GeoTIFF
Layer = Elevation
SourceDir = "Source"
SourceFile = "ASTGTM2_N52W001_dem123.tif"
CellXdimensionDeg = TO BE DETERMINED
CellYdimensionDeg = TO BE DETERMINED

[Source2]
Type = GeoTIFF
Layer = Elevation
SourceDir = "Source"
SourceFile = "ASTGTM2_N52W002_dem123.tif"
CellXdimensionDeg = TO BE DETERMINED
CellYdimensionDeg = TO BE DETERMINED

[Source3]
Type = GeoTIFF
Layer = Elevation
SourceDir = "Source"
SourceFile = "ASTGTM2_N52W003_dem123.tif"
CellXdimensionDeg = TO BE DETERMINED
CellYdimensionDeg = TO BE DETERMINED

[Destination]
DestDir = "Output"
DestBaseFileName = "Terrain"
DestFileType = BGL
LOD = Auto

I hope there is somebody out there who can help me. Thanks in advance for any help/hint about this
Kevin
 
Hi Kevin.

First, this would be for using the FS2004 SDK resample.exe

For the FS2004 version, resample cannot use Geotiff. So any data from that source would need to be translated to an acceptable format. FWTools is an open sourced set of tools that will allow such a translation. gdal_translate is the specific tool we would need, is found in that package.

Supposing that the data is in wgs 84 datum and lat-long format ( geographic ), you can make a batchfile to translate the data to BIL 16-bit signed integer, which is what resample likes.

Code:
gdal_translate -of EHdr 20111216084825_1795853552.tif 20111216084825_1795853552.bil

This gives me the BIL file and some extra files that define the data as an ESRI BIL file. The 20111216084825_1795853552.hdr is a text file that contains the info I need for making the INF file:

Code:
BYTEORDER      I
LAYOUT         BIL
NROWS          6009
NCOLS          10845
NBANDS         1
NBITS          16
BANDROWBYTES   21690
TOTALROWBYTES  21690
PIXELTYPE      SIGNEDINT
ULXMAP         158.872089892393
ULYMAP         -8.40928489232817
XDIM           0.000277784785615491
YDIM           0.00027778465634881
NODATA         -32768

From this, I can construct the test.inf file I use to resample the data:

Code:
[Destination]
LOD = Auto
DestDir = "."
DestBaseFileName = "Test"
UseSourceDimensions = 1

[Source]
Type = ElevS16LSB
SourceDir = "."
SourceFile = "20111216084825_1795853552.bil"
Lat = -8.40928489232817
Lon = 158.872089892393
NumOfCellsPerLine = 10845
NumOfLines = 6009
CellXdimensionDeg = 0.000277784785615491
CellYdimensionDeg = 0.00027778465634881

Cell dimensions are the decimal degree span, divided by the number of data-points minus 1. You need the north, south, east, and west decimal degree limits of the data to determine it manually.

CellYdimensionDeg = ((north - south) / (NumOfLines - 1))
CellXdimensionDeg = ((east - west) / (NumOfCellsPerLine - 1))


Probablythe easiest way to get ASTER dem data is to use the Global Data Explorer

You can get ASTER dems in a geotiff format that FSX resample will accept, and they convert properly to BILs using gdal_translate for FS2004 ( or earlier ).

Dick
 
Hey Dick, thanks for your help! Really appreciating.

Ok after understanding now the batchfile-thing, I got it finally "translated".
Now I have just a question. I get another .hdr file than you which makes me a bit thinking that I made a mistake...

Here the complete .hdr file from my ASTGTM2_N52W001 file:
Code:
BYTEORDER      I
LAYOUT         BIL
NROWS          3601
NCOLS          3601
NBANDS         1
NBITS          16
BANDROWBYTES   7202
TOTALROWBYTES  7202
PIXELTYPE      SIGNEDINT
ULXMAP         -1
ULYMAP         53
XDIM           0.000277777777777778
YDIM           0.000277777777777778

Now the ULXMAP and the ULYMAP seems to be correct, however my XDIM and my YDIM are equal. This must be wrong or, because then the whole mesh will be a point no? Or is it just my brain who thinks too much?

thanks again Dick for your help!
Kevin
 
The header is OK.

This is an ASTER tile, representing 1 degree. The north-south and west-east are both 1 degree, and the data is 3601 points each way so the xdim and ydim would be the same distance. xdim and ydim describe the distance between the data points in decimal degrees... in this case they are the same distance in fractional degrees.
 
Just to clear this up Dick: The source part should then look like this:

Code:
[Source1]
Type = ElevS16LSB
SourceDir = "Source"
SourceFile = "ASTGTM2_N52W001_dem123.bil"
Lat = 53
Lon = -1
NumOfCellsPerLine = 3601
NumOfLines = 3601
CellXdimensionDeg = 0.000277777777777778
CellYdimensionDeg = 0.000277777777777778

And now this is all I need to do? Nothing more to add?
Quite simple if it is only this..

greets Kevin
 
That should work... try it out and check the results in TMFViewer ( FSX TMFViewer will show the LOD of the mesh ).

Dick
 
Hey Dick, now after copy&paste errors it finally worked out like a charm.
However in FS9, I think I have a little problem. When the Terrain folder (which just contains the mesh for the scenery) is active then I get this picture in FS9:
fsscr001.jpg


You see that rectangle around the airport? When I disable that Terrain folder, then it looks like it should look:
fsscr003w.jpg


My setup.ini looks now like this (I post this directly with, maybe I did a mistake):
Code:
[Source]
Type = MultiSource
NumberOfSources = 3

[Source1]
Type = ElevS16LSB
SourceDir = "Source"
SourceFile = "ASTGTM2_N52W001_dem.bil"
Lat = 53
Lon = -1
NumOfCellsPerLine = 3601
NumOfLines = 3601
CellXdimensionDeg = 0.000277777777777778
CellYdimensionDeg = 0.000277777777777778

[Source2]
Type = ElevS16LSB
SourceDir = "Source"
SourceFile = "ASTGTM2_N52W002_dem.bil"
Lat = 53
Lon = -2
NumOfCellsPerLine = 3601
NumOfLines = 3601
CellXdimensionDeg = 0.000277777777777778
CellYdimensionDeg = 0.000277777777777778

[Source3]
Type = ElevS16LSB
SourceDir = "Source"
SourceFile = "ASTGTM2_N52W003_dem.bil"
Lat = 53
Lon = -3
NumOfCellsPerLine = 3601
NumOfLines = 3601
CellXdimensionDeg = 0.000277777777777778
CellYdimensionDeg = 0.000277777777777778

[Destination]
DestDir = "Output"
DestBaseFileName = "Terrain_1"
DestFileType = BGL
LOD = Auto

The TMFViewer file looks quite it should look:
fsscr005f.jpg


Now the question of the questions: What the heck did I do wrong?
Did I missed a step or is this "flattening" done automatically due to the airport?

thanks again in advance for any help and any advice!
Kevin
 
Last edited:
It would be the airport, or another flatten. The mesh looks OK.

In FS2004, we do not have the ability to exclude flattens. Either find the file and disable it, or if that is not possible, rewrite the file that causes the problem ( saving the original, of course ).

ASTER dems are not reworked much. they can have spikes and pits and runs, and gaps. They also can have large areas not at the correct elevation, as the files have not been vertically adjusted. ASTER is pretty raw compared to SRTM.

Dick
 
Hey Dick, I tried now a lot of ways to sort out the problem of that flatten, however I can't get rid of it.

I have one folder for the terrain/mesh which contains only ONE file. Terrain.bgl (which is in fact the terrain/mesh of the airport). The other folder is the airport folder. This contains one flatten, the AFCAD, the buildings,...

When I deactivate the terrain folder and activate the airport folder then I have not such a flatten area. If I deactivate the airport and the terrain folder, I have not such a flatten area. If I activate the terrain folder then I have that flatten area. When re-reading this I find it a bit complicated to get out what I meant. So here a little bit simplier:

Case A:
Activated: Terrain folder
Deactivated: Airport folder
Conclusion: Flatten area is there.

Case B:
Activated: Airport folder
Deactivated: Terrain folder
Conclusion: No flatten area.

Case C:
Activated: Nothing
Deactivated: Airport folder and Terrain folder
Conclusion: No flatten area.

Case D:
Activated: Airport folder and Terrain folder
Deactivated: Nothing
Conclusion: Flatten area is there.

So I conclude out of this:
If I have my Terrain.bgl (the file which contains the mesh-data) activated, then I have that flattened area. If I have disabled Terrain.bgl, then I have not this problem. Did I made a mistake while compiling/recompiling/... the file or does this really come from a Flatten (exclude)?

regards Kevin
 
Just a quick question:

Can it be that the resample.exe made a "mistake" here. I am using V 1.0.0.4. for FS2004. Is that good or should I use another version? If yes, can you maybe give me a download place for that file or upload it for me somewhere so that I can have the right version.

regards Kevin
 
Just a quick question:

Can it be that the resample.exe made a "mistake" here. I am using V 1.0.0.4. for FS2004. Is that good or should I use another version? If yes, can you maybe give me a download place for that file or upload it for me somewhere so that I can have the right version.

regards Kevin

no the 1.0.0.4 is the same i got and i think the latest version, the mesh looks ok in my opinion, there is just one hidden file which flattens this area or gets in conflict with your created mesh
 
Hey guys, just another question to ask you if this is "normal" or not.

My source is the ASTER format from N49E005 (filename: ASTGTM2_N49E005.zip).

After now translating the whole file into the correct format for FS2004, I get as .hdr-file this:
Code:
BYTEORDER      I
LAYOUT         BIL
NROWS          3601
NCOLS          3601
NBANDS         1
NBITS          16
BANDROWBYTES   7202
TOTALROWBYTES  7202
PIXELTYPE      SIGNEDINT
ULXMAP         5
ULYMAP         50
XDIM           0.000277777777777778
YDIM           0.000277777777777778

With this information I am a bit confused. ASTER tells me that the file matches the area N49 E005, but I get as ULYMAP=50 and ULXMAP=5. ULXMAP seems to be correct, but ULYMAP is 50 instead of 49. Is that normal or do I need to manually substract 1 so that ULYMAP=49?

That is not normal or is it?

thanks in advance Kevin
 
The tile name is from the SW corner... so the name is what's confusing you. SRTM tiles follow the same dumb naming convention.

The ULYMAP as 50 is correct. The NW corner is N50E005.

Dick
 
Last edited:
Ok thanks Dick for pointing this out. Now I am calm again as I now know that I did not make a mistake :)
 
Back
Top