I edited the statement regarding Sketchup and GMAX in my post above (I 'keep on' keeping late hours 'lately' ...un-clear English results
).
[
EDITED]
I'll post later regarding Sketchup options for "
Layers" (re-named to '
Tags' in newer versions by Trimble ... a dubious choice, IMHO).
https://forums.sketchup.com/t/layers-where-are-they/114882
https://forums.sketchup.com/t/tagging-system/257189/6
https://mastersketchup.com/sketchup-pro-2020-review/
[
END_EDIT]
FYI: The MSFS SDK Sample:
SimpleAerial documentation says:
https://docs.flightsimulator.com/html/Samples_And_Tutorials/Samples/Sceneries/SimpleAerial.htm
"
All image files for aerial images should be authored as 16bit PNG with a fixed size of 256x256px, and the build process will automatically generate the images for the lower levels of detail".
All examples of source imagery for MSFS Aerial Tiles I have seen online thus far have been RGB 24-bit, 8-bits per channel imagery.
The MSFS SDK
PROJECTED MESH OBJECTS documentation says:
https://docs.flightsimulator.com/ht...nery_Editor/Objects/ProjectedMesh_Objects.htm
"IMPORTANT! When being rendered,
projected meshes are baked into the terrain textures. This helps reduce the polycount and permits the element to be terraformed. However, it also means that the texture quality won't be any greater than the resolution of the terrain textures themselves. In general, this resolution is around 4cm/pixel at the equator, with the best/highest resolution terrain textures reserved for higher LODs so we have a better quality for airports. For users, they will experience the best resolution possible setting the "Terrain level of detail" option to its maximum value".
Additional MSFS SDK documentation details of note, are also to be found at:
https://docs.flightsimulator.com/ht...als/Samples/Sceneries/SimpleProjectedMesh.htm
Resolution of Aprons and Projected Mesh match at 4cm and are reasonable to use, as that is so high.
The difference between Aprons and Projected Mesh (in MSFS RTM) is in restriction of Aprons to inside a local Airport test Radius, and having little more than a environment-responsive "PBR"-type light attribute via Normals, and Rain Fx.
This limitation of Aprons and Projected Mesh may now be less limited according to recent updates cited in MSFS Docs, when source content is made external to- and prior to processing by- the MSFS SDK DevMode Scenery Editor.
There are, however, still limitations imposed when editing content for areas defined within MSFS default World Hub Airports.
Thus, work-arounds must necessarily involve making custom airport replacements with some source content being generated external to- and prior to processing by- MSFS SDK DevMode Scenery Editor in a 3D modeling app and/or MCX.
I am not certain whether 3DSMAX and/or Blender semi-automatic MSFS Export scripts are able to implement this level of control compared to manual export and 3D modeling apps and subsequent processing via MCX.
The latter is the workflow already in use by Sketchup user for MSFS content development.
We would almost always have to make custom textures to get 4cm, as publicly available aerial imagery rarely exceeds 15cm.
4cm on the ground / pixel = LOD 20 (~ Zoom Level 19 or 20 depending on the web map app versus SBuilderX tile downloader app)
Code:
Quad Area Area Area
Cell Point Point Point
Terrain Quad Quad Terrain
Grid LOD QMID Grid
Interval Grid Grid Interval
LOD QMID TMVL (Meters) Size Size (Meters)
20 22 30 9.6 28 30 0.0375 = (3.75 cm)
https://www.fsdeveloper.com/forum/threads/flattens.425495/post-633002
A 4K resolution, also known as
Ultra High Definition (UHD), typically refers to a display with a resolution of 3840 x 2160 pixels.
This means it has 3840 pixels horizontally and 2160 pixels vertically, totaling approximately 8.3 million pixels.
3840 pixels horizontally / 1000 pixels at 1mm in size per Meter = 3.84 Meters on ground extent of coverage per 4K texture image based on width of each 4K image used.
But actual resolving ability of most modern computer monitors involves pixels with a 0.25mm dot pitch, so potentially a monitor could display 4x higher resolution than 4cm.
https://www.google.com/search?client=firefox-b-1-m&q=monitor dot pitch units#sbfbu=1&pi=monitor dot pitch units
This equates to (2) quad LODs higher than LOD-20 (aka Zoom level 19 or 20) than 4cm, at LOD-22 / QMID-24 / Zoom level 21 or 22
...in MSFS texture display at run time.
To achieve this higher DPI resolution display, pixel scalar mapping via projection must be implemented via tiling of texture images.
Thus, we must use multiple tiles of "high" resolution textures to provide actual high resolution textures on G-Polys / Faces of large physical extent.
MSFS Default and custom Ground markings may exceed 4cm by design, IIRC, but may only be seen (very) close up ⁰due to LOD switching.
LOD switching is based on displayed size in pixels and/or internal vertex geometry complexity, but generally occurs as a function of (Z-sort) distance between the user aircraft / avatar camera and the displayed object of interest.
FYI: rhumbaflappy previously posted on related FS options for use of 3.5cm textures, and the issues of practicality for use due to LODs:
https://www.fsdeveloper.com/forum/threads/3-5cm-per-pixel.21121/
So, we must be selective as to 'where' we utilize 4K textures on objects, especially if multiple layers of 4K images are to be used in PBR.
We can also make G-Polys (aka GEDOT "Faux Photogrammetry") as textured 3D models; these can be sloped / non-flat 3D geometry.
G-Polys have nearly unlimited texture resolution exceeding that of Aprons or Projected Mesh (both being "merged" into terrain textures).
When made as SimObjects and/or SimProp Containers, G-Polys can have complex conditional attributes for Visual display at run time.
G-Polys also can have additional Visual attributes that match and exceed that of aircraft and FS2Kx "land class" vector objects.
GaryGB
I would assume that is the easiest approach to give the surface a more organic and natural look.