1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Airport terminal on a small hill

Discussion in 'Terrain Design General' started by seippg, 4 May 2017.

  1. seippg

    seippg

    Joined:
    17 Feb 2013
    Messages:
    194
    Country:
    unitedstates
    That'd be good and the best way to learn. Perhaps, if it's accurate enough, the only thing I'd need to do with it is adjust the area around the runways, taxiways and ramp. Thank you.

    So, essentially, I'd have two scenarios...
    • Starting on the ground at KILM, the FSX/P3D rendering engine will choose the higher LOD, guaranteed, so I'd have to set a higher LOD for my customized, small terrain CVX BGL (by choosing a higher LOD in MCX?)
    • Flying into the area, FSX will, under circumstances (I can't say I understand what the circumstances are, yet), choose the BGL by which it encounters first and you can set small spots outside the edges of the larger area BGL by making tiny areas around it...like outside the corners and at mid-points of edges of a rectangle.
     
  2. GaryGB

    GaryGB

    Joined:
    23 Dec 2005
    Messages:
    3,175
    Country:
    us-illinois
    Correct; Geographic extents of coverage for scenery content are coded in the headers of BGL files, for which data is read / loaded / displayed by the FS rendering engine as a concentric ring of decreasing LODs, based on increasing distance from the user aircraft camera position.

    If a flight originates farther away outside the extent of a smaller higher resolution terrain mesh BGL potentially containing higher LODs, but the aircraft first encounters and loads another BGL which has lower LODs, the FS rendering engine may fail to load and display the smaller higher resolution terrain mesh BGL with the higher LODs even when the user aircraft is within the Geographic extents of coverage for that BGL.

    If isolated elevation data points are added to one's custom terrain mesh BGL at the outer NW-NE-SE-SW corners of the lowest (and therefore largest on-ground coverage) LOD quad corners so that they extend outwards farther than the default or other 3rd party add-on terrain mesh BGL, larger Geographic extents of coverage for that BGL will be coded into the header of one's custom terrain mesh BGL, and will result in the user aircraft position (and therefore the FS rendering engine) to encounter and load that BGL before those other 'competing' BGLs.

    That should allow one's custom terrain mesh BGL to load and also display the smaller higher resolution LODs when the user aircraft is within the Geographic extents of the 'central' contiguous elevation data points area within that BGL. ;)

    GaryGB
     
    Last edited: 19 May 2017 at 15:22
  3. GaryGB

    GaryGB

    Joined:
    23 Dec 2005
    Messages:
    3,175
    Country:
    us-illinois
    Hi Greg:

    As a follow-up to my post in your earlier thread elsewhere which is related to this topic:

    ...and this earlier post within this same thread:

    As I stated above:

    "You might also extend your original photo-real aerial imagery a bit more to showcase terrain around the airport, and simplify making 'edges' for your Blend Mask at these linear borders:

    North: US-140
    East: US-40
    South: US-74
    West: Gordon / Blue Clay Road"


    So, I suggest that by using the work-flow cited above, you can extend your photo-real aerial imagery coverage surrounding the KILM area at a Zoom level 20 (LOD-19) at 0.075 Meters = 7.5 cm /pixel.

    In SBuilderX, by tracing edges of those 'road perimeter' landmarks and placing vertex points that capture Lon. / Lat. (aka "X / Y") Geographic coordinates to form a vector polygon over the above LOD-19 aerial imagery viewed as a continuously zoomable / pan-able background map with a super-imposed LOD-3 FS terrain grid, you can create a "boundary polygon", to then be exported from SBuilderX as a ESRI SHP file.

    That SHP file can be opened / used in QGIS to define a 'central' contiguous elevation data points area closest to the KILM airport for a higher resolution LiDAR Digital Terrain Map (aka "DTM").

    In QGIS, the Geographic region surrounding that SHP area up to- (but not including-) the NW NE SE SW "corner elevation data points" of a ex: LOD-3 FS terrain grid quad extent of coverage, would then be assigned a GIS "NO_DATA" attribute (...typically -32768 or -9999 depending on the GIS application).

    The LiDAR elevation data set can then be re-projected to EPSG:4326 and exported from QGIS as a GeoTIFF for use with FS / P3D SDK Resample.


    Thus, the loaded LiDAR data set between the 'central' contiguous elevation data points area closest to the KILM airport and the NW NE SE SW "corner elevation data points" outside the polygon provided by that SHP file ...could be prevented from being displayed in FS via the re-projected elevation source data exported from QGIS and then compiled to a terrain mesh BGL by FS SDK Resample.


    FYI: You can also provide a ex: LOD-12 / 10-Meter resolution terrain mesh via a separate BGL that underlies the above LOD-15 / 1.2 Meter
    resolution terrain mesh that has an even larger Geographic extent of coverage outwards from KILM ...if you wish to pursue that option.:idea:

    [EDITED]

    BTW: It is possible there may also be a separate work-flow in QGIS to use the GIS "NO_DATA" area outside the SHP polygon to define a absolute Black (RGB 0,0,0) within the same 8-Bit gray-scale Alpha channel in that aerial imagery GeoTIFF Raster image to make a FS SDK Resample Blend Mask.

    (...I'm not sure how that 'graphics' procedure may be done in QGIS at this point, but save all your data files anyway ! :scratchch).

    And by contrast, the interior area of the SHP polygon would be configured to define a absolute White (RGB 256,256,256) 8-Bit gray-scale Alpha channel in the same aerial imagery GeoTIFF Raster image to make that FS SDK Resample Blend Mask. :pushpin:


    Such a Blend Mask would configure the custom aerial imagery area between the 'central' contiguous elevation data points area closest to the KILM airport and the NW NE SE SW "corner elevation data points" outside the polygon provided by that SHP file ...to be displayed in FS subject to a transparency attribute in the re-projected aerial imagery source data exported from SBuilderX and then compiled to a BGL by FS SDK Resample using a "multi-source"-type INF file.

    That Blend Mask absolute White (RGB 256,256,256) 8-Bit gray-scale Alpha channel opacity attribute inside the boundaries of the 'central' contiguous custom data area enables the custom aerial imagery to show through onto the top of the local ground ...thereby preventing display of the FS / P3D default or other loaded 3rd party terrain land class textures otherwise seen outside the same boundaries of that 'central' contiguous custom data area as is defined by the SHP file referred to above.

    And by contrast, that Blend Mask absolute Black (RGB 0,0,0) 8-Bit gray-scale Alpha channel transparency attribute outside the boundaries of the 'central' contiguous custom data area enables the FS / P3D default or other loaded 3rd party terrain land class textures to show through onto the top of the local ground ...rather than the custom aerial imagery otherwise displayed inside the same boundaries of that 'central' contiguous custom data area as is defined by the SHP file referred to above.


    For more details on Blend Masks for custom Photo-real aerial imagery, see
    :


    Make photo-real ground textures in Flight Simulator X by Luis Feliz-Tirado

    Using the FS X Resample - Blend Mask


    https://library.avsim.net/esearch.php?CatID=fsxsd&DLID=140539


    ...Also see:

    How to create photoreal scenery for FSX by Tiberius-K et al.

    PART III - Watermasks and Blendmasks - Creating a Blendmask

    https://www.flightsim.com/vbfs/showthread.php?250762-How-to-create-photoreal-scenery-for-FSX

    [END_EDIT]


    Feel free to let me know when you are ready to proceed, and I'll post the URLs to LiDAR data for a 1.2 Meter / LOD-15 terrain mesh. :)

    GaryGB
     
    Last edited: 19 May 2017 at 21:30
  4. seippg

    seippg

    Joined:
    17 Feb 2013
    Messages:
    194
    Country:
    unitedstates
    Hi Gary,

    I've been busy learning the ins/outs and limits of the various tools. For example, I've found that Blender is a great tool for blending flattened runways/taxiways/ramps with surrounding terrain, but I've found that getting it from Blender to a tool that can work with what blender did to be problematic (it fails to export or, if it does export, the tool that can accept that export can't accept it because of size. So, I either break it up into chunks for the next app in the chain or reduce complexity to reduce size. SBuilderX won't even run on my Windows 10 machine so I have to move everything over to a Windows 7 machine to even start using it. I just have to patiently plod along discovering and learning how to work within these limits. Here's a well-blended section of the infield that I did get from Blender to MCX (right side of runway 6). There were some pretty sizeable 'cliffs' there and, with some work they were cleaned up nicely. (You can't see how nicely since Blender won't export the whole thing in a chunk in .shp format and MCX can't import the larger .x file.) TINs are cool to work with but there are limits to what you can do with them beyond that.

    [​IMG]

    It's a great solution but, using MCX, is not scalable as far as I can see at them moment without chunking it up into multiple CVX files. Perhaps there's a way to get a scalable solution from Blender to another tool. Or, perhaps there's a way to get Blender to intelligently reduce complexity before export. Flattening the runways to the same elevation and then blending them is key to me not having an absolutely flat airport.

    Back on topic, your 'no data' solution seems a very practical solution. As I recall, in QGIS I can set any value I wish as the 'no data' value.

    EDIT: Here's the area above as viewed in Blender. The orange arrow points to the area above and the yellow arrow points to another area I blended. It works well. The most you can see from the blend is a very faint line. If you see a clear line, that's an adjacent, unblended area. You can see the cliffs and lines for the areas I haven't blended yet...I wanted to see if I could see what it looks like in P3D/FSX before I went any further...

    [​IMG]
     
    Last edited: 18 May 2017 at 15:51
  5. GaryGB

    GaryGB

    Joined:
    23 Dec 2005
    Messages:
    3,175
    Country:
    us-illinois
    Hi Greg:

    What error message(s) do you get from MCX when attempting to import your 3D model *.X file ? :scratchch


    BTW: On a practical basis, if you simply allow the greater source of data for the terrain to be rendered in FS at run time by the actual FS SDK Resample-compiled LOD-15 / 1.2 Meter resolution terrain mesh derived from LiDAR source data, you may then only need to provide the CVX vector source data for the triangulated blending sloped flattens along the edges of Apron / Taxiway / RWY / perimeter service roads etc. to modifiy the underlying terrain mesh.

    This may prove to be less demanding on you as the developer, and on FS / P3D as the rendering engine, rather than attempting to provide the entire (massive !) triangulated terrain data set to be compiled as a FS SDK SHP2VEC-compiled CVX vector ground "surface" for the airport area. ;)


    FYI: The FS SDK Resample 'raster-derived' HeightMap-type elevation BGLs are rendered via a highly-optimized sub-system with multiple accessory CPU core-linked data loader processing threads and fast load internal file data address pointers

    IIUC, by comparison, the FS SDK SHP2VEC 'point-derived' CVX vector-type elevation BGLs are not as well optimized within the FS rendering sub-system, so the latter CVX vector 'ground' surface data is intended to be used "sparingly" in FSX / P3D to only "modify"- but NOT replace- the larger data set provided by actual Resample-compiled terrain "mesh". :pushpin:

    However, it would seem that you have likely learned quite a bit about Blender through this endeavor ! :coffee:


    Again, let me know when you are ready to proceed, and I'll post the URLs to LiDAR data for a 1.2 Meter / LOD-15 terrain mesh. :)

    GaryGB
     
    Last edited: 19 May 2017 at 16:27
  6. seippg

    seippg

    Joined:
    17 Feb 2013
    Messages:
    194
    Country:
    unitedstates
    Hi Gary,

    Yes, learned a lot about Blender. Still learning about what is useful in this context.

    Before I get the data you have, I do want to make sure I'm doing it in a way that works efficiently in FSX/P3D since this is an airport that demanding aircraft would use. From reading above, it sounds like the CVX idea...the way I'm doing i...isn't practical. That's kind of good news since it is a pain in the asterisk to work with even though it's such a practical way to go about it.

    Changing my thinking to sloped flattens and how to make them:

    Clearly, I *could* go all the way back to using ADE to make sloped flattens, though, I found using ADE for that was a real, real challenge. I could do it the 'nodata' idea using Blender to make the blends but...would those be 'sloped flattens'? Braining it out, I come up with this:
    • import a GeoTIFF from QGIS, convert it into a vector mesh and export it as a .shp file.
    • Import the .shp into Blender as a working file, most of which will be discarded.
    • In Blender, using the .shp data as a guide:
      • Separate the runways/taxiways/ramps and other places (ditches, roads) into separate objects, separate from the rest of the data. Raise the runways/taxiways/ramps as much as needed to keep the flattens such so that they will not make trenches in the terrain. Where needed, Blend the cliffs caused by that flattening down to the terrain. Fix the other places (roads, ditches) as needed.
      • Extract only the newly created slopes and fixes into a .shp file, and import them back into QGIS. Overlay the original GeoTIFF I started with and make holes in it that match the places I fixed as closely as possible. (Not clear on how to do that in QGIS.)
      • Do one of the following:
        • a) export the combined stuff in QGIS into a GeoTIFF and process it through SBuilderX. Doing it this way might be the best way for efficiency while running it in the sim.
        • b) Export the large GeoTIFF with holes and use SBuilderX on it. Export the fixes I made in Blender by converting it into a .X file from Blender, process it through MCX as a separate BGL. Might cause more texture-fighting.
    Remembering, the goals are:
    • Have flattened runways/taxiways/ramps that are blended with as much of the GeoTIFF real terrain as possible...for efficiency of the engine.
    • Have smaller terrain sections that are exportable and workable within the limits of existing tools.
    There may be a better way to do this (seems like their should be). Clearly, using a 3D editing application for this kind of work is more natural...if it would work. If I could export the entire vector results from Blender to a GeoTIFF...perhaps through a .shp file along the way, it would be easier.

    Gregg
     
    Last edited: 19 May 2017 at 00:12
  7. seippg

    seippg

    Joined:
    17 Feb 2013
    Messages:
    194
    Country:
    unitedstates
    Out of memory.
     
  8. seippg

    seippg

    Joined:
    17 Feb 2013
    Messages:
    194
    Country:
    unitedstates
    I'm working on a way to get the data from Blender back into a GeoTIFF. That would be a big win if it is successful and stable.
     
  9. GaryGB

    GaryGB

    Joined:
    23 Dec 2005
    Messages:
    3,175
    Country:
    us-illinois
    AFAIK, that could have been an error message from Windows as a result of what the MCX task session was attempting to do, because more likely it was exceeding the limits of the available USERVA range rather than the limits of available physical RAM; but perhaps Arno might have a different explanation for the error message you saw. :scratchch

    I got this type of error when Global Mapper GIS choked on a massive triangulated LiDAR data point source file. :banghead:

    When a data set is too large, one must either reduce the size, or find another work-flow to achieve the desired visual results in FS / P3D as rendered at run time.

    I believe we are presently endeavoring to identify the most FS performance-efficient means by which that may be done. :)

    GaryGB
     
    Last edited: 19 May 2017 at 19:26
  10. GaryGB

    GaryGB

    Joined:
    23 Dec 2005
    Messages:
    3,175
    Country:
    us-illinois
    Before I reply in detail to the proposed work-flow you described in your post above:

    http://www.fsdeveloper.com/forum/threads/airport-terminal-on-a-small-hill.440002/page-4#post-772265


    ...I believe it would be helpful to clarify a few things related to the types of objects we are working with.


    First, as seen in your screenshots in a prior post here
    :

    http://i.imgur.com/IFeerRf.png

    http://i.imgur.com/QvW4Df5.jpg

    ...in Blender, you are actually working with a Triangulated Regular Network (aka "TRN") that is a "gridded" configuration which uses a 'quad' configuration having a visible diagonal edge dividing (2) triangles to form each quadrilateral perimeter within that grid.

    https://gis.stackexchange.com/questions/121561/generating-a-mesh-from-dtm


    Possibly this TRN formation upon import is due to a default function, or due to a GIS plugin feature in Blender ? :confused:

    https://www.google.com/#q=Import+.shp+into+Blender


    Or does QGIS form a TRN via a "gridded elevation" option when forming the X,Y,Z 3D vector SHP export file ? :scratchch


    If so, be aware that the data burden will be greater with a TRN than with a TIN, and that an alternative would be to utilize a triangulation of elevation data points with the option to save a TIN, rather than a "gridded elevation" option within QGIS.

    https://www.google.com/#q=QGIS+TIN


    NOTE: I understand from working with the Sketchup feature to "Geo-locate" and edit a terrain mesh derived from the Google Maps source data which can be imported into a 3D modeling project, that manipulating triangles in a TRN may initially seem "easier" to do than with a TIN.

    However, there are ways available to make such editing work easier and/or as desired for a local modification of slope or subdivision of 1 or more triangles within a 'quad-triangle pair' or an array of such 'quads' ...with either default or plugin tool sets.

    Thus, working with TINs rather than TRNs would help reduce the data burden to create / process source data files. :idea:


    FYI: A TRN is distinct from a Triangulated Ir-regular Network (aka "TIN") as a TIN is NOT a "gridded" configuration.

    https://en.wikipedia.org/wiki/Triangulated_irregular_network


    Additionally, I believe it will be helpful to refer to any GeoTIFFs pertinent to this terrain mesh and/or 'terrain mesh modification' work-flow in your project, by including the word "elevation' so that we are referring to "elevation GeoTIFFs", to distinguish them from 'aerial imagery GeoTIFFs' that may be incidental to a discussion on the various aspects of your project work-flow.


    Regarding this proposal:

    ...one would instead export a SHP file from QGIS to be 'Appended' (imported) to SBuilderX, because AFAIK, SBuilderX does not process raster elevation data from GeoTIFFs (...but does process aerial imagery GeoTIFFs). :pushpin:

    The SHP vector object(s) 'Appended' to SBuilderX would be used to create 1 or more CVX vector polygon object(s) with assigned elevations for each vertex, and thus to implement 1 or more TINs that would be compiled into a "sloped flatten" BGL.


    Alternatively, the vector SHP of the terrain blending modifications (kept separate from the flatten polygon(s) for the Apron / Taxiway / Rwy / perimeter roadway surfaces themselves) exported from Blender could be imported to QGIS, which is then utilized to modify a loaded copy of the ex: 1.2 Meter / LOD-15 LiDAR elevation source data.

    That modified copy of the LiDAR elevation source data in QGIS, could then be converted / exported as a raster elevation data GeoTIFF for processing by FS/ P3D SDK Resample to create a terrain mesh BGL.


    I shall offer some further suggestions later today ...as soon as my available time permits. :)

    GaryGB
     
    Last edited: 19 May 2017 at 21:25
  11. seippg

    seippg

    Joined:
    17 Feb 2013
    Messages:
    194
    Country:
    unitedstates
    Update. I think I have found
    Yes...both efficient workflow as well as efficiency inside the sim. I'm sticking with my lower resolution data at the moment as the processing for the lower resolution data doesn't take as long (conversion to points and conversion to faces takes a while. Working with large, dense data in Blender can bog it down). Lighter data is best, for now.

    True. I use regular points and then 'sample' them. Then import into Blender and triangulate. QGIS does have a method for using random points...not much rhyme or reason to them. There are some other options that might, ultimately, create TINs or something better than what I used in those photos. More research to do there.

    NOTE: I'm still not exactly clear what a sloped flatten is...a polygon that is at an angle that pushes the land down below itself? My thought is that making a modified elevation GeoTIFF will help me avoid them except in areas where I have very specific needs for final adjustment (e.g. around the terminal and loading dock, or in areas where I need a very specific flatten.)

    I did have a marginal success, bypassing SBuilderX, processing a modified elevation GeoTIFF through resample.exe with an INF file, as we did earlier. I say 'marginal' because I'd been mucking with things so much (trying this...trying that) I couldn't identify a clear workflow from A to B and there were some things I didn't quite expect...A) the starting elevation GeoTiff to B) the modified elevation GeoTIFF (with blended flattened runways/taxiways/ramps). So, I'm going to, carefully, go back through the workflow, step-by-step, making notes along the way.

    Gregg
     
  12. GaryGB

    GaryGB

    Joined:
    23 Dec 2005
    Messages:
    3,175
    Country:
    us-illinois
    Correct, the CVX vector "sloped flatten" is capable of both lowering and raising terrain vertices to an assigned elevation.

    Any interconnected contiguous terrain surfaces will 'slope' or 'tilt' accordingly, to maintain a continuous surface to the fullest extent that the FS rendering engine can do so within a certain "snapping distance" via the DirectX graphics rendering sub-system of Windows.


    NOTE: In the quoted thread above, please review both screenshots in the post by "simulondo" (aka "Jose"):

    http://www.fsdeveloper.com/forum/threads/flattens.425495/page-2


    Especially note the fact that in SBuilderX, Jose used an on-screen super-imposed display of a LOD-23 FS terrain grid over the background map of non-warped aerial imagery tiles while drawing the poly-lines for his sloped flatten polygons to be exported to a CVX vector BGL "sloped flatten".

    Note as well, that Jose places his vertices for those poly-lines / polygons ...on the N_E_S_W corner vertices of FS terrain grid LOD-23 "mini-quads" / Area Points.

    http://www.fsdeveloper.com/forum/threads/flattens.425495/page-2#post-632968


    FYI: Despite Jose's diligent efforts to make the terrain re-meshing instructions very high resolution, the FS rendering engine still shows how it works from a terrain grid of quad tiles and Area Points (aka "mini-quads") which have a rectangular 3D shape.

    http://i1280.photobucket.com/albums/a483/simulondo/FSDeveloper/cabecera_zpsaa6d0024.jpg


    Thus we may still have 'some' degree of "jagged" or "aliased" edges in terrain down to the smallest terrain grid quads / Area Points at the very highest LODs when either a terrain mesh or a CVX vector re-meshing "sloped flatten" is displayed in FS / P3D at run time ...because ground surface edges are not aligned along the 'straight' N-E-S-W FS terrain grid axes that define the edges of terrain quads. :teacher:


    This is also true of 3D models used in FS / P3D, as triangles with straight edges are used to "simulate" the appearance of curves.

    However, we can make those triangular faces in 3D models look somewhat more 'smooth' by using many small faces, texture shaders, or "smoothing groups" in the geometry of the model to perform some trickery via control of lighting relative to face Normals. ;)


    BTW: When we use textured 3D models in FS / P3D with special AttachPoint "Platforms" to impose a hardened ground surface attribute, such surfaces do not inherit the same complete set of attributes as terrain compiled by FS SDK Resample mesh, or 're-meshing' terrain modifier CVX vector BGLs compiled by FS SDK SHP2VEC.

    In such scenarios, we have to implement seasonal changes of textures, display of autogen objects etc. through special procedures.


    GaryGB
     
    Last edited: 20 May 2017 at 14:39
  13. seippg

    seippg

    Joined:
    17 Feb 2013
    Messages:
    194
    Country:
    unitedstates
    Well, I did manage to get an export. I blended one of the retaining walls and exported. Here's where the P3D/FSX mesh settings come in. If I blend right up to the wall at a vertical angle in Blender, FSX blends the wall at an angle. At 1 meter mesh, it's pretty vertical but at 2 or 5 meters it's at an angle. So, to be certain I get a good wall, I'll need to use at least a small 3D object to ensure it's right at all reasonable mesh settings. Can't say I'm surprised by this.

    Gregg
     
  14. GaryGB

    GaryGB

    Joined:
    23 Dec 2005
    Messages:
    3,175
    Country:
    us-illinois
    Indeed, one must have sufficient FS terrain grid vertices enabled within the FS run time rendering system parameters to enable more accurate display of ground "shape" instructions / requests provided by FS SDK Resample-compiled terrain mesh and/or FS SDK SHP2VEC-compiled CVX vector flatten BGLs: :pushpin:

    I would recommend that in the event you distribute your scenery to 3rd parties, you should inform them to set the FS / P3D GUI Terrain sliders at 100% Complexity /1 Meter Resolution and supply a 1-Meter terrain mesh in addition to any CVX vector sloped flatten "re-meshing" BGLs.

    It is is important to be aware of the fact that if you or any other end user sets those terrain sliders at positions which result in less terrain grid rendering fidelity and a larger terrain quad / Area point terrain grid interval, you will likely NOT be able to predict at what physical / Geographic location any of the terrain vertex instructions you used (aka "requested" from the FS rendering engine !) to achieve a particular "ground shape" ...may actually end up being rendered. :alert:


    Thus, even if you use a 3D modeled, 1 -or- 2 Foot thick 'concrete' textured retaining wall along the edge of the apron areas etc., the hillside terrain mesh and/or CVX vector re-meshing sloped flatten 'break-line' where it approximates with the outside 3D surface of that retaining wall ...may- or may not- be rendered with precise alignment.

    This could potentially result in a low-profile hillside slope that projects under and through that wall, and subsequently displays its 'break-line' somewhere many Meters away from its 'intended location' by "aliasing" to a point farther back up the hillside itself, or out under the apron surface, rather than ending in a 'vertical' face at- or concealed within- the 3D modeled, 1 -or- 2 Foot thick 'concrete' textured retaining wall.


    If that compels you to contemplate making the entire KILM terminal, its surrounding hillside embankments and retaining walls as a 3D model, you would presumably then also be considering how to implement seasonal texture changes to the terrain portion of the embankment and hillside surfaces on such a 3D model in P3D, rather than simply leaving that up to the FS rendering engine to automatically switch using the draped default or custom photo-real land class terrain textures. :idea:

    GaryGB
     
    Last edited: 22 May 2017 at 17:42
  15. seippg

    seippg

    Joined:
    17 Feb 2013
    Messages:
    194
    Country:
    unitedstates
    That makes sense and is right inline with what I'm thinking.

    Well, the simplest answer there is that I'd probably use 3D objects in the small area around the front of the terminal and along the sides near the wall as green grass, blended. From what I've seen in winter photos they use winter grass at the top of the hill anyway. I could then blend that into the hill which looks really nice. From what I've seen, apart from the slopes FSX makes, the heights of the slopes look very accurate and work very well when the slopes are less than 25-30%...they get worse the steeper they are.

    As to what I'm going to do with the airport, the reason I started on it in the first place is I got tired of waiting for someone else to make it. I want to fly there! We'll see after that. :)

    Gregg
     

Share This Page