Global Mapper Export Question

[GaryGB]

These are impossible coordinates. Latitude has to be between between 90° 0' 0" N and 90° 0' 0" S. Longitude is between 180° 0' 0" W and 180° 0' 0" E

Something went wrong with the reprojection of the original data.

Dick

Hi Dick,

I literally re downloaded the zip file, extracted, put it into global mapper, and applied these settings and I get the same results. Its come straight from a government website focusing purely on sat and aerial data.


Projection: Geographic (Long/Lat)

Datum: WGS84

Planar units: ARC Degrees

Attribute - Central Longitude: 0

Gentlemen, you will kill me

it was loading the data it was the incorrect Projection being loaded that caused all this!

thank you everyone especially Gary for all your patience and support!

Hi Philip:

I have been rather busy conducting a review of the considerations related to how best to segment / grid / tile the GeoTIFF exports from the original massive ECW loaded by Global Mapper, and how best to output the BGL(s) from MSFS / P3Dv2.x SDK Resample while maintaining a optimum balance of visual quality, minimum file size, and maximum performance.

I did briefly notice the likely retention of the UTM-related projection info in the metadata, above, but I was so busy with my research that I failed to get back to this thread and post the recommendation that would correct this issue; sorry for the delay in posting about that.


CAVEAT: In Global Mapper, any geo-referenced data file that is opened or otherwise imported and loaded, is initially displayed in its own internal "native" projection and datum (which explains the retention of the "UTM32-EUREF89" projection in the metadata for that file).

http://www.euref.eu/symposia/book2001/nr_9.PDF

https://www.fig.net/resources/proceedings/fig_proceedings/fig2006/papers/ts26/ts26_02_bahl_0250.pdf



One must then re-project that data before submitting it to FSX / P3Dv2.x Resample by changing the workspace projection and datum settings of Global Mapper itself.

To reiterate my instructions previously posted above:

http://www.fsdeveloper.com/forum/threads/global-mapper-export-question.434552/#post-715864


Example Global Mapper workflow for your aerial imagery:

After first opening your ECW data file in its native "projection", one must next set Global Mapper to the "projection" required by MSFS / P3D SDK Resample ...so that any subsequent exported data will be correctly formatted:

1.) Global Mapper Menu > File > Open Data File(s)... > Browse / select your:

"ECW file in UTM 32 ETRS89 projection 10cm imagery"

2.) Global Mapper Menu > Tools > Configure > [Projection Tab]
a.) Configure:

Projection: Geographic (Latitude/Longitude)

Datum: WGS84

Planar Units: Arc Degrees

Parameters > Attribute

Central Longitude = 0

b.) Click Apply > OK


* Please post a new copy of the "Metadata" from Global Mapper Layer Control Center for that re-projected ECW file.

I need to reduce the 10cm imagery to 50cm currently its all being displayed in arcs so I am going to have to figure this one out.

Could you please explain more in detail, exactly what you mean by "its all being displayed in arcs" ?

GaryGB

 

[philipvjensen]

Hi Gary,

please don't apologize, I am just happy someone takes the time to help with this!

Right now I have projection correct and resample is working the file into a bgl.

Problems.

I am not sure how to retain the detail of the 10cm in the inf file. It seems even with no compressionquality change the resample is compressing or changing the quality of the image to be much lower.

e.g. my geotiff file is 533mb after trying several different inf settings it reduces the file size to 32mb and no larger.

At the moment I am not getting that orbx kind of quality from the bgl file.

Not sure what settings I have wrong but below is my standard test inf file at the moment. I also checked the exported GeoTiff imagery in photoshop and the quality is still there. Its just when its changed to a bgl file something is lost.

In the sim the imagery is placed precisely. I attached another one of screenshots to see, if you look close you can see the loss of detail mainly the roads and taxiways are very blurred when landing on them.

[Source]
Type=TIFF
Layer=Imagery
SourceDir="."
SourceFile="aalborg_airport.tif"
PixelIsPoint=0
ulxMap=9.86404258718466
ulyMap=57.090474293003
xDim=8.98313719559234E-07
yDim=8.9831371955935E-07
Variation=Day

[Destination]
DestDir="."
DestBaseFileName="aalborg_airport"
LOD=Auto,16

Hi Philip:

I have been rather busy conducting a review of the considerations related to how best to segment / grid / tile the GeoTIFF exports from the original massive ECW loaded by Global Mapper, and how best to output the BGL(s) from MSFS / P3Dv2.x SDK Resample while maintaining a optimum balance of visual quality, minimum file size, and maximum performance.

I did briefly notice the likely retention of the UTM-related projection info in the metadata, but I was so busy with my research that I failed to get back to this thread and post the recommendation that would correct this issue; sorry for the delay in posting about that.


CAVEAT: In Global Mapper, any geo-referenced data file that is opened or otherwise imported and loaded, is initially displayed in its own internal "native" projection and datum (which explains the retention of the "UTM32-EUREF89" projection in the metadata for that file).

http://www.euref.eu/symposia/book2001/nr_9.PDF

https://www.fig.net/resources/proceedings/fig_proceedings/fig2006/papers/ts26/ts26_02_bahl_0250.pdf



One must then re-project that data before submitting it to FSX / P3Dv2.x Resample by changing the workspace projection and datum settings of Global Mapper itself.

To reiterate my instructions previously posted above:

http://www.fsdeveloper.com/forum/threads/global-mapper-export-question.434552/#post-715864


Example Global Mapper workflow for your aerial imagery:

After first opening your ECW data file in its native "projection", one must next set Global Mapper to the "projection" required by MSFS / P3D SDK Resample ...so that any subsequent exported data will be correctly formatted:

1.) Global Mapper Menu > File > Open Data File(s)... > Browse / select your:

"ECW file in UTM 32 ETRS89 projection 10cm imagery"

2.) Global Mapper Menu > Tools > Configure > [Projection Tab]
a.) Configure:

Projection: Geographic (Latitude/Longitude)

Datum: WGS84

Planar Units: Arc Degrees

Parameters > Attribute

Central Longitude = 0

b.) Click Apply > OK


* Please post a new copy of the "Metadata" from Global Mapper Layer Control Center for that re-projected ECW file.




Could you please explain more in detail, exactly what you mean by "its all being displayed in arcs" ?

GaryGB

 

[GaryGB]

Hi Philip:

Try another compilation of your same re-projected GeoTIFF by FSX / P3Dv2.x Resample with a 'copy' of the INF edited so that:

LOD=Auto

...and:

FSX / P3Dv2.x Resample output BGL is named "aalborg_airport_LOD-Auto"

[Source]
Type=TIFF
Layer=Imagery
SourceDir="."
SourceFile="aalborg_airport.tif"
PixelIsPoint=0
ulxMap=9.86404258718466
ulyMap=57.090474293003
xDim=8.98313719559234E-07
yDim=8.9831371955935E-07
Variation=Day

[Destination]
DestDir="."
DestBaseFileName="aalborg_airport_LOD-Auto"
LOD=Auto


[EDITED]

FYI: Since 10.0 cm/pixel resolution aerial imagery source files theoretically may achieve a maximum resolution of imagery tiles within the BGL output by Resample of 'between' LOD-18 and LOD-19, one may need to use terrain mesh settings of at least 100% mesh complexity / 10 Meters mesh resolution and 7 CM texture resolution to enable a sufficient number of terrain vertices even with "flat" terrain ...to properly place, drape, resolve, and display those higher-resolution textures mapped onto the ground in MSFS at run time (within the small time frame allotted for doing so by the rendering engine).

[END_EDIT]

So, please use those settings during your test flight of the newly-compiled "aalborg_airport_LOD-Auto" BGL in FSX / P3D.


I shall look forward to your reply tomorrow (...it's quite late here in the USA).

GaryGB

 

[philipvjensen]

Hi Gary,

great success. Got the imagery to show at high resolution finally.

Only draw back is 8 bgls totalling 848mb. even with compression quality at 85. I did leave it at LODS = Auto and exporting the geotiffs no compression

I am not sure if 25 sqkm @ 10cm equaling 800mb over 8 bgls as I have not even touched the night lighting yet and layer masks.

Anyway here is 2 pictures of the results thus far... it looks great in the Sim

 

[philipvjensen]

 

[GaryGB]

Hi Philip:

Congratulations !


FYI: Just in case you might not have encountered this info before

Be careful to NOT change the overall dimensions in pixels (rows and columns aka horizontal width and vertical height in pixels) of whatever aerial imagery is being used, once it has been downloaded and Geo-rectified (aka 'Geo-referenced') ...regardless what program or utility that aerial imagery source file is being used in, whether GIS / SBuilderX / graphics editing program etc..

[EDITED]

In the case of GeoTIFF aerial imagery exported from Global Mapper, when any graphical editing is performed on "work" copies of the original files, one must FIRST back-up the Geo-referencing information which is inside the GeoTIFF file itself, as well as in any accompanying TFW and PRJ files (using a special GIS utility).


AFTER any graphical editing is performed on "work" copies of the GeoTIFF aerial imagery opened as "TIFF" files for ex:

* color-matching of adjacent tiles

* creation of seasonal variations

* creation of a LightMap (aka "night") variation

* creating a water mask in the (1st) 8-bit 'grayscale' (2-color 'Black+White') GeoTIFF Alpha channel

* creating a blend mask in the (2nd) 8-bit (256-color 'grayscale') GeoTIFF Alpha channel


NOTE: Final output source file format for Masks must actually be 8-Bit gray-scale; see:

http://www.fsdeveloper.com/forum/th...-scenery-achievable.440912/page-4#post-789447

[END_EDIT]

...the Geo-referencing information must AFTERWARDS be restored inside that edited 'TIFF' file itself to convert it back into a GeoTIFF file (using a special GIS utility).


BTW: I'll continue looking into options for output of the BGL(s) from MSFS / P3Dv2.x SDK Resample while maintaining a optimum balance of visual quality, minimum file size, and maximum performance ...as my available time permits over the weekend.


Keep up the good work; I'll watch for more screenies as the project progresses.


GaryGB

 

[philipvjensen]

Hi Gary,

thanks for the tips there with editing!

biggest challenge and unknowns i am still faced with

is can I use the export compression from raster images (global mapper) I am trying to creat less bgls.

the ones i have made are about 2gb and resample makes the bgl around 40mb. so instead of say 4 bgls I am trying to figure out how to make them 1 or just 2.

another thing is re projecting resolution. at what stage should I be doing that. I need to get it to say 50cm or 1m resolution for the greater area and again export it so that I can make minimal amount of bgls.

hope you enjoy your weekend and I will keep playing around and update this thread if I get any results from my side.

kind regards

Philip

 

[Tejal Bernardo]

Don't know if it is what you mean but you can specify in the .inf text file how many geotiff will be used, with mutisource parameter. then would be source 1, source 2 etc. and you just will get one .bgl.

 

[GaryGB]

http://www.fsdeveloper.com/forum/threads/global-mapper-export-question.434552/page-3#post-716190

Hi Gary,

thanks for the tips there with editing!

biggest challenge and unknowns i am still faced with

is can I use the export compression from raster images (global mapper) I am trying to create less bgls.

Hi Philip:

[EDITED]

I would not recommend using the compression option in Global Mapper with GeoTIFFs exported for use with FSX / P3D SDK Resample, as that internal compression will only greatly increase the compilation time via Resample, and will not effectively contribute to compression of the final BGL output.

Any compression desired can be achieved more efficiently via the (approximately 40 percent) compression option in FSX / P3D SDK Resample itself ...as specified by the "CompressionQuality = 85" parameter / value in the INF file submitted along with the GeoTIFF aerial imagery source files.

[END_EDIT]

the ones i have made are about 2gb and resample makes the bgl around 40mb. so instead of say 4 bgls I am trying to figure out how to make them 1 or just 2.

another thing is re projecting resolution. at what stage should I be doing that. I need to get it to say 50cm or 1m resolution for the greater area and again export it so that I can make minimal amount of bgls.

hope you enjoy your weekend and I will keep playing around and update this thread if I get any results from my side.

kind regards

Philip

Here's some initial info you may wish to consider (just a few threads among the many I am still reviewing):

http://www.fsdeveloper.com/forum/th...r-compiling-large-areas-photo-scenery.429040/

http://forum.avsim.net/topic/452357-terrain-lod-slider-fsx-v-p3d/#entry3086439

http://forum.avsim.net/topic/423417-lod-radius15-but-its-not-about-distance/

http://www.fsdeveloper.com/forum/threads/different-lods-within-one-bgl-using-resample.426723/

http://www.fsdeveloper.com/forum/threads/photoscenery-lod-radius-issue.300146/



A practical consideration is to decide what area you wish to be displayed in highest resolution (...ex: based on altitude of the user aircraft during approach / take-off from Aalborg airport).



As apparent from the screenies taken at a low 'base' approach flight Altitude in this thread:

http://www.fsdeveloper.com/forum/threads/lod19-photoscenery-worth-the-price.425664/

...one can extend the display of highest resolution aerial imagery in FSX / P3D by setting the LOD Display Radius at its maximum full-right slider position in the GUI, so one in theory could still see the highest LOD textures on the ground throughout an extended approach radius to / from the airport at 'normal' flight Altitudes.

Setting the LOD Detail Radius at its maximum "Large" slider position in the GUI imposes this parameter / value in FSX / P3D Cfg:

[TERRAIN]
LOD_RADIUS=4.500000

https://fsxtimes.wordpress.com/2011/08/03/fsx-cfg-lod_radius/


Most end users do not edit that value; but some users set it at 6.500000 or more ...often with adverse FS run time performance.

http://www.fsdeveloper.com/forum/th...d-rather-than-grouping-id.429331/#post-679112



Generally speaking, FSX / P3D, performance is impaired by excessive file I/O, so minimizing the number of files being read for a scenery can be more important than how big they are (other than the inconvenience of storage / distribution / installation size).

But, IMHO, 8 photo-real aerial imagery BGLs and many associated *an.AGN autogen annotation files should not impair performance.


Also, as Phil Taylor of ACES and the SDK docs warn, "transparency is computationally expensive", so how one segments the higher LOD BGLs will likely involve making them from separate GeoTIFF source files exported by Global Mapper using smaller selection "Boxes".

Thus, there will be smaller Geographic coverage areas within the highest-resolution aerial imagery Resampled BGLs (...and thus, less areas of transparency, aside from some 'feathering' very close to edges of those resulting highest-resolution aerial imagery tiles).


Another practical consideration is that, IIRC, autogen is not displayed farther out from the user aircraft than (14) LOD-13 quad-sized (approximately 1,223 Meters each on-ground) gridded spans of Resampled photo-realistic aerial imagery textures.

This 14-gridded-tile on-ground horizontal span is a Max. distance of up to 9.24514 Nautical Miles ...within the "Visual Display Radius " of the user aircraft.


Perhaps the highest-resolution area of Resampled photo-realistic aerial imagery textures might be limited to (14 ...or less) LOD-13 quad-sized (approximately 1,223 Meters each) gridded spans on the ground centered at Aalborg airport ?


Additionally, FSX / P3D loads files in alphabetic order.

So, IIUC, one should rename BGLs to ensure highest-resolution loads before lower-resolution BGL(s), thus smaller tiles of higher-resolution load before larger tiles of lower-resolution aerial imagery ex:


0_[filename].BGL loads before 1_[filename].BGL

[1,2,3,4,5,6,7,8,9,10]_[filename].BGLs loads before [A,B,C,D,E,F,G,H,I,J]_[filename].BGLs


...and Z_[filename].BGL loads after:

* any [1,2,3,4,5,6,7,8,9,10]_[filename].BGLs

* any [A,B,C,D,E,F,G,H,I,J]_[filename].BGLs


Hope this info gives you some idea as to what issues might be considered when planning how to best "segment" the highest-resolution aerial imagery tiles ...based on LOD-sized quads within the terrain quad matrix grid.


GaryGB

 

[philipvjensen]

hi Gary,

been experimenting a bit more and making all files into one bgl today.

total size is 340mb for 25 sqkm roughly.


problem I am noticing is that when flying larger airplanes the textures take longer to load or are reloading and not very sharp.

I have compared several addon sceneries such as flytampa copenhagen and flightbeam KIAD and there photoreal ground textures stay sharp and do not resize or change resolution when departing and climbing.

my LOD settings are LOD = 4,18

flying around in a helicopter I get no change in the textures at all really but flying larger aircraft seems to loose the resolution.

 

[GaryGB]

Hi Philip:

So, IIUC, keeping all other FSX / P3D settings the same, and only changing the LOD= parameter / value in the INF file submitted to FSX / P3D SDK Resample itself along with the GeoTIFF source files ...a "single" aerial imagery BGL output produces this result when flying a "complex"- versus a "simpler"- user aircraft ?

* Are the screenies you are posting from P3dv2.x ...or FSX ?

* If from FSX, are the screenies you are posting DX9 ...or DX10 mode ?


That result above is quite intriguing, and raises interesting questions about whether single- versus multiple- aerial imagery BGL file output from FSX / P3D SDK Resample has differences in effective run time performance, based on ex: available USERVAS per FSX / P3D Windows task session, and/or VRAM size on one's video card !



IMHO, it would be important to continue exploring this scenario, and the various options for single- versus multiple- BGL file output from FSX / P3D SDK Resample, to see what produces the best result without "tweaks" being required to the end users FSX / P3D configuration, as many may be unable to implement such tweaks correctly, if at all, and/or may be unwilling to use 'tweaks'.


IMHO, scenery to be used by others should run OK with settings accessible via FSX / P3D GUI menus, so "the onus is on us" as FS Developers, to find the best production methods to expedite that goal.


Please keep me informed on results of your further tests with this.


PS: I'll be continuing my inquiry into options for output of the BGL(s) from MSFS / P3Dv2.x SDK Resample while maintaining a optimum balance of visual quality, minimum file size, and maximum performance ...as my available time permits today.

GaryGB

 

[philipvjensen]

Hi Gary,

it is strange, if you look a this photo same distance altitude on my sim looking back at Flightbeams KIAD.

Also below is my scenery on approach and a helicopter looking back with the difference in quality very noticeable

. No graphics or displays changes

below is the inf file I am using for testning with my scenery.

[Source]
Type=TIFF
Layer=Imagery
SourceDir="."
SourceFile="aalborg_airport_B2_SU_test.tif"
PixelIsPoint=0
ulxMap=9.83898092906355
ulyMap=57.0985486066497
xDim=8.98313719556624E-07
yDim=8.9831371955664E-07
Variation=Day

[Destination]
DestDir="."
DestBaseFileName="aalborg_airport_B2_SU_test"
LOD=auto
compressionquality=85
UseSourceDimensions=1

Hi Philip:

So, IIUC, keeping all other FSX / P3D settings the same, and only changing the LOD= parameter / value in the INF file submitted to FSX / P3D SDK Resample itself along with the GeoTIFF source files ...a "single" aerial imagery BGL output produces this result when flying a "complex"- versus a "simpler"- user aircraft ?

* Are the screenies you are posting from P3dv2.x ...or FSX ?

* If from FSX, are the screenies you are posting DX9 ...or DX10 mode ?


That result above is quite intriguing, and raises interesting questions about whether single- versus multiple- aerial imagery BGL file output from FSX / P3D SDK Resample has differences in effective run time performance, based on ex: available USERVAS per FSX / P3D Windows task session, and/or VRAM size on one's video card !



IMHO, it would be important to continue exploring this scenario, and the various options for single- versus multiple- BGL file output from FSX / P3D SDK Resample, to see what produces the best result without "tweaks" being required to the end users FSX / P3D configuration, as many may be unable to implement such tweaks correctly, if at all, and/or may be unwilling to use 'tweaks'.


IMHO, scenery to be used by others should run OK with settings accessible via FSX / P3D GUI menus, so "the onus is on us" as FS Developers, to find the best production methods to expedite that goal.


Please keep me informed on results of your further tests with this.


PS: I'll be continuing my inquiry into options for output of the BGL(s) from MSFS / P3Dv2.x SDK Resample while maintaining a optimum balance of visual quality, minimum file size, and maximum performance ...as my available time permits today.

GaryGB

 

[GaryGB]

* Are the screenies you are posting from P3dv2.x ...or FSX ?

* If from FSX, are the screenies you are posting in DirectX-9 ...or in DirectX-10 preview mode ?

 

[philipvjensen]

P3D V2.5

 

[GaryGB]

Hi Philip:

FYI: In a FS computer, to properly render at run time, your scenery with very high-resolution aerial imagery BGL(s) for Aalborg made by FSX / P3D SDK Resample, there may be a need to consider:

* what hardware and drivers are being used, and how they are configured


...as well as a need to consider:

* how well optimized is one's configuration of FSX / P3D



If one downloads the free trial of Flightbeam KIAD at:

http://www.flightbeam.net/kiad.html/



Upon installation of Flightbeam KIAD:

1.) Open in FSX / P3D SDK TMFViewer, the following files:

[KIAD install path]\Scenery\KIAD_ground.bgl (LODs 4-16)
[KIAD install path]\Scenery\ainnerground.bgl (LODs 7-17)
[KIAD install path]\Scenery\a&sground.bgl (LODs 8-17)


2.) In FSX / P3D SDK TMFViewer:

a.) TMFViewer Menu > View > Level Of Detail > Auto

... note the range of LODs present within the (1 or more) BGL file(s) loaded in that instance of TMFViewer


b.) TMFViewer Menu > View > LOD Grid > check "LOD-13"

...one will see aerial imagery tiles covering an area of (8 x 10) LOD-13 quad tiles at Flightbeam KIAD


NOTE: Although Flightbeam KIAD scenery aerial imagery covers a larger area, its internal resolution is not quite as high ...as your Aalborg smaller area of highest-resolution aerial imagery (ex: LODs 4-18).

However, even with lower-resolution aerial imagery in one's scenery, one may need to consider whether proper run time rendering of your Aalborg very high-resolution aerial imagery may require custom optimization of one's FSX / P3D configuration.



If one also downloads the KIAD_Manual for Flightbeam's KIAD at:

http://www.flightbeam.net/kiad.html/

...you may note on Pages 4 + 5 in the Manual, the "Virtuali Addon Manager" utility FS configuration settings used at KIAD ...even with the lower-resolution aerial imagery in that scenery.


One might wonder whether your own Aalborg very high-resolution aerial imagery scenery may require may require further custom optimization of one's FSX / P3D configuration ...when compared to the somewhat lower-resolution aerial imagery scenery in Flightbeam's KIAD.



Thus, I would recommend that you configure a P3Dv2.x run time test flight using your very high-resolution aerial imagery BGL(s) for Aalborg, with 'at least' the same P3D configuration settings ...as used at KIAD by the "Virtuali Addon Manager" utility.


Hope this results in better performance and optimal display of your very high-resolution aerial imagery BGL(s) for Aalborg.

GaryGB

 

[philipvjensen]

Thanks Gary,

I did see the Virtuali Addon Manager config setup and had a think, but I have seen a few different sceneries all working well including flytampa sceneries who don't use Virtuali Addon Manager.

I will give some tests a try at home tonight and see what it does.

I will also try and re-export the a sample tile from global mapper just to make sure it was not a export setting I may have messed up.

also if your interested I can PM you a tile sample that is 70mb if you would like to see if its my settings or perhaps the bgl itself.

again thanks for the advise

Regards
Philip

 

[GaryGB]

Hi Philip:


Regarding the PM, if you post a link to a download site I can access without registering a new account, assuming the "tile" is a GeoTIFF, I could indeed load it up to inspect it in Global Mapper, and make a test BGL using FSX SP2 SDK Resample (I do not use P3D 'yet').

GaryGB

 

[philipvjensen]

Ah ok Gary,

I will make a tile tonight that is 1gb or so. as my current tiles are 2gb. I can send you a link from my google drive.

cheers
Philip

 

[GaryGB]

To update interested readers of this thread with some info from a series of PM's:


When inspected in FSX SDK TMFViewer, the OP's [LODs_4-18].bgl aerial imagery for the test area appears 'sharp'.


When loaded into my FSX Acceleration installation (which includes Sp2) in a run time flight, the OP's [LODs_4-18].bgl aerial imagery appears as sharp on-ground and at flight altitudes, as it does in FSX SDK TMFViewer.


But, when slewing the user aircraft from place to place and then holding a static position over that custom photo-real imagery, there is a brief delay of approximately 3 seconds before the imagery 'shifts position' slightly over another approximately 3 seconds before it then stabilizes.

It appears as though the imagery is still in the process of being fully 'draped' onto the ground, and raises questions as to whether FSX is still resolving terrain vertices (...and/or perhaps initially aliasing texture mapping to neighboring terrain vertices other than those the texture was originally intended to be mapped onto ?).


However, the above custom aerial imagery loaded appears 'sharp' throughout my entire FSX Acceleration flight session; it merely seems to shift its position slightly as the user aircraft moves over it.


I tested a number of FSX.Cfg tweaks, and was able to decrease the amount of time that the texture appears to require for becoming fully "draped" into its final position on the ground by somewhere between 25% to 50%; however, thus far I have not yet been able to entirely eliminate that delay with a "1-piece" LODs_4-18 aerial imagery BGL.

In SBuilderX, I made a test BGL from a very small downloaded tile of aerial imagery at the above project area containing LODs 7-18.

When that SBuilderX test BGL containing LODs 7-18 was loaded above just the underlying default FSX scenery (without the OP's test tile being loaded concurrently), I still get the same approximate pattern of rendering behavior:

"when slewing the user aircraft from place to place and then holding a static position over that custom photo-real imagery, there is a brief delay of approximately 3 seconds before the imagery 'shifts position' slightly over another approximately 3 seconds before it then stabilizes."

As with tests performed using the OP's [LODs_4-18].bgl aerial imagery for the test area, FSX.Cfg tweaks were able to decrease the amount of time that the texture appears to require for becoming fully "draped" into its final position on the ground by somewhere between 25% to 50%; however, thus far I still have not been able to entirely eliminate that delay with a "1-piece" LODs_4-18 aerial imagery BGL.



IMHO, there may be issues with FSX / P3D rendering of LOD-18 aerial imagery which invokes different requirements for production which we have not yet tested, and which are not to be compensated for via ex: Cfg file tweaks or other "system optimization" measures.


I suggest that it may still be possible to achieve FSX / P3D rendering of LOD-18 aerial imagery without a perceptible "draping delay", but further testing may be required wherein the LOD-18 tiles are contained in 1 or more BGLs without any of the lower LODs 4-17.

Thus those lower LODs would be output in 1 or more BGLs without any of the LOD-18 tiles.

I will continue to review that and other info to see if a criteria may be identified which might guide one in determining the LOD thresholds for separation of aerial imagery tiles into BGLs by specified LODs, and extent of coverage area at 1 or more specified LODs.

http://www.fsdeveloper.com/forum/threads/global-mapper-export-question.434552/page-3#post-716355

Ah ok Gary,

I will make a tile tonight that is 1gb or so. as my current tiles are 2gb. I can send you a link from my google drive.

cheers
Philip

Hi Philip:

You probably need not divert any of your available time away from sorting through this current phase of FS development and troubleshooting, to make such a 1GB example tile, as I have access to comparable (if not identical) aerial imagery at the same resolution for the project area to perform further 'tests' there ...via SBuilderX.


I look forward to future posts and PMs regarding your further work with exploring this very much less-explored and "under-documented" area of aerial imagery production via FSX / P3D SDK Resample.

GaryGB

 

[philipvjensen]

Hi Gary,

did some tests.

made a very large 60cm aerial imagery area, load times are far greater and visual quality remains. adding the 10cm imagery on top of it decreases load time significantly and I guess there are several ways to address this.

one is ones hardware and .cfg setup.

The other is examining whether 25cm would not impact visual quality at such an airport and would mean a performance gain for all users therefor removing the 10cm from the equation.

below are a series of photos I took while flying the heli which helps the computer and sim load the textures faster for 60cm imagery.

You can see the jet taking off there at 350+ knots starts to cause the delay in texture rendering, it is far more noticeable on approach.