Mount St. Helens pre-1980 terrain - issues with display after compiling

[Steve Rosenow]

So, this is a carryover from this thread here:

https://www.fsdeveloper.com/forum/threads/creating-inf-file-for-terrain-bgl.444921/

I've had success creating the terrain for the volcano's pre-1980 eruption profile. However, when it loads in the sim, there is a considerable gap between the compiled mesh and the mesh which displays underneath it from ORBX. At the point of the gaps, autogen trees seem to float thousands of feet into the air.

In addition, when I get closer, the compiled terrain mesh disappears entirely. Is there a fix for this?

Here's my INF file

[Source]
Type=GeoTIFF
Layer=Elevation
SourceDir="."
SourceFile="MSH_Pre_1980.tif"
FractionBits=6

[Destination]
DestDir="."
DestBaseFileName="MSH_Pre_1980"
DestFileType=BGL
LOD=Auto

*EDIT* I have since fixed the gap issue. However, the compiled terrain still disappears when you get closer to it, revealing the underlaying mesh below it.

 

[rhumbaflappy]

LOD=Auto is the problem. You need a value set that over-rides the default mesh or when you get close, the default will show.

 

[GaryGB]

Hi Steve:

I was almost finished composing this reply when Dick posted above (he's also quite knowledgeable about SDK Resample).


I assume the older contour-derived source data is lower resolution than that used for the OrbX FTX PNW terrain mesh file.


At least (2) considerations will have a bearing on whether your custom terrain mesh BGL may be displayed compatibly with ex:

[FSX install path]\ORBX\FTX_NA\FTX_NA_PNW07_MESH\scenery\4_mesh_multiLOD4-12_FTX-PNW_WA-S_v6.bgl (Payware)

...or:

[FSX install path]\ORBX\FTX_NA\FTX_NA_PNW07_MESH\scenery\4_mesh_multiLOD4-12_FTX-PNW_DEMOv2.bgl (Demo)


1.) Resolution as distance in Meters on ground between elevation data points must be the same or larger (lower LOD).

a.) Geographic extent of coverage in FS terrain grid Lower LODs cover ground for greater distances from center of a data set

b.) When a terrain mesh is loaded as the user aircraft encounters its outer boundary, it actually gains higher display priority

c.) The terrain mesh with higher display priority may defeat loading / display of smaller tiles of higher resolution terrain mesh

...if they are encountered within the outer boundary of the first encountered terrain mesh even if that BGL contains lower LODs


2.) Resolution as distance in Meters on ground between elevation data points must also be same or smaller (higher LOD).

a.) You must provide higher LODs of terrain mesh so they are available to be loaded by your custom BGL when the user aircraft is nearby at a 'close' distance to your custom terrain mesh.


Your default *.INF above allows SDK Resample to read source data and internally decide what LODs to output into your BGL.

You will need to specify that SDK Resample is to read source data and create LODs 4 through12 to output into your BGL.


Try using:

[Source]
Type=GeoTIFF
Layer=Elevation
SourceDir="."
SourceFile="MSH_Pre_1980.tif"
FractionBits=6

[Destination]
DestDir="."
DestBaseFileName="MSH_Pre_1980"
DestFileType=BGL
LOD=4,12

...so that SDK Resample reads source data and interpolates internally to 'artificially' create LODs 4 through12 for level of detail not already provided by your particular source data set.


NOTE: This should also allow the custom BGL to display at higher priority than the default FS terrain mesh as discussed here:

https://www.fsdeveloper.com/forum/threads/help-with-ade-terrain-etc.444894/post-817768


PS: You will encounter a similar scenario when creating a superimposed custom photo-real imagery BGL for that same area.


That will of course be a subject for a separate thread, since you already alluded to that being one of your project goals ...here:

https://www.fsdeveloper.com/forum/threads/creating-inf-file-for-terrain-bgl.444921/

GaryGB

 

[HolgerSandmann]

Hi there,

have you looked at the compiled bgl in TMFViewer? The "moat" along parts of the outer edges may be an issue with incorrect or invalid data.

Also, a FractionBits value of "6" removes six bits from the 16-bit signed integer range in the compiled bgl and thus might not be sufficient to cover the entire altitude range of the peak; see http://www.prepar3d.com/SDKv4/sdk/world/terrain/terrain_overview.html#Using Scaled Elevation Values . I normally use a value of 2 or 3, which is sufficient to prevent visible stair-stepping in the compiled mesh.

The "morphing" issue due to the FTX PNW mesh and its post-eruption DEM (or any other mesh, for that matter) overriding your new file at a distance is going to be difficult to deal with. It might help to compile your file at something like LOD 6,13 to override the maxLOD of the PNW mesh. However, the display engine actually reads the LOD layers of any active mesh as individual files and, when sorting through mesh data of the same LOD, will load the one it first encounters, and the PNW mesh has a much larger coverage area. Thus, when you load a flight right at the peak your mesh will show correctly, but when you approach from a distance it will only "morph" into view when getting close.

As Gary mentioned, developers have the same issue when trying to place a high-resolution photoreal section on top of a larger, lower-resolution photoreal bgl. This can be avoided by using the blendmask to cut a hole into the lower-resolution file of the size of the higher-resolution image. You don't have an equivalent option here with your mesh file so you may need to create a file with a much larger spatial extent to consistently override the default or third-party mesh files.

Cheers, Holger

 

[GaryGB]

I agree with Holger's observations and suggestions above.

I had also noticed the 'generous' FractionBits value used, but saw the Mt. St. Helens cone 'apex' was still visible, so I did not comment as I was not sure how badly 'terraced' the old contour-derived data set might otherwise be rendered in FS at run time.

It would also be helpful in troubleshooting / optimizing this work-flow, if Steve would tell us which data set was used for creating his Mt. St. Helens 1970's era 'pre-eruption' terrain mesh under discussion here (please post a link and file name etc.).

Yesterday, I only had time to search and find (1) old 30 Meter (composite ?) source file, but I'm not sure if it matches Steve's.


GaryGB

 

[Steve Rosenow]

UPDATE:

I've been able so far, to eliminate the "disappearing" mesh per Holger's suggestion. I did a test run with LOD set to 6,13, compiled the terrain, and was able to initiate a test flight near the pre-eruption summit dome. The mesh did not disappear as it did per my earlier testing.

HOWEVER:

The 30-meter terrain mesh I am using, is apparently set to the NAD-27 coordinate reference system. It's an anomaly I find weird since it loads in 3DEM using the WGS84 EPSG4326 system.

When I export the mesh using QGis software to a GEOTIFF set to the EPSG4326-WGS 84 CRS, I end up with a whole host of terrain anomalies caused by pixel value rotation. I would like to eliminate them as much as possible however I don't believe it can be done.

Gary, the source link to the DEM file I am using is at this site:
http://gis.ess.washington.edu/data/raster/thirtymeter/mtsthelens/

It is a 30-meter source file that has many east-west artifacts (which I would be okay with as it's the only DEM source data available to my knowledge). However, in the attached map output in 3DEM, you can see the artifacts caused by pixel value rotation within the mesh (as a result of setting the coordinate reference system to EPSG4326-WGS 84).

I was also able to eliminate the moat/gap issue by way of trimming the output mesh in 3DEM via cropping, then re-saving the GeoTIFF file.

Baby steps, but I'm getting somewhere.

 

[GaryGB]

https://www.fsdeveloper.com/forum/t...th-display-after-compiling.444927/post-818091

The 30-meter terrain mesh I am using, is apparently set to the NAD-27 coordinate reference system. It's an anomaly I find weird since it loads in 3DEM using the WGS84 EPSG4326 system.

When I export the mesh using QGis software to a GEOTIFF set to the EPSG4326-WGS 84 CRS, I end up with a whole host of terrain anomalies caused by pixel value rotation. I would like to eliminate them as much as possible however I don't believe it can be done.

Although we are required to submit source data to SDK Resample in (EPSG:4326) GIS format, we 'should' see that the GeoTIFF image is purposely "pre-warped", because the FS run time rendering engine will "un-warp" the image as it stretches it in a "rubber sheet" manner to drape and attach elevation (and/or other ex: aerial imagery) data onto the NW and SE corners of FS terrain grid quads so that it then appears 'correct' within the variably sized and shaped terrain quads of the FSX / P3D 3D spheroidal (WGS84 geoid) world model.

https://en.wikipedia.org/wiki/World_Geodetic_System


In order for the DEM to be displayed / rendered "un-warped" in ex: 3DEM or QGIS etc., one must use the original GeoTIFF.

Alternatively, to use a 'modified' version of that DEM, in ex: QGIS re-project it as UTM Zone 10, NAD27 (CONUS) GeoTIFF.

Or, if available in QGIS, use the online tile server "Spherical Web Mercator" (EPSG:3857) GIS projection format ...in order for one's GeoTIFF to be displayed / rendered "un-warped" in ex: 3DEM or QGIS etc.

https://en.wikipedia.org/wiki/Universal_Transverse_Mercator_coordinate_system

https://en.wikipedia.org/wiki/Web_Mercator_projection

https://www.fsdeveloper.com/forum/t...th-display-after-compiling.444927/post-818091

Gary, the source link to the DEM file I am using is at this site:
http://gis.ess.washington.edu/data/raster/thirtymeter/mtsthelens/

It is a 30-meter source file that has many east-west artifacts (which I would be okay with as it's the only DEM source data available to my knowledge). However, in the attached map output in 3DEM, you can see the artifacts caused by pixel value rotation within the mesh (as a result of setting the coordinate reference system to EPSG4326-WGS 84).

Baby steps, but I'm getting somewhere.

Thanks, that's the same one I had found; I'll take a look at it to see if I can offer some 'better informed' input on it later.

GaryGB

 

[Steve Rosenow]

SUCCESS!!!

After messing with the mesh in QGis, I had an epiphany.

I decided to try my hand at warping the mesh in QGis and reassigning its projection in the process. After that I did a test compile with the mesh and it worked FANTASTICALLY. Not only were the visual artifacts almost completely gone, but some of the east-west artifacts in the original DEM file were smoothed out as well!

After that, I did another test run in FSX to see how everything performed. I was still experiencing some issues with it disappearing the closer I got, so I decided to adjust the LOD call in the INF file.

This is the final compile I ran, and I am very pleased to report that the mesh no longer disappears when you're right up on it!

[Source]
Type=GeoTIFF
Layer=Elevation
SourceDir="."
SourceFile="MSH_Pre_1980_2.tif"
FractionBits=3

[Destination]
DestDir="."
DestBaseFileName="MSH_Pre_1980"
DestFileType=BGL
LOD=6,16

There are minor issues with the display of stair-step like artifacts but none like what I had been seeing in earlier test runs. Here's some test shots showing the test placement.

Viewed from the NW, near Elk Rock.

From above Spirit Lake

Looking up Dog's Head from above Sugar Bowl, up the Forsyth and Leschi Glaciers (which I'll be using photoreal ground scenery for)

Looking up towards Goat Rocks Dome and the north flank.

 

[Steve Rosenow]

And I'll be damned!

It has been YEARS since I've felt this good on a project!

I put together my photoreal terrain overlay with a blend mask last night and just a few minutes ago I just did a test run in FSX.

I AM TICKLED PINK.

There are some alignment issues on the west side of the peak but those can be rectified by realigning the image in Adobe Photoshop and re-compiling the BGLs

Now all I need to do is realign Highway 504, eliminate two lakes and a dozen ponds or so, and then realign Spirit Lake's shoreline to its pre-1980 level. I'll be reassigning landclass in this area via SBuilderX.

This is gonna be a fantastic package!

 

[Steve Rosenow]

Looking up towards Goat Rocks Dome and the north flank.

Looking up Dog's Head from above Sugar Bowl, up the Forsyth and Leschi Glaciers

That famous postcard view from Spirit Lake. Who'd have thought this would be possible in FSX?

 

[GaryGB]

Well done; keep up the good work !

PS: Your solution above is an interesting one:

https://www.fsdeveloper.com/forum/t...th-display-after-compiling.444927/post-818113


AFAIK, by having increased the terrain mesh resolution by telling SDK Resample to populate the FS terrain grid with more elevation data points at smaller intervals between those points on the ground, it seems the FS run time terrain rendering engine may be better able to form a more cohesive 'Direct Draw Surface' in the otherwise limited amount of time it is allowed to do so within the default 'ground' forming sub-system ...than it would with less elevation data points at larger intervals between those points on the ground.

Thus, IIUC, the result yields no "moat", spikes, pits, or "morphing" at close distances in the user aircraft between the display of the smaller tile of pre-eruption terrain mesh and display of the underlying terrain meshe(s) from the local FS default and/or OrbX FTX PNW ?

GaryGB

 

[Steve Rosenow]

SOOOOOO....

Five steps ahead, one step back.


Here's the text of my aerial image scenery overlay.


[Source]
Type = MultiSource
NumberOfSources = 3

[Source1]
Type = BMP
Layer = Imagery
SourceDir = "."
SourceFile = "MSH_Pre_1980_Aerial.bmp"
Variation = January, February, March, April, May, June, July, August, September, October, November, December
Channel_BlendMask = 2.0
Channel_LandWaterMask = 3.0
ULXMAP = -122.250000000000000000000000
ULYMAP = 46.249141666666666600000000
XDIM = 0.000061233480176213055940
YDIM = 0.000042842639593907500450

[Source2]
Type = BMP
Layer = None
SourceDir = "."
SourceFile = "MSH_Pre_1980_Aerial_Blendmask.bmp"
SamplingMethod = Gaussian
ULXMAP = -122.250000000000000000000000
ULYMAP = 46.249141666666666600000000
XDIM = 0.000061233480176213055940
YDIM = 0.000042842639593907500450

[Source3]
Type = BMP
Layer = None
SourceDir = "."
SourceFile = "MSH_Pre_1980_Aerial_LWM.bmp"
SamplingMethod = Gaussian
ULXMAP = -122.250000000000000000000000
ULYMAP = 46.249141666666666600000000
XDIM = 0.000061233480176213055940
YDIM = 0.000042842639593907500450


[Destination]
DestDir = "."
DestBaseFileName = "MSH_Pre_1980_Aerial"
DestFileType = BGL
LOD = 6,16
UseSourceDimensions = 1
CompressionQuality = 85



How would I go about making the seasons display correctly? When I did a test flight in December, the main terrain imagery showed which is supposed to be late summer.

 

[GaryGB]

Hi Steve:

Did you make a copy of your "Main - late summer" BMP image and edit it to be a unique Seasonal image [Source#] ?

If not, AFAIK, you must do so, and list that seasonal variation image as another [Source#] within your *.INF file above.


CAVEAT: Do not change the total number of Pixel Rows or Columns in edited copies of SBuilderX original *.BMPs

That precaution allows one to maintain the Geo-Referencing and Pixel dimensions of the SBuilderX original *.BMPs


Refer to:

https://www.prepar3d.com/SDKv4/sdk/world/terrain/terrain_overview.html#The Resample Tool


See especially this sub-section under SDK Resample:

Imagery Data Source Parameters


PS: You may wish to review these excellent tutorials by Luis Feliz-Tirado:

Make photo-real ground textures

File Description:
It is very easy to create your very own high-resolution, custom (photo-real) ground textures. This document explains the concepts and techniques and illustrates the use of SBuilderX with which you can quickly and easily download aerial images and make this type of scenery. So, why hesitate? Make Flight Simulator scenery as real as it gets! Very sorry - no support of any kind is offered. Please do not write. For any questions, please post in the Avsim Scenery Design Forum.

Filename: make_photo-real_ground_textures_in_fs_x.zip
License: Freeware
Added: 21st November 2009, 23:20:06
Downloads: 17714
Author: Luis Feliz-Tirado
Size: 2143kb

https://library.avsim.net/esearch.php?CatID=fsxsd&DLID=140539


Terrain Design

File Description:
Terrain Design for Flight Simulator X

This simple illustrated document explains the basic concepts in Flight Simulator X terrain, and how to change them using SBuilder for FS X. Make new water bodies, roads, vehicle traffic, airport flattens, remove autogen, add more detail - anybody can do it easily and quickly.
My most sincere apologies - I am unable, for lack of free time, to offer support of any kind. For questions or problems, please post in the Avsim scenery design forum.

Filename: terrain_design_for_flight_simulator_x.zip
License: Freeware
Added: 14th December 2009, 13:29:15
Downloads: 16648
Author: Luis Feliz-Tirado
Size: 3991kb

https://library.avsim.net/esearch.php?CatID=fsxsd&DLID=141643


Using the Autogen Annotator

File Description:
The Autogen Annotator is a powerful tool for modifying the autogen of default ground textures or adding autogen to custom (photo-real) ground. This document illustrates the use of the tool, and includes a pictorial guide to all autogen object types. Very sorry - no support of any kind is offered. Please do not write. For any questions, please post in the Avsim Scenery Design Forum.

Filename: using_the_autogen_annotator_264833.zip
License: Freeware
Added: 21st November 2009, 16:18:51
Downloads: 4220
Author: Luis Feliz-Tirado
Size: 8930kb

https://library.avsim.net/esearch.php?CatID=fsxsd&DLID=140537


Hope this helps !

GaryGB

 

[Steve Rosenow]

Thank you Gary for those tips. I'll look at them tonight when I get home.

I also need to figure out how to set excludes for existing LWM data. I tried in SBuilder last night and had some wild anomalies pop up. The idea is to shrink Spirit Lake's size down and eliminate two other lakes and a number of small ponds in the debris flow.

I also noticed - in the DEM mesh pre-1980, Autogen-based scenery does not load in spite of an entire landclass change. How do I get it to load? It looks like a wall of trees at the edge of the pre-1980 mesh, while the pre-1980 mesh is completely devoid of it.

Any suggestion helps.

-Steve.

Here's where things sit so far.

 

[GaryGB]

https://www.fsdeveloper.com/forum/t...th-display-after-compiling.444927/post-818218

Thank you Gary for those tips. I'll look at them tonight when I get home.

I also need to figure out how to set excludes for existing LWM data. I tried in SBuilder last night and had some wild anomalies pop up. The idea is to shrink Spirit Lake's size down and eliminate two other lakes and a number of small ponds in the debris flow.

As you will see in the Luis Feliz-Tirado tutorials cited / linked above, we must always Exclude and then Replace scenery.

I suggest that you first examine in FS Terrain SDK TMFViewer:

[FSX install path]\Scenery\0101\scenery\0dem_StHelens.bgl

[FSX install path]\Scenery\0101\scenery\dem1515.bgl

[FSX install path]\Scenery\0101\scenery\cvx1515.bgl



Jump to: N46.201256, W122.192845

Zoom in, and note the vector object IDs for Vector polygons / Poly-Lines / ABPs ...to be excluded and replaced.


Correlate GUIDs of the terrain CVX vector objects with the info here:

https://docs.microsoft.com/en-us/previous-versions/microsoft-esp/cc707102(v=msdn.10)#the-shp2vec-tool

https://docs.microsoft.com/en-us/previous-versions/microsoft-esp/cc526968(v=msdn.10)


NOTE: Left Mouse button centers display
Click Keyboard < + > / <-> Keys repeatedly to zoom in / out far enough to see separate Road and Freeway Traffic lines )



At the time Luis wrote the above tutorials (shortly after FSX RTM hit the shelves), there was no decompiler for CVX vector BGLs.

Now we have one, and it is a helpful way to maintain precision and reduce the workflow complexity for FS development.

For future use with ex: SBuilderX, I suggest you download Patrick Germain's CvxExtractor:

https://www.fsdeveloper.com/forum/threads/cvxextractor-exporting-vector-data.432918/


For example, the local default CVX vector BGL:

[FS install path]\Scenery\0101\Scenery\cvx1515.bgl


...can be decompiled via Patrick Germain's CvxExtractor into ESRI *.SHP files.


Those ESRI *.SHP files exported by CvxExtractor can then be 'Appended' to a new empty project in SBuilderX.


This would provide you with working copies inside SBuilderX, of the existing default CVX vector data which can be modified as needed, without having to create it all oneself.


SBuilderX can display Terrain SDK Quad LOD-9 / QMID-11 Grid Lines as a guide to place 'Excludes' for these local CVX vectors:

Flatten (FLX*.SHP), Exclude (EX*.SHP), Roads (RDX*.SHP), Hydro Polys (HP*.SHP), Hydro Shorelines (HL*SHP.) etc.


SBuilderX can display Terrain SDK Quad LOD-13 / QMID-15 Grid Lines as a guide to place 'Excludes' for these local CVX vectors:

Freeway Traffic (FWX*.SHP)


NOTE: 'Flattens' may include Airport Background / Boundary Polygons (aka "ABP's")


You can also make changes to the 'Appended' *.SHP CVX vector objects over a precisely Geo-referenced photo-real imagery background, then output 1 or more 'Replacement' CVX vector BGLs to modify the FS scenery area properly.

You can then compile the modified CVX vector objects (along with any desired new ones) into (1) or more replacement BGLs.



You may also wish to review a recent mini-tutorial on modifying Roads / Freeway Traffic that I wrote for Ken Manning here:

https://www.fsdeveloper.com/forum/t...ects-in-sbuilderx-for-katl.444877/post-817582



However, when you refer to "LWM" excludes, I infer- that you refer- ...to issues with anomalies due to 8-Bit grayscale *.TIF transparency in a Land-Water Mask used via the Alpha channel of the "DAY" image, or via a stand-alone file as seen in your SDK Resample *.INF above.

If you describe in more detail with a screenshot, exactly what anomalies you are seeing, we can likely sort that out quickly.

https://www.fsdeveloper.com/forum/t...th-display-after-compiling.444927/post-818218

I also noticed - in the DEM mesh pre-1980, Autogen-based scenery does not load in spite of an entire landclass change.

How do I get it to load? It looks like a wall of trees at the edge of the pre-1980 mesh, while the pre-1980 mesh is completely devoid of it.

Any suggestion helps.

-Steve.

IIUC, you are describing a 'lack' of Autogen on the texture area provided by your custom photo-real imagery BGL ?

If so, that is because you must create custom Autogen annotations for your custom photo-real imagery BGL.


Note as well, only FSX default Autogen annotations can be excluded by airport BGLComp-XML type Exclusion Rectangles.

FSX custom Autogen annotations are excluded by SHP2VEC CVX vector Airport Background "ExcludeAutogen" polygons


FS default Autogen, land/water class, CVX vector objects do not show on top of custom photo-real imagery unless you 'cut holes' in that imagery with the Blend Mask to allow that scenery content to show through to the top.

Only CVX vector Freeway Traffic shows through to the top without 'cutting holes' in that imagery with the Blend Mask.


I hope I understood your questions correctly.

GaryGB

 

[Steve Rosenow]

TWO STEPS FORWARD - FIVE STEPS BACK.

I have chosen to realign the textures to the GeoTIFF DEM file by way of using the source DEM as an underlay. I have everything lined up and ready to compile however, 3DEM's coordinate system isn't producing numbers that are compatible with the requirements of Resample.exe.

How would I find those coordinates?

 

[GaryGB]

Hi Steve:

I'll make an educated 'guess' that you are referring to the GIS file format "projection" required by SDK Resample.

SDK Resample requires source files to be in (EPSG:4326) aka: Geographic (Lat-Lon) Projection / WGS84 Datum) GIS format



If I read the 3DEM PDF help file correctly, 3DEM by default will output in the same projection as the original source files

Thus, if source files for 3DEM are all in the same (non-warped ?) format for map viewing, that will be the output format also.


BTW: Metadata Geo-referencing a UTM format file will not be Lat-Lon, and instead appears as 'Cartesian' decimal format.

https://en.wikipedia.org/wiki/Easting_and_northing


Try to load the ex: GeoTIFF file(s) output from 3DEM in QGIS, and re-project them in ex: QGIS to (EPSG:4326) GIS format.


If I have not correctly 'guessed' what you are referring to above, please explain what you mean by:

"3DEM's coordinate system isn't producing numbers that are compatible with the requirements of Resample.exe. "


Hope this helps.

GaryGB

 

[Steve Rosenow]

Hi Steve:

I'll make an educated 'guess' that you are referring to the GIS file format "projection" required by SDK Resample.

SDK Resample requires source files to be in (EPSG:4326) aka: Geographic (Lat-Lon) Projection / WGS84 Datum) GIS format



If I read the 3DEM PDF help file correctly, 3DEM by default will output in the same projection as the original source files

Thus, if source files for 3DEM are all in the same (non-warped ?) format for map viewing, that will be the output format also.


BTW: Metadata Geo-referencing a UTM format file will not be Lat-Lon, and instead appears as 'Cartesian' decimal format.

https://en.wikipedia.org/wiki/Easting_and_northing


Try to load the ex: GeoTIFF file(s) output from 3DEM in QGIS, and re-project them in ex: QGIS to (EPSG:4326) GIS format.


If I have not correctly 'guessed' what you are referring to above, please explain what you mean by:

"3DEM's coordinate system isn't producing numbers that are compatible with the requirements of Resample.exe. "


Hope this helps.

GaryGB

It did.

I also had an epiphany and tried using the coordinates from QGis and 3DEM to calibrate the map image I use for the terrain imagery in SBuilderX.

After a few rocky and rough starts, I was able to zero in the calibration riiiight where I need it to be!

Once that was done, I re-compiled the photoreal aspect and I am pleased and very happy to report things are looking stunning!

Not quite done yet but very close to release! I found some DEM data from pre-1980 for the debris flow area, too. I want to compile that as well but it's a grayscale GIF.

All I need to do is figure out how to create seasonal images based on what you've said before, but the process isn't well explained in the tutorials I have nor anywhere else. :/

The last screenshot shows the artifacts that happened from trying to create a water poly for Spirit Lake's pre-1980 shoreline

P.S. I still feel the use of FractionBits is too conservative. I notice a lot of stairstepping when I get really close.

 

[GaryGB]

https://www.fsdeveloper.com/forum/t...th-display-after-compiling.444927/post-818287

I found some DEM data from pre-1980 for the debris flow area, too. I want to compile that as well but it's a grayscale GIF.

It might be a gray-scale elevation HeightMap that is displayed on a web page as a GIF; got a link to that image / data ?

SDK Resample can process HeightMaps as type "RAW" via some special *.INF parameters.

But it may be easier to use QGIS to convert it to a 32-bit GeoTIFF (which, BTW gives the best results if using FractionBits)

https://www.fsdeveloper.com/forum/t...th-display-after-compiling.444927/post-818287

All I need to do is figure out how to create seasonal images based on what you've said before, but the process isn't well explained in the tutorials I have nor anywhere else. :/

The info is out there (primarily at FSDeveloper); try a few of these links for the graphics methods and *.INF examples

https://www.google.com/search?ei=XN-DXIPGGonusQWQ-J3gBw&q=site:www.fsdeveloper.com+Resample+season+imagery+texture+edit&oq=site:www.fsdeveloper.com+Resample+season+imagery+texture+edit&gs_l=psy-ab.12...28574.31380..34126...0.0..0.66.127.2......0....1..gws-wiz.mo_PrYxcPho

https://www.google.com/search?biw=9.....0.64.191.3......0....1..gws-wiz.SoUsGTtFHZs


BTW: Tell us which specific seasonal variations you want to implement in your imagery sources as separate layers in the *.INF

https://www.fsdeveloper.com/forum/t...th-display-after-compiling.444927/post-818287

P.S. I still feel the use of FractionBits is too conservative. I notice a lot of stair-stepping when I get really close.

Try using QGIS to convert elevation sources to 32-bit GeoTIFFs (which, BTW gives the best results if using FractionBits)

As long as you do not end up with a mountain peak clipped off above a certain Altitude, try a FractionBits value of 6 or 7.

If the mountain peak is clipped off, but you do see better interpolation and less 'terracing', adjust the Resample "BaseValue".

https://www.prepar3d.com/SDKv4/sdk/world/terrain/terrain_overview.html#The Resample Tool

GaryGB

 

[Steve Rosenow]

It might be a gray-scale elevation HeightMap that is displayed on a web page as a GIF; got a link to that image / data ?

SDK Resample can process HeightMaps as type "RAW" via some special *.INF parameters.

But it may be easier to use QGIS to convert it to a 32-bit GeoTIFF (which, BTW gives the best results if using FractionBits)



The info is out there (primarily at FSDeveloper); try a few of these links for the graphics methods and *.INF examples

https://www.google.com/search?ei=XN-DXIPGGonusQWQ-J3gBw&q=site:www.fsdeveloper.com+Resample+season+imagery+texture+edit&oq=site:www.fsdeveloper.com+Resample+season+imagery+texture+edit&gs_l=psy-ab.12...28574.31380..34126...0.0..0.66.127.2......0....1..gws-wiz.mo_PrYxcPho

https://www.google.com/search?biw=967&bih=674&ei=qd-DXPTrJ5K6tgWT6JDgBA&q=site:www.fsdeveloper.com+Resample+seasonal+variation+INF&oq=site:www.fsdeveloper.com+Resample+seasonal+variation+INF&gs_l=psy-ab.12...42834.43632..46899...0.0..0.64.191.3......0....1..gws-wiz.SoUsGTtFHZs


BTW: Tell us which specific seasonal variations you want to implement in your imagery sources as separate layers in the *.INF



Try using QGIS to convert elevation sources to 32-bit GeoTIFFs (which, BTW gives the best results if using FractionBits)

As long as you do not end up with a mountain peak clipped off above a certain Altitude, try a FractionBits value of 6 or 7.

If the mountain peak is clipped off, but you do see better interpolation and less 'terracing', adjust the Resample "BaseValue".

https://www.prepar3d.com/SDKv4/sdk/world/terrain/terrain_overview.html#The Resample Tool

GaryGB

Here's the link to the pre-1980 DEM for the debris flow area. It appears to be 30-meter mesh all the way to Hoffstadt Bluffs. Covers most of the immediate blast zone, too.

http://www.msss.com/earth/msh/msh.html