• 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.

Ade_gp 0.0.96

G

gadgets

Resource contributor
Messages
9,388
Country
ca-britishcolumbia
EDIT: Update withdrawn.

Updated version attached.

I thought that, with the previous version, I had solved all the triangulation issues. But, that turned out not to be the case. I was close, but no "cigar".

Importing nearly 1000 ground poly objects (previously created with Gmax and FS8 MakeMdl) into my CYYJ, highlighted a few new issues - some in the importer, some elsewhere.

The importer issues have been fixed. While there are still a couple of artefacts among the imported objects, I've found nothing that can't easily be found by inspection and addressed manually. While we've come to expect perfection in these sort of things, remember that the importer starts with nothing but lists of vertices and "instructions" as to which three of them to use to make triangles. The importer is as "perfect" as it's likely going to get.

The "big" discovery (which has resulted in me spending may frustrating hours "over the drawing board) was that the triangulation issues (at least not all of them) were not caused by the triangulation code (as I thought) but, rather, by the 100m. "chunking" code - the two most mathematically-complex parts of ADE_GP. The result was a total re-write - and simplification - of those two areas. "Chunking" is now done only on triangles that exceed the 100m limit. (Triangles are easier to split up.)

Bottom line, ADE_GP now handles my nearly-1000 imported objects flawlessly. I've also run it on a few of the problem airports you've sent me over the past few months, and it handles those as well. So now it's time for the "acid test.

Have at it George.

The .zip file also includes an updated manual.

Don
 
Last edited:
Hmm, it has reduced the GP size from 284Kb to 277Kb :p

I will now need to check it within FSX.
 
The new triangulation algorithm is entirely different from its predecessor. However, a sample of 1 isn't very predictive. Perhaps the file for the next airport will be larger.

Without a detailed analysis, there's no way to determine the underlying reason for the change. Partitioning of triangles, for example, increases the number of vertices from 4 to 7 in the case of a simple rectangular poly which exceeds the size limit in only one dimension whereas partitioning of the same poly prior to triangulation resulted in only 6. But the former seems to work in all cases whereas the latter didn't. (Try writing a program to partition a large "V" horizontally above the crotch.) So, I would have expected a slight increase in the number of vertices and triangles.

Perhaps triangulation first minimizes the number of large areas that need to be handled.

Anyway, fell free to analyse. So long as it works, I'm done!

Don
 
I spoke too soon :(

With .96, parts of long lines are missing in spot view. With .95h they are fine.

0.96:





0.95h

 
Send me the file, please. We need to be looking at exactly the same thing.

The lines are applied the same way in both versions. The only difference will be where they start and end. And, as you can see, the lines have been output to and are being processed by FSX (top-down view).

This wouldn't be the first time something inexplicably doesn't appear on your system but does on others.

I trust both were compiled with the same grouping option.

Don
 
Ok, try the attached. Sit in the middle of the runway and look in spot view.

You will notice that the GP file from 0.96 is half the size of that from 0.95h.

Edit. Sorry, forgot the compile options:

 

Attachments

Last edited:
Well, I now know why the file was smaller. As I final test of the new code, I compared the result of 100m partitioning with the same airport without partitioning - by disabling the partitioning. They were identically rendered in top-down mode - as they should be. However, I neglected to reinstate the partitioning before sending the new code off to you.

What you were seeing was the effect of round earth on long lines. (The display was fine at the ends of the runway; not so much in the middle.)

I'll re-release shortly. But, before I do, since my CYYJ didn't have any lines nearly as long as your airport does, I want to do a little more testing to ensure long lines are handled properly.

Don
 
Sorry, guys. There is still a problem partitioning long lines. I'll get an update to you ASAP.

Don
 
I now know what's going on. After triangulation, lines and polys are both just a bunch of rectangles and get partitioned in the same way. The new scheme works fine for polys, but results in very narrow slivers of textures for lines - which aren't handled as expected by FSX. Lines only a few hundred metres long are OK, but very long lines disappear.

To avoid other issues, I must use post-triangulation partitioning for polys. But, it would seem lines must be partitioned before triangulation. So, I've got some more work to do.

Update ASAP.

Don
 
Version 0.0.96(a) attached. I think you'll be a little happier with this one, George. It partitions lines prior to triangulation and, thus, preserves line width.

Don
 
Last edited:
Version 0.0.96(a) attached. I think you'll be a little happier with this one, George. It partitions lines prior to triangulation and, thus, preserves long line width.

Don

EDIT: Don't know how the double-post happened, but it's the same file attached to both..

Don
 
Last edited:
Using 0.96a versus 0.95(h), a single line increased in size from 1.1Kb to 5.93Kb :eek:

I think I'll stick with 0.95(h)

 
A 5 KB difference is a drop in the bucket when loading FS. I don't think you should worry about that, especially if it should have been 6 KB in the first place, and the old 1 KB version will cause visual problems.
 
tgibson said:
A 5 KB difference is a drop in the bucket when loading FS. I don't think you should worry about that, especially if it should have been 6 KB in the first place, and the old 1 KB version will cause visual problems.
Click to expand...

6Kb for one line, a 600% increase :eek:

The old 1Kb version does not cause visual problems, this is why Don spent so much time to create 0.9h(a).
 
Last edited:
George, I've been looking at results in FSX, not monitoring file size.

Concave polys >100m in size are now partitioned properly. Very long lines are now displayed properly. (If they weren't, I assume you'd have mentioned it.) And, from my testing, it seems I have also eliminated the triangulation issue brought on by the earlier algorithm. So, I think you'll agree those are also good things. And, if you put a big, V-shaped poly in the middle of your airport, I suspect you'd also agree that 0.0.95(h) has some shortcomings.

But, as you've discovered, there is an increase in file size with the new approach. From a preliminary investigation, the vertex count has increased by about 50%. I suspect that some of the line segments resulting from pre-triangulation partitioning (which is essential for triangles) is again being split during post-triangulation partitioning (which is essential for polys - but which can't be confined to polys). This shouldn't happen - but does no harm other than increase the workload for FSX.

Once I fully understand the issue, I'm sure it will be a simple fix.

Don
 
No problem Don. I will stick with 0.95(h) but will try new releases when available.

I suspect you'd also agree that 0.0.95(h) has some shortcomings.
Click to expand...

None that I have yet found.
 
My scenery has hundreds of 1-5 KB files, and if I remove all of them my frame rate goes up all of less than 1 fps...

Of course that's FS9 - FSX will be much worse...
 
You must log in or register to reply here.
Back
Top