Su-15

[vitos]

Lets quit it fast. If You would use any part of "Su" model, or will use it way other than personal flying, as attached license demands, You will have problems, as life made this way. I do not care about what You thinking about it, and any Your views on that.

Discussions at that forum, as I can remember, never had lead to any positive results. It's just blablabla. Do Your things as I do mine.

[Hooray]

Lets quit it fast. If You would use any part of "Su" model, or will use it way other than personal flying, as attached license demands, You will have problems, as life made this way. I do not care about what You thinking about it, and any Your views on that.

Seriously ?
So let's assume the following: I have just created 10 screen shots of your aircraft and 5 youtube videos, taken your radar.nas code and I am about to put all this on a DVD and sell the whole thing on ebay to anybody willing to buy it. And guess what, I would still not be violating any laws at all (neither in Russia, in the US or elsewhere) -whereas you are very much violating the GPL by your licensing and use of existing Nasal code, and by behaving like you do (I just finished reading the translation of your Russian readme file, including the propaganda).

[abassign]

@Vitos, @Hooray

Before you get mad for licensing problems that do not understand, let's move on testing to understand how a plane of this complexity, works in FGFs.
I decided to delete references to the various parts of models that contain files .ac. I just kept the file su-15.ac,, but before I replaced it with the UFO files. So instead of a file of 37 MB, magically it turned into a file of 33 KB.
For the sophisticated minds of many of you is a test idiot, but I'm obviously an idiot and then I do the test.
I simply want to know how much they weigh the various .avi file on the frame rate ...

This is the su-15/Models folder (BrakeChute.old Cockpit.old Engine.old ExternalTanks.old they contained all external .ac files used in Models):


This is the performance:


36-45 fps (On average, 43 fps)
Test model made by @Vitos:
"/sim/rendering/draw-mask/aircraft = 1" & "/sim/rendering/draw-mask/clouds = 1" & "/sim/rendering/draw-mask/terrain = 1" fps 39-41 (On average, 40 fps)

Configuration:
PC with GTX 870 graphics card with 6 GB VRAM, 32 GB RAM, quad-processor I7-4700MQ 2.4 GHz
Display: 1920-1050
Airplane: Vitos Su15 last version
Airport: San Francisco Intern. runway 01L
Meteo: Hight Pressure Region
ALS with all max effect
Pilot view
Random vegetation 5.0

In previous tests I had 40 fps with .ac file, which had been created by @Vitos (quiet @Vitos, get back files in place to avoid licensing issues ... mine is only a test!). The difference due to the enormous file .ac ofVitos is 3 fps (about 10%), as had already earlier have noticed, instead the maximum workload, or what really reduces the speed, is due to the advanced effects, of earth and sky. In fact I removed the sky and the earth, and I had 59-60 fps. Just like in precdenti test.

From all this I conclude that:

* "Flight" (FDM) apparently consumes a lot of CPU, but has no impact on performance (It seems absurd to many, but modern processors have a strange way of working) When is required a real workload, the load moves to the activities to perform.
* "Earth" and "Sky" consume many resources!
* Very large files ".ac" do not affect the speed with modern graphics card (obviously within certain limits that have verified in previous tests).

As mentioned many times, the most important test is that in a real situation, a flight simulator is very complex and is made up of many parts, the technique of dividing the problem into sub-parts may lead to partial and erroneous visions of reality.

[Hooray]

I don't mean to offend you, but you really have to read what people are telling you, or you will continue to waste everybody's time, including your own.
Thorsten explained exactly how to interpret the various stats you can get out of FG, and I think I posted a handful of links.
Please do spend 10 minutes reading those articles, and maybe have them translated to your own language using google translate.
That should help you understand immediately where your analysis is incorrect.
You should also consider watching Hamza's wiki edits, and work through those.

I believe that, given your hardware and interests, you could be helpful with this, but you have to do some "homework" first, which includes reviewing Thorsten's comments in this discussion

[Hooray]

Regarding your "ufo driven by the Su15-FDM/Nasal":

• stop using the performance monitor dialog, use telnet/http instead - or it will taint/influence your findings
• disable all rendering using the draw-masks, except for the aircraft
• use the built-in osg stats (like Hamza did) and post your screen shots here

Then, you can see exactly 1) if the complexity of the model affects your maximal framerate, and 2) if there are any remaining issue unrelated to the complexity of the model itself (e.g. Nasal)

Regarding fdm issues, those should also show up in standalone jsbsim mode, unless they are linked to Nasal listeners triggered by fdm properties (which you seem to have excluded already).

[vitos]

Minor update: background of textures changed to one made from own photo of airplane metal. For some unknown reasons it improved each parameter a bit.

[abassign]

@Hooray
Of course I've read what you've written and it's obvious that I do not agree with the method, but I prefer to use another. There are various ways to make a measurement, if, for you, my methodology is not good, is not a problem, use another method... It means that we do not use the same measurement protocol, but in the end what I am measuring is the reality that my system exposes me.
I explained the reason, you can accept or not it, but at the end it seems clear that the impact of the size of the file .ac used by the SU-15, is not decisive on system performance. Also the evaluation of the actual load caused by FDM, it seems to me not to have a real responsibility on performance (always of course to my system). There are other things much more specific for the slowdown, for example the clouds (I used the advanced weather with high pressure) or the trees ... If there is no interest for you to evaluate the program as a whole, but you are interested evaluate separately the parts of it, go ahead, it is another criterion measure that has its advantages and its disadvantages. Unfortunately, the execution of the programs does not follow the rules of a gospel, it is something much more complex and articulated.

[Hooray]

Like I, and others, have told you, it is indeed much more complex than it may seem, you are only just beginning to understand these complexities - so people don't necessarily disagree with some of your findings, but others are just plain wrong - and we've been trying to tell you WHY that is, and what to do about that. So it's so much a system-specific issue if the underlying method is flawed. Otherwise you are obviously correct that things will vary greatly depending on startup/runtime settings and hardware/OS etc.
But that was never the point, you can measure the impact of certain factors quite well, which includes things that Thorsten and hamzaalloush have mentioned, and explained to you.

I don't think anybody is telling you to ignore your system or to stop profiling/benchmarking fg as a whole, but to do that correctly you need to understand a few basics first. And while you may not agree with excluding certain systems/features from your tests, that is exactly the method to come up with reliable data that can be interpreted correctly.

Otherwise, there are too many unknown variables - like you briefly mentioned (CPU, GPU, drivers, OS, memory latencies, swapping etc).
Thus, what you need to do to come up with reliable information is to strip down the whole equation by removing external factors first, before you can re-introduce them at a later time.

I don't know if there's any good/lightweight analogy to explain what you are doing currently - but while you are saying that you are "measuring reality" according to your system, you are basically trying to predict the weather by looking at a thermometer only - while that may give you the current temperature, you are leaving out tons of other relevant context/information, so that you may sometimes be right, but you will never understand why you are usually wrong.

Or rather let's try this: Imagine your car's making strange noise every once in a while - one mechanic is telling you to exclude external factors first (close the windows, turn off the radio etc) to see if the problem is related to any particular "system" (low-hanging fruits), while the other one just emphasizes that cars are complex machines and that he needs to thoroughly check the whole engine and transmission first to be sure that it's not a serious problem, even though it turns out to be a broken speaker in the end ...

You should give us the benefit of the doubt, that most of us have literally spent hundreds of hours debugging, profiling and troubleshooting FlightGear related issues, so that we have a pretty thorough understanding how to exclude certain factors, without necessarily having to know what the real issue is - but we know how to get there. You can learn from us, or you can disregard all the information - but so far, you've already been wrong in a number of your statements, and we can help you stop wasting your time - so that you can come up with useful data instead.

you've had some good ideas in the last couple of days, but you are failing to interpret your findings correctly unfortunately

[hamzaalloush]

@abassign, if you really want to test aircraft, the maximum performance given in an FG context, then switch out to exterior view, disable all graphics setting(including ALS), enable wireframe mode(this one is most important, since it will let your GPU render both visible and hidden faces).

then, i want you to do this for me, just zoom in as close as possible not to obscure the osg stats, and do two screen shots: 1- fps only. 2- full osg stats.

i prefer that you turn draw-masks on, for Clouds and Terrain(since Terrain is different for each airport and we do not want sophisticated clouds).

i have a more powerful graphics card than you, and here are my results, it is important not to be biased, thus i have independently verified your testing method by replacing the model with UFO as well(using same method as renaming the files shown above).

all vertices rendered at once using "wireframe" mode in an exterior view zoomed as close as possible, i.e the ultimate cost of the model on the system(watch how frame rate drops "white line", and GPU time increase "orange" as i enable "wireframe"):



same as above, but fps only, shown just for clarification(even though the results are nearly equal):



now just to illustrate my point, here's the aircraft with no wireframe(see the fps increase because of the hidden faces? this is why it remains subjective without wireframe and dependent on view/camera, in addition, see the how the GPU "orange" time dropped)



exterior model replaced with UFO model, check property to see that it is indeed the Su-15 for clarity:



now fps only, and yes look how the osg stats are costly(390fps to 995fps just removing stats, and 1200fps without PUI), which is why Hooray is telling you to log the performance monitor to file instead of using GUI interface(for osgstats i have no alternative since it isn't exposed to the property tree, or else i would have recorded it to file):



finally, in comparison to previous screenshots, now comes the critical part that shows that fps in FG(or osg apps in general) depends on view and context, hence why i start with no Terrain/Clouds and enable "wireframe" mode, screenshot below shows the interior view, with the cockpit model removed(even with scenery/clouds, fps only: 192fps, osgstats: 64fps), the increase of fps is because of hidden faces:





since i did your method, can you verify that you see the same results with "my' method(using "wireframe", exterior camera just zoomed in, with osg stats, compared before/after replacing with UFO model)?

[Thorsten]

I do not care about what You thinking about it, and any Your views on that.

You don't have to.

Go to a lawyer of your choice and ask him to explain the GPL license to you, and he's going to tell you that you're on the wrong side of the law, plain and simple.

It doesn't matter whether you care about doing something illegal or not - you're still doing something illegal in licensing your plane the way you do, and we're perfectly safe in using it in any way allowed by the GPL license (see Hooray's post), regardless of what you happen to write into your license file. You don't have the legal right to license that way, which is why your license is invalid as it stands.

It's obvious that you don't want to hear that, but that doesn't change the situation.

[Thorsten]

Configuration:
PC with GTX 870 graphics card with 6 GB VRAM, 32 GB RAM, quad-processor I7-4700MQ 2.4 GHz
Display: 1920-1050
Airplane: Vitos Su15 last version
Airport: San Francisco Intern. runway 01L
Meteo: Hight Pressure Region
ALS with all max effect
Pilot view
Random vegetation 5.0

Speaking of confounding factors which need to be isolated...

What you've done is to choke down your system by an external factor so much that basically nothing else matters. So naturally the sensitivity to the observable is gone.

[hamzaalloush]

Speaking of which, Thorsten, what did you think of methods? As i tried excluding everything including ALS from skewing my test results.

My conclusion is that the Su-15 "model" is terrible at its current state, while the JSBSim implementation i agree is brilliant.

[Hooray]

FG has become a complex piece of software, you can really only determine maximal theoretical performance of different components in isolation, and then review if those results look sane or not. It is only then that people should look at performance with multiple components/subsystems running, to see how the impact/relate to eachother.

[hamzaalloush]

Where can i improve? I mean in hind sight, i can disable many of the sub-systems including sound , fgcom and ai for example, but i'm not sure they will have a profound affect on the running unless i probebly run without draw masks, which the model and Nasal(not sure if C++) running of the AI will have an effect... My point is, I've illustrated how this "Su" model can bring the FPS to its knees, regardless if drawmasks enabled or not(that's just for excluding terrain for consistancy), "wireframe" rendered all faces and loaded high even on a high-end GPU, and caused it to perform worse than if substituted with the UFO model(which makes abbasign comparsion invalid), and the aircraft will equally look the same from the exterior with normal maps used.


Though i agree for keeping sub-system in isolation when benchmarking, just see how Nasal affected the F-15, which for a strictly model comparsion does not do it justice.

[abassign]

@hamzaalloush

Dear, I could say with equal emphasis, that your tests are not valid ... as they are not linked with the actual use of the program. I want you to remember the problem with VW emissions Nx, the criterion to measure emissions test has encouraged the manufacturer since the method is absolutely far from the operational reality. Only when "someone" did some testing in the real conditions of use of the truth has been discovered! A program is a complex object, which interacts profoundly with the characteristics of the hardware and use by the user. A small example that might help you ... have you ever thought that both the CPU and the GPU have separate systems of heating management of core? You know what that means? It means that if one component gets too hot the system imposes a limit in order to prevent damage, then you have the real slowdowns that your tests "clean room" can not detect ... It's over, for a long time, the era for which we had certainty on the performance of the systems, sorry now for the PC world it is much more complicated to understand the real performance than you think. I know only one thing, on my system, the Su-15 does not weigh very much higher than the weight of the soil and the sky ... depending on the visual quality that I want to have!
I also remember that I, as a user of the program, affecting in his performances, though I do not have the advanced weather, miraculously, the program goes faster by 10-15%, if I want to see all the vertices the program will be 10 % slower, if I want to see the clouds the program will be 10-30% slower.
A program, like a flight simulator, is made to meet the needs of the user and therefore must consider the needs of the user are not those of the theoretical test cleanroom proposed in these posts. VW should remind you something

Good job