-
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.
Missing autogen around airport after compile
- Thread starter twharrell
- Start date
I'll see what I can do, Todd.
In the meantime, please everyone, be aware that part of the "story" of autogen suppression by ground polys has yet to be told. Now that I seem to have the 100m partitioning under control, I spent so time tweaking ground polys at my CYYJ. Earlier today, I had no autogen suppression. Now, after only changing some layer numbers, autogen suppression is back. Why??
Looks like I've got some more investigation to do.
Don
In the meantime, please everyone, be aware that part of the "story" of autogen suppression by ground polys has yet to be told. Now that I seem to have the 100m partitioning under control, I spent so time tweaking ground polys at my CYYJ. Earlier today, I had no autogen suppression. Now, after only changing some layer numbers, autogen suppression is back. Why??
Looks like I've got some more investigation to do.
Don
Todd, your two issues are easy. Your autogen suppression is being caused by the two long lines that run almost the entire length of the taxiways. Break those up and you should have no more difficulty.
As for the PAPI,, the left hand light is under the wide line. Ground poly objects are always displayed on top of airport objects. The PAPI is an airport object just like the runway/taxiway lights that were suppressed a few days ago. The solution is the same - though a little more limited this time, since there is no PAPI effect available. You'll either have to move that line a bit, move the PAPI or use a custom model. (There are instructions in the fsDeveloper Wiki for creating the latter.)
I had hoped your remaining autogen suppression might give me a clue as to what's happened at my CYYJ. But, alas, no. I'm going to have to solve this one the usual (hard) way.
Don
As for the PAPI,, the left hand light is under the wide line. Ground poly objects are always displayed on top of airport objects. The PAPI is an airport object just like the runway/taxiway lights that were suppressed a few days ago. The solution is the same - though a little more limited this time, since there is no PAPI effect available. You'll either have to move that line a bit, move the PAPI or use a custom model. (There are instructions in the fsDeveloper Wiki for creating the latter.)
I had hoped your remaining autogen suppression might give me a clue as to what's happened at my CYYJ. But, alas, no. I'm going to have to solve this one the usual (hard) way.
Don
You guys have made me paranoid!
Because I suddenly have autogen suppression, I assumed it was due to ground polys and I've spent the last several hours trying to fix it - to no avail.
As a last resort, I completely removed my ground polys and, lo and behold, I still have autogen suppression. Don't know what's causing it yet, but I do not what's not causing it!
Don
Because I suddenly have autogen suppression, I assumed it was due to ground polys and I've spent the last several hours trying to fix it - to no avail.
As a last resort, I completely removed my ground polys and, lo and behold, I still have autogen suppression. Don't know what's causing it yet, but I do not what's not causing it!
Don
Todd, don't rush to break up those two lines that are causing the autogen suppression.
During the investigation at my own airport yesterday, I realized there is a potential solution for the long line problem. It will be a few hours before I know if it will work.
Don
During the investigation at my own airport yesterday, I realized there is a potential solution for the long line problem. It will be a few hours before I know if it will work.
Don
It's Miller Time!
I'm happy to report that it looks like the new scheme is going to work. (I haven't messed at all with the triangulation and partitioning routines. So long as they continue to work, I'm not touching them.)
Basically, everything now gets partitioned at the start - including line backing and poly outlines. For FS9, partitioning is one-half the group size. (That's arbitrary, but it cannot be larger.) For FSX, it's the smaller of 100m and 1/2 group size.
Before, if an object didn't fit into a single group (like a long line or very large poly), the group was expanded to accommodate that object, generating a larger bounding box. Hence the autogen suppression for long lines. Now, with everything being partitioned up front, group size is guaranteed - since no partition will ever exceed specified group size. Autogen suppression will (should) never occur more than .707 (worst case oriented at 45 degrees) of the group size away from the group.
I want to do some more testing before I turn it over to you guys, but things are looking good at the moment.
Don
I'm happy to report that it looks like the new scheme is going to work. (I haven't messed at all with the triangulation and partitioning routines. So long as they continue to work, I'm not touching them.)
Basically, everything now gets partitioned at the start - including line backing and poly outlines. For FS9, partitioning is one-half the group size. (That's arbitrary, but it cannot be larger.) For FSX, it's the smaller of 100m and 1/2 group size.
Before, if an object didn't fit into a single group (like a long line or very large poly), the group was expanded to accommodate that object, generating a larger bounding box. Hence the autogen suppression for long lines. Now, with everything being partitioned up front, group size is guaranteed - since no partition will ever exceed specified group size. Autogen suppression will (should) never occur more than .707 (worst case oriented at 45 degrees) of the group size away from the group.
I want to do some more testing before I turn it over to you guys, but things are looking good at the moment.
Don
Time for you guys to have a go. 0.0.96(p) attached.
In addition to the revised grouping scheme, you'll notice a new button on the editor dialog to allow you to use the layer of the object currently in the editor as the default layer for new objects. This avoids repeatedly having to change ADE's 40 to something else if 40 is not what you want for a series of similar objects.
Note that you can make groups very small. But, in doing so, you will significantly increase the size of the .asm/.bgl files.
As well, since small groups now force more and smaller partitions, you may find you receive triangulation errors which you haven't previously. Triangulation tolerate things that partitioning doesn't. In my own case, I had a slight overlap in the closing of a poly wrapping a hole and, for the first time, the partition fell on the overlapped portion. I expect you'll find such new errors, if any, to be legitimate due to the construction of the object.
Have fun. (I'm off-line for much of the rest of the morning.)
Don
In addition to the revised grouping scheme, you'll notice a new button on the editor dialog to allow you to use the layer of the object currently in the editor as the default layer for new objects. This avoids repeatedly having to change ADE's 40 to something else if 40 is not what you want for a series of similar objects.
Note that you can make groups very small. But, in doing so, you will significantly increase the size of the .asm/.bgl files.
As well, since small groups now force more and smaller partitions, you may find you receive triangulation errors which you haven't previously. Triangulation tolerate things that partitioning doesn't. In my own case, I had a slight overlap in the closing of a poly wrapping a hole and, for the first time, the partition fell on the overlapped portion. I expect you'll find such new errors, if any, to be legitimate due to the construction of the object.
Have fun. (I'm off-line for much of the rest of the morning.)
Don
That's also possible, George. Lines are partitioned based on distance between vertices. During partitioning, lines become a series of simple polys. When a line changes direction, accounting for width, this could result in a partitioned poly a little (or a lot, depending on the width of the line) longer than the partitioning length. Consequently, lines previously were partitioned at 90 m, hopefully to avoid repartitioning during triangulation - where all polys were subjected to partitioning at 100m.
With the revised scheme, lines are partitioned at 100m, like polys. Hence, a long line will now generate fewer polys - giving a reduction in file size of 40-50 bytes per poly eliminated.
Offsetting that, if you use grouping, is that long lines and large polys (i.e., those that require partitioning) will generate more groups than before. The overhead of each new group is about 100 bytes plus an additional 80 for each texture involved. So, group size is likely to have a significant impact on file size - especially if the file includes a lot of large polys and long lines.
As I mentioned earlier, the partitioning and triangulation algorithms are unchanged (and, hopefully, will forever remain so). But the surrounding logic is quite different. My main concern is that the revised logic works in all circumstances.
Don
Glad to hear it!
That's not what generally is referred to as a "triangulation error". A "triangulation error" message will state that a poly cannot be triangulated. If it says it can't compile and asks you to edit, then you've moved one or more vertices (but not the entire poly) or you have added or deleted a vertex on the ADE display without going to the SP editor afterwards. That poly will not appear on your FSX display until you edit it - either during the compile process or later.
That message will appear for every compile until you edit.
Thanks for the beer.
Don
