# FSXFlattens

#### GHD

THE FSX RENDERING ENGINE WORKS WITH TRIANGLES... NOT RECTANGLES !

That was my initial thought, bit it is not true. It works with polygons. (The slope parameter is not used).

Last edited:

#### scruffyduck

##### Administrator
Staff member
FSDevConf team
Resource contributor
Is a triangle a three sided polygon?

#### GHD

Is a triangle a three sided polygon?

Yes, but a ten sided polygon isn't a triangle

#### GaryGB

(Posted 27 Mar 2013, 02:07)
http://www.fsdeveloper.com/forum/showpost.php?p=632862&postcount=21

That was my initial thought, bit it is not true. It works with polygons. (The slope parameter is not used).

Last edited by GaryGB; 26 Mar 2013 at 23:00.
http://www.fsdeveloper.com/forum/showpost.php?p=632852&postcount=19

BTW: Keep this in mind:

For sloped / tilted flattens, THE FSX RENDERING ENGINE WORKS WITH TRIANGLES... NOT RECTANGLES !

IMHO, it is a good idea to quote people in context; otherwise their actual meaning, as well as the relevance of- and reason for- making a statement within a particular discussion ...may not be readily discern-able to readers as intended by the person who originally wrote it !

But then, on second thought, probably some of the statements I make are not all that "readily discern-able to readers as intended" to begin with !

BTW: This was a rather intriguing (previous) post in light of your statements above:

http://www.fsdeveloper.com/forum/showpost.php?p=144300&postcount=12

http://www.fsdeveloper.com/forum/showpost.php?p=144300&postcount=12

I'm afraid I do not have the time to explain in detail.

I have found it unnecessary to create so many triangles, I now use convex polygons with the height of each outer vertex equal to the mesh height.

http://www.fsdeveloper.com/forum/showpost.php?p=144334&postcount=14

...for custom sloped flatten "convex polygons" we are referencing in this context, Triangles... with all interior angles less than 180° such that all the vertices will point outwards, away from the interior of the shape.

http://www.mathopenref.com/polygonconvex.html)

PS: Perhaps these threads might also be of additional help to the OP's "on-topic"discussion ?

http://www.fsdeveloper.com/forum/showthread.php?t=10663&highlight=triangles

http://www.fsdeveloper.com/forum/showthread.php?t=15184&highlight=triangles

http://www.fsdeveloper.com/forum/showthread.php?t=21714&highlight=convex

GaryGB

Last edited:

#### HolgerSandmann

Resource contributor
Hi guys,

I suppose the confusion regarding the use of triangles stems from the following:

It is true that FSX generates the surface of its terrain mesh, including any local flattens, as triangles; that's the classic polygon triangulation (or tessellation) used by many computer games and 3D applications. I've attached the title image of Joachim Buhre's "Terrain Doku" below that shows a tessellated mesh beneath the ground textures.

However, those triangles are created by the game engine, based on local terrain LOD and the user's two terrain mesh slider settings. Moreover, they are dynamic in that they move with the user aircraft, constantly being recomputed in a concentric "ring" of decreasing detail, that is size and spacing of triangles. There's a good description of this approach in Christian Stock's "TMF Manual" from 2003 but I don't know of that's still available for download.

In short, regardless of what triangular polygon one may draw it is not going to be used directly by FSX. That's why George's approach of more complex polygons works too because FSX will reshape those polygons into its dynamic polygon triangulation anyway. It's for the same reason that one can have flattened river polygons that span hundreds of miles.

Having said that, using complex polygons usually only works to a point. For example, if you draw sloped polys that wrap around 90-degree+ corners you often end up with odd ridges or even "ripples" (the same happens on complex river polys too and are the bane of my existence). Apparently, the tessellation algorithm can get "confused" in these cases and generates unwanted shapes. Splitting up overly complex polygons is usually required to fix those issues. Note how George's example avoids those wrap-around polys and thus is a good compromise of minimizing polygon numbers (and thus placement effort) and avoiding complexity.

Last but not least, how extensive and complex your sloped polygons need to be largely depends on the shape of the local terrain. In many cases it's not even necessary to have sloped polys all around the main flatten. In other cases it takes a lot of tweaking to avoid unwanted results.

Cheers, Holger

#### Attachments

• Dokutitel.jpg
77.6 KB · Views: 643

#### scruffyduck

##### Administrator
Staff member
FSDevConf team
Resource contributor
Thanks for that great explanation Holger It may be of some interest for folks that FS also tessellates flat airport elements such as aprons. One of the main reasons that the FS9 BglCompiler can fail with a buffer overflow is because of the number of 'triangles' needed to draw large aprons. In this case size matters so a large rectangular apron can have more triangles than a smaller but more complex shape.

#### simulondo

Maybe this could help you:

In my case, I had a complex slope at the end of my runway. In real life:

When I defined the flatten I got a lot of glitches. After a lot of days of testing I realized that the best approach it was use the sbuilder´s QMID grid based in the mesh resolution (my scenery include a 5m mesh, so I selected Level 23)

With this method, using the grid as guide, you can estimate how the mesh will react to the flatten. This is not perfect, but I´ve achieved the best result using it:

#### GaryGB

Hi Jose:

Excellent information !

I have also noticed that the terrain engine in FS renders less anomalies when sloped flattens are made with the vertices of ones triangles in alignment with the terrain mesh vertices of the FS quad matrix grid.

Indeed, as Holger described above, within the "Visual Display Radius" of the user aircraft, a Continuous Level Of Detail (aka "CLOD") function of the FS terrain rendering engine processes X, Y, and Z vertex coordinate information submitted by default and 3rd party TMF / vector BGLs for mesh or flat / sloped / tilted flattens ...prior to drawing triangles within the FS quad matrix grid.

This information was initially described in the "FS2000 / CFS2 Terrain Model File (aka "TMF") Documentation" by Christian Stock in "tmfdoc.zip" (still) available at:

http://www.flightsim.com/vbfs/fslib.php?do=copyright&fid=42974

And this information was also subsequently explained by Steve Greenwood back in the era of FS2002 as seen in his "Mesh Overview: Introduction" at:

http://fst.stevemg.net/overview.shtml

Scott Smart (aka "Scott967") alluded to some additional related considerations along these lines as well:

http://www.flightsim.com/vbfs/showt...age-quot-to-Terrain-Max-Vertex-Level-Settings

It seems, however, that 'terrain triangle' vertex coordinates submitted via 3rd party TMF / vector BGLs render on screen more efficiently, and with less "ground shape anomalies" (such as spikes or pits) when ex: sloped flattens are made with source data geographic coordinates for vertices of ones triangles in alignment with the known / calculable terrain mesh vertex positions of the FS quad matrix grid.

Otherwise, it seems the FS terrain rendering system sometimes has partial difficulty- (...or total inability !)- to compute what coordinates to use at run time when the FS terrain rendering engine processes X, Y, and Z vertex coordinate information submitted by default and 3rd party TMF / vector BGLs for mesh or flat / sloped / tilted flattens ...prior to drawing triangles within the FS quad matrix grid.

In the case of "pits", when investigated by "slewing into the depths", these sometimes drop to a elevation of (- 32,767) ...which is a known FS elevation 'fall-back' value for what would otherwise be a FSX SDK Resample *.INF file parameter value used in the event of a elevation source data void (aka "NO_DATA" or "MISSING_DATA").

But when a source data set of elevation points has been verified as complete and not missing any data points within its raster grid in a GIS application prior to being submitted for processing by FS SDK Resample, one might infer that the apparent rendered "data void" of the 'pit' (seen in FS at run time) ...is actually a failure of the FS terrain rendering system to successfully create a triangulated surface in the 'time' it was allotted by the FS rendering engine with the mix of X, Y, and Z vertex coordinate information "requested" by default and 3rd party TMF / vector BGLs.

Of course, as Holger also pointed out above, one can still encounter anomalies in certain known scenarios, and sometimes for reasons as yet unknown ...when 3rd party TMF / vector BGLs are rendered on screen in FS at run time.

I believe this approach of pre-aligning ones vertices to the FS quad matrix grid merits consideration to minimize unwanted "surprises", and to maximize one's productive FS development time when creating TMF / vector content.

[EDITED]

I have a hunch that in some high-density terrain vertex data point scenarios (especially involving terrain mesh and/or re-meshing "flattens"), pre-aligning ones vertices to the FS quad matrix grid (HINT: a quad tree engine ! ) ...may prove comparable in importance to- or even more important than- maintaining mapped Material texture image pixel dimensions which are "Powers of 2":

http://www.katsbits.com/tutorials/textures/make-better-textures-correct-size-and-power-of-two.php

[END_EDIT]

BTW: It does indeed seem to generally increase the certainty of outcomes when one creates TMF / vector content in alignment with an increasingly accurate and higher LOD resolution FS quad matrix grid, as this potentially enables higher precision terrain vertex placement and rendering in FS at run time.

One might wonder if this process might be made even more efficient and precise as to the "outcome" when ones TMF / vector content is rendered in FS at run time, by pre-aligning ones vertices to the FS quad matrix grid at the actual terrain mesh resolution that one 'intends' to be used in FS with one's TMF / vector BGL(s).

For example, Jose (aka "simulondo"), you described above that you had better results with less or no anomalies when you pre-aligned your sloped flatten vertices to the FS quad matrix grid at, IIUC, a QMID-23 level of detail (aka "LOD-21").

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

IIUC, you intended the TMF / vector content in your airport scenery project to be rendered in FS with a (supplied ?) 5-Meter terrain mesh BGL.

Since the maximum equatorial FS 3D world model LOD quad span in a '5-Meter' terrain mesh is 1,223 Meters, and each quad is subdivided into "Area Points" which are 1/256 of a quad span, the terrain vertices of a 5-Meter terrain mesh is 1,223 Meters / 256 = 4.777343750 Meters aka "4.8 Meters" (...or "5" Meters as shown on the FSX mesh resolution slider).

These 4.777343750 Meter 'Area Points' are actually "mini-quads" ...at a FS quad matrix grid QMID-23 (aka "LOD-21") level of detail.

IMHO, it would be helpful for those who prefer to implement their TMF / vector "sloped / tilted" flatten content pre-aligned with the FS quad matrix grid, to have the ability to super-impose a precise QMID / LOD grid in Airport Design Editor (aka "ADE9X") for both the FSX and FS9 modes < sorry Jon ! >.

Furthermore, it may be even more helpful (and could make ADE9X the first 'FSX' utility to offer this option) ...to have an on-screen FS quad matrix grid context-based "Snap-To-Grid" function for vertices when created !

Personally, if I had to choose between having a superimposed reference grid in ADE9X which was "arbitrary" in size, versus one which was geographic Lon-Lat, and versus one which displayed either a LOD or QMID grid such as offered by FSX SDK TMFViewer ...I'd want to have both the same superimposed grid options as TMFViewer.

Hope this information may prove helpful to the airport design process for the OP, and for other end users of ADE9X in the future.

< Hmmm... I think now I'll put on my "CLOD-hoppers", and go make some detailed 'furrows' for a freshly-plowed field in a FSX scenery project ! >

GaryGB

Last edited:

#### kevintampa5

In my case, I had a complex slope at the end of my runway. In real life:
When I defined the flatten I got a lot of glitches. After a lot of days of testing I realized that the best approach it was use the sbuilder´s QMID grid based in the mesh resolution (my scenery include a 5m mesh, so I selected Level 23)

Is there a spreadsheet that states what levels can go with what QMID or mesh levels?

#### GaryGB

Hi Kevin:

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 purposes of simplifying illustration and conceptualization.

CAVEAT: The extent of Meters on the ground mapped by draped aerial imagery texture pixels (aka "Texels") varies by FS Terrain Grid Quad / Area Point position on the FS 3D world spheroid / geoid.

The extent of Meters on the ground typically discussed are for a "theoretical" maximum quad "X" dimension of 1,223 Meters on the ground at ex: the equator of the globe.

NOTE: The extent of Meters for Quad / Area Point span increases with AGL Altitude to the FS theoretical maximum Altitude of 100 Million Feet.

Actual constants of measurement associated with the FS Terrain Grid Quad / Area Point extents is "Fractional Arc Degrees" on the ground, and in the air up to FS' theoretical maximum Altitude of 100 Million Feet.

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)
-2     0    8   40,075,468.8    6       8    156,544.8
-1     1    9   20,037,734.4    7       9     78,272.4
0     2   10   10,018,867.2    8      10     39,136.2
1     3   11    5,009,433.6    9      11     19,568.1
2     4   12    2,504,716.8   10      12      9,784.0
3     5   13    1,252,358.4   11      13      4,892.0
4     6   14      626,179.2   12      14      2,446.0
5     7   15      313,089.6   13      15      1,223.0
6     8   16      156,544.8   14      16        611.5
7     9   17       78,272.4   15      17        305.8
8    10   18       39,136.2   16      18        152.9
9    11   19       19,568.1   17      19         76.4
10    12   20        9,784.0   18      20         38.2
11    13   21        4,892.0   19      21         19.1
--------------------------------------------------------------------------> FS9*
12    14   22        2,446.0   20      22          9.6
--------------------------------------------------------------------------> FS8*
13    15   23        1,223.0   21      23          4.8
14    16   24          611.5   22      24          2.4
--------------------------------------------------------------------------> FSX*
15    17   25          305.8   23      25          1.2
--------------------------------------------------------------------------> P3D*
16    18   26          152.9   24      26          0.6 =(60 cm)
17    19   27           76.4   25      27          0.3 =(30 cm)
18    20   28           38.2   26      28          0.15 =(15 cm)
19    21   29           19.1   27      29          0.075 =(7.5 cm)
20    22   30            9.6   28      30          0.0375 =(3.75 cm)
--------------------------------------------------------------------------> MSFS-2020*
21    23   31            4.8   29      31          0.01875 =(1.875 cm)
22    24   32            2.4   30      32          0.009375 =(9.375 mm)
23    25   33            1.2   31      33          0.0046875 =(4.6875 mm)
24    26   34            0.6   32      24          0.00234375=(2.34375 mm)
25    27   35            0.3   33      35          0.001171875 =(1.171875 mm)
26    28   36            0.15  34      36          0.0005859375 =(0.5859375 mm)
27    29   37            0.075 35      37          0.00029296875 =(0.29296875 mm)``````

(*) = FS-Version maximum displayed mesh resolution

FS8 / FS9 = Hard-coded cap on maximum displayed mesh resolution; higher mesh LODs change slope texture on default land class, but not ground shape

FSX = Practical terrain mesh display limit: current "high-performance" computers based on 'fully resolved mesh' render speed VS. air speed needed for aerodynamics of flight (ex: > 45 KIAS) !

P3D = Hyothetical terrain mesh display limit: current "high-performance" computers based on 'fully resolved mesh' render speed VS. air speed needed for aerodynamics of flight (ex: > 45 KIAS) !

MSFS-2020 = Hyothetical terrain mesh display limit: current "high-performance" computers based on 'fully resolved mesh' render speed VS. air speed needed for aerodynamics of flight (ex: > 45 KIAS) !

BTW: Prepar3d (aka "P3D") reportedly may have a 64-bit version available within 3 years of the date of this post (ETA: year 2016).

IMHO, a 64-bit code base to increase available User Virtual Memory Address Space (aka "USER VAS") for a MSFS task session in Windows won't help all that much without also having a properly redesigned, multi-threaded, multi-CPU capable rendering engine for (P3D / ESP / MS Flight Simulator).

(^) = Area Point Grid Interval - calculated for Equator of WGS84 / Spheroid world model used in FS (...size 'on-ground' varies by Latitude North or South of Equator, and by Altitude AGL)

NOTE: Terrain Mesh Resolution (Meters) on FSX GUI Slider = Terrain Vertex Interval = Area Point Grid Interval

CAVEAT: Theoretical output of terrain grid vertices into mesh BGLs at "resolution" intervals closer than 1.2 Meters does not ensure their 'usability', 'display-ability' or 'visibility' in FS at run time !

PS: Need a ground shape with a higher resolution than the above 'Mesh Display Limit' which one might infer that either the FS9.Cfg "TMVL" or FSX.Cfg "Mesh_Resolution" parameter enables ?

IMHO, it is better to make such a (navigable) ground shape as a textured 3D static scenery object as an MDL with an attached platform having a 'hardened / concrete' attribute.

[END_EDIT]

Hope this helps !

GaryGB

Last edited:

#### kevintampa5

Hi Kevin:

Here's a basic guide for purposes of working with the FS quad matrix terrain grid system (for ex: making sloped / tilted flattens).

GaryGB

Dude seriously, you are the #\$^*\$#@ bomb!

Last edited:

#### kevinfirth

Dude seriously, you are the #\$^*\$#@ bomb!

+1, sometimes I lose track of what I originally came to find out when I read your posts Gary, simply because of the wealth of information in them, and soo many links! But thanks
k

#### kevintampa5

Thanks; I thought the extra bit of FS9 info might help with your FS9 KTPA project !

Still working on it. Im improving my texture and ambience abilities in Blender before I continue creating the scenery scape. I am thinking about releasing just the terminal and local facility buildings and afcad outside of the photo mesh and surrounding city structure, then going back and creating a full mesh terrain to reveal the taxi bridges. I am also thinking about just creating a model of all the roadways instead of using Sbuilder to place them, that way I can apply realistic texturing to them instead of the plain defaults.

I need to get a lidar style scan of an area so I can just convert the colorscale for depth and height of buildings to automate the creation of the buildings so all I have to do is texture them.

And I love the bomb.

#### GHD

Last but not least, how extensive and complex your sloped polygons need to be largely depends on the shape of the local terrain. In many cases it's not even necessary to have sloped polys all around the main flatten. In other cases it takes a lot of tweaking to avoid unwanted results.

I agree. The first thing I do is look at an overall view of the default setup, this is Fiesland:

Then, because I use photo-textures, I look at the default flatten and AFD with photo textures:

I then exclude the default flatten and AFD:

It is obvious that the default elevation of 50.292 metres is far to high. TcalcX gives a mean elevation of 41.8 metres.

Also, from the last pic, it is obvious that there is a short slope down to the surrounding road so this is where I place the edge of the skirt:

And the final result with the airport lowered to 41.8 metres:

#### hotelfox

I agree. The first thing I do is look at an overall view of the default setup, this is Fiesland:

[ ... ]

It is obvious that the default elevation of 50.292 metres is far to high. TcalcX gives a mean elevation of 41.8 metres.

[ ... ]

For those of you who might be interested:

George is talking about ENBR, Bergen Flesland

AD Elevation 166' (according to AIP Norway)

Last edited:

#### kevinfirth

George, thanks for that very visual and succinct example.

I've found my knowledge of flattens etc and how they work tremendously enhanced by this thread and everyone's comments in it

Can I ask one question though? I have been playing around terrain around Val de le Mere Dam just north of Jersey airport, as a test. I have been using polygons aligned closely to a QMID25 grid (for use with Mesh complexity 100 and Mesh resolution 1m in FSX) and at close range they work beautifully, (and much easier to create with TCalcX thanks George!). I have noticed at longer ranges, since the terrain is rendered at a lower LOD, the flattens that look great up close are then rendered more poorly.

Do any of you experts have any thoughts on how flatten polygons may be utilised more optimally so as to minimise those distortions at longer ranges please?

The only answer I've been able to come up with is to try to use the lowest possible QMID grid that appears acceptable when rendered at medium range...which kind of defeats the object of having them as detailed as possible! *more thinking necessary*

Thanks
k

Is this the dam?

#### kevinfirth

Fiesland? I' d just love to reproduce what you were doing ...

Is this the dam?

Yes that's the one.

Here's an SBX shot

And here's the result in FSX

I haven't been exact with the elevation data just was testing that it worked.

K

Last edited: