Future Proofing FGUK's hangar

12 Nov 2020 11:08 #48775 by Avionyx
Hi All,

A general discussion because I think there's many here with more of an insight than me.
I understand from talking to several people, and seeing the discussions on the Dev list that the newest builds of FG are going to be based on compositor being default.

Does this mean that the default FG config is going to be without support for OSG text?

Are there any other things which those of us who don't fully understand such things might be being replaced any time soon that could have an impact on aircraft currently in our hangar?

It seems a good time to prioritise development for the right things and if stuff is going to be depreciated it'd make sense to work around that first and make sure we don't incorporate any more of it.

Any and all thoughts appreciated.

Alex

Please Log in or Create an account to join the conversation.

12 Nov 2020 12:30 #48777 by enrogue
FWIW my reading of the 'A string of pearls' thread on Flightgear-devel is that some rewrite of osgText will have to happen in Simgear for OSG3.6 support to go ahead fully - who will do it is another matter

On the Compositor/HDR pipeline front I see a possible issue with having to update any aircraft specific effects & shaders - I haven't tried compositor in a while, will have to do an AppImage build

Please Log in or Create an account to join the conversation.

12 Nov 2020 12:57 #48778 by eagle12
For OSG all faces of the mesh must be converted into triangulate faces (quad faces are apparently not supported). If I understand this correctly. I'm not sure.

Please Log in or Create an account to join the conversation.

25 Nov 2020 12:34 - 25 Nov 2020 12:36 #48943 by Richard

eagle12 wrote: For OSG all faces of the mesh must be converted into triangulate

This isn't necessary for any version of OSG that I'm aware of - so don't worry about this one.

Avionyx wrote: the newest builds of FG are going to be based on compositor being default.


There are some big changes coming in the next version, such as
  • Compositor - which is a rework of the rendering pipeline that will give us shadows and lights that illuminate things.
  • Rembrandt is removed because it is obsolete and Compositor is better
  • CompositeViewer - together with Compositor this will allow us to have instruments that render a view (e.g. FLIR); or mirrors, or anything that requires a different view.
  • Ortho Scenery - satellite pictures instead of textures; this will be optional and probably require you to download the photos yourself; or to use a scenery package that someone else has built; i.e. ortho isn't going to be added into terrasync.
  • WS3.0 - which will give us levels of details in the scenery (better performance) but also much better landclass handling and hopefully dynamic airports so we can have upto date airports and navaids
  • OSG3.6 - requires a fix for the text problem;
  • New UI - replacement of PUI with Qt.
  • OpenGL Core Profile / OpenGL 4.2 - Moving away from OpenGL 2.x with its fixed function pipeline is a big change but if it can be done it will work better with Compositor (clustered shading) and gives the possibility of HDR.

The intention is to remain compatible with current models. Taking an example of the OSGText / <text> problem - until a resolution is found we will not be moving to OSG3.6.

There may need to be some aircraft model changes to be able to better use Compositor (such as lights when we get them) and maybe some cases of effects embedded in models needing to be removed or rewritten. Rembrandt support should also be removed from models; as should the non Rembrandt light cones.

Allow a good few months - because at the moment the next branch will be in a state of change - because after an LTS release is when all of the big changes happen.

It would be wise to perform a hangar wide review of each model and fix all of the errors that are reported in the console; so that all models work nicely with 2020.3 LTS.
The following user(s) said Thank You: enrogue, geed

Please Log in or Create an account to join the conversation.

25 Nov 2020 12:56 #48944 by geed
Richard may I ask about the state of change in the audio solution?

Will it still be OpenAL or something different?

It would be nice to be able to model more audio properties by writing XML or nasal or of course C++

If I really will have some free time I will try setting up a VM with a Linux just to be able to compile FG to be able to work on that.

Please Log in or Create an account to join the conversation.

25 Nov 2020 13:57 - 25 Nov 2020 13:58 #48949 by eagle12

It would be wise to perform a hangar wide review of each model and fix all of the errors that are reported in the console; so that all models work nicely with 2020.3 LTS.


That sounds like a lot of work.


What about the custem-scenerys. Are these no longer needed?

I tested today DrawThreadPerContext and CullThreadPerCameraDrawThreadPerContext makes for
me not much difference (only other threads are in use). Of 32 threads, 2 threads are used at 50-60%, the others 30 threads are used at approx. 1-3%.

My question is there will be better hardware usage in the future?

In your opinion, what are the best nvidia settings for current RTX graphics cards (OS is Linux)?

Please Log in or Create an account to join the conversation.

25 Nov 2020 15:22 #48953 by Richard

geed wrote: Will it still be OpenAL or something different?

It would be nice to be able to model more audio properties by writing XML or nasal or of course C++


Erik has previously said something about AeonWave on the devlist list - and problems with cross platform - but I'm not sure what his current thoughts are; it might be worth asking him directly (erik ehofman.com)

If you've got Visual Studio 2017 or 2019 installed then really it is quite easy to setup a Windows build.

Please Log in or Create an account to join the conversation.

25 Nov 2020 15:40 #48954 by Richard

eagle12 wrote: 2 threads are used at 50-60%, the others 30 threads are used at approx. 1-3%.

My question is there will be better hardware usage in the future?


FlightGear is heaviest on the rendering, whether it is CPU or GPU limited. The OSG threading can make a little bit of difference; but really the main problem is that we don't have any levels of detail in the scenery. The lack of LOD means that too much CPU and GPU time is spent processing areas that occupy a small part of the screen - so the first thing that needs to be done is WS3.0.

I've spent the last 3 or 4 years trying to get more performance out of FlightGear; and the conclusion that I've come to is that there is very little to be gained in terms of frame rate from any extra use of the CPU with more threads; and I've proved this by implementing multi-threaded rendering.

Using multi-threaded rendering on the F-15 does result in a slightly higher frame rate because the multi-threading saves around 4ms per frame however the rendering is still taking 18.68ms and that is at a location without that much terrain.



Also I added multithread garbage collection to Nasal and that broke the Shuttle so it is turned off because we could not track down what was going wrong. You can activate this from the property tree and it might reduce frame pauses caused by foreground garbage collection.

In summary I don't think that we'll get any significant FPS improvements from multi-threading anytime soon; avoid buying a CPU that hasn't got excellent single core performance for use with FG.

eagle12 wrote: In your opinion, what are the best nvidia settings for current RTX graphics cards (OS is Linux)?

Sorry but I have no idea about NVidia cards under Linux as I'm running Radeon R9 290 under Windows.
The following user(s) said Thank You: eagle12

Please Log in or Create an account to join the conversation.

25 Nov 2020 20:58 - 25 Nov 2020 21:03 #48957 by eagle12
Thanks for your detailed answer, Richard.

The frame rates are not a problem for my new PC, i.e. it's always smoth even if FG only shows 25-30 FPS. When I fly alone the frame rates jump from 30-60 or fall back from the best value 160-50, but it doesn't matter, even at low frame rates everything is smooth. The only difference is if I fly with flightnight and many aircrafts are on the ground, I get more constant FPS of 30-45 (you can see on the screenshots that I took at Flightnight).

That the frame rates vary is already clear to me, but not such big leaps. I don't have a problem with it either, I just wanted to understand better. And the strange thing is that mostly only 2 threads are used at 50-60% (AMD Ryzen9 3950X). The graphics card is an RTX3080 and this is idle mode at 30 degrees. The RTX3080 warms up to 45 degrees under FG max, but mostly it is 40-41 degrees.

A small comparison of a simple zip file with a size of 1GB, all 32 threads (16 core CPU) are used and the file is unzipped very quickly.
The graphics card is used well under Blender (rendering) so that it is 60-70 degrees warm.

My conclusion is that the FG does not particularly stress the new hardware.
This is not a criticism of FG, I just wanted to understand better how FG works under the hood.
But that's probably a secret.
BTW I like your F-15, but I like a lot of aircraft anyway. I'm crazy.

Please Log in or Create an account to join the conversation.

26 Nov 2020 11:20 #48959 by Richard

eagle12 wrote: My conclusion is that the FG does not particularly stress the new hardware.
This is not a criticism of FG, I just wanted to understand better how FG works under the hood.
But that's probably a secret.


There are no secrets in an open source project; and it's definitely not a secret that FlightGear, OSG and OpenGL don't make good use of lots of cores; that's what Vulkan was designed to fix - but we a long way from moving FlightGear to Vulkan.

Please Log in or Create an account to join the conversation.

26 Nov 2020 11:26 #48960 by Richard
To return to the original topic

We are expecting the next LTS to be at least a year and probably 2 years away; so in this period I think it is reasonable to review and improve each FGUK model ready for the release; but probably don't start this process until Compositor supports illuminating lights.
  1. Remove Rembrandt lights and light cones
  2. Add Compositor lights
  3. Ensure that there are no load errors in the console (bad paths, missing textures, Nasal errors)

The other that we should try to get done is to migrate the FGUK hangar to a Launcher compatible format - as that really helps to get the models installed and manage the update process. All we need to do this is to put all of the models onto a webserver and create an XML catalog. James has offered space on his web server if that helps.

The launcher also supports installing required packages (e.g. the DavePack) - so it might be an idea to make an FGUKPack.

Please Log in or Create an account to join the conversation.

26 Nov 2020 11:49 #48961 by timi
Which property controls this multi-threaded garbage collection?

Please Log in or Create an account to join the conversation.

26 Nov 2020 12:29 - 26 Nov 2020 12:29 #48962 by Richard
/sim/nasal-gc-threaded true
/sim/nasal-gc-threaded-wait false (true will be more reliable but less performant)

Please Log in or Create an account to join the conversation.

26 Nov 2020 12:31 - 26 Nov 2020 12:35 #48963 by timi
Thanks Richard,

I want to see what I can do to get every bit of performance
out of the Raspberry Pi 4B.

Please Log in or Create an account to join the conversation.

26 Nov 2020 13:33 #48964 by eagle12
Aha, Vulkan (API) is the magic word.
I think it belongs to the topic.

Today I flew over New York with the new custom scenery.
Was that a stress test for my PC, not really but apparently for FG. The result was that for the first time I only had 7-10 FPS i.e. it jerked heavily. This time the CPU needed 2-4 threads
approx. 50-80%. The graphics card was bored at 41 degrees.

If I compare that with the new Flight Simulator from Microsoft (see YOUTUBE videos) the performance with an RTX3080 is much better. 60-80 FPS are possible and the buildings are more detailed.

If you give me an answer now, why don't you fly with Microsoft. Then you can put the answer somewhere else.
In the FG forum I read that the (godfather of the developer Sir Thorsten) gave such an answer. he says: If you want all of the cores to be fully utilized, then fly X-plane.
Really a very competent statement!

I would say I have good hardware, but what good does the hardware do if FG gives me 7-10 FPS when I fly over New York. So its time to think.

Please Log in or Create an account to join the conversation.

26 Nov 2020 15:28 #48965 by enrogue
The current development cycle looks to be introducing some interesting new things:

- compositor
- composite-view (think real mirrors)
- world scenery 3 that has LOD & materials defined by a texture draped over the scenery, oh and automagically generated airports
- there was also mention of making the scenegraph more efficient, but tbh I dont understand it well enough

I asked James to email Alex about hosting FGUKs hangar+catalog - I'd be happy to help work on automating the catalog but to be honest at first it can even be manual (it's just xml). I'd love to see FGUK downloadable & update-able from the Qt launcher

Please Log in or Create an account to join the conversation.

26 Nov 2020 16:52 #48966 by Richard
The script that builds the catalogs for FGAddon could be fairly easy to adapt :

sourceforge.net/p/flightgear/fgmeta/ci/next/tree/catalog/

Please Log in or Create an account to join the conversation.

Time to create page: 0.169 seconds
Powered by Kunena Forum

Latest Forum Posts

PM Notifications

You are not logged in.

PM Mailbox

You are not logged in.