What to expect from FlightGear 3.2?

[punkepanda]

We have a newsletter for what new things has been added to the project (Monthly Newletter). I bet that will be the most read pages on flightgear.org, maybe except for the forum.

My big guess will be that many others are interesting in what people are actually working on from time to time. And when they have planned to release they're work. What about a wiki page for work in progress similar to the monthly newsletter.
I think this would be interesting to read about, both for simmers and for other contributors.

I also think this would give the forum a break for many requests about missing stuff because they can look at the "Work in progress"-wiki pages that something is being done to manifest some result.
For other contributors it would also give them insight about new ideas that people before them have had, so they not need to work in parallel with the same idea. rather than cooperate.

Let's try this for version 3.2 in this thread and we can then put inputs from contributors here to a new wiki page.

What are you working on for the next release? (If its a secret, then tell us you are working on some really nice stuff in your hidden cave, and give us some hints

[Hooray]

right, there's roughly 6 months of newsletters for each release cycle, as well the changelog for the upcoming release itself: http://wiki.flightgear.org/Changelog_3.2
Also, according to the devel list, Thorsten will probably come up with a write-up for the website about new/improved features to be expected in 3.2
And then there's obviously the git commit log itself for SG/FG and fgdata.

So, please don't come up with yet another wiki page for this - instead, help maintain the changelog.
At some point, we're hoping to re-organize this a bit (see the "village pump"), because there's clearly overlapping stuff here - and even the "development plans" category could fit in there.

[Prometeo 2013]

Thanks for the work...and I want to know if for the 3.2 I need a better computer or if for 3.0 is enought then for 3.2 too?. Sorry for my english.

[Johan G]

That depends on what you have now.

Could you add your computer specs to your forum profile? (Click the "User Control Panel" button on top of the page, then the "Profile" button.)

Note that what you write in the "System" field will only be visible to logged in forum users, but that what you write in the fields with the operating system and FlightGear version will be visible next to all your posts. This information can sometimes be an valuable help when troubleshooting. For an example of what could be visible to logged in users, click my name to the right of this post.

[Prometeo 2013]

Well I filled my Profile, ...Im only waiting that the 3.2 flightgear give me a breack and dont need a Nuclear Reactor to run it, jeje

[Hooray]

Im only waiting that the 3.2 flightgear give me a breack and dont need a Nuclear Reactor to run it, jeje

Obviously, performance depends on your system specs - but no matter your horsepower, you will still be able to bring any high-end system down to its knees, FlightGear is not particularly optimized and is generally a "resource hog", and there are a ton of factors that are having an impact here, including stuff contributed and developed by scenery and aircraft developers that may have significant effect on your frame rate and frame spacing. Usually, these things cannot be looked at in isolation - there are many features and factors that mutually affect each other. Aircraft like the 777-2000 or extra500 will remain heavy, no matter what is done on the FG side of things, short of procedurally optimizing textures, 3D models and bytecode...

And we're still missing the tools to really enable non-coders to easily identify expensive features (including scenery, aircraft, scripts etc), "expensive" in terms of CPU/GPU/RAM and VRAM utilization.

It is something that is being worked on, but it's probably going to take another ~2 release cycles until something materializes.

Please, just keep in mind that this is not generally a problem about FlightGear itself: some of us are actually working towards a more framework-centric development model, so that there's basically just a single component that can be optimized over time, while all aircraft would benefit from such optimizations automatically - unfortunately, this requires more coordination, organization and collaboration than most contributors are willing to put up with, because it no longer is just about a certain instrument and/or aircraft, but about generic development - so that good ideas end up being adopted in a poor way using copy&paste methods instead of generalization. Undoubtedly, there are some really cool aircraft, but many aircraft developers tend to use resources (textures, 3D models) and scripting constructs that are extremely heavy, and they're not really aware of the impact this is having on final FG performance.

[Prometeo 2013]

Thanks Hooray....

[hvengel]

...Usually, these things cannot be looked at in isolation - there are many features and factors that mutually affect each other. Aircraft like the 777-2000 or extra500 will remain heavy, no matter what is done on the FG side of things, short of procedurally optimizing textures, 3D models and bytecode...

This can't be said enough. I have been working on a new external model for my aircraft and in the process of adding new animations I decided to add a spent shell case ejection animation (Am I the first to do this?) along with gun muzzle flashes and smoke (fairly common features). I am running a very powerful computer with a high end GPU (overclocked GTX770) and these new animations will drop frame rates into the mid teens while the guns are being fired. This animation is creating about 360 new submodels per second while the guns are firing as well as using the particle system. GPU utilization is in the 80% to 85% range when this is happening - the highest I have ever seen in FG with this hardware by a significant margin. The muzzle flashes and smoke only have a small affect on frame rate so this is mostly the shell case ejection animation issue. I will be adding some controls so that users can disable these new animations so that things still run nicely on mid level and above systems.

Hoorays basic point is that some aircraft are very "feature rich" and it can require lots of computer horse power to handle some of those features. It's just the way it is and this is also true for other flight sims. I think the key to running these feature rich aircraft on not so high end hardware is to allow for users to selectively disable features that have high frame rate impacts. In my case I have clearly identified what features a problematic and it should be easy to provide a user configurable way to disable them. On some other aircraft there appears to be some difficulty identifying that is causing the resource issues for which makes implementing this type of configurability problematic.

It would be really nice to have some type of property tree based hook(s) for this that where part of FG (IE. not aircraft specific) that aircraft developers could hook into in a standardized way to disable features based on user settings. Or is there already something that can be leveraged for this? Thinking out load. I know there are performance vs. quality settings for rendering and that has something like 4 or 5 levels. Could this be used by aircraft devs to control resource intense features? Is this setting available in the property tree?

[Hooray]

right, having some kind of standardize "API" for feature-scaling would be good - on the other hand, I do believe that we first of all need a way to really "look under the hood" and see which features are expensive in terms of CPU/GPU, RAM and VRAM utilization - otherwise, it is far too easy to keep pointing out how poorly some aircraft perform, without giving aircraft developers the right tools to actually tell what's going on in terms of performance, i.e. regarding textures, 3D models, scripts etc

[hvengel]

Another thing that makes this difficult for aircraft devs is that something that has no noticeable performance impact on my machine might have a huge impact on another machine with a different GPU (IE. AMD instead of NVidia) even for GPUs of similar power. As you have pointed out in the past all of us need end users who are actively testing our stiff on a wide range of hardware so that we know that there is an issue with XYZ feature on AMD or Intel or ... hardware sooner rather than later.

Currently many aircraft devs are at least somewhat aware of which things in their aircraft cause performance issues and which of these could be turned off with minimal impact on the usability of the simulation. So as an example I know that even without the new animations that shooting the guns on my aircraft causes a significant frame rate drop. The new animations make this worse because there are 3 times as many submodels being animated. The new animations could be disabled without making the simulation significantly less usable but this is not the case with the basic gun animations (IE. the tracer and bullet submodels).

There are other considerations here as well. Very high end GPUs can handle much larger more detailed textures. Most low, mid range and older GPUs can handle textures up to 2048 x 2048 but some really high end GPUs can handle textures up to 8192 x 8192. I think most aircraft devs do their external model textures using higher resolution images that then get down sampled to allow them to work on all hardware. IE. I am working with 8192x8192 images for my wing and fuselage textures and these are down sampled to 2048 x 2048 for the texture that is actually distributed with the aircraft. So many aircraft devs could actually deliver a range of texture resolutions (IE. 1K, 2K, 4K, 8K). On my hardware I see no frame rate difference if I use the larger 8K x 8K textures and it has the potential to have 4 times the resolution (IE. much higher LOD with no impact on frame rate) but most users machines will fall over with the 8K x 8K textures. So this is sort of like the features vs. frame rate issue we have been talking about but it is about what level of texture LOD can be supported by the users hardware. It would be nice if the livery system handled this type of thing so the liveries could be delivered in different resolutions and the livery system would pick the correct resolution based on some automated system or on a user setting. If it were user configurable it would allow for some performance tuning based on texture size if this were an issue for a particular hardware setup.

[Jabberwocky]

For the not so deep in ... is there a way to see how many polygons are in a plane-model?

[Johan G]

A very small and neat 3D viewer that can handle .ac files is this one:

http://karelse.home.xs4all.nl/3DViewer/

You can see the number of triangles in the lower right corner.

The alternative is of course using Blender. You will then also see the number of vertices.


You will probably find that the number of polygons have less impact than you would expect. I once flew a model that had really good framerate and a very plausible FDM (CASA C-101 Aviojet). When looking at the model I got quite a shock: It had 10-20 times more polygons than I had expected. In fact it had more polygons than many worse performing aircraft i have tried.

[hvengel]

To amplify the above point. My new 3D model has significantly more (perhaps 4 to 5 times as many) polygons than the one I am replacing and I am seeing, at most, a 1 FPS difference in frame rate that I can attribute to the new 3D model. Fact is that the scenery with clouds and other features will tend to have way MORE polygons than any reasonable aircraft model and modern graphics cards can handle millions of polygons at any given time so the aircraft model's complexity, if with in reason, is only a minor part of what the graphics card has to handle. On modern hardware you don't see much difference in frame rates in an aircraft with 150K polygons than one with 10K if they are otherwise very similar feature wise.

On the other hand older/lower end graphics hardware can be very sensitive to things like texture size and polygon count. Fortunately mid range modern graphics cards are not expensive and it is easy to replace older graphics hardware. For FG with normal resolution monitors (IE. 1920x1200 or less) cards that normally sell in the $100 range will do a decent job and if you wait for a sale you will sometimes find this same hardware for considerably less than $100. The same type of thing is true for much higher end hardware as well. A few months ago a well known on-line hardware vendor had an "open box" special on GTX670 cards for $139 and this class of cards will pretty much handle anything you through at it.

[Gijs]

Just a couple of very simple questions.
1. I have derived a great deal of enjoyment with FS9 and the PMDG 737-800: will Flightgear match these without requiring me to take a degree in software engineering.
2. Can I acquire Flightgear in its entirety on discs - will they load without(also) requiring a degree in software engineering. If you where do I send the money and how much?

I meant to add that I have a W8-64bit PC, top of the range with all sorts of bells and whistles...............

[Hooray]

1) nope, FlightGear's support for airliner/bizjet-style "glass" avionics is only just beginning to emerge thanks to the Canvas system, EFIS modeling (PFD, ND, CDU, EICAS etc) and aircraft systems fidelity is non-existent basically and overall FG avionics are far from anything that you can find in (even outdated versions) of MS FS and X-Plane, which applies even more so to commercial add-ons
2) yes, see the website: http://www.flightgear.org

Some of our best-developed airliners have fairly extensive performance problems, i.e. frame rate / frame spacing - for example, the 777-200. In addition, FG itself (and its FDMs) lacks some hooks to support a real performance database, so that related autoflight (M/CDU) VNAV modes cannot currently be implemented (easily). These are the main showstoppers when it comes to modern airliners and bizjets in FG.

Overall, given your area of interest (and your background/experience with proprietary add-ons), you'll probably not enjoy FG as much as FSX and/or X-Plane for the time being.