hans05 wrote: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).
hans05 wrote:(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.
V12 wrote: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).
V12 wrote: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.
hans05 wrote: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/