Su-15

[vitos]

You are wasting Your time. I said that "Su" is JSB model. It means all systems of it - each switch, everything, exclusive pure FG multiplayer and beacons calculations - runs not at Nasal, but on JSB. You would comment out end of Su-15.xml file with all systems declarations - however it is prohibited by license, so You should believe to my word.

BTW, it says a lot about how good modeller You are - as of Your decency too - so do not try to advice me to remove polygons, switch everything to Nasal, so on. It gotta work as it is.

[hamzaalloush]

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

Which is saying something on a GTX 870 card... I don't know weather to laugh or cry, the ignorance and general attitude of this guy Vitos is astonishing.

edit: lol... in multi-threading mode with a basic airport not demanding scenery and lower graphics settings, still barely 60 fps with the costly osg stats, and 71 fps with performance monitor, i would guess it would require me a second GTX 980 Ti in SLI configuration just to keep up in complex scenery, which as Vitos probebly knows is the 2nd most powerful graphics card you can buy, the F-15 is a much better aircraft then the Su-15 and performs in lower computers too, that's what i call a masterpiece, the Su-15 sucks, you don't need Google translate for that.

[Thorsten]

You are wasting Your time.

With you? Certainly - the rest of your post confirms that you have no idea what I am talking about (for your information, both JSBSIM and Nasal are executed on the CPU - which isn't fully utilized anyway because it has to wait for rendering to finish the frame - doesn't matter whether it's all Nasal, all JSBSIm or a mixture for the question).

However, there are others in the thread which may benefit from pointing out the flaws in your models so that they can do better.

You would comment out end of Su-15.xml file with all systems declarations - however it is prohibited by license, so You should believe to my word.

Oh, stop waving the license around - as it seems you're calling routines from the Nasal library, you're utilizing GPL stuff, which forces you to license all dependent routines also under GPL - your plane as it stands is illegally licensed.

Cheers

[hamzaalloush]

edited my last post, yeah Thorsten, this guy waives the flag of data, when presented he doesn't comment on them or take into consideration, i believe this guy is a waste completely of our time.

[vitos]

You are using GPL stuff too - it not makes You GPL. GPL is only code what is derivative of GPL code.

My code is written completely by me. There is not any copypaste from any GPL code. Same with model and anything. So know Your place.

And yeah, I am ignorant. I do not want to depend on people who had demonstrated many times that they are can not be trusted.

[Thorsten]

My code is written completely by me. There is not any copypaste from any GPL code. Same with model and anything. So know Your place.

I think you may want to read what the GPL license has to say about dependencies and code. That your code is written by you is a necessary, but not a sufficient condition for licensing the bundle as you like.

Edward would argue that merely using a 3d model to visualize flight dynamics triggers the relevant GPL provision for everything in a bundle if, say, the flight dynamics is GPL licensed. I'm less sure in this case, but your code calling GPL'd routines? That's a rather clear-cut dependency and automatically makes your code GPL.

[vitos]

I think You are going too far in Your wish to bring freedom to others. In case You making it by freeing some product of its author it would lead to freeing You from something too - and it does not matter if it's demanded by some license or not. Life is fair by itself, laws exists only to help people know some normal rules. So if You are making or following wrong law it would make You harm irrelatively of what You are thinking about it.

Don't You know what I mean?

[hamzaalloush]

another interesting fact about the Su15 vs F15 comparison, the F15 in its current status has alot of Nasal in it, it really is "GC" bottlenecked rather than vertex limiting to GPU's, it works good on lower-end devices, but on higher-end where vertex count seems not to be an issue, i don't seem to have better FPS with draw-masks disabled using it compared to the Su15.

F-15 with Canvas/Nasal on lower-end Intel HD3000 with draw masks disabled for aircraft and models(Where vertex count isn't an issue, i use integrated card for cases such as this with draw masks):



also GC stats for this case using Thorsten B's old patch:

Code: Select all

   

    Initializing f15 Systems
    F-15 External loads init
    Master arm 0
    Weapons System stop
    External load set Clean
    F-15 MP network broadcast init
    Initializing f15 weapons system
    Master arm 0
    Weapons System stop
    Weapons System stop
    Initializing Radar Data
    **** Nasal garbage collection statistics: objects: 29165, references: 102706
    Setting replay medium res to 50hz
    Starting with gear down as below 500 ft
    --> Set parking brake as below 50 ft
    **** Nasal garbage collection statistics: objects: 28561, references: 101640
    **** Nasal garbage collection statistics: objects: 28562, references: 101633
    **** Nasal garbage collection statistics: objects: 28569, references: 101677
    **** Nasal garbage collection statistics: objects: 28562, references: 101628
    **** Nasal garbage collection statistics: objects: 28594, references: 101722
    **** Nasal garbage collection statistics: objects: 28562, references: 101634
    **** Nasal garbage collection statistics: objects: 28564, references: 101660
    **** Nasal garbage collection statistics: objects: 28566, references: 101649
    **** Nasal garbage collection statistics: objects: 28561, references: 101631
    **** Nasal garbage collection statistics: objects: 28551, references: 101619
    **** Nasal garbage collection statistics: objects: 28556, references: 101634
    **** Nasal garbage collection statistics: objects: 28551, references: 101592



F-15 without Canvas/Nasal on lower-end Intel HD3000 with draw masks disabled for aircraft and models, Nasal file was simply deleted(Notice the higher performance):



GC stats for this case(Notice the lower numbers):

Code: Select all

   

    Cannot find Nasal script 'Aircraft/F-15/Nasal/awg_9.nas' for module 'awg_9'.
    Cannot find Nasal script 'Aircraft/F-15/Nasal/chronograph.nas' for module 'f15_chronograph'.
    Cannot find Nasal script 'Aircraft/F-15/Nasal/liveries.nas' for module 'aircraft'.
    Cannot find Nasal script 'Aircraft/F-15/Nasal/aircraft-main.nas' for module 'aircraft'.
    Cannot find Nasal script 'Aircraft/F-15/Nasal/flaps_computer.nas' for module 'aircraft'.
    Cannot find Nasal script 'Aircraft/F-15/Nasal/cadc.nas' for module 'aircraft'.
    Cannot find Nasal script 'Aircraft/F-15/Nasal/engines.nas' for module 'aircraft'.
    Cannot find Nasal script 'Aircraft/F-15/Nasal/gear.nas' for module 'aircraft'.
    Cannot find Nasal script 'Aircraft/F-15/Nasal/hud.nas' for module 'aircraft'.
    Cannot find Nasal script 'Aircraft/F-15/Nasal/engines.nas' for module 'aircraft'.
    Cannot find Nasal script 'Aircraft/F-15/Nasal/adverse.nas' for module 'aircraft'.
    Cannot find Nasal script 'Aircraft/F-15/Nasal/fuel-system.nas' for module 'aircraft'.
    Cannot find Nasal script 'Aircraft/F-15/Nasal/electrics.nas' for module 'aircraft'.
    Cannot find Nasal script 'Aircraft/F-15/Nasal/instruments.nas' for module 'aircraft'.
    Cannot find Nasal script 'Aircraft/F-15/Nasal/afcs.nas' for module 'aircraft'.
    Cannot find Nasal script 'Aircraft/F-15/Nasal/fox2.nas' for module 'aircraft'.
    Cannot find Nasal script 'Nasal/HUD/HUD_main.nas' for module 'aircraft'.
    Cannot find Nasal script 'Nasal/VSD/VSD_main.nas' for module 'aircraft'.
    Cannot find Nasal script 'Nasal/TEWS/TEWS_main.nas' for module 'aircraft'.
    Cannot find Nasal script 'Nasal/MPCD/MPCD_main.nas' for module 'aircraft'.
    Cannot find Nasal script 'Aircraft/F-15/Nasal/weapons.nas' for module 'aircraft'.
    Cannot find Nasal script 'Aircraft/F-15/Nasal/ext_stores.nas' for module 'aircraft'.
    **** Nasal garbage collection statistics: objects: 9813, references: 34169
    Cannot find Nasal script 'Aircraft/F-15/Nasal/mp-network.nas' for module 'f15_net'.
    **** Nasal garbage collection statistics: objects: 12407, references: 44588
    **** Nasal garbage collection statistics: objects: 13950, references: 51094
    **** Nasal garbage collection statistics: objects: 15217, references: 56689
    **** Nasal garbage collection statistics: objects: 15888, references: 59529
    **** Nasal garbage collection statistics: objects: 20705, references: 74516
    **** Nasal garbage collection statistics: objects: 20725, references: 77464
    **** Nasal garbage collection statistics: objects: 20736, references: 77502
    **** Nasal garbage collection statistics: objects: 20731, references: 77483



Conculsion: on lower-end machines, the vertex count has a higher chance of bogging down the system before the GC ever kicks in, even then... the GC has a slight reduction of performance, about 20% of total performance, whereas vertex count makes it unplayable.

Vitos, you don't trust my methods now, regardless if you trust me or not

[geed]

BTW, it says a lot about how good modeller You are - as of Your decency too - so do not try to advice me to remove polygons, switch everything to Nasal, so on. It gotta work as it is.

Vitos, I have a question: How does the model run on your system and could you give us your system specs, please?

[vitos]

1) What I said about fairness of life is relevant about anything else. You gotta live very angry live to bother someone like this and go into anger even deeper by that.

2) I made it earlier at topic. How it runs here does not matter. Matter it not depends on dudes who changes important properties names just because they want so. And matter it will go smoother and smoother with time, while models with reduced polygons number and 0.1sec timers will look worse and worse. Nah, and matter it's quite easy to import it with JSB as aside library into some other simulator, where people are more interested in common result and more friendly therefore.

[hamzaalloush]

No one is telling you to lose implementation of JSBSim(i think it is a good idea), i just illustrated Nasal effects on performance, it is your attitude towards others that is Impeding you from further improvement, i personally think the aircraft is good(hey i can fly it above 60 FPS on my high-end machine), but with less vertex count and normal maps everyone else can enjoy it too and have good performance(even better than F-15), but if you are not into contribution, and release everything under a license not to even modify something, then yes i think another simulator might be a good idea.

[abassign]

@Vitos

Vitos not remove polygons ... please let!
Your plane is beautiful and flies also good and fluid, is sufficient just have a good video card Obviously is not an aircraft for all ... I like it, is a beautiful airplane build in a great 'Soviet Union' aviation era!
I like it, is a beautiful airplane that had been built in a very important historical period of Russia. I would like to see more and more complete and closer to reality.

[Thorsten]

I think You are going too far in Your wish to bring freedom to others. In case You making it by freeing some product of its author it would lead to freeing You from something too - and it does not matter if it's demanded by some license or not.

First, you're confusing me with the authors of the GPL license. I'm merely pointing out to you what your legal situation is - and your legal situation doesn't change if someone else points it out to you, or if I sympathize with you, or if I think your situation should be different.

Please deal with reality here.

Second, you are using a GPL licensed product (FG), which means in doing so you accepted the provisions of the license. This binds you into a legal contract to adhere to the GPL insofar as you're introducing dependencies in your own work - which is intentional by the GPL authors to keep open software open.

You can not say after you've eaten a cake that you think you shouldn't pay for it - you have to decide before eating the cake whether you want to eat it or not.

Life is fair by itself, laws exists only to help people know some normal rules. So if You are making or following wrong law it would make You harm irrelatively of what You are thinking about it.

Don't You know what I mean?

Yes, you mean that you're free to break the law if you think it justified.

But see, by the same argument anyone could just grab your plane ignoring how you want to license it - if license issues would matter only if people want, your license wouldn't have any meaning either.

[Thorsten]

Your plane is beautiful and flies also good and fluid, is sufficient just have a good video card

I guess that must be one of the most condescending statements I've ever heard in the context of FG development.

Let's just not optimize features at all, because really all we need to do is to invest into the best GPU available and we can run as crappy code as we like and use as many unneeded polygons as we like.

@abassign: Don't ever ask me again to optimize any feature - with your attitude, you have just voided any sympathy from my side.

[Hooray]

@hamzaalloush: thanks for making these tests and for sharing your screenshots and findings with us. I believe that it would be good to also update the wiki article accordingly, so that we can also document the underlying processes and workflows - i.e. so that abassign and vitos can independently verify these results.
BTW: I particularly liked the idea of running the FDM in standalone mode to demonstrate that threading is not going to be the solution in this.


Anybody interested in seeing the impact of reducing model complexity can do so without even using a 3D modeling program, i.e. by using "osgconv" and its integrated mesh simplifier

Besides,it is true that you cannot reuse GPL'ed code in your own code, without also "tainting" your own code, due to the viral nature of the GPL. The only distinction that the GPL makes is that code has to be running the same process/address space as the GPL'ed code - which is to cover DLLs, DSOs, dynamically linked libraries.
There is no distinction made between binary or scripted/interpreted - and under the hood, Nasal code will indeed be compiled and "linked into" the same address space as other modules.
While that may be an unfortunate fact for external aircraft hangars/developers, $FG_ROOT assets are generally GPL'ed, without any exception for Nasal code in place.

We did have this discussion previously, and a few people suggested to re-license $FG_ROOT/Nasal accordingly, using a more permissive license - and while that might not be such a bad idea, it is a ton of work, especially given that most modules/code were written by people who may no longer be actively involved, so we would need to get in touch with those to explicitly ask the them to re-license their contributions accordingly, which makes the whole not feasible.

It is for that reason that the FSF asks contributors to its GNU projects (e.g. gcc) to explicitly provide the corresponding paperwork upfront, to ensure that such situations can be avoided, i.e. by granting all copyright to the FSF, or releasing all work into the public domain (which is automatically compatible with the GPL. no matter what some folks are saying): https://gcc.gnu.org/contribute.html#legal

Adopting HLA/RTI is going to make this even more problematic, because the GPL can be totally circumvented due to the whole "process/address space" distinction - which is why more and more DISTRIBUTED projects are moving to the Affero GPL (AGPL) instead.

PS: @vitos: I don't remember the discussion you were referring to (changing property names), but unfortunately there are tons of inconsistently-named/placed properties all over the place in FG, and that is complicating matters for other efforts. It would be really good to review/update these things, but that would inevitably break a lot of aircraft. One thing that might work is to update these things at the C++ (core) level and introduce a fgdata wrapper to map/mirror properties to their old equivalent (location/name in the property tree), e.g. using property rules.
Right now, FlightGear's way of using properties is unfortunately pretty problematic and does not scale too well, especially if you look at it with a focus on supporting multiple FDM, autopilot or route-manager instances - e.g. for the AI traffic system, there are too many hard-coded assumptions all over the place.