There was a nice 3 page review of Flightgear in linux-magazine [1] a bit over a week ago (had a look at news google news results). It's a thorough and helpful type of article.
It was seemingly reviewed by an experienced opensource/linux person, one Peter Kreusser, that knew where to find information in FOSS projects and was reasonably technical - so he would fare better than the average newcomer in solving problems and avoiding misconceptions about FG. He doesn't appear to be someone with a huge flight simulation interest / knowledge at this point, and the fairly thorough article was part aimed at gaming ...
Two things:
1. The reviewer went from 16FPS to 50FPS [2] while flying the F-15 by manually setting the OSG multi-threading model on Linux to:
--prop:/sim/rendering/multithreading-mode=DrawThreadPerContext
This was on a system with a AMD Ryzen 1800X CPU and AMD 580RX GPU, single monitor at 2540x1440.
Is there a problem with automatic threading model selection that doesn't pick the least CPU bound option for a system / aircraft - maybe even on Linux and/or Ryzen specifically? I've seen this issue mentioned several times here and there, and I'll open an issue on Sourceforge if there's no reason why I shouldn't
2. He had this [3] to say as the concluding sentence
But you should not expect models, especially jets, to feel exactly like they do in reality, since the flight dynamics model is obviously too simple for that. The commercial X-Plane [7] flight simulator, which is also available for Linux, offers an alternative for this purpose
"the flight dynamics model is obviously too simple for that". Obviously? How? Question is, where does he get that impression? Is it from asking a friend he knows that he takes advice on flight sim from perpetuating a misconception from the community of another casual sim? From having seen such a misconception on another review? From a throwaway marketing line by xp about being more accurate than other sims? From some bug?
Once of the reasons for FG was interests of commercial sims not aligning with realism, FG started with NASA's LARCSim if I understand correctly before developing JSBSim (?) - so there shouldn't have really been a time when FG's FDM engine was less capable than fs-x let alone x-p's approach. Makes it intriguing as to how that misconception came about
This is a person writing for a FOSS magazine, with a understanding and respect of opensource. So it's a genuine misconception, not done intentionally .
JSBSim was used to create a measuring stick for future FDM engines by NASA a long time ago [4]. The F15 in particular has windtunnel data available.
"[X-Plane]...offers an alternative for this purpose". "This purpose" being accuracy of Jet simulation. This is also untrue. X-P uses a blade element approximation originating from analysis of incompressible fluids that starts breaking down at faster speeds for compressible fluids, and has a singularity (from a division by zero) when any air flowing over any part is at the speed of sound including tips of rotors (transonic regime which happens at speeds well below Mach 1 depending on craft geometry). Similar to YaSim x-p FDM looks at elements of wings ignoring the effect on flow over other lifting surfaces downstream which can be the main wing in canard configurations, and even over parts of the wing.
That makes the JSBSim approach conceptually better. The weaknesses of the x-p approach becomes worse at faster speeds, let alone at supersonic speeds for jets like the F15. If anything jets are a weakness of x-p.
X-P's own page on aerodynamics (mainly there to do an x-p vs outdated fs-x comparison it seems)
x-plane.com/desktop/how-x-plane-works/ wrote:Compressible flow effects are considered using Prandtl-Glauert, but transonic effects are not simulated other than an empirical mach-divergent drag increase. In supersonic flight, the airfoil is considered to be a diamond shape with the appropriate thickness ratio; pressures behind the shock waves are found on each of the plates in the diamond-shaped airfoil and summed to give the total pressures on the foil element.
That is, the approximation becomes invalid when airflow over any part reaches the speed of sound or faster, and they have to fudge it.
See https://en.wikipedia.org/wiki/Prandtl%E ... ingularity . There isn't a way to input more detailed CFD and/or windtunnel data.
Of course, this type of approach is commercially the most efficient in producing the most DLC revenue, and x-p has seemingly not gotten large enough to have the ability to support both (success with xp 11 is in the last 2-3 years).
There are some other things in the linux-magazine article that could be tweaked/corrected
I had a quick look at google news search results in the last few months for "flightgear" to see for other articles that may perpetuate misconceptions. Didn't find anything apparent
Closest was this [5]
Overall reasonable, but it mentions the X-P demo and repeats their claims with lots of adjectives "… not a game, but an engineering tool that can be used to predict the flying qualities of fixed- and rotary-wing aircraft with incredible accuracy ( x-plane.com/desktop/meet_x-plane/ )”
At the same time the article doesn't mention or know anything about FGs capabilities. It also will not have found the details on x-p or have the background to understand weaknesses. The digitaltrends article does a good job of making it clear that it's a claim, not fact, but putting those adjective filled marketing next to descriptions of other efforts that don't do that will make the casual reader get a wrong impression.
The problem here is that the linux-magazine article will be around for years, and the concluding sentence will help create an ambient impression of FG's FDM engine being inaccurate / WiP. Meaning there will be newcomers with a wrong assumptions being quick to blame FG for problems or being frustrating - people writing articles may also carry on the bad impression.
It may help for a dev "officially" related to the project to ask for a formal correction to the linux-magazine article - can point to references in the wiki edit I did.
In general this type of situation could be partially sidestepped by updating the very outofdate info on parts of the homepage - the most official source. The most sustainable way to do that may(?) be to find some way to have an automated (low-level?) script copy basic text, links, and images with restricted formatting from a (locked) wiki page to parts of the flightgear.org homepage. The content of the wiki article proposal [4] I did could be a placeholder starting point as that sort of gives an (extremely) high level overview with references even if the language is a bit technical/short - there are also enough screenshots uploaded to illustrate.
Kind regards