Help! Why is FG so bad?

[hans05]

I use

Blender --> Works for me, not at all too slow to use
Gimp --> Since it has layer-groups I do not see any reason to use PS
Kdenlive --> For the simple tasks I do it works perfectly ok, especially NOT too slow

FG --> Well....

MT in FG I totally agree with you. If I enable it, FG runs MUCH faster than w/o, BUT -as you say- only one core is used to the max and 7 other cores are used to maybe 5-10%. Why that?

My theory: If FG big names focus on clouds, space shuttle and the one millionth new aircraft instead of improving performance and quality of the existing stuff, then this is what we get: nice clouds, one million aircraft but low performance and no shadows....

But if 2018.3.1 IS faster, maybe there is hope (I have not tried it).

[V12]

I solved all problems with FG - flying FSX PMDG 737. No problems with weather discontinuity, unstable fps, shadows, etc. Problem with live weather solved with free FSXWX.

[D-73]

Think of this, Hans. If you buy lets say x-plane, it's gonna be mininum 60$ just for the barebone version and for all that money you dont get many aircrafts, less then 10 if i remember right. Then you are gonna want some more aircrafts and they are gonna cost ya ,alot. Then you wanna scenery and that's gonna cost as well. This can turn into a blackhole for you wallet. A nice simulator im sure but, as it is know for flight simulators, it's a complete money drain.

On the other hand, flightgear is completly free AND if you are interested in programming or modelling, you can contribute as much as you like. And Flightgear can only get better. And no company can say later, hey we are just not gonna support flightgear anymore. Like other sims.

Cheers

[D-ECHO]

D-ECHO has become quiet....

I generally try to only post to topics as long as I have something to contribute and when it comes to the insides of osg, I'm basically out. What I can say though is that if those capable of changing something were unhappy with the current situation, they would change it (time permitting), so either no one is able to do it the way you want or no one wants to, because (like me) they are happy with the current situation (volunteer development - everyone does that what he/she/it wants)

[V12]

FG is not so bad, everybody can make nice flights with FG. But we should not close eyes over many troubles in this sim.

...AND if you are interested in programming or modelling, you can contribute as much as you like.

No, I do not, but I can do something. And did.

...And Flightgear can only get better...

There is 20 years of FG development, but there is not one completed modern airliner. Almost completed, but still not 100% is only IDG 3xx family.

...everyone does that what he/she/it wants...

When I obtain in FG something like this :



Yes, I know, FG has very nice 777 - graphicaly best developed liner, but this thing fly like RC model, not 200 tons airplane

[hans05]

@D-73:

Think of this: One hour of my time is worth 60$ (what I get at work). I already spent 25h+ solving scenery, aircraft, Linux and MT issues. In addition I already spent 80h+ trying to improve the EC665.
Do you really think that for me this is about money?

AND if you are interested in programming or modelling, you can contribute as much as you like.

With regards to programming in the FG-core code, that is almost surely not true! There is the great wall of Curt, Stuart, bugman, Thorsten and some more to get over before being allowed to contribute. That is too big a wall at least for me. From my point of view those guys are so ill minded (observing how they treat many people that try to contribute) that I could not even bother to try to contribute (YES, I AM aware that from their point of view I seem ill minded and that is OK).

Contributing by modeling can maybe be done by doing it like IDG and myself: Do not even try to get into fgaddon!

Ironically I started FG 1.5 years ago in order to evaluate how I could organize a project where my students (I teach programming) and myself can study and contribute to FG. After a VERY short time I had to decide that FG-forum-responsibles care so little about respect for others (at least from my point of view), that I had to cancel the entire idea. What a shame!
I'll find another open source project some day

[123apple]

Not entirely sure why you think that we are not trying to get it into FGADDON - as far as I know it was our intention to put it in once we get v1.0 released.

[hans05]

@123apple:

The development of IDG seems to be ongoing for a while and I never saw a sign of anybody trying to move it (one of the already best developed aircraft) to fgaddon.
So if it IS planned to get there, even better!

[Richard]

For the work in progress I deleted all textures and gave the outside a grey material.
And what do I get in FG? Or rather what do I NOT get? Shadows!
…
indeed I also noticed that high poly does not impact the frame rate too much. I am doing an extremely high poly and had planned to bake a normal map to a low poly copy. But when trying my model in FG I noticed not a single frame rate less than the original low poly that I started from.

So you see that I am REALLY interested in the explanation/solution to the quality issues here.....

1. By shadows I think you mean ambient occlusion. Often this is implemented using SSAO and deferred rendering (Rembrandt) can do this; however the way to do this in FG is I think to make a lightmap (or bake it into a texture). I think DCS uses deferred rendering to do shadows and lightmaps for SSAO. The reason the aircraft in other sims look so good is because they have been created by professional 3d modellers and texture artists using a rendering engine that is developed to work well with these aircraft.

Run time SSAO and shadows both have a runtime performance penalty and at the moment the penalty is high (at least a reduction of 50% in FPS). By baking the AO map using Blender's ray tracing you will get better results; but this is a hard thing to do in Blender as it requires advanced skills to understand how to do this in Blender and how to configure in FG.

My own opinion is that we shouldn't be computing things at runtime that can be more efficiently calculated offline; yes this does increase the burden on modellers and possibly some modellers won't have the skills to do this so it seems that FG should do this because it is easier to have the core engine do something than figure out how to model it. For example the F-15 doesn't have lightmaps on the outside or SSAO because I can't figure out how to do this even after trying multiple times; and I'd like to have a lightmap on the outside so that the vertical tail light worked in ALS and the afterburners lit up the rear section as they do in real life..

2. My testing has shown that high verts and polys has little impact on FPS, but state changes (lots of models, textures or materials) and inefficient Nasal does impact frame rate. I managed to improve the F-15 from around 30fps on my system to almost double that by using these techniques but it took a lot of work.

3. Sometimes performance of FG aircraft suffers because they never get optimised; possibly because FG doesn't really have the tools to be able to identify what is causing a model to have bad performance (FPS).

(shadow boxing is really BAD) and Rembrand is dead and slow.
So still the question is: How do all the other flight simulators do it (so much better than FG)?

Cube maps for shadows are actually a good technique; but again skills are required to get these right.

Real time dynamic shadows are a hard and time expensive thing to do; there are a number of different ways to achieve the required results, and Rembrandt could probably be fixed to work better would require contributor(s) to do this. DCS, P3D and X-Plane can go out and recruit the developers and 3d modellers with the required skills and pay them until it's done, or terminate their employment and find someone who can do it.

IceCodeGL is working on a new rendering engine called compositor that looks promising - but we'll have to wait and see how it turns out.

Biggest problem is multithreading optimalization - I never seen 100% CPU load on my quadcore CPU.

It is unlikely that you'll ever see 100% CPU load from FG whilst we are using OSG and OpenGL to do the rendering as both of these only have limited support for multi-threading. OpenGL is multithreaded and thread safe but it uses locking to do this so generally it is accepted that it is best practice to only have a single rendering thread. Again this might be something that the upcoming VSG may fix in a few years with a move to Vulkan - but we'll have to wait for VSG to be developed first (I just applied to join the VSG development list so I can keep track of developments).

OSG multithreading will basically allow the cull of one camera to be run when the draw of another camera has started. This does provide a performance increase - but only as much as the cull time of the second camera.

OSG was developed, as was FG, before multi-core CPUs were available and few people had multiple CPU's - so threading wasn't really a consideration for performance (and multi-threading adds a lot of complexity that would have been largely a waste of development time back then). Things have changed which is where VSG will hopefully come to our rescue.

The only extra time we can ever realistically expect to get is the amount on the OSG screen stats horizontal bars between the end of the last draw bar and the start of the next frame. This can be about 7ms - which would help but nowhere near as much as a faster dedicated GPU that simply does the drawing faster. I built an experimental multithreaded FG that did the rendering in one thread and the simulation in another and it worked for long enough to prove the concept but only gave me an improvement of a few FPS. This is still something that I'll be working on as I get new ideas and maybe one day it'll be stable enough for production, but at the moment it's stable enough to run for about 5 minutes without the ability to use the mouse or keyboard (as I said it was experimental).

There is 20 years of FG development, but there is not one completed modern airliner. Almost completed, but still not 100% is only IDG 3xx family.

Again this is one of the problems with free software; it's hard to get good 3d modellers, flight model developers and aircraft systems developers. The A320 is coming along nicely and I'm sure the team will eventually get there. The 707 has a good cockpit, but could use some aero work, as could the B777; and both of these would also benefit from aircraft systems developers who understand and can model what the aircraft actually does.

With regards to programming in the FG-core code, that is almost surely not true! There is the great wall of Curt, Stuart, bugman, Thorsten and some more to get over before being allowed to contribute.

This is false. If you want to contribute to the core code build FG from source, make the fixes and submit a pull request and the pull request will be reviewed simply on whether or not it does what it says it does and doesn't negatively impact something else.

The path to becoming a core contributor starts by making changes and submitting pull requests and it has never been in the interests of FG or the intent of the current set of core developers to exclude anyone who has a contribution to make. Just do it right, if you're not sure what right is then discuss on the dev-list and then do it, make it work and submit a pull request.

This is how most opensource developments work; you contribute and one day you will be given core commit access when you don't need to have your contributions reviewed before commit, but usually after committing the other core developers will still check your work.

The forum is also not really that relevant to the core development discussions as these all take place on the dev-list and only a few core developers actually read the forums.

---------------------
[1] SSAO https://sites.google.com/site/perumaal/

[D-73]

@hans
well, you can always fork it.