Board index FlightGear Development Aircraft

Su-15

Questions and discussion about creating aircraft. Flight dynamics, 3d models, cockpits, systems, animation, textures.

Re: Su-15

Postby Thorsten » Thu Nov 12, 2015 6:39 pm

I honestly prefer to do the test in the context of FGFs and not out of context, obvious that an object with 300K vertices is heavier than one with 15K vertices, but it is also infinitely more realistic!


No, it ain't necessarily, not if you can achieve the same set of screen pixels by using e.g. a texture, a normal map or similar techniques at much lower cost, and not if you never see 90% of these vertices.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Su-15

Postby legoboyvdlp » Thu Nov 12, 2015 6:47 pm

However, how about those fire extinguishers at the back of the Boeing 777, or the closet-type thing behind the panel behind the captains seat, visible from the observer seat behind the first officer?
Are all those details worth the vertices?
Speaking of which, I do love those details so much.
User avatar
legoboyvdlp
 
Posts: 7981
Joined: Sat Jul 26, 2014 2:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

Re: Su-15

Postby Thorsten » Thu Nov 12, 2015 6:49 pm

We're not talking about this sort of details.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Su-15

Postby Hooray » Thu Nov 12, 2015 6:57 pm

for the record, on my old Intel GMA netbook, I am getting 66 fps using osgviewer when viewing the ufo, and getting 3.3 fps when viewing vitos Su15.ac file, and it takes roughly a minute to load, too ...

Personally, I believe it is the right thing to use such metrics, and even expose them at run-time, i.e. using properties and/or runtime logging (log file/console), to tell people how complex their models/textures are.

To understand this, you need to understand that FG is using a certain stack of technology, so it is using osgviewer internally - and so is fgviewer (with some added simgear stuff).
In other words, there is no better/lighter way to view models in standalone mode than using osgviewer - which is to say, that the maximum that you can expect in terms of rendering/graphics performance (framerate) really is what osgviewer/fgviewer can provide.
Equally, running fgfs in minimal startup mode, will disable tons of other subsystems (FDM, AI traffic, shaders/effects) - so you are basically taking away tons of features to determine just how much load a certain component is causing, regardless of any FDM/Nasal related features etc

In a sense this is troubleshooting at its best, because you exclude all possible factors and re-add them one by-one to determine if/how and where something is causing issues
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Su-15

Postby geed » Thu Nov 12, 2015 7:57 pm

I am working in the games and simulation industry and from my experience I can only second what Thorsten said:

To gain performance and to guarantee a minimum FPS at a good detail level it has been established as good practice to use low detail models together with a normal map. The normal map is being produced using the high detail model. By that you get the impression of high detail which is perfectly fine for our brains :)

Graphic cards can render a lot of triangles but this can be exploited way too easy. A high level of detail is worth nothing if your user cannot enjoy it because of a bad frame rate.

To get a lot of users you want to target a low to mid range system - well basically, where you can expect most users.
geed
 
Posts: 89
Joined: Fri Apr 18, 2014 1:53 pm
Location: in between
Callsign: G-EED
Version: 2017.3.1
OS: OSX, Win8.1

Re: Su-15

Postby hamzaalloush » Thu Nov 12, 2015 7:58 pm

abassign wrote in Thu Nov 12, 2015 5:14 pm:@ hamzaalloush
I think we could define an airport, runway and weather conditions that are standard, and only on that arena test this (and other) aircraft. Might be opened an area of interest in this blog in order to do these tests and show.


sure, i'll come up with pre-recorded flight file that you load up, with a specified set of command line instructions and an xml file for logging properties that you place in $FG_HOME. only thing not exposed is the osg perfs/stats
hamzaalloush
 
Posts: 631
Joined: Sat Oct 26, 2013 10:31 am
OS: Windows 10

Re: Su-15

Postby abassign » Fri Nov 13, 2015 1:19 am

In Italy we tell "Avere la botte piena e la moglie ubriaca" (You can have your cake, or you can eat it) ... or if you want to have a simulated aircraft of high quality, you have to accept a processing cost!
It is natural that in Fgfs planes can coexist with 15000 vertices with planes that 300,000 vertices! Obviously those with 300,000 vertices go slower or may not work with certain hardware configurations ;)
Two years ago I had a laptop that would not let me fly in FGFs in advanced configuration, to take pictures to put in the blog FB Fgfs Italy, I stopped with pauses, I changed the parameters to the maximum, and I did start right after F3! They were, in this way, however, pretty pictures. FGFs can do this, so I started to do a script to automate this feature when you press F3 ... But then I bought a new laptop with the GTX870, and so I do not continued the project :)

Now the problem is different: "It is right that His-15 is so heavy in the .ac file?"

I personally think that is right, if the author wanted to set up the work in this way, it is free to do so and we are free to use it or not use it!

Instead I repeat that what is interesting is the fact that even a model so complex not actually produces the highest workload for the GPU! But only 10-20%, the rest is done by the ground (including trees ...) and clouds. 80-85% of the workload is not about airplane, but its context, so I think we need to do tests on the application and not on the OSG viewer.

@Vitos
FDM (JSBSim) normaly has a low workload, even if it is run 120 times per second. I used JSBSim separately and the performances were excellent with a low CPU load, I am tempted to do the same test for this aircraft, if I have time I will do it.

If I start the Monitor System Performance I must note, however, that the first four processes account for 80% of total load, thi is the process:
"flight"
"gui"
"events"
"input"

"flight" is always very high, it seems that it is FDM since it goes to 122 iterations per second, but honestly it seems very high, such as CPU load (50%), I'd like someone to help me find the exact significance of the processes listed in the monitor. I noticed that "light" is really very high, much more than for other aircraft like the F15, maybe you can reduce it without changing the characteristics of the aircraft to be simulated. Free up the CPU to that process can surely give advantages. Of course the best thing would be to move the FDM on a different CPU, which, however, unfortunately does not happen automatically.
Last edited by abassign on Fri Nov 13, 2015 1:32 am, edited 2 times in total.
Developer of the program https://wiki.flightgear.org/Julia_photoscenery_generator
FDM developer of the G91R1B aircraft https://wiki.flightgear.org/FIAT_G91R1B
JSBSim collaborator
abassign
 
Posts: 947
Joined: Mon Feb 27, 2012 6:09 pm
Location: Italy (living 5 Km from airport LIME)
Callsign: I-BASSY
Version: 2020.4
OS: Ubuntu 20.10

Re: Su-15

Postby hamzaalloush » Fri Nov 13, 2015 1:26 am

Yes, but the F-15 is equally pretty from the exterior, which makes the airplane very *unoptimized, that's is my take, for your information, we can eliminate the FDM load with a pre-recorded flight using an external flight path file.
hamzaalloush
 
Posts: 631
Joined: Sat Oct 26, 2013 10:31 am
OS: Windows 10

Re: Su-15

Postby Thorsten » Fri Nov 13, 2015 7:59 am

Instead I repeat that what is interesting is the fact that even a model so complex not actually produces the highest workload for the GPU! But only 10-20%, the rest is done by the ground (including trees ...) and clouds. 80-85% of the workload is not about airplane, but its context, so I think we need to do tests on the application and not on the OSG viewer.


I'm sure in your theory you can also explain why people get 25 fps in the F-15 and 7 fps in the Su-15 in the same scenery where the only difference is the plane.

No?

Because your assertion is not true.

Having said that, by tuning rendering and weather accordingly, you can always increase the load coming from the scene, and eventually, for 150+ kilometers visibility, lavish random vegetation etc, the terrain will completely dominate everything.

So it's not a question of absolutes, it's a question of how the context is set.

The issue is not whether the model is slow compared with 150 km of terrain rendering, or slow compared with a dense forest rendered with a tree coverage of 10 - the issue is whether the model is slower than it needs to be for the visuals it provides - and that is the case. As explained elsewhere, you need a valid reference to judge something slow.

There's a reason for the introduction of normal maps in 3d rendering. There's a reason trees aren't rendered with every leaf, but just as texture sheets. And that is to give you by and large the same visuals at much lower cost.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Su-15

Postby Hooray » Fri Nov 13, 2015 10:28 am

@abassign, thanks for checking the FDM theory.

In general, you will find that "events" is for Nasal timers.

However, you will want to use the http/telnet interfaces to watch the performance stats, because the GUI dialog using PUI/Nasal is dead-slow, and even adding to the overhead you are seeing :!: :!: :!:

Once you have confirmed that flight/fdm still is fairly high, despite not showing up in standalone JSBSim mode as such, you have basically narrowed down the problem - for instance, it's usually FDM-coupled Nasal code, i.e. listeners triggered by FDM properties, that is causing this.

To check if that's the case, I would next comment out the <nasal> section in the Su15-set.xml file to prevent Nasal modules from being loaded. If the theory is correct, the overhead for events/flight should be much lower.

In summary, what you are seeing and interpreting is misleading/incorrect - you really need to understand how this works under the hood - i.e. the FDM showing >= 100 iterations is to be expected because it runs several times per frame, which also means that offloading this onto a separate core may not get you much/anything at all, especially should there be FDM<->Nasal code running 100+ times per frame (which seems to be the case so far).

Please make sure to read & understand this: http://wiki.flightgear.org/Howto:Use_the_system_monitor
If you should be able to confirm that it's Nasal related, the next step would be to identify the corresponding callbacks.
For the whole background on the Nasal GC, see: http://wiki.flightgear.org/How_the_Nasal_GC_works

Also, regarding the term "processes" you used in this context: FG is basically using cooperative multi-tasking-imagine it like a team of people (15+), all of whom need to finish their work and hand it over to the next person, so that a single frame can be produced - with some people (subsystems) being allowed to redo/check their work several times in a row (fdm, autopilot), while others will only get a single opportunity to update their internal state.
Finally, it is this "team of people" that will produce a single frame - so whenever "someone" is too slow, it will end up causing stuttering. No matter the reason, scenery/terrain, Nasal etc - at some point, another subsystem will have to wait, which means fewer frames created per second.

I think this is also where vitos failed to interpret correctly what he was seeing - but you really can draw reliable conclusions once you render the model in standalone mode, and then run the FDM in standalone mode.

In both cases, you will obtain the "maximal theoretical performance" of each system (in isolation), so that you can check if/how complexity of the 3D model and/or FDM is playing a role here.
Next, you would do the same thing with Nasal code, i.e. by disabling it entirely and watching performance then.

Overall, it makes sense to team up with Hamza, because he's meanwhile pretty experienced with benchmarking FG meanwhile, so you could learn a lot, while also improving the quality of your bug reports, as well as your whole troubleshooting process

None of this is changing anything about the complexity of the model though
To see for yourself, you can use osgconv to reduce the complexity and see for yourself just how much faster frames can be rendered
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Su-15

Postby abassign » Fri Nov 13, 2015 9:48 pm

@Hooray

To reduce the load on the CPU due to FDM he tried various ways:
* From the file Su-15-set.xml I removed references to programs NASAL (row from 4110 to 4,127), nothing has changed, the parameter "flight" has remained very high.
* From the file Su-15.xml I removed all the function declarations (line 493 to 2,835), but the value of "flight" has remained very high.
* I deleted the files NASAL, but the value of "flight" has remained very high.

At this point I do not know why the parameter "flight" so high, I do not know where to look :(

Image

In the same scenario, the F15C has an improved performance of 10%, but in this case "flight" is much lower:

Image

At this point, I suspect that the parameter "flight" is high although in reality the system is unloaded, it happened to me, sometimes to find programs that claim very high loads, but in the end do not have a degradation of performance system. In fact, for the Su-15 it has a CPU load of 106% (is activated mode that allows the dual CPU) while for the F15C, the CPU load is 104%.
Developer of the program https://wiki.flightgear.org/Julia_photoscenery_generator
FDM developer of the G91R1B aircraft https://wiki.flightgear.org/FIAT_G91R1B
JSBSim collaborator
abassign
 
Posts: 947
Joined: Mon Feb 27, 2012 6:09 pm
Location: Italy (living 5 Km from airport LIME)
Callsign: I-BASSY
Version: 2020.4
OS: Ubuntu 20.10

Re: Su-15

Postby Hooray » Fri Nov 13, 2015 10:26 pm

Just briefly:
From the file Su-15-set.xml I removed references to programs NASAL (row from 4110 to 4,127), nothing has changed, the parameter "flight" has remained very high.


Actually, you only need to open the -set.xml file, and navigate to the top-level <nasal> section (around line 4263 in my version), which should look like this:
Code: Select all
<!-- Nasal initialisation  -->

        <nasal>
          <radar>
                  <file>Aircraft/Su-15/Nasal/Radiocompass.nas</file>
          </radar>
          <radar>
                  <file>Aircraft/Su-15/Nasal/Radar.nas</file>
          </radar>
          <radar>
                  <file>Aircraft/Su-15/Nasal/Infoline.nas</file>
          </radar>
          <mpdata>
                  <file>Aircraft/Su-15/Nasal/Mpdata.nas</file>
          </mpdata>
                <Su15>
                        <file>Aircraft/Su-15/Nasal/Su-15.nas</file>
                        <script>startup();</script>
                </Su15>
        </nasal>



You can use XML comments (README.xmlsyntax/wiki) to disable the whole section entirely.

You don't need to edit the FDM file at all, because you confirmed already that it is not showing up in standalone mode, so why even touch that ??

But deletion/renaming of the "Nasal" folder should have just as well worked to disable the code referenced in the -set.xml

Besides, like I told you, you should stop using the GUI to inspect those stats, and use telnetd/httpd instead, to ensure that GUI overhead is not adding to what you are seeing (in fact, events & gui show up quite prominently).

Finally, those systems are not "processes", but just "loops" - i.e. whatever the thing is called in the list, you should append "update-loop" to it - and some names are still misleading (events=Nasal).

Overall, you are well-advised to coordinate your benchmarking efforts with Hamza, to ensure that you are not wasting your time here, because you are not yet seeing the whole picture.

Personally, I would also disable other features (e.g. weather) and do all the benchmarking using the minimal startup profile - otherwise, you are misled way too easily, especially if you don't understand what all these systems are doing/responsible for.

http://wiki.flightgear.org/Howto:Troubl ... nce_Issues
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Su-15

Postby abassign » Sat Nov 14, 2015 1:39 am

@Hooray

I activated only: "/sim/rendering/draw-mask/aircraft = 1" all other options have been disabled

The speed has reached 59-60 fps, while the CPU load has decreased slightly, from 106% was reduced to 97% (-9%). This reduction is small, smaller than I would have expected. Observing the even steeper increase in the value of "flight" in relation to other values, it makes me think that there is some time-consuming process active. Just a cycle "nop" or something that is turning around to do anything special. In my experience this is situational typical when you have waiting threads that do not need to do anything special.

Image
Developer of the program https://wiki.flightgear.org/Julia_photoscenery_generator
FDM developer of the G91R1B aircraft https://wiki.flightgear.org/FIAT_G91R1B
JSBSim collaborator
abassign
 
Posts: 947
Joined: Mon Feb 27, 2012 6:09 pm
Location: Italy (living 5 Km from airport LIME)
Callsign: I-BASSY
Version: 2020.4
OS: Ubuntu 20.10

Re: Su-15

Postby hamzaalloush » Sat Nov 14, 2015 4:07 am

some more info, it appears that at least on my laptop's modest graphics card, the model's vertex count is what takes the most precedence on my FPS loss, it is *not* the FDM, as you it would show in the next picture. the context of this screenshot is drawmasks enabled except for terrain, and using an external FDM instead of JSBSim, however as you would see on the other screenshots, the heavy model is what took its toll on my performance.

Image

comparison between Su-15 and F-15 using the same pre-recorded flight, granted i was using a Optimus technology to enable my dedicated graphics by use of a *software* render offloading bridge(screen is physically connected to the integrated gpu), so there would be a hard limit in transfer and memory buffers, that if the vertex count for scene drawables weren't so high, i would have better performance on my Intel card(i have tested this), so the test isn't perfect.

Image

now comes comparison of osg stats for both planes, with and without aircraft drawmask.

Su-15:

Image

F-15:

Image

Su-15 w/ drawmask applied:

Image

F-15 w/ drawmask applied:

Image

edit: seems that i have a very early version of the Su-15, because i don't see a ton of Canvas/Nasal related code on the tested version, or i would have carried out a test with Nasal directory simply deleted to figure the differences.
hamzaalloush
 
Posts: 631
Joined: Sat Oct 26, 2013 10:31 am
OS: Windows 10

Re: Su-15

Postby Thorsten » Sat Nov 14, 2015 7:33 am

At this point I do not know why the parameter "flight" so high, I do not know where to look


Try a pocket calculator...

1 ms = 1/1000 s

which means

1 s = 1000 ms

'Flight' has a mean duration of 1.59 ms. It is iterated 123 times, coming to a total duration of 195.57 ms. We can add to this 'events', having a mean duration of 1.57 ms, being repeated 28 times each second, and get another 43.96 ms accounted for. For the fun of it, let's take 'input' with a mean of 2.08 being iterated 28 times, and another 58.24 ms gone.

For the fun of it, let's assume that all the small rest sums to 250 ms (it's probably much less).

Then we have 195 + 43 + 58 + 250 ms accounted for - that's 546 ms.

Meaning your the sum of all the submodules you're looking at is busy about half a second for every second you run the sim. What's it doing the rest of the time? An educated guess is that it waits for the graphics cards to render the tremendous vertex count of the Su-15 mesh...

Or in other words, if you believe that 'flight' is high and drags the system, you didn't add up the numbers on your screen.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

PreviousNext

Return to Aircraft

Who is online

Users browsing this forum: No registered users and 13 guests