Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
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 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.
what is your experience regarding custom aerial imagery compiled to CGL's - which LOD / zoom equals which quality and size?
starting point:
LOD / zoom 19 = high quality = 2.6 - 2.8 times of tile size, which means 1000 MB of tiles x 2.6 - 2.8 = 2600 - 2800 MB CGL file
has anyone a clue what to expect with LOD 17 and LOD 15 regarding quality and size of CGLs?
which LOD / zoom level is the absolute minimum quality for flights between 1500 - 3000 ft?
...and what is the bottleneck compiling CGL*s - the read/write rate of the hdd and/or CPU? would also like to know what the compiler is doing exactly compiling CGL*s - sampling the input images in what fashion? and at last - regarding the algorithm what to estimate when compiling 5 sqm with ZL19 in comparison to ZL 17 - will there be differences in compiling speed or just in CGL - filesize?
whatever, sorry for the asking but there is almost no to 0 documentation about compiling CGL*s.
I have some questions regarding the simple task, to create a scenery package with custom arial images georeferenced in qgis and converted with tiles2bing...
...and what is the bottleneck compiling CGL*s - the read/write rate of the hdd and/or CPU? would also like to know what the compiler is doing exactly compiling CGL*s - sampling the input images in what fashion? and at last - regarding the algorithm what to estimate when compiling 5 sqm with ZL19 in comparison to ZL 17 - will there be differences in compiling speed or just in CGL - filesize?
whatever, sorry for the asking but there is almost no to 0 documentation about compiling CGL*s.
There have been some issues with MSFS run time rendering of aerial imagery CGL's which may impact how FS Developers prepare their PackageSource files, while the overlying default Photogrammetry system apparently is still undergoing 'enhancement' by MS-Asobo into what IIUC, may become a new type of what some of us referred to in FSX/P3D as terrain "Land Class" textures.
These issues may factor into the actual processing time required by MSFS' FSPackageTool CGL compiler system.
Thus it is reasonable for FS Developers to reassess how best to make aerial imagery, as Asobo has IIUC not resolved all the current anomalies reported with aerial imagery and photogrammetry LOD / MIPMAP display.
It has been stated by some that MS-Asobo may not actually resolve all the current anomalies reported with aerial imagery and photogrammetry for MSFS-2020 in the future.
But there are also assertions that MSFS-2020 will continue to be developed and (some ?) issues resolved in the future.
FYI: FSX/P3D terrain "Land Class" textures were limited to ~1 Meter / pixel on the ground.
Here's a basic guide for purposes of working with the FS quad matrix terrain grid system (for ex: making sloped / tilted flattens).
LOD + 2 = QMID
LOD + 8 = Area Point Quad LOD Grid Size
LOD +10 = TMVL
QMID + 8 = TMVL
QMID + 8 = Area Point Quad QMID Grid Size
TMVL = Area Point Quad QMID Grid Size
NOTE:
TMVL = "TERRAIN_MAX_VERTEX_LEVEL" @ FS9.Cfg
TMVL = "MESH_RESOLUTION" @ FSX.Cfg
[EDITED]
NOTE: These tabular values have been 'rounded off' for...
...it appears MSFS SDK used "Level Of Detail" in a generic sense, but actually refers to QMID / Zoom Level (aka "ZL").
IMHO, the table quoted immediately above for MSFS SDK Docs actually refers to LOD-18 / QMID-20
AFAIK, this aligns with Microsoft Flight Simulator versions (and most EPSG:3857 projected 3D world 'spheroid' models)
Note also the range of LODs Microsoft Flight Simulator SDK historically cited within its TMF Quad Grid scheme.
If MSFS has actually capped aerial imagery display at LOD-18 / QMID-20, has it capped 'other' texture LOD display ?
IIRC, glTF 3D models and flat or TIN-derived glTF Ground Polygons (aka G-Polys) may display textures at > LOD-18.
[END_EDIT]
Since BING (formerly known as MS Virtual Earth) imagery rarely exceeds Zoom Level-18 IRL, MSFS "up-samples" it.
Depending on zoom level of 'custom' source aerial imagery you wish to use, you may need to "up-sample" it for MSFS.
Due to the functionality of the terrain scenery subsystem:
* FSX/P3D custom aerial imagery needed to be at least LOD-15 / QMID (Zoom Level)-17 in order to display on top of default terrain "Land Class" textures.
[EDITED]
* MSFS custom aerial imagery needs to be at least LOD-18 / QMID (Zoom Level)-20 (...or slightly less in some areas) in order to display on top of default terrain aerial imagery textures.
[END_EDIT]
Run time rendering of aerial imagery around a user camera may vary according to FS Terrain display slider settings:
* LOD Radius in FSX (reportedly can be slightly increased via manual edits of FSX.CFG file)
* Terrain Level Of Detail in MSFS-2020 (reportedly can be slightly increased via manual edits of UserCfg.OPT file)
But, an important consideration must be kept in mind regarding run time rendering of any texture:
FS LODs switch imagery MIPMAPs displayed according to user camera distance from terrain and/or 2D / 3D objects.
Thus, in-flight above-ground altitudes will not- / can not- display all higher LOD MIPMAPs we 'anticipate' seeing.
Even on ground in a cockpit, some textures will not- / can not- display all higher LOD MIPMAPs we 'anticipate' seeing.
Consequently, in some cases there is no benefit to making ultra-high resolution terrain and/or 2D / 3D object textures
So, IMHO we must know more about where you plan to use 'custom' aerial imagery ...to answer all of your inquiries;
* What are the Geographic coordinates for the center of your 5 square mile area ?
Another thing that may prove important to know and consider when responding to your inquiries on this project, is:
* What type of aerial imagery you hope to utilize as source data ?
AFAIK, one would only wish to use "ON-NADIR" imagery taken in a special type of camera with post-processing of images correlated to known Ground Control points for Geo-rectification of resulting image tiles.
"OFF-NADIR" (aka 'Oblique' / 'Bird's Eye View') images taken out an aircraft window or skydive door etc. would likely not be feasible to use in FS for terrain aerial imagery draped onto the ground surface).
The latter "OFF-NADIR" imagery type would, however, be useful mapped onto the sides of buildings, canyon walls etc..
I believe your reply to my questions above would help us to answer your specific questions above more precisely.
If you prefer to instead focus first on potential replies to your posted questions above without the info I posted, let me know and I'll delete my reply.
many thanks for your detailed informative reply. i want to use RGB aerial images shot with Ultracam Osprey 4.1 converted and georeferenced with QGIS for a short presentation of the imagery.
the 5sqm was just an testfield and calculation example. since there is no documentation about structure and size of CGL's i wanted to find out:
- calculation time compiling CGL's on different LOD / ZL - levels
- read / write time compiling CGL's with different LOD / ZL - levels
- final size of CGL's regarding source imagery
as far as i understand the process, CGL's compilation is bottlenecked by read/write speed of the harddrive and does not depend on CPU heavily since the compiler seems just to sample the input imagery and write the output to a CGL which is al library file of different LOD of input imagery. seems also like compiling a LOD 15-17 imagery takes same time as compiling LOD 19-20 imagery on the same area in size.
so i would have to downsample the imagery to LOD 20 before converting. since compiling the CGL-library is pretty limited and undocumented, maybe i should use prepar3d for the presentation of the image data or unreal engine 5.
FSDEV has threads which discuss FS2Kx / P3D SDK Resample data processing times versus resolution and data burden.
But, indeed, there is otherwise little / no discussion here yet regarding working with MSFS' BGL and CGL file structures.
Until we know more about whether MSFS SDK CGL compiler 'caps' aerial imagery resolution at LOD-18 / QMID-20, you may wish to make your presentation scenery in FSX using the P3Dv1.4x SDK Resample compiler to maximize resolution.
This may also prove helpful if you have limited time available in which to test methodology and produce a final result.
That would allow display of the high quality imagery on ground, and optionally also on 3D MDL / TIN 'PG' Buildings.
Depending on performance / HDW of demo computer used, you may best achieve optimal data display in FSX.
And that refers to use of any data set up to LOD-18 and beyond, as FS2Kx can compile / render such high resolutions.
Feel free to inquire further if you would like me to post some GUI and manual optimization settings for a FS2Kx demo.
PS: Very impressive technology and results in the Vexcel Imaging camera and software you cited above.
It appears that system may now yield better quality source data for multiple FS scenery types than both Google / MS.
FS Developers interested in testing Vexcel's data in FS versions may wish to explore their sample data offerings:
again many thanks for the detailed info and links!
the quality of the images is indeed extraordinary while the technology is extremly expensive. i got just a small dataset of a limited area to process for presentation purpose.
since the CGL integration seems to be bugged and so poorly documented i recently decided to use unreal engine 5 for a reliable, presentable result of the data without having to backward engineer and guessing what is what and how.
i don't know if this is part of the MS/Asobo strategy to build obstacles for developers who are creating content for the simulator and to maintain a competitive advantage over rival independent developers, but it seems to me that there are some unusual hurdles in certain areas regarding the SDK, the documentation and generally the integration of custom content. hurdles that may not be in line with the intention of giving users the same capabilities that Asobo has for creating content.
have a nice day and plenty of air under your wings!
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
