Board index FlightGear Support Graphics

Periodical stuttering (A320-family, FG 2020.3.3)

Graphics issues like: bad framerates, weird colors, OpenGL errors etc. Bad graphics ar usually the result of bad graphics cards or drivers.
Forum rules
In order to help you, we need to know a lot of information. Make sure to include answers to at least the following questions in your initial post.

- what OS (Windows Xp/Vista, Mac etc.) are you running?
- what FlightGear version do you use?
- what graphics card do you have?
- does the problem occur with any aircraft, at any airport?
- is there any output printed to the console (black window)?
- copy&paste your commandline (tick the "Show commandline box on the last page of FGRun or the "Others" section on the Mac launcher).
- please upload a screenshot of the problem.

If you experience FlightGear crashes, please report a bug using the issue tracker (can be also used for feature requests).
To run FlightGear on old computers with bad OpenGL support, please take a look at this wiki article. If you are seeing corrupted/broken textures, please see this article.

Note: If you did not get a reponse, even after 7 days, you may want to check out the FlightGear mailing lists to ask your question there.

Periodical stuttering (A320-family, FG 2020.3.3)

Postby V12 » Sun Nov 29, 2020 6:56 pm

Split off from the topic A320-family development.


I observed periodical stuttering with A320-family Revision 41 in FG 2020.3.3. Check gray line in the graph :

Image

And there are many errors Cannot add listener to tied property
for example /controls[0]/lightning[0]/beacon[0]
and many other properties. I downloaded aircraft from FGADDON.
With for example 737-800YV that stuttering doesn't exist.
Last edited by Johan G on Mon Nov 30, 2020 1:33 pm, edited 1 time in total.
Reason: Split off from the topic "A320-family development".
Fly high, fly fast - fly Concorde !
User avatar
V12
 
Posts: 2200
Joined: Thu Jan 12, 2017 4:27 pm
Location: LZIB
Callsign: BAWV12

Re: A320-family development

Postby V12 » Sun Nov 29, 2020 8:35 pm

I investigated bit more and found :
In multithreaded mode (--prop:/sim/rendering/multithreading-mode=CullThreadPerCameraDrawThreadPerContext) is stuttering more visible, route LOWI-EDDF :

Image

Cold'n dark state, stuttering is here but in other style : :

Image

Ready to taxi state, MCDU not initialized, no flight plan :

Image

With UFO stuttering is not present.
Last edited by V12 on Sun Nov 29, 2020 8:47 pm, edited 1 time in total.
Fly high, fly fast - fly Concorde !
User avatar
V12
 
Posts: 2200
Joined: Thu Jan 12, 2017 4:27 pm
Location: LZIB
Callsign: BAWV12

Re: A320-family development

Postby Hooray » Sun Nov 29, 2020 8:43 pm

If you want to start making useful postings, consider to do as people have told you: use the 1) OSG stats, 2) draw masks/LOD ranges, 3) performance monitor and 4) debug.benchmark/built-in profiler.

Otherwise, I am afraid that what you are currently doing isn't exactly helpful.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12157
Joined: Tue Mar 25, 2008 8:40 am

Re: A320-family development

Postby merspieler » Sun Nov 29, 2020 9:06 pm

Hm... not sure if it's an A320 issue... I've been running some OpenGL based monitoring(mangohud) and there even the UFO has that stuttering.
Also notice your Framtime/fps...
With an even frame rate (no stuttering) your frametime should almost match 1000/$fps ... which isn't your case.

Code: Select all
Screenshot      FPS     Frametime IS    Frametime SHOULD
1               35      77              29
2               49      46              20
3               58      38              17
4               53      54              19


So as you can see, your frametimes are consistenly at least twice at high as they should be on an even frame rate.
In other words, one frame is rendered at half your "fps" or lower, resulting in stuttering.

This happens usually cause your CPU can't execute the draw call quick enough ->CPU bottleneck.

I know, that my system is heavily CPU bottlenecked...
In my case (only tested cold and dark) In multithreaded mode (--prop:/sim/rendering/multithreading-mode=CullThreadPerCameraDrawThreadPerContext) the frame times where better and more consistent.
If everything is going against you, keep in mind that airplanes take off against the wind, not with it.
merspieler
 
Posts: 878
Joined: Thu Oct 26, 2017 10:43 am
Location: Wish to be in YBCS
Callsign: JST935. ORI1711
IRC name: merspieler
Version: next
OS: Debian Bullseye

Re: A320-family development

Postby Hooray » Sun Nov 29, 2020 9:13 pm

There's a minimal statup profile detailed in the wiki to help come up with a "baseline" for their system: http://wiki.flightgear.org/Fgfsrc#Using ... _debugging

It's a good idea to disable terrain/scenery altogether and use other draw-masks, and then incrementally re-add features while monitoring frame spacing/rate, and if necessary the OSG stats and/or the built-in performance monitor.

It would also be possible to use a shell script and tinker with different startup/runtime settings while running a profiler or even just while logging frame rate/frame spacing to disk, while replaying a fgtape file with different rendering/environmental settings.

To exclude Nasal from the list of potential culprits, it would also be possible to patch fgfs and disable Nasal/Canvas entirely: http://wiki.flightgear.org/Howto:Disable_Nasal_entirely
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12157
Joined: Tue Mar 25, 2008 8:40 am

Re: A320-family development

Postby V12 » Sun Nov 29, 2020 9:26 pm

... or frametime or fps is not displayed correctly...
I observed that inconsistency. Because 1/35 is 29 miliseconds, frametime can't be 77 ms at that fps. Ryzen 7 CPU specific problem ?
I remember era, when I can't use Clipper compiler on AMD K6 CPU, because some timer events was unmeassurable for Clipper and result was division by zero error...
Fly high, fly fast - fly Concorde !
User avatar
V12
 
Posts: 2200
Joined: Thu Jan 12, 2017 4:27 pm
Location: LZIB
Callsign: BAWV12

Re: A320-family development

Postby Hooray » Sun Nov 29, 2020 9:29 pm

http://wiki.flightgear.org/OSG_on_screen_stats
Being CPU and draw limited means the yellow bar is long. And the blue one grows when cull happens to be a problem.

A simple help is to switch on the onscreen stats in the viewer or flightgear and see if the yellow bar is longer than the orange one. A yellow bar longer than the orange one means that the cpu is not able to saturate the gpu.

Again, beware this does in no way mean that you should write complicated shaders to saturate the gpu! This rather means that the geometry setup/state change time - the yellow one - must decrease!

Once your orange bar is longer than the yellow one, you can start to care for the shaders and their execution. When thinking about shaders, keep in mind that different GPU's perform very different on the same shader.

How to achieve that is a very long chain of right decisions. Starting with the modeler:

Avoid having leaf geometry with very small parts. Collapse as much triangles as sensible for culling into the same leaf geometry. Sure if geometry needs a different texture or anything that requires a different OpenGL state you cannot collapse this into the same leaf. May be it makes sense then to collapse the textures into a common one. Then you might be able to collapse more geometry.

Avoid animations that are not really required. If you need a transform node in between some geometry, the geometry below the transform needs to be drawn seperate which takes time on the cpu. Everything that needs geometry to be drawn seperately should be avoided to that level where it stops to make sense because of culling.

May be introduce some level of detail. Not just avoid the whole model in some distance, but also provide a static model without animations, simple geometry for the mid range. May be provide some more culling friendly and detaild with the animations you need for the short range.

Keep in mind that culling a model that you are close to should make you split the model into more parts that could possibly be culled away. But for culling a far away model is probably very sufficient to cull it either as a whole or not.

Avoid state changes. Use as much common state as possible. Osg does a good job in sorting together draws using the same state, but if the overall scene contains plenty of different state osg cannot change that.A new texture is a new state for example. A new shader is a new state. ....

Once your orange bar is longer than the yellow one, you can start to care for the shaders and their execution. When thinking about shaders, keep in mind that different GPU's perform very different on the same shader.

Appart from OpenGL we spend a lot of time in scenegraph traversal. This is mostly due to plenty of structural and often needless nodes in the scenegraph. The reason or this is that historically the xml files did some implicit grouping for *every* animation in the xml file. To make that reilably work Mathias had to introduce a huge amount of group nodes in the xml file loader. These really hurt today as they introduce a whole lot of group nodes that just have a single child which need to be traversed for update and for cull.

There's also the long-term plan to flatten the LOD quadtrees and transforms of the tiles. Each tile will get some top-level LOD groups for all objects (shared and static). I'm hoping in combination with the LOD-scale function in OSG, this will mean we can automatically drop random tress / building and STG objects to keep frame-rate up. (as an optional mode of course!) - we hope to simply get less tiles and models present by a better lod structure.

The trick is to minimize the number of LOD nodes introduced into the scene graph while avoiding popping effects - flattening the transforms is good to do. But some of them are critical to stay like the are or at least similar. The first one that positions objects with respect to the earth centered coordinate system for precision reasons. Also these coordinate systems coudl for drawing reasons aligned in any direction. But as long as we do simulations using the same tree and geometry alignments that we do for draw this still interferes with the bounding volumes we have for ground intersections. And this axis aligned bounding box implementation gains a lot by having the boxes horizontally aligned. Todays transforms are done so that huger things are aligned with the horizont which serves this purpose.

In FGViewer there's a PagedLOD whole world database tree running. This is similar to osg's marble dataset but carefully designed around our tile structure. Using this I think we can really replace a lot of our fine structured scenery tiles with something more croase that is used for tiles more far away. Drawback with our current codebase: Our integration of the particle systems need to be rethought as this contains geometry with culling disabled which makes a pagedlod just never expire. Switching the particle systems off works pretty good so far.

Another goal is to add more node bits (and a GUI dialog to control them) so various categories of objects can be disabled during the update pass. This will mean the direct hit of, say, AI models vs particles vs random trees can be measured. Of course it won't account for resources (memory, textures) burned by such things, but would still help different people identify slowness on their setups.

Profiling shows that Group::traverse is the most used function in flightgear. The lowest hanging fruit could be to optimize away the redundant nodes from the top level model that gets loaded by a database pager request. We cannot do that recursively once a model part is loaded since the mentioned grouping nodes might be referenced in any level in the model hierarchy above the currently loaded model. So only the top level model could do this without braking tons of models.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12157
Joined: Tue Mar 25, 2008 8:40 am

Re: A320-family development

Postby merspieler » Sun Nov 29, 2020 9:40 pm

V12 wrote in Sun Nov 29, 2020 9:26 pm:... or frametime or fps is not displayed correctly...
I observed that inconsistency. Because 1/35 is 29 miliseconds, frametime can't be 77 ms at that fps.


It can be... as the frame time is the highest value a frame took.
Simple example.
You run at 60 fps.
But frame time shows 30ms
This means, that one frame took 30ms while others took less than 16.67ms (1000/60) but you still got 60 frames in that one second.
fps has a rather low sampeling rate (1 second) and is since not the best measurement of a smooth experience.
It doesn't tell you how the frames are distributed over that one second... 16.67ms -> uniform distribution.
They can also be like 59 frames in 0.5 seconds and the last frame takes the other half second.... that'd be sill 60 fps.
If everything is going against you, keep in mind that airplanes take off against the wind, not with it.
merspieler
 
Posts: 878
Joined: Thu Oct 26, 2017 10:43 am
Location: Wish to be in YBCS
Callsign: JST935. ORI1711
IRC name: merspieler
Version: next
OS: Debian Bullseye

Re: A320-family development

Postby V12 » Sun Nov 29, 2020 10:24 pm

OK. possible. Thx for explanation. Here is UFO screenshot - there is not any periodic stuttering :

Image
Fly high, fly fast - fly Concorde !
User avatar
V12
 
Posts: 2200
Joined: Thu Jan 12, 2017 4:27 pm
Location: LZIB
Callsign: BAWV12

Re: A320-family development

Postby Octal450 » Sun Nov 29, 2020 10:46 pm

Alot of the problem is legacy code that needs to be rewritten. The cleanup of that should gain huge FPS. I'm currently busy with the new flight model so I don't look into it .

Kind Regards,
Josh
Skillset: JSBsim, Systems, Canvas, Autoflight/Control Systems, Basic Animations
Aircraft: MD-11 (Mainly), A320-family, MD-80, Contribs in a few others

Octal450's Hangar|Launcher Catalog
|MD Dev Discord|Airbus Dev Discord
User avatar
Octal450
 
Posts: 4862
Joined: Tue Oct 06, 2015 12:51 pm
Callsign: WTF411/Octal
Version: next
OS: Windows 7/10 x64

Re: A320-family development

Postby merspieler » Sun Nov 29, 2020 10:48 pm

Well.... as I said, I know my system is prone to CPU bottlenecking... you said you've got an Ryzen 7 which is way better than why I have so you might not be bottlenecking on the ufo.
All I can say is, that I do.

I use https://github.com/flightlessmango/MangoHud which gets it's data from OpenGL.
With it, you can record your fps and frametimes and it even shows you the slowest 1% and 0.1% of frames after you stop recording...
You'll be surpprised, now slow some few frames actually are.
If everything is going against you, keep in mind that airplanes take off against the wind, not with it.
merspieler
 
Posts: 878
Joined: Thu Oct 26, 2017 10:43 am
Location: Wish to be in YBCS
Callsign: JST935. ORI1711
IRC name: merspieler
Version: next
OS: Debian Bullseye

Re: Periodical stuttering (A320-family, FG 2020.3.3)

Postby Johan G » Mon Nov 30, 2020 1:41 pm

On my new machine (see my profile), I have noted some stuttering. A common tip I have seen now and then to alleviate that is to throttle the frame rate (Main Menu > View > Rendering Options > enable Throttle frame rate and set the frame rate). For me that will give no stuttering and a smooth frame rate. Even though the frame rate drops a little in for example Paris, there was still very little or no stuttering.
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 6227
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

Re: A320-family development

Postby legoboyvdlp » Mon Nov 30, 2020 6:44 pm

Octal450 wrote in Sun Nov 29, 2020 10:46 pm:Alot of the problem is legacy code that needs to be rewritten.



Actually, I've already done a fair bit (about 70%) of this ... !
User avatar
legoboyvdlp
 
Posts: 7859
Joined: Sat Jul 26, 2014 1:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

Re: Periodical stuttering (A320-family, FG 2020.3.3)

Postby Hooray » Mon Nov 30, 2020 6:48 pm

merspieler wrote in Sun Nov 29, 2020 10:48 pm:Well.... as I said, I know my system is prone to CPU bottlenecking... you said you've got an Ryzen 7 which is way better than why I have so you might not be bottlenecking on the ufo.
All I can say is, that I do.


You should not be mixing up different things here - you are not "bottlenecking on the ufo", but on everything else that you have enabled (scenery, terrain, effects) - the ufo can be rendered even by 20+ year old hardware while providing several hundreds fps.

Do yourself a favor and check out the "draw masks" feature to see for yourself. If that has no impact, you clearly have a very different problem, but it won't have to do with a 3D model like the ufo/ogel/santa etc

note that you can also run fgviewer/osgviewer in standalone mode to see for yourself
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12157
Joined: Tue Mar 25, 2008 8:40 am

Re: Periodical stuttering (A320-family, FG 2020.3.3)

Postby CaptB » Mon Nov 30, 2020 7:21 pm

The flightdeck is far from optimized and has at least several uneccessary elements/objects producing additional draw calls that could be combined into one. This will take place as some improvement efforts continue. Not sure if it has enough of an impact to cause stuttering.
Ongoing projects(3D modelling): A320, MD-11, A350, B767
FG767: https://fg767.wordpress.com/
CaptB
 
Posts: 637
Joined: Thu May 23, 2013 6:36 pm
Callsign: EKCH_AP
IRC name: CAPTB
Version: 2020.1.1
OS: Xubuntu 20.04

Next

Return to Graphics

Who is online

Users browsing this forum: No registered users and 1 guest