• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

Bizarre Behavior of Sloped Flattens

Messages
1,964
Country
unitedkingdom
My airports got a lot of sloped flattens, but now a couple have stopped working.

I've uploaded the files. It's for KBNA, and this (ZBNA) is a higher priority than my actual airport.

If you generate this and look at the area just to the north of the apron and by the road and taxiway, the slope isn't working...

This isn't down to the lower priority one either, see the attached pictures.

The thing is, it was working perfectly, and I can't fix it now!

12322366_1664580883755232_7054175867382001480_o.jpg

12291841_1664580873755233_5340721969752836274_o.jpg

12304320_1664580877088566_7894423210864696210_o.jpg
 

Attachments

I had similar problems making sloped flattens at 65S with SBuilderX, seems like once I reached a certain number of flattens in the area they started doing odd things like you described. I'd add a flatten to the project and it would render another one 3 miles away null & void. I fixed it to a degree by messing with the drawing orders of the polys. I'd tried splitting the flatten file up into multiple .bgls and I even tried placing them in different locations in the scenery library but nothing I tried made any difference. I eventually got the drawing orders swapped around so that most of the more important flattens were working and then locked down the SBuilder project to further modifications, I never considered it fully "fixed" though.

PITA! :)
 
I had exactly the same problem, and i notice that sometimes work fine and sometimes doesnt.
 
http://www.fsdeveloper.com/forum/threads/bizarre-behavior-of-sloped-flattens.435821/

My airports got a lot of sloped flattens, but now a couple have stopped working.

I've uploaded the files. It's for KBNA, and this (ZBNA) is a higher priority than my actual airport.

If you generate this and look at the area just to the north of the apron and by the road and taxiway, the slope isn't working...

This isn't down to the lower priority one either, see the attached pictures.

The thing is, it was working perfectly, and I can't fix it now!

12322366_1664580883755232_7054175867382001480_o.jpg

12291841_1664580873755233_5340721969752836274_o.jpg

12304320_1664580877088566_7894423210864696210_o.jpg
Hi Shaun:

I am unable to see any "pictures" attached to your OP above; could you please attach or link to them so other readers can better understand the described scenario here ? :confused:


Thanks ! :)

GaryGB
 
Last edited:
http://www.fsdeveloper.com/forum/threads/bizarre-behavior-of-sloped-flattens.435821/#post-728916

I had similar problems making sloped flattens at 65S with SBuilderX, seems like once I reached a certain number of flattens in the area they started doing odd things like you described. I'd add a flatten to the project and it would render another one 3 miles away null & void. I fixed it to a degree by messing with the drawing orders of the polys. I'd tried splitting the flatten file up into multiple .bgls and I even tried placing them in different locations in the scenery library but nothing I tried made any difference. I eventually got the drawing orders swapped around so that most of the more important flattens were working and then locked down the SBuilder project to further modifications, I never considered it fully "fixed" though.

PITA! :)

Hi Jim:

I'm trying to better understand the workflow you alluded to above with regards to the cited "drawing orders of the polys". :scratchch

[EDITED]

IIRC from the SBuilderX Help file, SBuilderX outputs EITHER a legacy format Vector Textured Polygon (aka "VTP") with an assigned draw order (VTP layer referenced as a "Priority" number) compiled to BGL via SCASM, OR one outputs a CVX format Vector Textured Polygon compiled to BGL via SHP2VEC, which AFAIK does not offer the option of an 'assigned (VTP) draw order' ...as recently described during the course of this discussion:

[END_EDIT]

http://www.fsdeveloper.com/forum/th...-polygon-showing-as-black.435733/#post-728251



I would greatly appreciate it if you would post a more detailed clarification of what your SBuilderX workflow actually was with creating such "textured polygons" in general, and more specifically, in creating "sloped flattens" (with a texture map ? :confused:) ...in what, IIUC, was a 'textured' sloped flatten polygon output into a CVX BGL file format.


BTW: My (initial and cursory) search on this brought up only this seemingly related thread regarding CVX format BGLs; all others appeared to involve creation of a legacy format Vector Textured Polygon (aka "VTP") with an assigned draw order. :pushpin:

http://www.ptsim.com/forum/viewtopic.php?p=3622


Thanks in advance for further sharing your insights with us on this ! :)

GaryGB
 
Last edited:
Thanks for the replies. Nearly put my fist through mymonitor.

I notice all the flattens have the same guid. Maybe if they were assigned different ones it might help?
 
Not sure about any of that Gary but if you do properties on any given poly in SBuilder there's an option on the general tab to change the draw order, you can move them up or down incrementally or move them to top or bottom. I'm not sure if that would actually make one landclass poly display above another in the sim for example, that's probably defined in the terrain.cfg so I doubt it, it may have only to do with the order they're processed by Shp2Vec or something. My polys were all AB_Flatten (47D48287-3ADE-4FC5-8BEC-B6B36901E612), not sure what other options there are when you just want an invisible sloped flatten to address some elevation problems, maybe AB_Flatten_MaskClassMap (5A7F944C-3D79-4E0C-82F5-04844E5DC653) would also work, I didn't try.

Appears there were a total of 91 flatten polys in that SBuilder file, I think I started having problems at around 55 or so IIRC so it was a royal fight every time to add the last 36 and get the draw orders sorted out for minimal damage as the project progressed. Oddly it reached a point where I wasn't even able to revert to a previous configuration that was working, almost every poly I added after 55 or so rendered another one useless somewhere in the project, often that would go for days unnoticed because I was busy working on another part of the airport. It finally came down to a last ditch effort to get the most important ones working and then I locked down the SBX file to further edits, beyond that we adjusted some .mdls to compensate for flattens that didn't work as expected.
 
Thanks Jim; so IIUC, for your 65S scenario cited above, you were describing "invisible" flattens ...rather than "textured flattens" ? :scratchch

BTW: IIUC "MaskClassMap" causes one's custom CVX airport background terrain polygon to be assigned / mapped with a 'locally-compatible' Land Class texture.

GaryGB
 
Last edited:
Yes they were all invisible, covered entirely with photoreal actually. I thought MaskClassMap merely excluded textured airport backgrounds but with a flattening effect? No idea really, something to experiment with one day :) .
 
http://www.fsdeveloper.com/forum/threads/bizarre-behavior-of-sloped-flattens.435821/#post-728944

Yes they were all invisible, covered entirely with photoreal actually. I thought MaskClassMap merely excluded textured airport backgrounds but with a flattening effect? No idea really, something to experiment with one day :) .


Thanks for that clarification, Jim. ;)


FYI
: The MSFS SDK says: :pushpin:

https://msdn.microsoft.com/en-us/library/cc707102.aspx#TheShp2VecTool

"Vector Data Sample Notes

FLX7824


Although this area is titled Airport Boundaries, these are used for a number of purposes, including flattening a surface and excluding certain types of data, in addition to defining airport boundaries.


The .dbf file contains two columns, UUID and GUID. Enter the following GUIDs in the GUID column to achieve flattening, or Autogen or land class exclusions.

Airport boundaries are one example of the use of Flatten + MaskClassMap + ExcludeAutogen.

{6c0c6528-5cf1-483a-a586-2c905cf2757e} ExcludeAutogen
{47d48287-3ade-4fc5-8bec-b6b36901e612} Flatten
{5a7f944c-3d79-4e0c-82f5-04844e5dc653} Flatten + MaskClassMap
{1f2baab1-4132-416e-8f6f-28abe79cd60b} MaskClassMap

{46bfb3bd-ce68-418e-8112-feba17428ace} Flatten + MaskClassMap + ExcludeAutogen
{18580a63-fc8f-4a02-a622-8a1e073e627b} Flatten + ExcludeAutogen
{594e70c8-06a5-4e3f-be6e-4dbf50b49d11} MaskClassMap + ExcludeAutogen
"


NOTE: {1f2baab1-4132-416e-8f6f-28abe79cd60b} MaskClassMap can be used by itself (without a flatten and/or exclude attribute) ...to only texture a custom terrain polygon with "locally-compatible" Land Class (which may or may not yield a predictable result, depending on whether certain default files which define Land Class mapping have also been "customized" by a 3rd party).


BTW: According to Jim Vile, however, there are a few "gotchas" when using MaskClassMap by itself (without a 'flatten' and/or 'exclude' attribute) ...to only texture a custom terrain polygon with "locally-compatible" Land Class:

http://www.fsdeveloper.com/forum/threads/landclass-visibility-problem.15173/#post-97802


Helmuth (Helli) Hauck posted some "gotchas" on using MaskClassMap (-and a caveat if used with LC Polys): "Don't overlap" :alert:

http://www.fsdeveloper.com/forum/threads/landclass-polys.429421/#post-665637



...Also, some info I personally had cited on "gotchas" when using MaskClassMap:

http://www.fsdeveloper.com/forum/threads/cvx-files.434746/



Some of Jim Vile's other knowledgeable treatises on MaskClassMap: :teacher:

http://www.fsdeveloper.com/forum/search/1583626/?q=MaskClassMap&t=post&o=date&c[user][0]=345


...and a general list of threads here citing MaskClassMap: :coffee:

http://www.fsdeveloper.com/forum/search/1584067/?q=MaskClassMap&t=post&o=date


Hope this helps clarify some of the other options with this type of airport background polygon. :)



PS: Perhaps a 1-piece airport "flat-and-sloped-flatten" might avoid some "gotchas" above ...using Arno's MCX: :wizard:

http://www.scenerydesign.org/2013/04/flattens-from-3d-objects/


GaryGB
 
Last edited:
I seem to always forget to check Arno's Blog on http://www.scenerydesign.org, so I greatly appreciate it when he posts a "heads up" type of announcement in the fsdeveloper forums on one of his latest feature enhancements for his utilities.

Many thanks to Arno for all the things he has made possible for us to do via his utilities over the years ! :)

GaryGB
 
Well, after more days of frustration it looks like the terrain files generated by MCX are subject to the same laws of fuckery those exported by ADE are... Export too many and some don't show, or partly show.

it also seems to interact with other files in the project, so exporting some via MCX as different files, and some vix ADE doesn't work either.
 
Hi Shaun:

AFAIK, the "Laws of F***ery" are yet another 'un-documented' part of the SDK ...revealed only to those who endure all the many "gotcha's" ! :rotfl:

With regard to many things such as the latter topic of this thread, the SDK docs certainly do not tell "the truth, the (w)hole truth, and nothing but the truth", since IIRC, it is undocumented by ACES that when working with Parent / Child / 'Hole' methods for vector polygons, including adjacent polygon (triangle) edges in a contiguous 1-piece sloped flatten "TIN", or when abutting the "visual" portion of other nearby vector polygons (within the same QMID grid quad), the underlying mechanism is that polygons (whether textured or not) are 'Masks' for a quad-sized, rectangular Direct Draw Surface (aka "DDS") attached to a (NW) corner of a quad, and which co-exists within a 'layering' scheme that establishes a "draw order".

Even SBuilderX documentation and FS forum threads at PTSIM only 'allude' to these, and other mechanisms inherent in working with vector polygons.

http://www.ptsim.com/forum/viewtopic.php?p=7126


Furthermore, above and beyond consideration of vector polygon GUID type, one may need to consider clockwise and/or counter-clockwise "winding" direction of polygon vertices as a basis for the above referenced layering scheme which establishes a "draw order" within a 'layering' scheme.


So when drawing a 1-piece sloped flatten "TIN", vertices defining all edges must be drawn in a specific sequence in keeping with the existing contiguous vertices in that TIN, or the FS rendering engine may not form a "solid" DDS for some or all of that object 'layer'.

And when placing multiple sloped flatten "TIN" or other terrain polygons within the same QMID grid quad, vertices defining all edges must be drawn in a specific sequence relative to vertices in other polygons, or the FS rendering engine may not form a "solid" DDS for some or all such polygon object 'layers'.

IIRC, mixed clockwise / counter-clockwise "winding" direction of vertices in polys that intersect / overlap may also result in an "exclusion". :alert:


For purposes of this discussion, IMHO, we can regard FS as a type of GIS application functioning comparable to other GIS apps when it displays "layers", because, as with other such GIS apps, one may also need to consider clockwise and/or counter-clockwise "winding" direction of vertices as a basis for a layering scheme which establishes a "draw order".


Additionally, IIUC, certain considerations may apply when 'segmenting' terrain polygons with a specific "winding" direction of vertices across quad borders, as has been discussed in the past for 'legacy format' VTP vector polygons:

http://www.ptsim.com/forum/viewtopic.php?p=4158\


Keeping BGLs for certain terrain polys in separate "layers" within the FS scenery library as adjacent paired "upper" and "lower" layer numbers might be another consideration for compatibility purposes, as well.

Hope these additional considerations might prove helpful to the learning and development process. :)

GaryGB
 
Last edited:
Well I don't really understand why drawing a polygon a certain way around would affect this. But there's no overlapping polys, and everytime I export it it's random as to what vert/polygon where isn't working properly. it's such a shame I can't use an elevation BGL because of the flat runways not following the terrain like it does in the DEM; there's a 30ft drop at the end of some.
 
Well I don't really understand why drawing a polygon a certain way around would affect this. But there's no overlapping polys, and everytime I export it it's random as to what vert/polygon where isn't working properly. it's such a shame I can't use an elevation BGL because of the flat runways not following the terrain like it does in the DEM; there's a 30ft drop at the end of some.


You should draw all polygons in a clockwise direction. Even though the SDK shp2vec did not mention this the winding of holes MUST, however, be opposite of the containing outer ring.

Drawing polygons in different direction can cause them to grow in size or show up miles away from where you want them.
 
Back
Top