Hi Steve:
The "stretched rubber sheet" distortion when aerial imagery is draped "top-down" onto the terrain mesh as textures via the FS world rendering engine is indeed a major factor which might compel use of 3D models for valley walls that have a near vertical orientation relative to the "ground" of the valley floor.
Another factor is that the real world camera viewpoint used when the above panoramic landscape photos were taken was via a "horizontally oriented" perspective parallel to the plane of the valley floor (thus perpendicular to the vertical plane).
Therefore those ultra high detail images would IMHO need to be draped via a "lateral approach" to avoid the same undesirable texture distortion in FS at run time that one would have incurred when draping aerial imagery "top down" onto the vertically oriented (sky-ward) surfaces of 'terrain' objects ...whether displayed by means of terrain mesh, or by 3D objects.
However, IIUC, you plan to utilize ultra high resolution textures only on the major landmarks with predominantly vertical faces for which suitably detailed "horizontal landscape" imagery is available, so that might lighten the workload by allowing the remainder of the valley terrain structures and ground surfaces to be implemented by aerial imagery draped "top down" onto a custom higher resolution terrain mesh as custom photo-real land class textures, such as is typically done in the FS world rendering engine.
Creation of custom terrain mesh and photo-real land class textures can be a mostly automated process assuming availability of suitably detailed, georeferenced, orthographically projected etc. data from sources which are free or affordable, and which allow unrestricted use of the data for ones intended purpose.
One might wish to initially determine what approximate target resolution the available imagery is to be compiled into for use within FS by analyzing the size in Meters of the horizontal span of the landscape / object(s) versus the horizontal span in Pixels of the imagery, whether aerial "top down" or "horizontal" panoramic ...to determine the effective LOD of textures to be draped onto terrain mesh (or mapped onto 3D objects), and how many tiles of
ex: 4096 x 4096 Pixel imagery are needed to cover the areas / objects of interest.
In the case of source imagery for custom photo-real land class textures, one will end up deriving the "size" (aka 'dimensions') of imagery Pixels (expressed as Pixels per
Geographic 'Arc Degree') for use in the INF file submitted to FSX Resample.
[
EDITED]
https://msdn.microsoft.com/en-us/library/cc707102.aspx#SourceParameters
CAVEAT: FSX SDK docs infer that achieving 'intended' run time display of higher resolution textures may require use of resolutions no greater than
LOD-13 (QMID-15) aka 4.75 Meters/Pixel:
https://msdn.microsoft.com/en-us/library/cc707102.aspx#QMIDandLODValues
The above FSX SDK doc caveat may be particularly true if the user aircraft is moving at higher rates of speed (such as in a "race") at a
close distance to the textured object.
Thus, when a FS user aircraft is moving very fast in close proximity to the ground or a 3D surface, rendering of very high resolution textures may be at risk for "blurries", slowed display and/or clipping / shifting of LODs to lower resolution MIPMAPs etc. if they are mapped over a very high vertex density 3D model, or draped over a very high grid density (higher LOD / smaller distances between elevation data points) terrain mesh.
This may be even more likely to occur if the end user computer running MSFS is not powerful or well-optimized.
However, the above FSX SDK doc caveat is rather curious, as LOD-13 is the maximum resolution that FS2004 (aka "FS9") can display for custom photo-real land class textures, and the FSX default land class terrain texture resolution is 1.2 Meters/pixel (LOD-15); why would ACES have given us high resolution ground textures with a rendering engine that "can't keep up" ?
Regardless, over the years that have passed since FSX was still in development prior to its release, the FS Community has shown that we are quite capable of using and displaying resolutions higher than the supplied "out-of-the-box" max 30 Meter / LOD-10 default terrain mesh and 1.2 Meter / LOD-15 default land class terrain textures ...on "most" modern computers running FSX,
without incurring the above rendering and display issues (as ACES likely had already envisioned).
[
END_EDIT]
NOTE: SBuilderX can perform most of the above required work and calculations semi-automatically.
Furthermore, by using GeoTiff format for source data submitted to FSX Resample to make terrain mesh, ones workload with such calculations can be greatly reduced or eliminated.
I believe you may find that some work with SBuilderX may prove to be worth the investment of time, such that you might find other aspects of your perceived pending workload can be reduced substantially.
And as for draping texture materials onto Yosemite landmark 3D objects, IMHO, the method I previously described using Sketchup (with optional use of 1 or more Ruby script plugins) may merit further consideration.
http://www.fsdeveloper.com/forum/threads/mesh-from-sketchup.433127/#post-701342
This procedure might make it possible to complete the texture material draping operation onto the side wall structures of those Yosemite landmark 3D objects via a "lateral approach" in a single step (and/or a very few additional such steps), as shown in Taff Goch's tutorial.
https://3dwarehouse.sketchup.com/model.html?id=7b8a0bd3d848e985e523d8740930d7f9
http://help.sketchup.com/en/article/94883
GaryGB
