Hi Dick:
IMHO, applications of this type of utility for output of background imagery in both FS2Kx legacy
and FSX / P3D scenery creation via 3rd party freeware and payware ...may potentially merit consideration of an expanded feature set.
A proposal for such an expanded feature set may ultimately merit discussion in yet another thread- and programming project- separate from any that you may presently have intended for this 'current' thread and programming project.
Please let me know if you prefer that I manually relocate this post to a separate thread in this forum.
Assuming this might prove to be of interest to you and others reading this thread, I'll tentatively mention here, the general idea(s) I had, in the event that, while you are resurrecting this code (no doubt utilizing new insights you likely have gained since it was last updated in 2013), you may consider adapting this utility, or other utilities you have also released, to provide some enhanced features that could be of further help to the FS Development Community.
Considerations for a utility that provides Background Images
Ground2K is especially sensitive to background image size to the extent that it sometimes requires smaller, highly-compressed, 16-Bit color or 8-Bit gray-scale images, and even reduction of Windows system display attributes to 16-Bit color mode ...to avoid USERVA OOMs, CTD's etc.
IMHO, it would be helpful to have a LOD-5 image with a visual guide to LOD-8 quad tile names ("friendly" and/or logical sequential or directional alphanumeric names, if possible) that would assist the user with
manually loading smaller imagery tiles into the work-space to maintain greater stability within the USERVA for
ex: Ground2K4.
A somewhat comparable issue affects use of SBuilder for FS9, SBuilderX 3.13, ADE, AFX and other FS utilities, all of which are 32-Bit applications having limited 'resources' available for loading / using larger background maps within their Windows task session USERVA.
AFAIK, all the above 3rd party FS scenery utilities require the end user to
manually load a background image file for the tile area that they are currently working on.
ADE offers a pick-list to
manually 'swap' between such background images
after their file/folder path is 'added', linked and manually configured with Geo-referencing information by ADE.
However, I am wondering if it is feasible to add an option in your 'LOD#_Image_Tool' (or other such 'background image' tool), to:
* Directly access the same aerial imagery tile servers as SBuilderX, when selected from a comparable pick-list
...
or:
* Read selected SBuilderX tile server sub-folder chains created by tile down-loader DLLs in SBuilderX\
Tiles
...then output a user-specified, 'stitched' / 'composite' image 'tile' size, with a "world" file, into a separate folder path,
ex:
* LOD-5 image with a visual or TXT file guide to LOD-8 quad tile name / grid position for LOD-8 sized images
* LOD-8 image with a visual or TXT file guide to LOD-13 quad tile name / grid position for LOD-13 sized images
* LOD-13 image with a visual or TXT file guide to LOD-18 quad tile name / grid position for LOD-18 sized images
...which could more easily be used to semi-automatically import 'tiled' background images to 3rd party freeware and payware scenery creation utilities, provided that authors for such 3rd party utilities were inclined to develop an import mechanism for such 'gridded' images having paired Geo-referencing "world" files.
Another consideration which I believe could be of great help to FS Developers in creation of legacy FS2Kx and MDL-based G-Polys, would be an option for aerial image tile output at specified LOD quad tile sizes:
* Mapped by end users following a grid 'template' in a file that provides a quad tile name / grid position guide
...and:
* 'Placed precisely in alignment on MSFS terrain grid quad vertex coordinates
...provided for each
local quad in the FS 3D world on which G-Polys are intended to be displayed.
Although the FS terrain rendering engine may subsequently utilize submitted mapped imagery and other texture images as it sees fit within a Continuous LOD (aka "CLOD") mechanism at run time, IIUC, the reason ACES implemented a QMID terrain grid system is to load and submit terrain scenery content to be rendered at run time via a quad-based schema.
AFAIK, on that basis, it may merit testing to see if there may be run time FPS performance benefits to be had with custom G-Polys mapped to precisely-sized LOD quads that are also 'placed' precisely in alignment on the known and calculable MSFS terrain grid vertex coordinates ...for each local quad in the FS 3D world onto which G-Polys are intended to be displayed.
IIUC, G-Polys may require development considerations similar to default MSFS Land Class / Water Class tiles mapped with texture images in "Powers of Two" aspect ratios,
and terrain mesh quad 'tiles' that are also 'placed' precisely in alignment on the known and calculable MSFS terrain quad grid vertex coordinates, for each local quad in the FS 3D world where they are intended to be displayed.
I believe it is reasonable to infer that G-Polys share comparable design considerations to the above referenced default FS scenery tiles that have been configured by ACES to work within the MSFS "quad tree" structure for a number of valid reasons ...not the least of which is run time FPS performance.
Thus, for creation of G-Polys, I believe it would be helpful to have a means to:
* derive aerial imagery tiles that are "pre-sliced" into quad grid LOD-sizes
...which are:
* mapped onto G-Polys that are "pre-sliced" into MSFS quad grid LOD-sizes on N-S, E-W 3D world axes
...that are also:
* 'placed' at designated local MSFS
terrain quad grid vertex coordinates (
rather than at variable 'offsets' from grid vertices)
...and which:
* have mapping to local terrain quad grid identifiable via a visual or TXT file guide to image file LOD-# quad tile name / grid position.
If you have already tested this and concluded that when texture images are utilized in "
Powers of Two" aspect ratios with MIPMAPs, whether the objects onto which they have been mapped, are 'placed' on- or off- "the default FS terrain grid coordinate system" does not significantly impact MSFS run time performance, I would welcome reading such a conclusion that is drawn from objective testing.
The number of FS Developers 'endeavoring' to create G-Polys (and the associated 'anguish') is increasing; so I believe they may appreciate some help, as would those wanting an easier way to create and utilize higher resolution aerial images and/or maps as a background image in 32-Bit FS scenery utilities.
Many thanks for taking the time to consider these possible feature options in your future work with your innovative MSFS utilities.
GaryGB
