Board index FlightGear Development New features

planes

Discussion and requests for new features. Please note that FlightGear developers are volunteers and may or may not be able to consider these requests.

planes

Postby airforce master » Wed Jan 28, 2009 1:09 am

we should be able to switch planes in the sim because i hate having to close flightgear then switching to a new plane
airforce out
airforce master
 
Posts: 158
Joined: Sun Apr 13, 2008 12:14 am
Location: In the Sky

Re: planes

Postby YourDailyTsunami » Thu Jan 29, 2009 9:08 am

I think that'd bring down the performance of FG on older computers quite a bit!
all the booze is free, airline goin' broke, here come the ladies with another jack'n'coke... :P
YourDailyTsunami
 
Posts: 584
Joined: Wed Dec 12, 2007 8:01 pm
Location: Europe, mostly
Callsign: Tsunami

Re: planes

Postby Flying toaster » Mon Feb 09, 2009 12:01 pm

On the other hand, let's face it... My G4 iBook with with 1GHz 700Mb and a radeon card is brought to its knees by the latest Flight Gear... What's funny, it is more than twice the Flops I had on a workstation back in the time I worked on Computational Fluid Dynamics :roll: Yeah 1998 is a long time ago

Even if those specs are definitely low end by today's standards, I am really wondering if running on a low end machine can still be seen as a goal of FG. Especially, I think not being able to downgrade/remove scenery textures is a big no-no on older graphic hardware. In general it is quite hard to downgrade the FGFS rendering system in order to get adequate performance on slow CPUs.
Reliance on scripts instead of compiled code is also not very nice to slower CPUs. And if at one point we have multithread everywhere, which seems logical since today speedups are obtained through multicore CPUs rather than single core performance (what has become of Moore's law), that is going to be even more deleterious to performance on older boxes.

I am not criticising the path FG has taken, I am more than happy of all the eye candy we got in the process, but it seems that the low end has moved up, up, up ... :D
Flying toaster
 
Posts: 390
Joined: Wed Nov 29, 2006 7:25 am
Location: Toulouse France

Re: planes

Postby BrianVanSpeybroeck » Mon Feb 09, 2009 1:32 pm

Agreed, on the need for bigger, faster, computers to run idea. I'm all for being able to switch to another plane in flight *but* I also feel this makes the sim more like a game. More gamers is not necessarily a good thing for a simulator to try and attract.

As long as it doesn't stiffle performance and lug everyones computer down then I'm fine with it. If it just pushes the need for a faster computer with even more RAM and such to get the ability to change aircrafts without exiting and re entering the sim I don't need the concept.
Done!
BrianVanSpeybroeck
 
Posts: 496
Joined: Tue Dec 02, 2008 1:36 pm

significant misconception ...

Postby Hooray » Mon Feb 09, 2009 3:45 pm

YourDailyTsunami wrote:I think that'd bring down the performance of FG on older computers quite a bit!

That's actually a slightly misleading interpretation, there's really no technical reason why a capability to select and switch FlightGear aircraft at runtime within the simulator should have any significant or relevant performance penalties associated (after all: once you want to switch aircraft, you don't care about a simulator slow down during re-initialization-you certainly don't if you are accustomed to having to restart the whole sim!).

In fact performance-wise, the opposite would be more likely to be true, given that currently changing aircraft means to terminate and restart a whole process, including reloading and re-initializing lots of runtime state that doesn't necessarily have to be reloaded just to change the active aircraft, this happens only relatively quickly because of a hot cache once you've started FG before, but apart from that it's actually a terribly inefficient method to re-initialize an application.

The reason why this still isn't possible in FlightGear is because it is complicated to implement the necessary support because the current architecture was never designed and implemented with this requirement or priority in mind, so most code existing today in FlightGear would need to be changed to make this possible because it was developed without this capability in mind, and even most new code is added without such concerns.

Additionally, most of the necessary modifications boil down to "unsexy" cleanup work, rather than developing exciting new features and code (which provides for somewhat direct gratification), several developers would probably have to spend several months to fix the current design, without introducing major new code or features during that time. This would include lots of refactoring work and other stuff that's generally considered "boring" by most.

And then, this would also first of all require a decision that this is in fact a design flaw which needs fixing, so developers would need to agree that this should be changed.

So, in this sense this issue does boil down to a performance issue at some point, simply because of the limited man power available which would then be pretty busy doing stuff behind the scenes that most users wouldn't get to "see" or understand in any way, until of course such an effort succeeds and people are suddenly able to switch aircraft at runtime.

But the lack of support for changing aircraft at runtime is certainly not in way related to FlightGear wanting to support low end systems or anything like that.

Likewise, FlightGear's extensive use of open interfaces such as XML and scripts shouldn't have any significant performance penalties either.

For example, most costly XML and Nasal processing (think parsing) doesn't happen on a "per frame" basis, but takes instead place before the main loop is run, during initialization.
So, that's when the overhead for parsing and expensive processing comes in.

Most of the code run during simulation is merely based on dynamically populated data structures, for example by initializing the corresponding structures or setting up bytecode that is then run in the Nasal VM, but all this doesn't permanently happen during simulation!

The mere and proper use of technologies such as XML or scripting certainly doesn't automatically impose any significant performance penalties, the few instances where a piece of Nasal code was indeed found to be the case for a simulator slow down this also wasn't a shortcoming of Nasal, but mostly a matter of someone not using the proper approach to do something, or someone just not being aware of the limitations imposed on Nasal scripts that are necessarily run in the main loop of FlightGear and may thus negatively interfere with other subsystems if not properly coded.

Of course there are some scenarios where the use of Nasal cannot be really recommended, but this wouldn't be so much due to shortcomings of the Nasal scripting language, but much more due to architectural shortcomings in FlightGear, that eventually resulted in Nasal being embedded in it the way it is, so that scripts get to run in the main/rendering loop.

But Nasal/scripting in itself doesn't automatically have to imply "slow": with a properly modified FlightGear architecture, Nasal scripts could be used for many more interesting things without necessarily affecting overall simulator performance.
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: planes

Postby Flying toaster » Mon Feb 09, 2009 4:59 pm

Made your point, I was not aware of the VM part :oops:
My main concern regarding scripting code or any bytecode is that *theoretically* (important to notice that) it is slower than its compiled counterpart. I can see the Java crowd coming to me with anger and nice benchmarks showing their favorite language outperforms plain C (which has always puzzled me) and I do not want to start a flame war, really.
What I will never deny in the use of Nasal is the extra flexibility it offers (and believe me, I use this flexibility in my aircraft models)
I am more than happy with current FG performance (I only use my mac for 3D modelling ,painting and debugging purposes). It's just that as a "remember-when" I am always a bit annoyed when hardware requirements keep increasing. But then again you always have to consider what you get for the extra CPU/memory/disk space eaten and so far it has been a lot of nice extras :wink:
Flying toaster
 
Posts: 390
Joined: Wed Nov 29, 2006 7:25 am
Location: Toulouse France

Re: planes

Postby Jester » Mon Feb 09, 2009 6:57 pm

While not everybody seem to agree with me, my measurements show 90% cpu usage goes to graphics and less than 10% goes to fdm and nasal and everything else (assuming you don't write silly nasal code).
Jester
 
Posts: 1191
Joined: Wed Feb 28, 2007 4:53 pm
Location: Hungary
Callsign: BA996,Rescue1
IRC name: Jester01
Version: GIT
OS: Debian Linux

Re: planes

Postby Ineedhelp » Wed Feb 25, 2009 8:15 pm

My G4 iBook with with 1GHz 700Mb and a radeon card is brought to its knees by the latest Flight Gear...


It is? With every feature enabled or none? Mine with 512 MB RAM and Windows(Memory hog and a lot of useless processes.) and it runs it fine, it just takes maybe five minutes to load, but that doesn't matter, and it lags a little with Atlas. Must be Macs.

Well, on topic, it would be handy, but, it would be bad for older systems. Why not you just wait for it to load?
Callsign: Aero
Aircraft: Aerostar, C172P.
Airports: Somewhere not KSFO, but with people.
Ineedhelp
 
Posts: 278
Joined: Sun Jan 18, 2009 11:13 pm
Location: In from of my computer.

Re: planes

Postby Gijs » Wed Feb 25, 2009 8:28 pm

I would expect some more problems, apart from the implentation. Changing a plane during a flight would be bad, you would get a chancing FDM for example; hard to keep the plane controlled when it suddenly changes size/weigth/power etc. If we implent this "feature", we should keep this in mind and think of some way to prevent users from having accidents. Changing on ground only might be one of the solutions.
Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9544
Joined: Tue Jul 03, 2007 3:55 pm
Location: Delft, the Netherlands
Callsign: PH-GYS
Version: Git
OS: Windows 10

Re: planes

Postby Hooray » Wed Feb 25, 2009 9:06 pm

Gijs wrote:Changing a plane during a flight would be bad, you would get a chancing FDM for example; hard to keep the plane controlled when it suddenly changes size/weigth/power etc.


If I am not terribly mistaken, I think you are misunderstanding the scope of this discussion (if not, I surely did!): as far as I am understanding this discussion, it isn't about changing the aircraft in flight, in order to resume the same flight with a different aircraft, but instead about switching/resetting to a different aircraft at runtime, without having to restart FlightGear solely for this purpose, pretty much like "resetting" the simulator with the possibility to use a different aircraft after the reset.

In fact, think about it like having to quit Word in order to start a new document, rather than simply starting a new document from within Word, without restarting the whole word processor (and process), so it's mostly about usability and design/architecture.

As far as I am understanding things, that's really what this discussion is all about. And if that's the case, this is in fact mostly about good and proper design.

The potential problems you are mentioning are however somewhat similar, but most of these would be automatically addressed by suspending and resetting all subsystems one by one.
A more technical discussion is to be found in the developer's section on the wiki, where this is referred to as "FlightGear Sessions".

An ability to switch to a different aircraft while resuming the same flight would be totally pointless and ridiculous, think about scenarios such as totally incompatible aircraft and flight regimes (e.g. B747<->C172, Concorde<->737, BO105<->Seneca etc).

Most of the corresponding settings don't directly map to the setting of another aircraft, and even if they do, they don't necessarily do so in a valid flight profile.

So, having such an option would be really ridiculous from a feature/functionality point of view-from a technical point of view, it might however be probably very instrumental to help in the effort of modularizing FlightGear and decoupling individual subsystems.
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: planes

Postby YourDailyTsunami » Wed Feb 25, 2009 9:12 pm

Ineedhelp wrote:
My G4 iBook with with 1GHz 700Mb and a radeon card is brought to its knees by the latest Flight Gear...


It is? With every feature enabled or none? Mine with 512 MB RAM and Windows(Memory hog and a lot of useless processes.) and it runs it fine, it just takes maybe five minutes to load, but that doesn't matter, and it lags a little with Atlas. Must be Macs.

Well, on topic, it would be handy, but, it would be bad for older systems. Why not you just wait for it to load?


Well my old 512 RAM pc had many problems in the end when running flightgear. But even the new machine with a better graphics card than ineedhelp's often has lags on startup in busy areas (I suspect this somehow is connected to the multiplayer).
all the booze is free, airline goin' broke, here come the ladies with another jack'n'coke... :P
YourDailyTsunami
 
Posts: 584
Joined: Wed Dec 12, 2007 8:01 pm
Location: Europe, mostly
Callsign: Tsunami

Re: planes

Postby Hooray » Wed Feb 25, 2009 9:57 pm

There are several things to keep in mind about FlightGear and its performance. First: FlightGear's really isn't particularly optimized at all, second: FlightGear really isn't particularly slow on current hardware/systems either.

In fact, on average I am easily getting between 50-80 fps at KSFO in graphically complex aircraft (think A-10), of course this is on a relatively new/powerful machine with 512 MB turbocache graphics hardware, 2 GB RAM and 2 ghz dual core support.

But most computers nowadays can be assumed to have at least 256 MB dedicated graphics memory, and about 512-1024 MB ram, as well as at least one 1-3 ghz processor.

Regarding optimization, it is only since just recently that -in the scope of the continuing migration to OSG- rendering related components are starting to benefit from optimizations that are either coming directly from the OSG side of things, or that are at least significantly facilitated by the use of OSG instead of PLIB/SG*.

So performance limitations in FG are not so much due to use of dynamic features such as scripting or XML
but it's mostly due to architectural and algorithmic shortcomings.
The most promising RUNTIME performance improvements could probably only be gained by splitting up the FlightGear subsystem architecture because most subsystems have a sequential order and dependency.
The process of decoupling subsystems from one another would also help identify those subsystems that are computationally more complex, and which may possibly benefit from algorithmic optimizations.
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: planes

Postby Liam » Sun Mar 01, 2009 2:09 am

I dont find it that much of a chore to restart it... especially if your computer is "fast" like yours aparently is :)
The faster the better I think- Without making it slower I think its just perfect
User avatar
Liam
 
Posts: 1905
Joined: Tue Dec 23, 2008 4:33 pm
Location: United Kingdom
Callsign: Liam
Version: GIT
OS: MAC OS X

Re: planes

Postby Hooray » Wed Mar 04, 2009 12:56 pm

Liam wrote:I dont find it that much of a chore to restart it... especially if your computer is "fast" like yours aparently is :)


No, it's really not much of a chore for me either - as previously mentioned, on any "current" machine (i.e. bought or upgraded during the last 12 months), rebooting FlightGear really isn't all that slow and personally I honestly don't care much about having to restart FlightGear or not: from my point of view, this "feature request" would also be mostly about usability/convenience, which is certainly also based on experiences and expectations coming from other simulators or games, which don't require rebooting for re-initialization.

However, frankly spoken my not bothering about switching aircraft in the simulator is really mostly due to my computer which gets FlightGear started in about 10-15 seconds flat, and usually rebooting the simulator takes even less than 10 seconds, even for complex aircraft/airports combinations (in fact, if it really annoys you, this can be even more accelerated by keeping the executable image in memory -i.e. by running fgfs inside a debugger such as gdb- or putting the base package/scenery data onto a virtual RAM drive, so that the startup is no longer disk I/O bound).

For novice FlightGear users, the only thing that may appear somewhat disturbing is the fact that the splash screen isn't really properly updated/redrawn so that it may appear as if it had crashed during bootup, this is something that most Win32 users are not used to - because most Windows GUI applications use at least two different threads to do UI updates and background processing, in order to ensure that the UI is always responsive regardless of the background processing going on.

But given an average of ca. 10-15 seconds for the boot process on current hardware, FlightGear startup does already perform rather well compared to ALL of its commercial counterparts (MSFS & X-Plane), some of which may take even more than a minute for starting up in some situations or configurations.

So, this is another proof that "premature optimization is the root of all evil" - simply because CPU power has so heavily caught up during the last years, that it doesn't really matter if the init code is particularly optimized or not.

I do understand however that if I didn't have access to a current and powerful computer, my opinion would surely be a very different one, simply because it can be annoying to wait for several minutes in order to change an aircraft or restart the simulation, just because you managed to crash your aircraft again ;-)
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


Return to New features

Who is online

Users browsing this forum: No registered users and 8 guests