ADE GP - FPS cost

[jjbld]

Hi Don,

I have nearly finished the ground part of my airport. Without ADE GP, I don't know if I would have succeeded, it is really a valuable tool, thank you!

I have drawn the aprons with polys and the ground markings with polys and lines. The GP objects list says 1300 objects, I don't know how many vertices and triangles are drawn.

The cost of this amount of detail is about 6 to 10fps!

I have decompiled the produced bgl in order to look at the scasm file. This file contains 35 objects, each object has several drawcalls (3 to 5). The visibility is set to 10000 for every object.

Do you have any idea to minimize the fps cost ?

Best regards

 

[gadgets]

I have decompiled the produced bgl in order to look at the scasm file.

That was unnecessary, Jacques. The original .asm file, names "ADE-GP" is in the ADE folder.

The GP objects list says 1300 objects, I don't know how many vertices and triangles are drawn.

The number of vertices and triangles is simply the sum of the number of VERT and DRAW TRI statements, respectively, in the .asm file.

The cost of this amount of detail is about 6 to 10fps!

Is this unreasonable for that number of objects? If you drew the polys as aprons in ADE, do you get a significant reduction in overhead?

The visibility is set to 10000 for every object.

Presumably, a lower value could be used in some cases. But, since the reference point for everything is the ARP, it's still going to be a relatively large number.

Do you have any idea to minimize the fps cost ?

There are probably a few things I could try, but each has a penalty associated with it. For example, I could handle lines and polys separately, minimizing the visibility distance for the lines, but this will increase the number of bgl objects. I could also handle each texture individually which, presumably, would minimize drawcalls, but once again, the number of objects would increase.

That being said, if you send me the AD3 files, textures and texture control files for your airport, I'm happy to do some experimentation to see if such approaches have a worthwhile positive impact.

Don

 

[jjbld]

Thanks Don, I will send you the files

 

[gadgets]

Jacques, I received your files.

I will conduct some experiments as mentioned.

Your measurement of FPS impact seems very precise. How are you measuring that impact? What is your reference?

With all my sliders hard right, I get about 55 FPS with your scenery, compared to about 100 for the stock airport. I also compared it with the FS2004 airport done in 2005 by one of your countrymen. With his AFCAD alone, I measure about 90 FPS. However, in all cases, my FPS measurement fluctuates by about 10%, so I wouldn't even see 6-8 FPS.

The stock airports and those prepared with AFCAD or ADE all make use of built-in functions for runways, taxiways and aprons. You've done everything with ground poly - and it looks very nice. But there is a FPS penalty for doing this. Nonetheless, your 55 compares very favorably with my CYYJ which measures about 28. It uses ADE-generated runways, taxiways and aprons but models virtually every light on the airfield.

More in a day or so.

Don

 

[jjbld]

Don,

My measurement of FPS impact is done with JAB_FPSx in slew mode, at the same place with no traffic and no weather.

I get about 32 FPS with my scenery, about 41 without the ADEX_GP.bgl and about 46 with the stock airport.

 

[arno]

There are probably a few things I could try, but each has a penalty associated with it. For example, I could handle lines and polys separately, minimizing the visibility distance for the lines, but this will increase the number of bgl objects. I could also handle each texture individually which, presumably, would minimize drawcalls, but once again, the number of objects would increase.

Handling textures individually would not reduce drawcalls, it would just spread the same amount of draw calls over more objects. For the performance that would be the same or possible worse due to the overhead of an object.

If possible try to use less different textures, but merging the content into one texture. That reduces the amount of drawcalls and is good for the performance.

But the best way to get good performance with ground polygons I have found is to not put everything in one big reference point. Especially when only part of the airport is in view that gives a big overhead. Instead have multiple reference points on the airport and each of them has the polygons within 250 meters of that reference point or so. This also makes it easier to have shorter visibility for small features.

 

[arno]

Don,

Do you correct the polygons for the fsx curve of the earth already? If not we might want to try run one output file through the modelconverterx ground polygon wizard to see how much performance can be gained from multiple reference points.

 

[scruffyduck]

Multiple reference points is something that we plan for the next major update to the ADE GP function.

 

[jjbld]

Handling textures individually would not reduce drawcalls, it would just spread the same amount of draw calls over more objects. For the performance that would be the same or possible worse due to the overhead of an object.

Thanks Arno for this information

If possible try to use less different textures, but merging the content into one texture. That reduces the amount of drawcalls and is good for the performance.

Unfortunately, it's too late for my project, I can't imagine to texture 1300 objects again, except if a pattern selection for polys (as for the lines) is implemented in a future release.

But the best way to get good performance with ground polygons I have found is to not put everything in one big reference point. Especially when only part of the airport is in view that gives a big overhead. Instead have multiple reference points on the airport and each of them has the polygons within 250 meters of that reference point or so. This also makes it easier to have shorter visibility for small features.

A glimmer of hope !

 

[gadgets]

Handling textures individually would not reduce drawcalls, it would just spread the same amount of draw calls over more objects. For the performance that would be the same or possible worse due to the overhead of an object.

Thanks, Arno. Glad you're still watching.

But the best way to get good performance with ground polygons I have found is to not put everything in one big reference point. Especially when only part of the airport is in view that gives a big overhead. Instead have multiple reference points on the airport and each of them has the polygons within 250 meters of that reference point or so. This also makes it easier to have shorter visibility for small features.

My plan is to "divvy up" the objects based on location and create new reference points at the center of each group. In addition, I intend to have separate groups for lines and allow the user to specify visibility. (Presumably, you want maximum visibility for polys.) Any thoughts, Arno?

Do you correct the polygons for the fsx curve of the earth already?

Yes, but the reference point remains the same.

Multiple reference points is something that we plan for the next major update to the ADE GP function.

Jon, this may no longer be necessary.

I get about 32 FPS with my scenery, about 41 without the ADEX_GP.bgl and about 46 with the stock airport.

Jacques, a 20% FPS hit when adding 1300 objects to an airport doesn't seem all that unreasonable. Nonetheless, we should be able to realize some improvement.

My measurement of FPS impact is done with JAB_FPSx

I have just downloaded that utility.

Don

 

[arno]

Hi Don,

My plan is to "divvy up" the objects based on location and create new reference points at the center of each group. In addition, I intend to have separate groups for lines and allow the user to specify visibility. (Presumably, you want maximum visibility for polys.) Any thoughts, Arno?

I guess it depends a bit on what you call a group. It would not make sense to have an object for each parking spot or so. That would give too many objects and reference points and would hurt the performance as well. It seems good performance is a balance between not too many reference points and not too big areas covered by a reference point.

Yes, but the reference point remains the same.

That makes sense. If the object has already been corrected for the curve we can't test if using the GPW afterwards gives a much better performance, that requires untweaked input (like you would make for fs2004).

Jacques, a 20% FPS hit when adding 1300 objects to an airport doesn't seem all that unreasonable. Nonetheless, we should be able to realize some improvement.

It really depends on many factors. I have done tests with a big airport where all lines only used one texture. In that problem I could add over one hundred thousand triangles without too much performance hit. But that was one drawcall and with multiple reference points each with a visibility of only a few kilometer.

 

[gadgets]

Jacques, I have some good news. I have the new compiler working. With test settings of line visibility = 1 km and breaking the ground polys into nominal 1km square groups, I get FPS of 102-104. This compares very favorably with the stock airport at 114 - only about a 10% hit. Without the improvements, the FPS is 93-95. I haven't tried any other values.

The final version, which I expect to release sometime tomorrow, will have a small user interface that will allow you to specify both visibility and group size, so those parameters can be "tuned" for each airport.

Don

 

[jjbld]

Many thanks Don !