Test: 2.10.03 on old hardware

[Bjoern]

Being out of the "actually use Flight Gear" loop for a while, I've taken a spin in 2.10.03.


Hardware:
CoreDuo 1,83 GHz
2GB PC5300 RAM
ATI Mobile X1300 64/128MB
80GB 7200 RPM SATA HDD

Software:
Windows 7 x86 SP1
ATI Catalyst 10.2


Installation was very smooth without hiccups.
Run the installer, run FGRun, set options and off I was (to setting options in-sim).



FlightGear settings:
Screen - 1024*768*32
Refresh rate - locked at 20 Hz
Rembrandt - off*
Shaders - all off**
Point sprites - off
Light scattering - off***
3D clouds - off****
Horizon effect - off
Distance attenuation - off
Fog - fastest
Specularity - off
Random buildings - on, set at 1.5
Random trees - on, set at 1.5
Random objects - on
AI Traffic - on
Multithreading tweak - on*****
Terrasync - off******


Testing conditions:
Area - Hawaii
Airport - PHHL
Aircraft - F-14B, Seneca
Weather - Local, fed by METAR -> clouds 6/8ths in certain areas with precipation


Performance with above settings:
On the runway, cockpit view - 16FPS
Airborne, no clouds - 20 FPS
Airborne, in clouds - 16 FPS
Airborne, in rain - 12-15 FPS


Test session:
After several program launches and exits related to setting everything up and tweaking, I went flying for real.
Assigning joystick controls works really well from the UI, although dead bands and sensitivities have to be edited by hand in the joystick's XML, which can be a bit irritating to the unwary.

I've done a few AI intercepts in the F-14 and the flying was quite nice most of the time.
With the dynamic camera and a 70° FOV, flying was quite immersive and the short cicuit in the Seneca was especially nice to demonstrate that you were flying an unstable, wind sensitive light twin.

Refreshing the weather after an automatic METAR refresh made the sim stutter, but that's quite normal.
Speaking of: Switching from one "local weather" theme to another triggers a "Local weather already active; aborting" warning. You've got to select and apply "METAR based" weather before you can switch to a different local weather theme.
Rain caused graphics glitches, like appearing only left from the model's centerline when rotating the camera 45° left or having a few drops draw in front of the cockpit geometry. I've switched "precipitation" off after that, which helped frames a tad.

The regional texturing looks great and really adds to the landscape, as do the random buildings.
And albeit still having the rough polygon edges, the terrain textures do not blur out like they do in FS9 at low framerates, which is rather nice.

At higher altitudes, I've had problems with missing tiles around my aircraft. From ~30km outward or so, they just didn't render.
I've experienced that in previous (GIT) versions, but I'm not sure if I've unticked one too many checkbox or if you need a shader to render smooth horizon transitions.
Once in a while, there was a missing terrain tile within the otherwise visible range, but it occurred on a rather random basis and seldomly.

At one point, I lost all sound in the sim. I'm not sure what I did to trigger this, but I could not get it back within the current session (exiting and restarting FG would have probably fixed it).

Shortly before touchdown, my framerate went down to 12 and then to 6 combined with heavy stutters. Needless to say that JSBsim couldn't keep up and thus, I slid all across the airport.
Could have been caused by the sound issue mentioned above.

I then called it a flight.


Remarks:
*Rembrandt amazingly worked without graphical glitches, albeit at 5 FPS with every sub-option disabled. Enabling Bloom, Occlusion and shadows (1024, 1 cascade) dragged the framerate down to 2 FPS.

**Enabling any shader incurred at least a 30% hit in performance and made the sim laggy.

***Scattering cut framerate by 50% and introduced a sky straight from a LSD trip.

****3D clouds cut framerate by at least 30% when enabled and set to minimal.

*****Should have kept this off as it seemed to cost 2 or 3 FPS when enabled.

******I've dowloaded the Hawaii tiles manually before going flying.



Conclusions:
- If one can live without the new shader-based eyecandy, Flight Gear offers a FS9-like experience with version 2.10.
- People with similarly incapable hardware and without the need for buildings and trees have a really good flight simulator at their hands.



All in all, I like this release as the regional texturing and random buildings really add to the sim.
Flightgear is maturing really well and once the blockiness of the landscape is alleviated, it will look better than FS9 on my hardware.
So carry on, lads!

[Thorsten]

Speaking of: Switching from one "local weather" theme to another triggers a "Local weather already active; aborting" warning. You've got to select and apply "METAR based" weather before you can switch to a different local weather theme.

No you don't, I've done this a gazillion times and never seen that behaviour. Can you tell us the precise sequence of things you did and how checkboxes were set?

At higher altitudes, I've had problems with missing tiles around my aircraft. From ~30km outward or so, they just didn't render.

Set LOD bare to a higher value in the menu - that's a user-defined setting. Maybe something needs to be done to it though...

*Enabling any shader incurred at least a 30% hit in performance and made the sim laggy.

Well, the GPU isn't exactly *cough* top-notch...

Scattering cut framerate by 50% and introduced a sky straight from a LSD trip.

No idea about the LSD sky, but yeah, doing 220 additional lines of fogging instructions (which is longer than the whole terrain default shader) instead of the original two lines might do just that

Flightgear is maturing really well and once the blockiness of the landscape is alleviated, it will look better than FS9 on my hardware.

Ah - getting rid of that blockiness is not a trivial task, and if we manage to pull it off, it's most likely to be a solution for the top end of the graphics cards. For the hardware you're running here, the is no solution coming or being discussed.

[Hooray]

thanks for taking the time to test FG on old hardware, I have been trying to maintain a list of settings that should work on such hardware, maybe you could briefly check if I missed anything and just add it to the wiki: http://wiki.flightgear.org/Howto:Debugging_extreme_lag

Regarding the performance implications of enabling certain shader-based features, I have to agree that this is to be expected on such old hardware, certain shaders are likely to be emulated and run on the CPU instead ... On the other hand, we do have people who are interested in such benchmarks obviously - and it may actually help us determine which features are statistically relevant, for users using all sorts of different hardware: viewtopic.php?f=6&t=19202

[Bjoern]

No you don't, I've done this a gazillion times and never seen that behaviour. Can you tell us the precise sequence of things you did and how checkboxes were set?

This is a bit inconvienient, as I've already uninstalled FG and I don't have Windows booted up to reinstall and check.

So, from the top of my head, and speaking with rough representations of the options' names:
- Weather dialog
- Select "model after METAR", set "live weather" as source
- Hit "Apply"
- Hit "Okay" to trigger weather loading
- Let weather load
(- Determine that there are too little clouds for your taste)
- Re-open weather dialog
- Select a prefixed weather theme like "middle of cell"
- Click "Okay"
- Cue error message

Note:
Changing options happened within a relatively short amount of time, so it could be that the local weather initialization process wasn't entirely done yet. I've judged from the ceasing stuttering and ceasing popping up of clouds here and there that there was nothing left to do.

Workaround, when "model after METAR" is selected and a change of input METAR i.e. from "live data" to any preset one is desired:
- Select "Interpret METAR directly"
- Hit "Okay"
- Let weather load for a bit
- Reopen "Weather" dialog
- Select "Model after METAR" and the desired METAR source
- Hit "Okay"
- Weather now loads


Also, the error message called for a "local weather reset" or so. Should the above really be a problem and not just an ID10T code, simply adding that "Reset Weather" function to the UI would work.
As would clearing the weather after selecting a new METAR source.

Set LOD bare to a higher value in the menu - that's a user-defined setting. Maybe something needs to be done to it though...

Oh, I thought this was a setting exclusively reserved for objects like terminals, landmark buildings or the like.

I think I've written this before, but a solution based on actual pixel size instead of mere distance might be a more viable solution.
OSG supports LOD switching based on pixel size on-screen*. This scheme is used by MSFS for switching LODs.
AI aircraft for MSFS, for example, have different models compiled into the model file which get switched based on a numerical suffix for the root node.
An A320, for example might contain submodels named "A320_400", "A320_100" and "A320_50". The "_400" LOD model is displayed when the aircraft has a pixel size of at least 400 on-screen, the lower detail "_100" model is displayed between a size of 400 and 100 pixels, the "_50" model between 100 and 50 pixels, etc...
In theory, you could have 20 LOD models contained within the model file to ensure a gradual and smooth increase in detail as the model comes closer into view, albeit at the cost of more development effort (making LOD models can be a challenge in itself).

By using this model switching scheme, MSFS scales pretty well with actual screen resolution which in turn benefits users with smaller monitors (and likely weaker hardware).
A prerequisite for this, however, is that all models actually contain LOD submodels or have a dedicated, LOD supporting AI version available. If you, e.g. use a model made for user space (and thus containing only one, highly detailed LOD model) as AI, that very model is used whenever it is in "AI space", i.e. within a radius of ~80 nm around the player. This means that having a lot of instances of this model lingering around you (at big airports or such) can drag down simualtor performance dramatically.

As for terrain itself, FS9 tends to flatten out elevation features near the horizon based on this LOD scheme. I think this is done by deliberately not drawing every n-th terrain vertex contained within the elevation file. If you, for example, fly around the edges of the alps, you will at best see rolling hills on the horizon instead of the massive peaks you'd expect.
This effect can be toned down in MSFS by implementing dedicated, so called "buffer meshes" as add-ons to high res mesh add-ons, which are, I think, made from rougher source data (e.g. SRTM 120 arc sec) or at least specifically interpolated to give the illusion of higher elevations in the distance.
For FSX, the developers increased the treshhold for terrain LOD switching and thus the "nonexsitant Alps" effect is not as prominent as it is in FS9.


Taking all this into consideration, my take on environment rendering in future FG versions is as follows:
- Derive an effective pixel-based LOD switcing scheme for objects and terrain alike (even consider using it in 3D clouds, but we've covered that before), then have the users add LOD models to as many "environment space" objects (landmarks, airport buildings, AI aircraft) as possible.
- As for the terrain itself, consider the problem drawn out above for LOD based elevation rendering.
- If smoother rendering for landclass polygons (cities, forests or the like) or polylines (coast lines, roads, railway lines, rivers) is to be implemented, the iterative "omit every n-th vertex at pixel size x on screen" scheme could work pretty convincingly.


Settings that could influence LOD switching and thus overall detail could be as follows:

1. A "maximum visibility" setting in meters at which the lowest detail terrain will not be rendered anymore. This is already implemented, although it seems that it is only valid for the skybox.
Suggestion: Make terrain rendering sensitive to this setting and if the treshhold intersects a tile, the tile will still be rendered though to avoid the "holes" I've experienced.
Preferences.xml

2. "Maximum cloud radius" is already implemented, although I'd really love to see a solution that is performance friendly enough to have this setting tied to the general "maximum visibility" setting mentioned above.

3. Fixed LOD treshholds in the Preferences.xml. Similar to the current handling based on distance, but based on pixel size instead in a form among the lines of:
LOD_0=1
LOD_1=10
LOD_2=20
LOD_3=50
No_LOD=200 (<- This is for models not containing any LOD submodels. They'd pop into view with that setting, but it's better than drawing them all the way)

There could be separate entries for objects and terrain.

LOD-sensitive objects would logically be required to have submodels named "LOD_n" to use this.

4. A "LOD" slider in the UI. Basically a multiplier for the treshholds in the Preferences.xml, for quick and dirty adjustments for novice users.



*http://www.openscenegraph.org/documentation/OpenSceneGraphReferenceDocs/a00395.html#26f05cb664bfcda164c1b928629a0bbb

Well, the GPU isn't exactly *cough* top-notch...

Of course not, but I can run other applications using shaders, so this is a bit of a disappointment.

No idea about the LSD sky, but yeah, doing 220 additional lines of fogging instructions (which is longer than the whole terrain default shader) instead of the original two lines might do just that

Interesting effect though.
I wonder if it is an "out of resources" symptom or related to drivers or such.

For a split second and at certain angles though, I could see a properly rendered, light scattered sky. And it looked very beautiful.

Ah - getting rid of that blockiness is not a trivial task, and if we manage to pull it off, it's most likely to be a solution for the top end of the graphics cards. For the hardware you're running here, the is no solution coming or being discussed.

See above.

Granted, it's probably nothing new and has been discussed before, but it could turn out to improve things.

thanks for taking the time to test FG on old hardware, I have been trying to maintain a list of settings that should work on such hardware, maybe you could briefly check if I missed anything and just add it to the wiki: http://wiki.flightgear.org/Howto:Debugging_extreme_lag

Hm. Can I revamp that article a tad, i.e. add more structuring and cross-linking to other articles?

The information itself contained within is okay at a first glance.

Regarding the performance implications of enabling certain shader-based features, I have to agree that this is to be expected on such old hardware, certain shaders are likely to be emulated and run on the CPU instead ... On the other hand, we do have people who are interested in such benchmarks obviously - and it may actually help us determine which features are statistically relevant, for users using all sorts of different hardware: http://flightgear.org/forums/viewtopic.php?f=6&t=19202

This too, could go in the Wiki by extending the "problematic video cards" article and, i.e. mention disabling texture compression for Intel GMA cards on Linux.


I need more tiiiiiiiiiiiiiiime!

[Hooray]

sure, please do feel invited to contribute to the article and it improve it as you wish, but please keep in mind that we tend to direct users to the article who either experience FlightGear crashes, extreme lag or visual artefacts.

[Thorsten]

So, from the top of my head, and speaking with rough representations of the options' names:

Definitely not seeing this here. It smells like a timing issue...

I think I've written this before, but a solution based on actual pixel size instead of mere distance might be a more viable solution.

*shrug* For models, the modern solution seems to be to keep the geometry stage trivial and do all interesting things in the fragment shader - as long as the model is a few pixels (as it will be most of the time) the fragment shader performance just doesn't matter. If you don't need to do fancy stuff in the vertex shader, it can crunch millions of vertices blindingly fast.

For 3d clouds, you're between a rock and a hard place - they're drawn on quads (so we can't cut down vertices) but since they are transparent, they're a serious drain on the fragment shader as well because there's no z-buffer telling you where to stop rendering. So one of the few solutions is to drop sprites - which is what Stuart actually has implemented.

For terrain this is less of an option, because it's always going to fill a large part of the screen. So what we really could need is a good terrain LOD system.

[Bjoern]

sure, please do feel invited to contribute to the article and it improve it as you wish, but please keep in mind that we tend to direct users to the article who either experience FlightGear crashes, extreme lag or visual artefacts.

I've created a wiki account and edited your article. Since it contained too many repetitions in the buildup to the actual settings, I've trimmed, condensed and shuffled it around a bit so that panicking users don't lose patience after a few paragraphs.
The very core of this article, however, has been kept unchanged.

Before that, I've injected all my experience with FG on this hardware into the appropriate articles (especially "settings for slower cards" and "problematic video cards"). I've also posted my tried and proven driver updating procedure for Windows into "about video drivers" to make sure that at least Windows users can rule out video drivers as a culprit.
Also, the article on "$FG_Root" now contains a warning about UAC for users of Windows Vista/7/8.

Definitely not seeing this here. It smells like a timing issue...

Hm. Too impatient then.

For models, the modern solution seems to be to keep the geometry stage trivial and do all interesting things in the fragment shader - as long as the model is a few pixels (as it will be most of the time) the fragment shader performance just doesn't matter. If you don't need to do fancy stuff in the vertex shader, it can crunch millions of vertices blindingly fast.

So the vertex and fragment shaders are capable of LODing models on their own?

Now that would be a step forward.

For 3d clouds, you're between a rock and a hard place - they're drawn on quads (so we can't cut down vertices) but since they are transparent, they're a serious drain on the fragment shader as well because there's no z-buffer telling you where to stop rendering. So one of the few solutions is to drop sprites - which is what Stuart actually has implemented.

Same for MSFS, but funnily enough, they don't affect performance that much. Probably because they're mostly rendered by the CPU and not by the GPU.

For terrain this is less of an option, because it's always going to fill a large part of the screen. So what we really could need is a good terrain LOD system.

This is going to be tough...

[Thorsten]

So the vertex and fragment shaders are capable of LODing models on their own?

Well, sort of. The fragment shader workload always scales with the number of pixels an object occupies on the screen, the vertex shader workload always with the number of vertices of an object.

So if you have flat terrain occupying half the screen which is just a quad, you're most likely better off by doing all the work for the 4 vertices of the terrain quad than for the ~1 million pixels. On the other hand, if you have a half-million vertex model in 20 km distance, you can just see a single pixel of it, and so you're better off doing all the work in the fragment shader for the one pixel rather than doing half a million vertices.

So in essence, by inserting reasonable guesses for typical distances at which we see stuff and for typical vertex spacing, we can get something like a LOD system for models, i.e. a system for which the model rendering workload scales more or less directly with the amount of pixels it has on the screen.

Same for MSFS, but funnily enough, they don't affect performance that much

They seem to be able to render faraway clouds to impostors, something which Stuart has tried, but at least for me never has worked out properly.

[Bjoern]

So in essence, by inserting reasonable guesses for typical distances at which we see stuff and for typical vertex spacing, we can get something like a LOD system for models, i.e. a system for which the model rendering workload scales more or less directly with the amount of pixels it has on the screen.

That's kind of clever. I guess it's already implemented then?

I'm trying to think of suitable applications in terrain rendering, but so far, none of these would look convincing enough.

They seem to be able to render faraway clouds to impostors, something which Stuart has tried, but at least for me never has worked out properly.

Too bad.

Maybe the only thing really helping with 3D clouds is smaller bitmaps...