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

On fraction bits

After creating 10-meter terrain mesh for several states in the U.S., I have finally come across what appears to be a terracing effect. Not a very good example, but you can see below what looks like graph paper laid over the mountain.

2020-7-5_9-59-21-951.jpg


My source data is USGS 1/3 arc-second, 1-degree lat/long tiles. I convert to WGS84 and export via QGIS, then generate an INF file like this:

[Source]
Type=GeoTIFF
Layer=Elevation
SourceDir="."
SourceFile="N36W118.tif"
PixelIsPoint=0
NullValue=-32767

[Destination]
DestDir="."
DesFileType=BGL
DestBaseFileName="N36W118"
CompressionQuality=100
LOD=Auto

Here is an example of the tile as it appears on TMFViewer:

tmf.JPG


Is this the terracing effect that can be cured by including FractionBits in the INF file? I had started with FractionBits=3, but GaryGB advised that the quality of the USGS data was such that the FractionBits code didn't appear necessary -- when I was dealing with tiles in Missouri. Given that I am creating 1/3 arc-second mesh for the entire conterminous United States, will having scenery in some tiles generated with FractionBits in the INF file be consistent with those that do not have that code?

Thanks,
 
Hello Chris, try this ... for me it is satisfactory!

[Source]
Type=GeoTIFF
Layer=Elevation
SourceDir="."
SourceFile="N36W118.tif"

[Destination]
DestDir="."
DesFileType=BGL
DestBaseFileName="N36W118"
FractionsBits = 3
LOD=Auto,11
 
What I have attached to you is my .INF configuration, if then there are still those marked terraces it can also depend on the quality of the source DEM file.
 
Source quality could be it. Occasionally when I import USGS elevation data there is a warning that pops up asking to convert the data to another format with varying options of accuracy. Perhaps that's evidence that despite all data coming from the same source, some tiles are older and are of a different format and maybe that is when I get terracing. I'll probably have to re-examine each tile on TMFViewer and look for the grids/lines. As indicated above, it does show up when you zoom in close enough.
 
After learning more about terrain design, I realized that the terracing effect I see seems to be caused by reprojecting and not resampling. The TIF files I load into QGIS from USGS 1/3 arc-second data look good until they are reprojected to WGS84 format. Perhaps this is why I haven't noticed much difference when adding "fractionbits" into the INF file.

Before projection:
Untitled.png

After reprojection:
Untitled1.png

The metadata for this file:
Code:
<geodetic>
<horizdn>North American Datum of 1983</horizdn>
<ellips>Geodetic Reference System 80</ellips>
<semiaxis>6378137.000000</semiaxis>
<denflat>298.2572221</denflat>
</geodetic>
</horizsys>
<vertdef>
<altsys>
<altdatum>North American Vertical Datum of 1988</altdatum>
<altres>1.000000</altres>
<altunits>meters</altunits>
<altenc>Implicit coordinate</altenc>
</altsys>
</vertdef>

Is it possible to use reprojecting commands in my OSGeo4W interface instead of QGIS, like I use to create photoreal scenery? I'm hoping there is a way to fix this issue before I officially release the scenery to the public as freeware -- it's good enough for me, but not if I'm publishing it. I just wish I had looked into this further before I was almost done compiling 10m scenery for the entire conterminous United States.
 
After learning more about terrain design, I realized that the terracing effect I see seems to be caused by reprojecting and not resampling. The TIF files I load into QGIS from USGS 1/3 arc-second data look good until they are reprojected to WGS84 format. Perhaps this is why I haven't noticed much difference when adding "fractionbits" into the INF file.

Before projection:
View attachment 63670

After reprojection:
View attachment 63671

The metadata for this file:
Code:
<geodetic>
<horizdn>North American Datum of 1983</horizdn>
<ellips>Geodetic Reference System 80</ellips>
<semiaxis>6378137.000000</semiaxis>
<denflat>298.2572221</denflat>
</geodetic>
</horizsys>
<vertdef>
<altsys>
<altdatum>North American Vertical Datum of 1988</altdatum>
<altres>1.000000</altres>
<altunits>meters</altunits>
<altenc>Implicit coordinate</altenc>
</altsys>
</vertdef>

Is it possible to use reprojecting commands in my OSGeo4W interface instead of QGIS, like I use to create photoreal scenery? I'm hoping there is a way to fix this issue before I officially release the scenery to the public as freeware -- it's good enough for me, but not if I'm publishing it. I just wish I had looked into this further before I was almost done compiling 10m scenery for the entire conterminous United States.

Hi Chris:

Sorry, apparently I must have missed this thread when it began in the first week of July (I was probably traveling then).


AFAIK, it is more likely that the terracing effect you see is caused by resampling and not re-projecting.


IIUC, the question is what output Bit Depth GeoTIFFs are you generating from QGIS when you process the above DEM source data ?

Another question is whether Metadata for each CONUS USGS DEM source file is individually inspected / known before configuring multi-source SDK Resample *.INF files ?


The goal of using Scaled Elevation Values via SDK Resample *.INF FractionBits parameter values is to force Resample to derive sub-Meter units from Integer Meters.

[EDITED]

https://www.prepar3d.com/SDKv4/sdk/world/terrain/terrain_overview.html#Destination Parameters

See
:

Using Scaled Elevation Values​

[END_EDIT]

To do this one must submit the source GeoTIFF DEMs to SDK Resample in 32-Bit Floating Point format.


The file cited in your latter example immediately above is already in that format:

ftp://rockyftp.cr.usgs.gov/vdelivery/Datasets/Staged/NED/13/TIFF/n36w102/

ftp://rockyftp.cr.usgs.gov/vdelivery/Datasets/Staged/NED/13/TIFF/n36w102/USGS_13_n36w102.tif

...shows this Metadata in Global Mapper:

FILENAME=[path]\USGS_13_n36w102.tif
DESCRIPTION=USGS_13_n36w102.tif
UPPER LEFT X=-102.0005092601
UPPER LEFT Y=36.0005092600
LOWER RIGHT X=-100.9994907405
LOWER RIGHT Y=34.9994907404
WEST LONGITUDE=102° 00' 01.8333" W
NORTH LATITUDE=36° 00' 01.8333" N
EAST LONGITUDE=100° 59' 58.1667" W
SOUTH LATITUDE=34° 59' 58.1667" N
UL CORNER LONGITUDE=102° 00' 01.8333" W
UL CORNER LATITUDE=36° 00' 01.8333" N
UR CORNER LONGITUDE=100° 59' 58.1667" W
UR CORNER LATITUDE=36° 00' 01.8333" N
LR CORNER LONGITUDE=100° 59' 58.1667" W
LR CORNER LATITUDE=34° 59' 58.1667" N
LL CORNER LONGITUDE=102° 00' 01.8333" W
LL CORNER LATITUDE=34° 59' 58.1667" N
PROJ_DESC=Geographic (Latitude/Longitude) / NAD83 / arc degrees
PROJ_DATUM=NAD83
PROJ_UNITS=arc degrees
EPSG_CODE=EPSG:4269
COVERED AREA=10098 sq km
LOAD TIME=5.66 s
FILE_CREATION_TIME=10/15/2020 10:14:57 AM
FILE_MODIFIED_TIME=10/15/2020 10:17:54 AM
GDAL_NO_DATA_VALUE=-9999
NUM COLUMNS=10812
NUM ROWS=10812
NUM BANDS=1
PIXEL WIDTH=0.0000926 arc degrees
PIXEL HEIGHT=0.0000926 arc degrees
MIN ELEVATION=779.931 m
MAX ELEVATION=1153.354 m
ELEVATION UNITS=METERS
BIT DEPTH=32
SAMPLE TYPE=32-bit Floating Point
GEOG_CITATION=NAD83
PHOTOMETRIC=Greyscale (Min is Black)
BIT_DEPTH=32
SAMPLE_FORMAT=Floating Point
TILE_WIDTH=256
TILE_HEIGHT=256
COMPRESSION=LZW
PIXEL_SCALE=( 0.00009259259269, 0.00009259259269, 1.0 )
TIEPOINTS=( 0.00, 0.00, 0.00 ) --> ( -102.0005555564, 36.0005555563, 0.0000000000 )
MODEL_TYPE=Geographic lat-long system
RASTER_TYPE=Pixel is Area
OVERVIEW 1=Pixel Size: 5406 x 5406
OVERVIEW 2=Pixel Size: 2703 x 2703
OVERVIEW 3=Pixel Size: 1352 x 1352
OVERVIEW 4=Pixel Size: 676 x 676
OVERVIEW 5=Pixel Size: 338 x 338
GeoTIFF::GeographicTypeGeoKey=4269
GeoTIFF::GeogToWGS84GeoKey={ 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000 }
GeoTIFF::GeogAngularUnitsGeoKey=9102

...and is therefore is already in the required 32-bit Floating Point format.


The SDK Resample *.INF FractionBits parameter value actually required to be used will vary with the maximum peak height in Meters AMSL of data points in a local DEM.

Certainly the range of total peak height in Meters AMSL of data points in Missouri was OK with a SDK Resample *.INF FractionBits parameter value of "3".

But, higher Metric elevation points may require larger SDK Resample *.INF FractionBits parameter values with/without a SDK Resample *.INF BaseValue parameter values. :alert:

[EDITED]

FYI: After re-projection to EPSG:4326 GIS format required by SDK Resample, and exporting a "Elevation Grid Format" GeoTIFF file, Global Mapper shows this Metadata:

< NOTE: I am not familiar with an equivalent work-flow in OSGeo4W / QGIS via GDAL command line switch parameters, but I suspect there is an 'obscure' way to output 32-Bit DEM GeoTIFFs. :scratchch >

Perhaps Frank Warmerdam et al might have explained that in this recent GDAL documentation:

https://gdal.org/gdal.pdf

[END_EDIT]

FILENAME=[path]\USGS_13_n36w102_EPSG_4326.tif
DESCRIPTION=USGS_13_n36w102_EPSG_4326.tif
UPPER LEFT X=-102.0005092601
UPPER LEFT Y=36.0005092600
LOWER RIGHT X=-100.9994907405
LOWER RIGHT Y=34.9994907404
WEST LONGITUDE=102° 00' 01.8333" W
NORTH LATITUDE=36° 00' 01.8333" N
EAST LONGITUDE=100° 59' 58.1667" W
SOUTH LATITUDE=34° 59' 58.1667" N
UL CORNER LONGITUDE=102° 00' 01.8333" W
UL CORNER LATITUDE=36° 00' 01.8333" N
UR CORNER LONGITUDE=100° 59' 58.1667" W
UR CORNER LATITUDE=36° 00' 01.8333" N
LR CORNER LONGITUDE=100° 59' 58.1667" W
LR CORNER LATITUDE=34° 59' 58.1667" N
LL CORNER LONGITUDE=102° 00' 01.8333" W
LL CORNER LATITUDE=34° 59' 58.1667" N
PROJ_DESC=Geographic (Latitude/Longitude) / WGS84 / arc degrees
PROJ_DATUM=WGS84
PROJ_UNITS=arc degrees
EPSG_CODE=EPSG:4326
COVERED AREA=10098 sq km
FILE_CREATION_TIME=10/15/2020 10:42:29 AM
FILE_MODIFIED_TIME=10/15/2020 10:42:56 AM
GDAL_NO_DATA_VALUE=-32767
NUM COLUMNS=10812
NUM ROWS=10812
NUM BANDS=1
PIXEL WIDTH=0.0000926 arc degrees
PIXEL HEIGHT=0.0000926 arc degrees
MIN ELEVATION=779.931 m
MAX ELEVATION=1153.354 m
ELEVATION UNITS=METERS
BIT DEPTH=32
SAMPLE TYPE=32-bit Floating Point
GT_CITATION=GCS_WGS_1984
PHOTOMETRIC=Greyscale (Min is Black)
BIT_DEPTH=32
SAMPLE_FORMAT=Floating Point
ROWS_PER_STRIP=1
COMPRESSION=None
PIXEL_SCALE=( 0.00009259259269, 0.00009259259269, 1.0 )
TIEPOINTS=( 0.00, 0.00, 0.00 ) --> ( -102.0005092601, 36.0005092600, 0.0000000000 )
MODEL_TYPE=Geographic lat-long system
RASTER_TYPE=Pixel is Point
GeoTIFF::GeographicTypeGeoKey=4326
GeoTIFF::GeogSemiMajorAxisGeoKey=6378137
GeoTIFF::GeogSemiMinorAxisGeoKey=6356752.3
GeoTIFF::GeogEllipsoidGeoKey=7030
GeoTIFF::GeogAngularUnitsGeoKey=9102

[EDITED]

BTW: As you already may know, when configuring a SDK Resample *.INF, one must also specify one of these parameter values for the submitted source file Raster data:

* Pixel is Area ; (SDK Resample *.INF, parameter value: PixelIsPoint=0

...or:

* Pixel is Point ; (SDK Resample *.INF, parameter value: PixelIsPoint=1

https://www.prepar3d.com/SDKv4/sdk/world/terrain/terrain_overview.html#Source Parameters

p3d_sdk_resample_source_section_pixelispoint_parameter-jpg.63686


[END_EDIT]

...or Geo-Referencing will be incorrect in processed output files (...like it apparently was in some default FS2Kx terrain BGLs :tapedshut ).


That may not impact terracing, but incorrect parameter values for maximum Metric Altitudes in a local DEM- or using non- 32-Bit source data- can result in terraced terrain mesh.

GaryGB
 

Attachments

  • P3D_SDK_Resample_Source_Section_PixelIsPoint_Parameter.jpg
    P3D_SDK_Resample_Source_Section_PixelIsPoint_Parameter.jpg
    266 KB · Views: 67
Last edited:
No sweat... the INF script I have used is:
Code:
[Source]
Type=GeoTIFF
Layer=Elevation
SourceDir="."
SourceFile="N37W90.tif"
PixelIsPoint=0
NullValue=-32767

[Destination]
DestDir="."
DesFileType=BGL
DestBaseFileName="N37W90"
CompressionQuality=100
LOD=Auto

The terracing/grid marks I noticed when I zoomed in on my new TIF immediately following re-projection was exactly what I saw in the sim after resampling. So it seemed like the issue was during reprojecting and there was a better way of converting to WGS84 (perhaps with OSGeo4W commands) without introducing the terracing effect.
 
Is it possible to use reprojecting commands in my OSGeo4W interface instead of QGIS, like I use to create photoreal scenery?
Yep, it's the same command you'd use on one of the NAIP .tifs:

Code:
gdalwarp -of GTiff -co "INTERLEAVE=PIXEL" -t_srs "+proj=latlong +datum=WGS84" -r cubic "%dems%\USGS_13_n36w107.tif" "%outputpath%\output_WGS84.tif"

IIRC I downloaded that particular N36W118 and tried it when you originally posted this, I scrutinized the reprojected .tif and the .bgl but I couldn't reproduce the striated anomolies you showed in your pics.

Jim
 
IIRC I downloaded that particular N36W118 and tried it when you originally posted this, I scrutinized the reprojected .tif and the .bgl but I couldn't reproduce the striated anomolies you showed in your pics.
Well that's good news! I'll try using your command above and see how it goes...

Code:
Geotiff_Information:
   Version: 1
   Key_Revision: 1.0
   Tagged_Information:
      ModelTiepointTag (2,3):
         0                 0                 0                
         -102.000555322075 36.0005580829603  0                
      ModelPixelScaleTag (1,3):
         9.25925967764651e-005 9.25925967764651e-005 0                
      End_Of_Tags.
   Keyed_Information:
      GTModelTypeGeoKey (Short,1): ModelTypeGeographic
      GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
      GeographicTypeGeoKey (Short,1): GCS_WGS_84
      GeogCitationGeoKey (Ascii,8): "unknown"
      GeogAngularUnitsGeoKey (Short,1): Angular_Degree
      GeogSemiMajorAxisGeoKey (Double,1): 6378137          
      GeogInvFlatteningGeoKey (Double,1): 298.257223563    
      End_Of_Keys.
   End_Of_Geotiff.

GCS: 4326/WGS 84
Datum: 6326/World Geodetic System 1984
Ellipsoid: 7030/WGS 84 (6378137.00,6356752.31)
Prime Meridian: 8901/Greenwich (0.000000/  0d 0' 0.00"E)
Projection Linear Units: User-Defined (1.000000m)

Corner Coordinates:
Upper Left    (-102.0005553,36.0005581)
Lower Left    (-102.0005553,34.9994469)
Upper Right   (-100.9994442,36.0005581)
Lower Right   (-100.9994442,34.9994469)
Center        (-101.4999997,35.5000025)

I generated a .GTF file and maybe this isn't the right metadata I should be looking at, but does this mean I should switch from "Pixelispoint" to "Pixelisarea" now?
 
Last edited:
BTW, when I was doing the Colorado/New Mexico mesh I reprojected all the sources at once with a command like this BTW (run from the OSGeo4W console):

Code:
for %f in ("%dems%\*.tif") do gdalwarp -of GTiff -co "INTERLEAVE=PIXEL" -t_srs "+proj=latlong +datum=WGS84" -r cubic %f "%outputpath%\%~nf_WGS84.tif"
 
BTW, when I was doing the Colorado/New Mexico mesh I reprojected all the sources at once with a command like this BTW (run from the OSGeo4W console):

Code:
for %f in ("%dems%\*.tif") do gdalwarp -of GTiff -co "INTERLEAVE=PIXEL" -t_srs "+proj=latlong +datum=WGS84" -r cubic %f "%outputpath%\%~nf_WGS84.tif"
You read my mind! Do I need to us a command to set the %dems% and %outpath% file locations?
 
You can either use the full path or you can "set" the dems path, in my case it was:

set dems=E:\Projects\New_Mexico_mesh_project\sources

and then every time the command window sees %dems% it converts it to E:\Projects\New_Mexico_mesh_project\sources. Note that the "for" command doesn't reproject the dems together into one .tif, it just goes through the source folder reprojecting each NAD83 .tif to WGS84 one at a time.


I usually "set" a bunch of stuff when I open the OSGeo4W shell, for example:

set remote=G:\Projects\Los_Alamos_NM\PR\1m
set jp2s=G:\Projects\Los_Alamos_NM\Sources\1m
set 60cm=G:\Projects\Los_Alamos_NM\Sources\60cm
set shapes=G:\Projects\Los_Alamos_NM\SBuilderX\Shapes
set 2016=G:\Projects\Los_Alamos_NM\Sources\1m\2016
cls

And then I use commands like this:

gdalwarp -s_srs EPSG:3857 -tr 0.00001 -0.00001 -t_srs EPSG:4326 -of gtiff "%jp2s%\m_3510606_se_13_1_20140609_20140922.jp2" "%jp2s%\m_3510606_ne_13_1_20140609_20140922.jp2" "%jp2s%\m_3510605_ne_13_1_20140609_20140922.jp2" "%jp2s%\m_3510605_se_13_1_20140609_20140922.jp2" "%jp2s%\m_3510606_nw_13_1_20140609_20140922.jp2" "%jp2s%\m_3510606_sw_13_1_20140609_20140922.jp2" "%remote%\klam_1m_tile14.tif"
gdal_rasterize -burn 255 -burn 255 -burn 255 -tr 0.000010000000000 -0.000010000000000 -te -106.4375283 35.8749747 -106.2499683 36.0000247 -ot BYTE "%shapes%\snowline.shp" "%remote%\klam_1m_tile14_snowline.tif"
 
IIUC, the question is what output Bit Depth GeoTIFFs are you generating from QGIS when you process the above DEM source data ?

Another question is whether Metadata for each CONUS USGS DEM source file is individually inspected / known before configuring multi-source SDK Resample *.INF files ?
I couldn't find what output depth I was conjuring. I only know how to generate a GTF file and I couldn't find anything regarding bit depth.

And no, I do not individually inspect each tile. I exclusively use USGS 1/3 arc-second data and I naïvely assumed that they would be consistent. Project time is limited and given the scope of my project, I had to limit steps where possible. I can say that I experience terracing pretty much everywhere. But without flying it to be sure, it seems that Jim's suggestion may have solved my issue with the QGIS process I've used for hundreds of 1-degree scenery tiles. Once I know whether I should use "Pixelispoint" or "Pixelisarea", I'll resample it and check it out. Exciting!
 
I generated a .GTF file and maybe this isn't the right metadata I should be looking at, but does this mean I should switch from "Pixelispoint" to "Pixelisarea" now?
I think that has to do with the ulxMap, ulyMap, xDim, and yDim in your .inf. If you're using GeoTiffToInf it will put PixelIsPoint=0 in the [Source] which I presume is what it writes the ulxMap, ulyMap, xDim, and yDim for. ???

There is such a thing as a snowline shapefile?!

There is if you make one! :)

I loaded a mesh .bgl into TMFViewer and set the elevation color ramp to 9500' and took a screenshot of it. In Photoshop I turned everything above 9500' black and filled the rest of it with white. I resized it to the same pixel dimensions as the reprojected dem source (which I'd cut down specifically for the "snowline" exercise). I made a .gtf off the dem source and injected the coords into the screenshot, then I used gdal_polygonize to turn it into a .shp.

snowline01.jpg


snowline02.jpg
 
There is if you make one!
That's incredible! P3D does mountains very little justice. I was proud of myself finding out what the code for glaciers was in the NHD dataset, but I knew they'd stick out like a sore thumb next time I flew through the Rockies. This is a great idea!
 
Orbx did photoreal glaciers in their SAK and PFJ regions, they just blended the edges out and laid the glaciers down over the landclass. They looked pretty good. What were you thinking of, landclass polys? They'd probably look OK, no?

On the snowline I'm not sure I'm happy with what I've done in PhotoShop with them just yet. From the gdal_rasterize .tif you basically just get a selection area on the photoreal source showing where the 9500' line lays, then it's up to you to try and make everything above the line look like snow. I still need to play with it, maybe more feather so the snow looks heavier around the peaks and dissipates a bit as it comes down the mountains nearer to the line. Problem is there are 14 ~2.5 Gb .psbs with snowlines and the process needs to be exactly the same on each one or you see lines where the tiles join. It turns into a pretty big job to modify them all. :banghead:

I did a snowline around McCall, Idaho back in the FS9 days and I think I liked it a lot better, maybe it was because we were limited to 4.7m resolution and the blurriness made them seem more plausible. One thing that happened in FS9 though was the seasons would change with the weather; turn on some snowy weather and the mild winter/hard winter textures would start mixing which wreaked havoc with my snow lines. To my knowledge that doesn't happen on photoreal in FSX/P3D, I believe it does on LC textures but not on photoreal so hopefully my snowline will survive, lol.
 
Many thanks to Jim for so generously continuing to share his exceptional in-depth analysis skills, insights, and innovative work-flows in this- and other- threads here at FSDeveloper. :teacher:

I think that has to do with the ulxMap, ulyMap, xDim, and yDim in your .inf. If you're using GeoTiffToInf it will put PixelIsPoint=0 in the [Source] which I presume is what it writes the ulxMap, ulyMap, xDim, and yDim for. ???

The onus is ...on us, to recall Ollyau's GeoTiffToInf is intended for creating imagery BGLs, and the SDK Resample *.INF output must be edited for use with elevation source data for terrain mesh BGLs. :alert:


Imagery pixels are, IMHO, best regarded as 'Areas'; elevation data points are are IMHO best regarded as ...'points', and source file / *.INF Geo-Referencing should be commensurate. ;)


AFAIK, if we use a GIS application to sample a raster source to create gridded elevation data points as pixels, they might best be regarded as derived intermediate vector vertices or ...'points'.

Thus, a final GIS application output file in ex: GeoTIFF format would likely yield Geo-Referenced elevation data points with a GIS parameter format known as "Pixel Is Point".

And of course we cannot arbitrarily change a SDK Resample *.INF parameter value from Pixel Is Area to Pixel Is Point or vice-versa; it must match what the GIS application assigned to the data file. :pushpin:


PS:

Chris:

I have made a couple of edits in my post above to try and clarify a few things; hope this helps. :)

https://www.fsdeveloper.com/forum/threads/on-fraction-bits.448084/post-860824


Perhaps rhumbaflappy may know which GDAL command line switch parameters would work to output 32-Bit floating point GeoTIFF gridded elevation source files for SDK Resample ? :wizard:

GaryGB
 
Last edited:
Orbx did photoreal glaciers in their SAK and PFJ regions, they just blended the edges out and laid the glaciers down over the landclass. They looked pretty good. What were you thinking of, landclass polys? They'd probably look OK, no?
Yeah, from a statewide shapefile I pulled out the dams, wetlands, beaches, and glaciers and gave them appropriate textures in ScenProc. Then I got rid of inundation areas and all the flowlines that didn't have names. The P3D stock landclass textures are pretty lame but still it really brought sourthern Florida to life. I haven't flown across my handiwork in California yet but I imagine the glaciers look a lot better than the lakes that were magically sticking on the sides of mountains before.

I really like the idea of snow lines on mountains. I love flying through the mountains by Lake Tahoe and there is the same forested landclass from the bottom to the top, which is breathtaking given the accuracy of the terrain but you get no sense of how high you are. I wonder if there is a way to somehow burn shapefiles based altitude. Or at least some kind of local landclass map using the USGS nationwide landclass data.
 
Last edited:
Top