Airport terminal on a small hill

[seippg]

I just realized. The misalignment I'm seeing there is due to the stock flatten. Ugh. It's not right. BTW, I reprojected with 4326 and tried it and I don't see any visible difference. It's still very well aligned.

EDIT:

Also, I looked at Airnav for the airport stats.

http://www.airnav.com/airport/KILM

The airport elevation is the highest point on the landing area...31.7 ft...within a foot of the airport elevation in ADE. But, looking at the approach ends of the runways, 35, 6 and 24 approach ends are 10 feet or more below that. That would explain the tall plateaus. The approach end of 17 is about even with the custom mesh.

To fix the plateaus, I could, perhaps, blend them out somehow (preferred choice but difficult), lower the airport, broaden the flatten to the trees, etc.

I don't seem to be able to get a 3D projection like you did, but I overlayed the photoreal with the elevation (I didn't make any adjustment after they were imported) and added some transparency to the photo layer and got this which looks pretty good.

 

[GaryGB]

Be certain to properly exclude the default (aka "stock") central airport background / boundary flatten polygon as cited in the thread I had linked for you elsewhere:

http://www.fsdeveloper.com/forum/threads/ade-remembering-deleted-flattens.440003/#post-771443


See this post within the thread I had referred you to above regarding 'ABP Excludes':

http://www.fsdeveloper.com/forum/threads/create-small-slope-on-terrain.438028/#post-752117


[EDITED]

NOTE: The "ABP Exclusion 3-sided Polygon" object should be compiled by ex: SBuilderX into a CVX vector BGL named ex: EXCL_0302_ABP_KILM.bgl, that must be located in a \Scenery sub-folder of an active Area layer.

That active Area layer must be placed physically above that for the default [P3D install path]\Scenery\0302\Scenery\ Area layer ...within the FS / P3D Scenery Library GUI stack of layers.

[END_EDIT]


If you do not see a change in the apparent alignment of a compiled BGL after re-projecting a source data file, it may be because of the ongoing use of the Geo-referencing coordinates originally inserted into the INF by using GeoTIFF-To-INF; DO NOT USE THAT INFO !

Remove the 'explicit' source parameter values for ulxMap, ulyMap, xDim, yDim from within the INF when submitted to FS / P3D SDK Resample, and allow the compiler to read the Geo-referencing from the source file GeoTIFF *.TIF and *.TFW files with the proper source parameter value of "Type"=GeoTIFF" in that INF.


CAVEAT: All source data, whether aerial imagery, RAW Land Class / Land Use raster data, elevation data, etc, submitted to FS / P3D SDK Resample must be in Geographic (Lat-Lon) Projection / WGS84 Datum (aka "EPSG:4326").


"Spherical Web Mercator" (aka "EPSG:3857") is to be used only for' non-warped' aerial imagery or SHP data in SBuilderX as a calibrated background map and/or with "Appended" similarly "EPSG:3857"-projected vector SHP data.


"EPSG:3857" is also the GIS projection format to be used for background aerial imagery in a 3D modeling application such as Blender, Sketchup, GMAX / 3DSMAX, RenderMan, Cinema 4D, TrueSpace etc.


And in the case of vector SHP data, AFAIK it too will automatically and internally be 'warped' when re-projected by SBuilderX when submitted to the FS / P3D Terrain SDK SHP2VEC compiler.


Also, if you want AI Traffic and Ground Vehicles to be able to traverse the ground at KILM without getting "stuck" on un-level terrain, the Altitude assigned to all vertices of your 1-piece "central airport background / boundary flatten" polygon must be all the same elevation.

This is a compromise that MSFS has always had.

At the least, all Aprons / Taxiways / RWYs must be all on one level; but remember there are also Ground vehicles that will try to move over the aprons, so most developers allow for all these things by assigning a single Altitude for the entire "central airport background / boundary flatten".

Alternatively, you could use sloped flattens to modify the terrain plateaus / encasements for Taxiways / RWYs using a multiple-piece airport background / boundary flatten" multiple polygon CVX vector BGL.

GaryGB

 

[seippg]

Be certain to properly exclude the default (aka "stock") central airport background / boundary flatten polygon as cited in the thread I had linked for you elsewhere:

http://www.fsdeveloper.com/forum/threads/ade-remembering-deleted-flattens.440003/#post-771443


See this post within the thread I had referred you to above regarding 'ABP Excludes':

http://www.fsdeveloper.com/forum/threads/create-small-slope-on-terrain.438028/#post-752117

Okay, I'll look at these. Thanks for the further explanation for the uses of the various projections.

 

[GaryGB]

"Bumped" again, for edits to my latter post immediately above.

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


GaryGB

 

[seippg]

Late last night I got the ADE exclusion for the flatten working right...just to see what the alignment looked like. It's not proper removal of the flatten but it's good enough to see what I've gotten so far. Alignment looks good and the hill size looks right which is the important thing at the moment. The road also looks very good. See the photos below. The taxiways are all elevated (they're set that way in ADE). The runway surfaces are elevated but not the terrain around them so they are, sort of, hovering up in space about 10 ft up (odd...a glitch in the matrix).

The thing I can see is I'll need to really work on blending it. I'm kind of wondering if I could make this work without a flatten. E.g. if I modified the TIFF by changing the runway surfaces, taxiways and ramp all the same 'color' in the TIF as a spot on the ramp (also changing their altitude to be the same in ADE) if FSX would say "okay, it's flat enough" and let AI traffic and vehicles move properly. I could also use the same technique to 'blend down' the terrain around approach end of runway 17 so the runway's not in a hole. Then I could make a new flatten at the loading ramp, below the custom terrain and use a 3D object to give it a ramp that slopes down. Using a technique like this (using colors on the TIFF), I could make small adjustments to the terrain elevation to blend it with the airport anywhere needed rather than mucking around with elevation polygons.

I'm going to 'properly' remove the flatten in the next day or so to make sure I've got the full custom terrain.

 

[GaryGB]

Hi Greg:

Whether one excludes the default "Airport Background / Boundary flatten" polygon (aka "ABP") with ADE or SBuilderX does not matter as long as the resulting CVX vector exclusion BGL (compiled with the same FS / P3D SDK SHP2VEC) is located in a \Scenery sub-folder of an active Area layer.

Either method is "proper", IMHO, as long as it 'successfully' excludes the ABP (...and if a big 1-piece area- versus a tiny 3-point triangle- exclude polygon does not also interfere with rendering of 'other' desired scenery content ).

That active Area layer must be placed physically above that for the default [P3D install path]\Scenery\0302\Scenery\ Area layer ...within the FS / P3D Scenery Library GUI stack of layers.


I simply referred you to a thread showing the work-flow for an ABP exclude via SBuilderX because AFAIK, Jon Masterson (aka "Scruffyduck") did not yet have a detailed tutorial posted online (with illustrations) showing how to create a 3-sided exclusion polygon with ADE for an ABP exclude.

http://www.fsdeveloper.com/forum/threads/create-small-slope-on-terrain.438028/#post-752117


My apologies to Jon if I have thus far not found one that actually does exist.

If there actually is one which I have missed thus far, I would be grateful if he (or any other ADE team member or end user) could provide a link to that "official" Scruffyduck online ADE tutorial.

Also, I know Jon has been busy recently with some family concerns, and I didn't want him to feel compelled to take time away from those important matters to post an even more time-consuming reply to an ongoing inquiry regarding how best to implement an ABP exclude.


Additionally, you expressed an interest in exploring creation of sloped flattens, which is also addressed in the thread I referred you to.


Personally, I hardly ever enable AI Traffic or Ground Vehicles, but most FS / P3D scenery intended for public distribution (whether as freeware or payware) will most commonly implement the compromises required to allow those feature to work properly.

That compromise requires all 'connected surfaces' of Aprons / Taxiways and RWYs to be at the same Altitude for AI Traffic or Ground Vehicles to work.

That does not, by any means, require you to make your KILM airport perfectly flat if you do not wish to enable AI Traffic or Ground Vehicles.

However, the 'default' RWY type used by ADE or AFX will always be a flat planar textured hardened BGLComp-XML-type object perpendicular to its Z-axis relative to its position on the surface of the FS / P3D, 3D world globe.

So if you want to instead use "sloped RWYs", you will have to use the draped custom photo-real aerial imagery to provide the RWY texture on a CVX vector 'sloped' terrain flatten.

Alternatively you could create those "sloped RWYs" as custom 3D models with a hardened concrete 'platform' attribute via an AttachPoint within the 3D model and apply custom high resolution texture materials.

[EDITED]

PS: It would be IMHO, "inhumane" of me to not caution you about the headaches involved in creating synthetic terrain or editing existing terrain using color-associated elevation data sets in hybrid GIS / graphics software.

Far better that you should create / edit 'TINs' for what you want in a 3D modeling software application, then import it to MCX for Geo-referencing and export as a FSX / P3D cvx vector 'sloped' terrain flatten.

[END_EDIT]


Keep up the good work !

GaryGB

 

[seippg]

Hi Gary,

Here's the bgl files all zipped if you want to see how it looks. They're a bit of a mess because of all the mucking around, but you can see the alignment. In particular you can see the ground slope and there's a dark 'hole' to the right of runway 35 (just like RW) in addition to being able to see how the taxiways, runways and road line up and look. I fixed the locations of all the taxiways, runways and ramp with ADE. The drawing layer for that exclude is 139, BTW. I see no way to change it.

https://www.dropbox.com/s/ewtrglb6f0ayuz3/scenery.zip?dl=0

Thanks for the encouragement and help. I'd have not gotten this far without your guidance. There is *so* much to learn but it's rewarding.

PS: It would be IMHO, "inhumane" of me to not caution you about the headaches involved in creating synthetic terrain or editing existing terrain using color-associated elevation data sets in hybrid GIS / graphics software.

Far better that you should create / edit 'TINs' for what you want in a 3D modeling software application, then import it to MCX for Geo-referencing and export as a sloped FSX / P3D cvx vector terrain flatten.

I was afraid you'd say that about it being difficult. What are 'TINs' and what 3D software works to do it. I'm looking at and learning all options.

Gregg

 

[GaryGB]

Hi Greg:

I am examining the latest file set linked above.

Would you also please ZIP and link to the ADE *.AD4 file, and the INF file used to compile the aerial imagery BGL ?

GaryGB

 

[seippg]

Would you also please ZIP and link to the ADE *.AD4 file, and the INF file used to compile the aerial imagery BGL ?

Here you go. It still has the coordinates (took them out of the TIFF file with all the digits).

https://www.dropbox.com/s/frvsh82utj28uvy/Projects.zip?dl=0

 

[seippg]

Gary,

I took the coordinates out of the photoreal and recompiled. A screenshot is below showing the hole by the runway. I can't imagine it lining up better. I've also included the new BGL and INF files below the picture.

Gregg

https://www.dropbox.com/s/tp28zp99e9pxidf/KILM.zip?dl=0

 

[GaryGB]

Hi Greg:

Bearing in mind that Google will allow use of its aerial imagery only for personal non-commercial projects, you should be able to access a ZOOM level of 20 for making a background BGL with SBuilderX.

This will require some modification of the tile downloading process in SBuilderX, and some modification of the INF output by SBuilderX.

That BGL can be used in FS / P3D for more precise user aircraft positioning to capture point coordinates when connected to ADE and/or SBuilderX via FSUIPC.

Those point coordinates can be used for vertices with either captured FS terrain mesh ground surface elevations, or assigned Altitudes in ADE and/or SBuilderX.

Those vertices can be used to create CVX vector sloped polygons (aka "sloped flattens") that you may wish to implement for customizing terrain mesh display in FS / P3D to achieve the desired 'ground' configuration at your airport.


I have downloaded your most recent files, and will try to offer further feedback and reply to your prior questions this evening if I can.

GaryGB

 

[GaryGB]

Hi Greg:

Sorry for the delay in my reply, but I'm rather short on available free time at the moment.

I am preparing to provide a link to a higher-resolution LiDAR-derived terrain mesh at LOD-15 (1.2 Meters between elevation data points on ground) for the area surrounding KILM as an example for you to display with a higher resolution aerial imagery BGL.


You could also create the same quality aerial image seen in my FSX screenshot attached above in my latter post:

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


...via SBuilderX' tile down-loader feature:

1.) Center the SBuilderX background view on the KILM terminal building at a zoom level of 16

2.) Activate the Add Map > From Background dialog

3.) Choose a "zoom level 20" tile resolution capture.

4.) Compile a BGL

5.) Immediately after compilation, browse to:

[SBuilderX314 install path]\Tools\Work\ subfolder

6.) Copy Photo01.INF, Photo01.BGL, "L*.BMP", and "L*.TXT" (all the same file date and approximate times)

a.) Paste the copied files into a new 'KILM_Work' sub-folder along with a copy of FS / P3D SDK Resample


7.) Edit the Photo01.INF and configure "CompressionQuality=100"

8.) Save the changed file with a proper 'INF' file extension (not as 'TXT')

9.) Re-compile the file set to a BGL by dragging-and dropping the edited Photo01.INF file onto Resample

10.) Wait for Resample to finish completely before attempting to use the BGL in FS / P3D from an Active \Scenery sub-folder.


Feel free to try this, and let me know how it worked.


We can then address doing a FS / P3D coordinate & terrain mesh altitude capture via ADE or SBuilderX via FSUIPC, as this would be far less complicated (and would produce a much more satisfactory result) than attempting to 3D model and Geo-rectify a TIN via MCX for the terrain adjacent to the KILM terminal and hillside.

GaryGB

 

[seippg]

I am preparing to provide a link to a higher-resolution LiDAR-derived terrain mesh at LOD-15 (1.2 Meters between elevation data points on ground) for the area surrounding KILM as an example for you to display with a higher resolution aerial imagery BGL.


You could also create the same quality aerial image seen in my FSX screenshot attached above in my latter post:

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


...via SBuilderX' tile down-loader feature:

1.) Center the SBuilderX background view on the KILM terminal building at a zoom level of 16

2.) Activate the Add Map > From Background dialog

3.) Choose a "zoom level 20" tile resolution capture.

4.) Compile a BGL

5.) Immediately after compilation, browse to:

[SBuilderX314 install path]\Tools\Work\ subfolder

6.) Copy Photo01.INF, Photo01.BGL, "L*.BMP", and "L*.TXT" (all the same file date and approximate times)

a.) Paste the copied files into a new 'KILM_Work' sub-folder along with a copy of FS / P3D SDK Resample


7.) Edit the Photo01.INF and configure "CompressionQuality=100"

8.) Save the changed file with a proper 'INF' file extension (not as 'TXT')

9.) Re-compile the file set to a BGL by dragging-and dropping the edited Photo01.INF file onto Resample

10.) Wait for Resample to finish completely before attempting to use the BGL in FS / P3D from an Active \Scenery sub-folder.


Feel free to try this, and let me know how it worked.


We can then address doing a FS / P3D coordinate & terrain mesh altitude capture via ADE or SBuilderX via FSUIPC, as this would be far less complicated (and would produce a much more satisfactory result) than attempting to 3D model and Geo-rectify a TIN via MCX for the terrain adjacent to the KILM terminal and hillside.

GaryGB

Hi Gary,

I haven't had a chance to try this yet. I was having real difficulty getting any data out of Google on my SbuilderX 64-bit install (314 build). Not sure what's going on there.

I *have* been working on learning TINs (see images below). I had to reduce the resolution of the elevation data to get this far as it was taking a long, long time to process the point data as well as UV Unwrap. Even with that, it was taking 5-10 minutes.

Gregg

 

[GaryGB]

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

Hi Gary,

I haven't had a chance to try this yet. I was having real difficulty getting any data out of Google on my SbuilderX 64-bit install (314 build). Not sure what's going on there.

If you are having issues with blank / white tiles and/or missing tiles at differing zoom levels, be sure you have installed the latest 64-Bit GoogleServer.DLL file from:

http://www.fsdeveloper.com/forum/threads/new-googleserver-dll.19913/


Also, consider installing / using the new Google Maps V3 API-based tile server DLL from:

https://drive.google.com/uc?export=download&id=0B0QpXWuJbh-bMkJjbldlVDdZdTg


...created and released very generously by Richard Ludowise as a result of discussions in this thread:

http://www.fsdeveloper.com/forum/th...not-download-the-poi-business-overlay.439956/


NOTE: While Google Maps vector roads as a superimposed layer are variable with their accuracy and positioning relative to other content in the map display, those other graphical / vector elements themselves, are rather well-aligned with the Satellite and/or other aerial imagery layer which is otherwise also available via the Google Earth product line.

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

I *have* been working on learning TINs (see images below). I had to reduce the resolution of the elevation data to get this far as it was taking a long, long time to process the point data as well as UV Unwrap. Even with that, it was taking 5-10 minutes.

Gregg

Very few 3D modeling and/or GIS applications can handle massive LiDAR data sets without careful sub-sampling / binning / gridding / tiling, and by incremental loading of work sets.

I recommend the work-flow I referred to using ADE or SBuilderX via FSUIPC to capture coordinates and ground elevations to create / modify sloped CVX vector flattens instead.


PS: File attachment of multi-part ZIP files does not appear to be working at FSDev forums right now.

UPDATE:

I have linked a prototype "quick-&-dirty" version of the higher-resolution LiDAR-derived terrain mesh at LOD-15 (1.2 Meters between elevation data points on ground) for the area surrounding KILM cited above ....via a public-accessible download site here:

https://www.mediafire.com/?221zmbjyd6d5m4d

GaryGB

 

[seippg]

I'll grab the latest Google stuff and try the steps. Not sure how much I'll get to do over the next couple of days, Mother's day weekend and all.

Very few 3D modeling and/or GIS applications can handle massive LiDAR data sets without careful sub-sampling / binning / gridding, and by incremental loading of work sets.

I recommend the work-flow I referred to using ADE or SBuilderX via FSUIPC to capture coordinates and ground elevations to create / modify sloped CVX vector flattens instead.

I'm thinking of a hybrid approach with Blender and the mesh...keep the most needed details from the mesh (the road, the hill up to the retaining wall) and polygonize most of the rest. I'm still working out the details but, if it works, it might be a good way to work with real world mesh to enable someone to get efficient, sloping terrain around the runways and taxiways instead of a big flat surface. It'll be manually intensive, manually selecting all the points, but no worse than making the polys manually in ADE or SBuilderX.

I have linked a prototype "quick-&-dirty" version of the higher-resolution LiDAR-derived terrain mesh at LOD-15 (1.2 Meters between elevation data points on ground) for the area surrounding KILM cited above ....via a public-accessible download site here:

https://www.mediafire.com/?221zmbjyd6d5m4d

GaryGB

I see what you're doing there. The road looks brilliant all the way to the highway. The loading dock slope is well defined and the wall area is nearly vertical...I even see the cut out on the one wall. There are some big spikes off the airport here and there. How efficiently would FSX handle something like this?

Gregg

 

[GaryGB]

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

I'm thinking of a hybrid approach with Blender and the mesh...keep the most needed details from the mesh (the road, the hill up to the retaining wall) and polygonize most of the rest. I'm still working out the details but, if it works, it might be a good way to work with real world mesh to enable someone to get efficient, sloping terrain around the runways and taxiways instead of a big flat surface. It'll be manually intensive, manually selecting all the points, but no worse than making the polys manually in ADE or SBuilderX.

Hmmm... "polygonize" is a GIS concept that merits some 'inquiry-of-digression' all on its own:

https://www.google.com/#q=polygonize+qgis


...especially considering that SHP files output by QGIS projected to EPSG:3857 can be "Appended" to SBuilderX and used for creation / modification of other scenery content, including CVX vector flattens made "sloped" by using the ground surface Altitude capture feature of SBuilderX with the displayed terrain mesh in FSX / P3D under the slewed user aircraft position via FSUIPC.


But more to your likely 'intended' point, IIUC, you allude to having most local ground details contributed by a underlying 1-Meter high-resolution terrain mesh, with super-imposed modification of that terrain mesh by CVX vector sloped flattens derived from 3D models via MCX conversion ?

If so, that certainly may be rendered in FSX / P3D at run time with no significant impact on FPS.


And, yes it is definitely NOT required to use a big 1-piece flatten at airports; but it is simply a requirement in FSX / P3D that the ARP, and all connected Apron, Taxiway, RWY surfaces and their underlying flatten polygons must be at the same Altitude ...for AI Traffic / Ground Vehicles to work properly ...if you want to allow your end users to exercise their right to display those features.

Use of multiple flatten polygons or sloped sections within a 1-piece flatten polygon is possible, to further modify display of the underlying terrain mesh anywhere desired to ex: cut a vertical face into the hillside by the retaining wall and/or to implement a deeper ramp to/from the loading/receiving dock area of the terminal building.

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

I see what you're doing there. The road looks brilliant all the way to the highway. The loading dock slope is well defined and the wall area is nearly vertical...I even see the cut out on the one wall. There are some big spikes off the airport here and there. How efficiently would FSX handle something like this?

Gregg

Indeed; mesh 'prototypes' may have spikes/pits to be cleaned up later; thus the term "Quick-&-Dirty" !


That terrain mesh cited and linked above, is rendered in FSX at run time with no impact to FSX' average 50 FPS on one of my 'not-so-modern' test computers with a middle of the road 3.4 MHz quad-core CPU, 3-GB VRAM GPU, and 8 GB system RAM.

GaryGB

 

[seippg]

But more to your likely 'intended' point, IIUC, you allude to having most local ground details contributed by a underlying 1-Meter high-resolution terrain mesh, with super-imposed modification of that terrain mesh by CVX vector sloped flattens derived from 3D models via MCX conversion ?

If so, that certainly may be rendered in FSX / P3D at run time with no significant impact on FPS.

Good. I'm working on a workflow to do that, mostly with Blender since it allows you to manipulate things so easily.

And, yes it is definitely NOT required to use a big 1-piece flatten at airports; but it is simply a requirement in FSX / P3D that the ARP, and all connected Apron, Taxiway, RWY surfaces and their underlying flatten polygons must be at the same Altitude ...for AI Traffic / Ground Vehicles to work properly ...if you want to allow your end users to exercise their right to display those features.

Hmmm. I understand that the airport has to be flat for AI and vehicles. Just wondering...can it be tilted a bit? Here at KILM it wouldn't be useful but at single runway airports that could be more realistic.

Use of multiple flatten polygons or sloped sections within a 1-piece flatten polygon is possible, to further modify display of the underlying terrain mesh anywhere desired to ex: cut a vertical face into the hillside by the retaining wall and/or to implement a deeper ramp to/from the loading/receiving dock area of the terminal building.

That's what I'm after at the moment. Not sure if I'll use it that way but at least I'm learning.

 

[GaryGB]

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

Hmmm. I understand that the airport has to be flat for AI and vehicles. Just wondering...can it be tilted a bit? Here at KILM it wouldn't be useful but at single runway airports that could be more realistic.

AFAIK, not only do the airport surfaces intended for un-impeded function of AI Traffic and/or Ground Vehicles need to be "flat", but they must also be "level", meaning its surface is perpendicular to the vertical Z-axis of the local position on the surface of the FSX / P3D globe ...in the FS rendering engine's run time 3D 'world'.

So, IIUC, unlike with some arcade games and other types of simulators using AI objects, MSFS and its derivative progeny will not accommodate "Tilt" (aka "Slope") on surfaces to be navigated by AI Traffic and/or Ground Vehicle 'SimObjects', as it will be an impediment to movement over the ground.

Thus, any raised ground due to a inclined surface or other change in mesh Altitude after AI 'SimObjects' spawn on ground, or after landing on a airport surface at a defined Altitude ...effectively blocks further motion of such objects.

GaryGB

 

[seippg]

I've probably done 20 elevation extractions at this point while I'm learning, thinking, and figuring things out. It's interesting.

Gary, the reasons I'm trying to process this is

1. to correct problems in the mesh we created (tune the mesh around the retaining wall, loading dock, drain ditches, etc.)
   
2. to blend the area around the newly flattened runway so it's smooth. (Get rid of the cliffs.)
   
3. to be able to process it from Blender into something MCX can handle. Seems that Blender is not very efficient with that.

Most of the mesh I'm working on is pretty fine as it is...needs little adjustment spots. I wonder if it is possible to use the mesh as it is except, in those places where I need to make those adjustments, overlay it with small meshes in some few places where I need to apply fixes. That might eliminate item 3 above which is not a small point. Usually, those adjustment areas are 100 meters square or less and, in some places, would move a ditch over or make a ditch more defined. If that's possible I would:

• Use the BGL from the mesh I've been working with.
• Create new smaller BGL files containing small, specific meshes that would correct specific areas I need corrected.problem areas. I'd process those through MCX and include them in the scenery directory. (But, how would FSX know they are a higher layer than the larger mesh?

Not sure I can or should do it this way but I think it's worthwhile knowing if it could be done.

Gregg

 

[GaryGB]

Hi Greg:

IMHO, we should have the FSX / P3D SDK Resample-compiled terrain mesh BGL as the base / underlying layer; this could be a ex: 1-Meter terrain mesh derived from the LiDAR source for which I posted a "Q-&-D" test-of-concept above.


BTW: I'll provide you with the LiDAR source download URLs later if you are interested in trying that process for yourself (...without the spikes/pits seen in my "Q-&-D" prototype).


We can then 'modify' the terrain mesh with a FSX / P3D SDK SHP2VEC-compiled CVX vector BGL containing poly-lines and/or polygons with vertices that have assigned elevation values, which essentially acts as a "re-meshing" instruction set.


NOTE: A MCX imported / converted 3D terrain model output as a "sloped" flatten is a CVX vector "re-meshing" BGL.


That latter CVX vector BGL cited above simply needs to be placed in a active Area layer physically above that containing the custom 1-Meter terrain mesh BGL in the FS Scenery Library GUI stack of layers.

Alternatively, careful alpha-numeric naming will allow sequential loading of the terrain mesh and the CVX vector re-meshing BGLs from within the same \Scenery sub-folder.

If there is competition for loading and prioritization of run-time display by other default or 3rd party terrain mesh BGLs with larger extents of Geographic coverage, one can still impose a greater priority in one's custom terrain mesh BGL over that of competing terrain mesh BGLs, by placing elevation data points in remote locations at extents with a larger ex: LOD-3 ground coverage value than the competing BGLs, with interposed GIS NO_DATA values for blank areas that have no provided elevation data points between those remote points and the central contiguous set of terrain data coverage in one's custom terrain mesh BGL.

This 'tricks' the FS rendering engine into assuming that custom terrain BGL has a greater Geographic extent of coverage than actually exists within the central contiguous area of elevation data points, so that it will load when the user aircraft is farther away from KILM.

This effectively allows the custom BGL to pre-empt display of any competing default or 3rd party terrain mesh that otherwise might have loaded first and prevented local display of that local terrain mesh BGL with a smaller extent of coverage when a user aircraft arrives at KILM from a departure point far away outside its actual extent of contiguous mesh coverage.


FYI: ADE author "scruffyduck" has a good tutorial on control of load / display priority via FS filenaming etc. ...here:

https://scruffyduck.screenstepslive.com/s/help_docs/m/20268/l/199760-priority-matters


A related discussion on implementing / controlling priority with terrain BGLs:

http://www.fsdeveloper.com/forum/threads/higher-lod-terrain-not-drawn.435658/


PS: An in-depth discussion of FS / P3D CVX vector sloped flattens, TINs, TRNs, terrain grid Quads, and LODs:

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


GaryGB