• 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.

P3D v5 Not a TIFF file, bad version number 43 (0x2b) - File size too large

scotth6

scotth6

Messages
542
Country
australia
Hi,

I'm trying to create some mesh for the Houston area. I have downloaded the 1m DEM files from USGS, stitched them together with FWTools/gdal, then reprojected to WGS84 also with gdal. That took a long time to create a pretty large file (31GB). I can see it's still a GeoTiff when I import it into QGIS, but when I try to create a mesh with resample I get this error message:

C:\downloads\BMPs\Houston_DEM_WGS84.tif: Not a TIFF file, bad version number 43 (0x2b).
Unable to open data source 'C:\downloads\BMPs\Houston_DEM_WGS84.tif'.
Failed to create data source.

I am assuming the issue is the large file size. What is the maximum size I can use for a GeoTiff source file? I really don't want 78 individual mesh files just for the Houston area. Maybe I can split the large file into 4 somehow?
 
scotth6 said:
Maybe I can split the large file into 4 somehow?
Click to expand...

Assuming you meant 4 GB maximum size per terrain mesh BGL, then, yes, that would work; FS2Kx SDK Resample will not output BGLs larger than 4 GB

One can use directives in the INF file to iterate processing of source data to force output of multiple BGLs for the total extent of the requested areas using all submitted source data that does not have NODATA exclusion areas.

Before I would output the BGLs, however, I would want to know where I actually needed 1 Meter resolution in the Terrain.

Thus, other output directives may be indicated for areas where one is AGL in an aircraft, to reduce LOD resolution while increasing coverage extent via use of lower local Quad LOD values, and thus to reduce resulting size (and number) of output BGLs.

In FS2Kx, we normally are at flight level in user aircraft, and higher LODs will not be rendered at run time, unless one is on ground and/or otherwise not too far AGL in that aircraft cockpit.

In the morning, I will try to find and post some references to the FS2Kx SDK Resample INF iterative output directives I alluded to above.

GaryGB
 
Last edited:
Thanks Gary. I actually meant split the source GeoTiff into 4, so each source file would be 7.5GB. Not sure what the limit is on source files. There were originally 78 individual files, so I didn't want to reproject 78 individual files and create 78 individual bgls. My purpose for creating the mesh so fine is that I've seen great results with photoreal combined with mesh that is 1m to 5m, using a high res source data. It's more for experimentation and creating for the sake of it a bit too. It's been a while since I created much, and recently had the urge again. I used to love making small areas of hi res mesh in small areas using LIDAR data from OpenTopography, and like I said the results looked really good, just like the photogrammetry we see in MSFS. My first one was the meteor crater in Arizona quite a few years ago, and then others like Whitesands, Slater NM, Susquehannock, or anywhere that had interesting features. Then just the other day I was looking for DEM data for Walton Beach in Florida on USGS and happened to see that Houston had hi res DEM data available, and as I had just installed PR for Houston and had been flying there, it seemed like a good idea to try and create some mesh just to see what the result would be. Thanks.
 
I managed to find a way, thanks Gary. I combined rows of the original DEM GeoTiffs, ending up with 9 files, and first I thought I had cracked it, but then once again, 6 out of the 9 files were too large, being between 4.1GB and 4.6GB. Then I tried to use compression in the gdal warp phase, but when I used COMPRESSION=DEFLATE I found that resample didn't like those files. Then I tried COMPRESSION=LZW, and finally those file sizes were reduced enough AND were accepted by resample. The resulting BGLs are tiny in comparison. For example the GeoTiff "Houston_DEM_WGS84_1.tif" is 3.47GB, but produces a BGL of just 7.61MB!
 
For anyone reading later, the methods I used were:

Combined groups of files using a virtual raster method, eg:

gdalbuildvrt mosaic.vrt C:\Users\scott\Desktop\Houston_LIDAR\DEM\7\*.tif

then

gdal_translate -of GTiff -co "TILED=YES" mosaic.vrt C:\Users\scott\Desktop\Houston_LIDAR\DEM\mosaic_7.tif


Starting with 78 files, I ended up with 9 larger files. 6 of the 9 were still above the 4GB size limit, so in the reprojection stage (gdal warp) I used compression. Note that "COMPRESSION=DEFLATE" produced a GeoTiff that caused an error in resample. The "COMPRESSION=LZW" method worked, and reduced the file size sufficiently.


gdalwarp -of GTiff -co "COMPRESS=LZW" -co "INTERLEAVE=PIXEL" -s_srs "+proj=utm +zone=15N +datum=NAD83" -t_srs "+proj=latlong +datum=WGS84" -r cubic C:\Users\scott\Desktop\Houston_LIDAR\DEM\mosaic_7.tif C:\Users\scott\Desktop\Houston_LIDAR\DEM\4326\Houston_DEM_WGS84_7.tif


then running the resulting GeoTiffs through resample with:


[Source]
Type = GeoTIFF
Layer = Elevation
SourceDir = "BMPs"
SourceFile = "Houston_DEM_WGS84_7.tif"
NullCellValue = 0

[Destination]
DestDir = "Output"
DestBaseFileName = "Houston_DEM_7"
DestFileType = BGL
LOD = Auto
CompressionQuality = 95



For this file/bgl, a GeoTiff that was 3.58GB produced a BGL of 12.7MB.
 
Hi Scott:

That was a very impressive use of some obscure options in both GDAL and SDK Resample to yield an astonishingly small output BGL size. :wizard:

Just out of curiosity, when the output BGL is opened in TMFViewer, what LODs did SDK Resample actually create for the area of interest ? :scratchch

GaryGB
 
Last edited:
Thanks Gary. This was a success in that I learned a few things. Houston was terrible place to make a 1m DEM for though. It is fairly flat 😄. I can see mounds of dirt, riverbeds, gullies etc in the mesh when down very low though, which looks good. Unfortunately at 1m resolution the mesh is constantly morphing as I fly. In TMF viewer there appears to be lines visible at the border of each section that I created, although that wasn't obvious in the scenery. In TMF viewer the mesh shows as LOD 1 up to LOD 15. I am surprised at how small the output files are, although I suppose they are for a pretty small area.

Screenshot 2024-12-07 012850.jpg
 
Last edited:
You must log in or register to reply here.
Back
Top