Nach der in den letzten Tagen öffentlich zutage getragenen Diskussion über die Performance und Lauffähigkeit von Szenerien die ein Orthophoto als Untergrund haben, bin ich einem Wunsch eines Entwicklers nachgekommen und möchte genau zu diesem Thema etwas schreiben und so den Versuch unternehmen zu erklären, wie man durch Anwendung einer bestimmten und im FSX/P3D-SDK dokumentierten Technik es erreicht, dass die Szenerie insgesamt eine stabile Bildlaufzahl und keinen negativen Einfluss auf die Nachladezeiten des Luftbilds hat. Die hier beschriebene Technik knüpft an die VAS-Problematik und die Belastung der CPU/GPU an.
Dabei ist die eingesetzte Technik relativ simpel; anstatt sein Luftbild in ein oder zwei BGL-Dateien zu hinterlegen ist es dringend empfohlen, sein Luftbild in mehrere gleichgroße Kacheln zu unterteilen und dabei hängt die Anzahl der Unterteilungen von der Größe des Luftbild ab, die Größe wird bemessen an der Fläche in Km². Bei relativ kleinen Orthoszenerien, wie z.B. die Insel Lindau im Bodensee, braucht es eher keine Unterteilung!
Das Konzept
Angenommen das Luftbild hat eine Fläche von 40 km² und die Auflösung beträgt 30 cm pro Pixel. Im FSX/P3D-SDK wird die 30 cm-Auflösung als LOD17 bezeichnet. Wir müssen also zunächst unser 40 km² großes Luftbild in gleichgroße Kacheln aufteilen.
Bei dieser 40 km²-Lufbildfläche würden 12 gleichgroße Teile völlig ausreichen. Bei größeren Gebieten kann es ratsam sein die Aufteilung größer zu gestalten, also z.B. 16 oder sogar 20 gleichgroße Teile, damit die einzelnen Kacheln verhältnismäßig "klein" bleiben, was die spätere Bearbeitung, z.B. mit Photoshop, erleichtert. Aber bitte immer bedenken: die Teile sollen durch den Faktor 4 teilbar sein!
Die eigentliche Lösung besteht also darin, das man das Luftbild in eine Anzahl unterteilt, die durch den Faktor 4 teilbar ist. In unserem Beispiel würden wir die 40 km² in 12 gleichgroße Kacheln splitten. Das Splitten kann man sehr gut mit QuantumGis machen, die Erweiterung in QGIS trägt den Namen "gridSplitter", siehe Bilder 1-3.
Bilder 1-3: gridSplitter in QuantumGis, zum Unterteilen von Luftbildern in gleichgroße Kacheln
Jedenfalls hätten wird nach dem Splitten 12 gleichgroße Bild-Dateien, die unsere Basis für das resampeln mit dem Resampel-Tool aus dem FSX/P3D-SDK bilden.
Die INF-Dateien
Um die mit "QGIS-gridSplitter" erzeugten 12 Kacheln zu BGL-Dateien zu machen (resampeln), müssen wir dem Resample-Tool sagen, was das Tool mit den Bilddaten genau machen soll. Hier ein kleines Beispiel, wie der Inhalt so einer INF-Datei aussehen kann:
[Source]
Type = GeoTiff
SourceDir = "."
SourceFile = "edrn_nannhausen_su_x2_y0.tif"
Layer = Imagery
Variation = March,April,May,June,July,August,September,October,November
NullValue = ,,,,0
[Destination]
DestDir = "."
DestBaseFileName = "edrn_nannhausen_lod_17_9"
DestFileType = BGL
LOD = 17
CompressionQuality = 95
Die ersten 12 INF-Dateien jedenfalls beinhalten jeweils 1 Kachel und müssen den Wert "LOD=17" haben. Das wären zusammen 12 INF-Dateien mit LOD17.
Teilt man nun diese 12 INF-Dateien durch den Faktor 4, erhält man als Ergebnis 3. Das bedeutet, dass wir nun 3 INF-Dateien brauchen, die jeweils 4 Kacheln beinhalten und den Wert "LOD=16" haben müssen. Zusammen wären das 3 INF-Dateien mit LOD16.
Abschließend benötigen wir 1 INF-Datei, die alle 12 Kacheln beinhaltet und den Wert "LOD=Auto,15" haben muss. Das Resultat nach dem Resampeln wären also insgesamt 16 BGL-Dateien, siehe Bild 4.
Bild 4: fertig resampelte Luftbilder (BGL-Dateien) der Nannhausen-Szenerie
12 INF-Dateien mit LOD17 = 12 BGL
3 INF-Dateien mit LOD16 = 3 BGL
1 INF-Datei mit LOD7-15 = 1 BGL
Insgesamt hätten wir also 16 BGL-Dateien mit unterschiedlicher Auflösung: 12 BGL-Datein mit LOD17, 3 BGL-Dateien mit LOD16 und 1 BGL-Datei mit LOD7-15. Und genau diese Aufteilung mit unterschiedlichen Auflösungen sorgt dafür, das die Ladezeiten deutlich reduziert werden. Denn es wird immer nur die Kachel in voller Auflösung dargestellt, über der wir uns gerade befinden. Die Kachel hingegen, die am anderen Ende des Luftbild, liegt wird mit einer geringeren Qualität angezeigt. Es ist logisch; dadurch dass das Luftbild nicht in Gänze geladen werden muss, also an einem Stück sozusagen, sondern nur der Teil geladen wird der gerade benötigt ist, erreicht man eine insgesamt verbesserte Performance.
Fazit
Durch die gezielte Anwendung dieser Technik erreicht man
a) ein Ladezeiten optimiertes Luftbild, Stichwort verwaschene Bodentexturen im Sim
b) eine optimale Speicherbelegung des Luftbild, Stichwort VAS-Verbrauch
c) die Verringerung von Latenzzeiten, Stichwort Nachzieheffekt
Es ist natürlich klar, dass das Luftbild nur einen Teil der Gesamtszenerie ausmacht, und erst durch die Anwendung weiterer Optimierungen, wie z.B. der in die Szenerie verbauten 3-D Modelle, kann selbst eine sehr komplexe Szenerie auch auf älteren oder leistungsschwächeren Systemen eine befriedigende Leistung ereicht werden
Das LOD-System
Das oben genannte gilt ebenfalls für Höhendaten (Mesh) und das von der Grafikengine zur Verfügung gestellte LOD-System für 3-D Modelle.
Bei den Texturen der 3-D Modelle ist es das gleiche Prinzip wie beim LOD-System; die Texturen werden erst dann in höchster Auflösung dargestellt werden, wenn man sich nahe am 3-D Modell befindet. Die hier verwendete Technik bei Texturen heißt aber nicht LevelOfDetail, sondern MipMapping, kurz MipMap; das sind ineinander verschachtelte Bilder mit unterschiedlicher Auflösung. Man bezeichnet es auch als Antialiasing-Technik für Texturen. Sie wird in modernen 3D-Grafikchips zur Verbesserung der Bildqualität, aber auch der Geschwindigkeit eingesetzt, siehe Bild 5.
Bild 5: MipMap-Technik bei Texturen
*Zum besseren verständnis sind an diesem Beitrag die 16 INF-Dateien aus dem Nannhausen-Projekt angehängt. Daraus wird sehr schnell ersichtlich wie das mit der Aufteilung gemeint ist