FlightGear: Grafikeinstellungen gemessen – schön und trotzdem flüssig

Projektziel: FlightGear soll gut aussehen und trotzdem flüssig laufen. Statt nach Gefühl an den Reglern zu drehen, habe ich gemessen: dieselbe Stelle, dieselbe Uhrzeit, nur jeweils eine Einstellung anders, dazu ein Bildschirmfoto. Ergebnis vorweg: Die meisten Grafikeinstellungen kosten kaum Bildrate, weil bei FlightGear fast immer der Prozessor bremst und nicht die Grafikkarte. Eine Startoption, die ich lange benutzt habe, hatte überhaupt keine Wirkung. Und eine versteckte Einstellung bringt mehr als alle anderen zusammen: über dichter Landschaft rund 30 %.

Warum die Grafikkarte selten der Engpass ist

FlightGear erledigt Flugphysik, die Skripte der Flugzeuge (Nasal), das Zeichnen der Cockpit-Anzeigen und die Vorbereitung jedes Bildes überwiegend nacheinander auf einem einzigen Prozessorkern. Erst wenn dieser Kern mit einem Bild fertig ist, hat die Grafikkarte etwas zu tun. Im Task-Manager sieht man das gut: Unter „Leistung → CPU“ mit Rechtsklick auf „Logische Prozessoren“ umschalten. Ein Kern steht fast auf 100 %, die Grafikkarte langweilt sich. Einstellungen, die nur die Grafikkarte belasten (Texturfilter, Kantenglättung), sind deshalb fast gratis. Einstellungen, die mehr Objekte erzeugen (Bäume, Gebäude, Wolken), kosten Prozessorzeit.

Messung 1: Was im Flug abschalten bringt

Im Reiseflug mit Autopilot (Cessna 172, 3500 ft) habe ich nacheinander Schatten, dynamisches Licht, 3D-Wolken und die halbe Detailreichweite abgeschaltet, jeweils 100 Sekunden gemessen, und am Ende alles wieder eingeschaltet:

Die letzte Zeile ist die wichtigste: Mit allen Einstellungen wieder an war die Bildrate fast so hoch wie mit allem aus. Der Anstieg kam also vom Flug selbst (anderes Gelände, fertig geladene Landschaft), nicht von den Einstellungen. Zusammen bringen sie höchstens ein paar Bilder pro Sekunde. Ohne diese Kontrollmessung hätte ich falsch geschlossen, dass Wolken und Licht 6 Bilder pro Sekunde kosten.

Messung 2: Baumdichte und Presets über dem Thüringer Wald

Für den zweiten Test steht die Cessna angehalten über dem Thüringer Wald, jede Variante zeigt also genau dasselbe Bild (Fotos aus 3500 ft). Die Bildrate stammt aus einem zweiten Durchlauf: Start in 5000 ft, Pause lösen, 30 Sekunden geradeaus fliegen und dabei messen.

Die geringere Baumdichte spart nur gut 2 Bilder pro Sekunde und kostet sichtbar Wald. Der Texturfilter 16× kostet gar nichts messbar. Wer wirklich mehr Bildrate braucht, nimmt besser das Preset medium: 6 Bilder pro Sekunde mehr bei einem Bild, das immer noch ordentlich aussieht.

Der größte Hebel: Arbeit auf mehrere Kerne verteilen

FlightGear zeichnet mit OpenSceneGraph. Das kann zwei Arbeitsschritte auf eigene Prozessorkerne legen: das Aussortieren der Objekte, die gerade nicht zu sehen sind („Cull“), und das Abschicken der Zeichenbefehle an die Grafikkarte („Draw“). Die Einstellung dafür steht in fgdata/defaults.xml, ist dort aber auskommentiert. Gemessen an derselben Stelle über dem Thüringer Wald, zweimal wiederholt:

Das sind rund 30 % mehr, und auch die schlechtesten Momente werden besser (kleinster Wert 35 bis 37 statt 20 bis 29 Bilder pro Sekunde). Wie viel es bringt, hängt davon ab, was bremst: Der Modus entlastet das Aussortieren und Zeichnen der Landschaft. Parkend auf der Bahn in Erfurt, je zwei Messungen:

Bei einem Flugzeug, dessen eigene Skripte den Hauptkern auslasten, bringt er dagegen nichts: Mit einer Cessna mit G1000-Glascockpit lag die Bildrate im Reiseflug mit und ohne Mehrkern-Modus gleich (31,5 und 33,0). Eingeschaltet wird der Modus mit einer Startoption:

--prop:/sim/rendering/multithreading-mode=CullThreadPerCameraDrawThreadPerContext

Die Stolperfalle: Das Preset überschreibt die Startoptionen

In meinen Startdateien stand lange --prop:/sim/rendering/vegetation-density=0.6 zusammen mit --graphics-preset=high-quality. Bei der Messung zeigte FlightGear trotzdem eine Baumdichte von 2,0. Offenbar wird das Preset nach den einzelnen --prop-Optionen angewendet und überschreibt sie. Die 0,6 hat also nie gewirkt. Wer einen Wert abweichend vom Preset haben will, lässt --graphics-preset weg und übergibt alle Werte des Presets einzeln (sie stehen in fgdata/Video/high-quality-preset.xml); so hat es in der Messung oben funktioniert. Der Texturfilter (--texture-filtering) wird dagegen übernommen, er gehört nicht zum Preset.

Meine Einstellungen

--graphics-preset=high-quality                  # Schatten, Wasser- und Landschafts-Shader, Kantenglättung 4x,
                                                # Baumdichte 2,0
--texture-filtering=16                          # scharfer Boden auch schräg zum Horizont, kostet nichts
--prop:/sim/rendering/multithreading-mode=CullThreadPerCameraDrawThreadPerContext
                                                # Cull und Draw auf eigenen Kernen: bis ~30 % mehr
--visibility=40000                              # 40 km Sicht
--prop:/sim/rendering/clouds3d-vis-range=40000  # Wolken passend zur Sicht
--disable-ai-traffic                            # kein KI-Verkehr, wenn man ihn nicht braucht

Bei Flugzeugen mit engem Cockpit hilft ein größeres Sichtfeld, zum Beispiel --prop:/sim/view[0]/config/default-field-of-view-deg=90. Das kostet keine Leistung.

Was wirklich hilft

• Andere Programme schließen. Ein Browser mit vielen Tabs belegt Arbeitsspeicher und Prozessor; bei mir waren mit offenem Firefox nur noch 1,2 GB von 15,4 GB frei.
• Das Flugzeug. Aufwendige Glascockpits in Nasal kosten mehr als jede Grafikeinstellung. Dieselbe Cessna lief mit Rundinstrumenten deutlich flüssiger als mit einem G1000.
• Preset medium, wenn es trotzdem nicht reicht.

Fazit

Preset high-quality, Baumdichte so lassen, Texturfilter auf 16 und der Mehrkern-Modus CullThreadPerCameraDrawThreadPerContext: Das sieht gut aus und läuft über dichter Landschaft rund 30 % flüssiger als mit den Standardeinstellungen. Wichtiger als die Grafikregler sind ein freier Prozessor und ein sparsames Flugzeug. Und: Jede Messung braucht eine Gegenprobe, sonst misst man den Flugverlauf statt der Einstellung.