Mesh und Landclass in der X-Plane-Welt

Heute darf ich Euch einen sehr interessanten Gastbeitrag von Andras Fabian, Entwickler für X-Plane, präsentieren. Er schreibt: “Angeregt durch den sehr interessanten und informativen Artikel von Holger zur Einführung in die Welt der Landklassen möchte ich an dieser Stelle die Initiative ergreifen, und den Blickwinkel gleich noch mal ein gutes Stück in die X-Plane Welt erweitern.”

Den sehr lesenswerten Artikel findet Ihr im erweiterten Textteil.

Angeregt durch den sehr interessanten und informativen Artikel von Holger zur Einführung in die Welt der Landklassen möchte ich an dieser Stelle die Initiative ergreifen, und den Blickwinkel gleich noch mal ein gutes Stück in die X-Plane Welt erweitern. Dies tue ich in meiner mittlerweile langjährigen Funktion als „freischaffender“ Scenery-Mitentwickler bei Laminar Research (der Firma hinter X-Plane), als „Herausgeber“ der verschiedenen, freien Landschafts-Szenerien auf www.alpilotx.net (die alle quasi auch in Synergie mit der ersten Rolle entstanden / entstehen) und auch als jemand, der vor langer Zeit interessiert in der MSFS Welt unterwegs war (und daher bis heute gerne auch die Technik auf der „anderen Seite“ verfolge).

Anmerkung: weitere Details zu meinem Hintergrund möchte ich hier ersparen, verweise aber gerne auf ein englisches Interview mit flightsim.com:

 

Der grundlegende Unterschied von MSFS und X-Plane

Wie bereits an der Überschrift ersichtlich, möchte ich ein wenig weiter ausholen (als nur pur über Landclass zu schreiben), da zum Verständnis der Scenery Grundlagen in X-Plane ein paar zusätzliche Zeilen nicht schaden können. Dies ist deshalb sehr wichtig, da zwischen der MSFS und X-Plane zumindest ein recht grundlegender Unterschied besteht, welcher die Struktur der Scenery Daten stark beeinflusst.

Definition Mesh: ein komplexes Gitternetz, bestehend aus einer großen Anzahl von Dreiecken, welche die Grafikkarte mit zahlreichen Texturen versieht um damit eine möglichst glaubwürdige Darstellung einer Landschaft zu erreichen. Die Texturen können generisch (Landclass bestimmt) sein oder aber auch Fototexturen.

Sehr vereinfacht (im Detail steckt natürlich viel vom Teufel) kann man sagen, dass MSFS die Scenerydaten näher an der Rohform vorhält (also die Höhendaten, Landclass Daten etc.), und diese zur Laufzeit in ein Mesh umwandelt (gewisserweise interpretiert), welche eine Grafikkarte dann versteht und visualisieren kann.

X-Plane hingegen erwartet in seiner Scenery deutlich mehr vorbereitete / vor-interpretierte Daten die es ohne viele Umwege an die Grafikkarte weiterreichen kann.

Beide Ansätze haben ihre Vor- und Nachteile. Der MSFS Ansatz hat den Vorteil, dass es bis zu einem gewissen Grad einfacher ist, die ganzen Rohdaten zu verändern (weil diese nah an ihrer Rohform in der Scenery vorliegen) und dadurch das Leben der Entwickler deutlich einfacher sein kann … aber eben auch zu dem Preis, dass man in vielen Punkten dann der „Interpretation“ dieser Daten durch MSFS „ausgeliefert“ ist (bzw. der MSFS nicht unendlich Zeit beim Laden der Scenery aufwenden kann, um seine „Interpretation“ zu verbessern – sonst wartet der User ewig).

X-Plane hingegen verschiebt die Arbeit zum Entwickler, der (oder zumindest dessen Tools!) viel Aufwand treiben muss, um im Vorfeld das Mesh und die Daten in eine Form zu bringen, welche dann aber nicht mehr viel Interpretation seitens des Simulators bedarf.

Da kann also die Interpretation / Vorberechnung / Optimierung der Rohdaten für eine 1×1 Grad Scenery Kachel (die X-Plane üblich Grundeinheit bei Scenery) auch mal eine Stunde dauern, denn der User bekommt davon nichts mehr mit (die fertigen Daten werden „nur“ noch geladen und los gehts). Der Preis ist aber eben, dass diese Mesh Erstellung einiges an Algorithmen benötigt und auch die nachträgliche Änderung des Meshes sehr umständlich ist (bzw. kaum mehr möglich mangels entsprechender Tools).

Wie weiter oben angedeutet, ist das natürlich sehr vereinfachend, da auch X-Plane in einigen Bereichen (z.B. beim Straßennetz) recht viel Interpretationsarbeit leistet, aber zumindest beim Mesh (worum es hier bevorzugt geht) stimmt die Anfangsaussage.

 

Das Mesh entsteht

Wie im vorherigen Ansatz angedeutet, muss das Mesh bereits im Vorfeld komplett erstellt werden, so wie es X-Plane anschließend darstellt. Dies kann man theoretisch mit beliebigen Tools machen, allerdings existiert in der X-Plane Welt von dritten Entwicklern in dem Bereich sehr wenig (hauptsächlich im Bereich der Fototexturen). Bei Laminar Research hingegen wird ein über lange Jahre entwickeltes, internes Tool verwendet (welches zwar Open Source ist, aber aufgrund der Ausrichtung extrem komplex und kaum dokumentiert ist – da es ja nie für Dritte gedacht war). Dieses wird einfach nur „RenderFarm“ genannt – man sollte in den Namen nicht zu viel rein interpretiern.

RenderFarm übernimmt im Prinzip den Großteil der Interpretation der verschiedenen, passend aufbereiteten Rohdaten (Höhendaten, Vektordaten über Gewässer / Straßen etc., Klimadaten, Landclass Daten etc.) und deren Umwandlung (anhand komplexer, aber auch extrem weit anpassbaren Regelwerken) in das Mesh (bzw. weiteren Scenery Elemente wie Straßennetze, Waldpolygone, Autogen Zonen etc. – aber die jetzt nicht das Thema der Abhandlung hier sind) für X-Plane.

Extrem vereinfacht (!) könnte man sagen, dass die grundlegende Mesh-/Dreiecksstruktur primär von zwei Faktoren bestimmt wird: von den Höhendaten und den ganzen Vektordaten (Polygone) der Gewässer. Ja, richtig, auch die Gewässer spielen hier eine wichtige Rolle, da sie bis heute auch „einfach“ nur direkt als ein Teil des Meshes dargestellt werde (Wasser ist bei X-Plane auch „nur“ eine spezielle Form von Bodentexturierung – also kein überlagertes Element).

Also nehmen wir ein sehr vereinfachtes – nicht reales – Beispiel, bei dem folgende Rohdaten vorliegen (gut zu erkennen die grauen Höhendaten in Raster Form, und die blauen Gewässer als Vektordaten):

Im ersten Schritt werden diese Daten in ein Dreiecksgitternetz umgewandelt, welches primär den folgenden (wieder sehr vereinfachten!) Regeln folgt:

• im Flachland, wo das Gelände sich wenig verändert, werden weniger, größere Dreiecke benutzt, hingegen im Gebirge, mit vielen kleinräumigen Änderungen, werden kleinere (feiner auflösende) Dreiecke benutzt.
• Gewässer werden intern mit möglichst wenigen großen Dreiecken abgebildet (sind sie ja doch für gewöhnlich recht flach), aber die Ufer (definiert durch die Vektordaten) werden möglichst exakt abgebildet (wegen dieser Regel setzt RenderFarm meist in einer Vorstufe noch eine „sanfte“ Vektorsimplifizierung an, um eine extreme Explosion der Dreieckszahlen entlang der Küsten zu vermeiden).

Das Ergebnis könnte dann (wir bleiben durchgängig beim vorher begonnen Beispiel) in Etwa so aussehen (das ist eine schematische Zeichnung von mir, und stammt NICHT direkt von den RenderFarm Algorithmen!). … im „Hintergrund“ habe ich noch andeutungsweise die Rohdaten gelassen:

Bei dem Anblick des erstellten Dreiecksgitters dürfte sofort auffallen, dass bei X-Plane für gewöhnlich (auf jeden Fall bei der default Global Scenery oder der von mir erstellten HD Mesh Scenery) ein „irregular mesh“ (sprich, ein unregelmäßiges Dreiecksgitter) zum Einsatz kommt (was auch im Kontrast des – meines Wissens – für gewöhnlich regulären Gitters von MSFS steht).

 

Landclass kommt ins Spiel

Aber ohne Texturen ist das Dreiecksgitter nicht viel wert – und das ist der Punkt wo, wie zu erwarten war, die Landclass Informationen ins Spiel kommen.

Landclass Rohdaten sind in der X-Plane-Welt üblicherweise Rasterdaten mit verschiedener Auflösung (meistens von 30m bis 300m) und stammen aus zahlreichen, oft recht unterschiedlichen Quellen (meistens von staatlichen / überregionalen Organisationen oder Forschungseinrichtungen). Auch bei X-Plane ist es deren Aufgabe, für eine bestimmte Bodenfläche eine generalisierte Beschreibung / Klassifizierung der Bodenbedeckung/Bodennutzung (land cover / land use) zu liefern, um möglichst geeignete Texturen auf die Dreiecke des meshs „kleben“ zu können. Und auch bei X-plane ist das Ziel, durch den geeigneten Einsatz und der Variation der Bodentexturen eine möglichst realitätsnahe, aber zumindest plausible (ist ein wichtiges Stichwort bei Laminar Research), Darstellung der Welt zu bekommen.

Als Beispiel – wieder stark vereinfacht – könnten die raster Landclass Information für unser Gebiet folgendermaßen aussehen:

Man sieht die grobe Darstellung des Wassers (erscheint meistens auch in den Landclass Daten, aber zu grob, um direkt davon Gewässer ableiten zu können), Wälder (dunkelgrün), dünne Gebirgsvegetation (braun), Grasflächen (hell grün), Ackerland (gelb) und eine Ortschaft (rot).

Nun könnte man meinen, dass man einfach jedem Dreieck in der Mesh den Typ (bzw. die dazu passende Textur) des nächstgelegenen Landclass-Wertes zuordnen kann. Aber ganz so einfach macht es sich X-Plane aus mehreren Gründen nicht. Erstens wäre es auch für die Grafikengine recht ineffizient, jedes Dreieck einzeln abzuhandeln, und zweitens hätte man somit an den Grenzen wo ein Landclass-Typ-Wechsel stattfindet, auch harte Texturübergängen (was die Optik sehr stören würde).
Aus diesem Grund macht die RenderFarm zwei wichtige Dinge:

• Es versucht, möglichst Dreiecke zu gruppieren (im Prinzip ein kleines Mesh-Stück, quasi wie ein „Flicken“ im Flickenteppich zu nehmen) welche den gleichen Landclass-Typen bekommen.
• Es verdoppelt die Dreiecke (überlappend) entlang der Grenzen von Landclass-Übergängen um dort mit fließend veränderter Transparenz weiche Übergänge zu schaffen (das ist wieder sehr vereinfacht, da hier auch vielfältig parametrierbare Shader-Effekte zum Einsatz kommen).

Die folgenden Bilder zeigen, jeweils zerlegt, die verschiedenen, Landclass-spezifischen Dreiecksgruppen, welche eben eines der jeweiligen Landclass-Typen (und später auch die passenden Texturen) zugeordnet bekommen.

Die jeweils helle Farbvariante zeigt die „speziellen“ Dreiecke, welche als „Duplikat“ vorliegen und tiefer liegende Texturen überlappen. Diese sorgen dann letztendlich mit ihrer Halbtransparenz dafür, dass im Simulator weichen Texturübergänge entstehen (außerdem ist ganz leicht die Original-Mesh sichtbar, dient aber ausschließlich als Referenz in den Illustrationen):

Landwirtschaft

Stadt

Wald

Gras

Dünne Gebirgsvegetation

Und natürlich auch Wasser, wobei Wasser keine überlappenden, transparenten Texturen benutzt, da diese dann häufig auf schräge Berghänge kommen würden, was aber bei einer Wasserfläche recht unrealistisch anmuten täte. Bei den Ufern wird deshalb eine andere Technik eingesetzt, um halbwegs natürlich zu erscheinen (die sogenannten „beach“ Polygone, welche im Prinzip wie ein „halbtransparenter Klebestreifen“ entlang der Küste „aufgetragen“ werden).

Letztendlich werden all diese Dreiecksgruppen („Flicken“) in X-Plane dann natürlich gemeinsam dargestellt, wodurch es dort ganz natürlich wie ein Mesh erscheint (eben der komplette Flickenteppich). Aber dank der Übergänge bei überlappenden Dreiecken werden im Endergebnis die scharfen Texturkanten vermieden. Das ganze kann man sich dann – abstrakt – so vorstellen:

Wie man sieht, landen also die Landclass-Daten NICHT in ihrer Rohform (als Rasterdaten) in der Scenery sondern nur abgeleitet, als Typzuordnungen den jeweiligen kleinen „Flicken“.

Nach der theoretischen Darstellung folgen noch einige Beispiele, um die Techniken und deren Komplexität anhand echter Daten zu veranschaulichen. Hierbei handelt es sich um einen kleinen Ausschnitt in der Region um Garmisch-Partenkirchen (die Ortschaft ca. links in der Mitte). Als Datengrundlage habe ich eine HD Mesh Scenery v2 Kachel (+47+011) genommen, und diese mit meinem Skript „XP10 DSF-to-GML v2 script“ in das GML-Format umgewandelt, welches man dann z.B. mit dem standard GIS Werkzeug QGIS visualisieren kann.

Im ersten Bild sehen wir nur die rohe Dreiecksstruktur des Meshses, und können deren irreguläre Natur ganz gut erkennen (kleinere, größere Dreiecke welche nicht an einem rechteckigen Grundmuster ausgerichtet sind):

Das folgende Bild zeigt wieder die Dreiecksstruktur, aber gelbe, halbtransparent ausgefüllte Dreiecke zeigen die Stellen, wo verdoppelte (oder noch mehr) überlappende Dreiecke später im Simulator für die transparenten Texturübergänge sorgen werden:

Nun das ganze mit der farbkodierten Landclass-Information und den „beach“ Linien (welche die Ufer mit Texturstreifen „überkleben“) als dunkelgelbe Streifen entlang der Ufer:

Nachträglich (als Bonus) noch zwei Bilder (weiterhin der gleiche Ausschnitt), in dem noch überlagerte Scenery-Informationen dargestellt werden (aber technisch NICHT mehr Teil der Mesh sind!) die im Simulator eine wichtige Rolle spiele.

So die Autogen Informationen (Polygone/Linien etc. welche dem Simulator sagen, wo, welche Art von Autogen aufzubauen ist) und das Straßen-/Bahn-/Stomleitungsnetz (Linien, welche dann durch komplexe Algorithmen im Simulator mit der aufwändigen Straßen-/Bahn-/Stomleitung-darstellung belegt wird):

Und hier noch die Waldinformationen, welche als Polygone in der Scenery definiert werden (die unterschiedlichen Farben zeigen unterschiedliche Waldtypen):

Abschließend, um ein wenig näher an die Technik zu kommen, noch ein paar Worte zu der Verknüpfung des Meshes mit den letztendlichen Texturen…

In den einzelnen Scenery Files (bei X-Plane immer 1×1 Grad abdeckende „Kacheln“!) werden natürlich keine Texturen direkt gespeichert. Es werden noch nicht einmal direkt externe Texturdateien durch die „Flicken“ (Dreiecksgruppen) referenziert, sondern nur sogenannte „terrain description files“, oder auch einfach TER-Files (weil man sie im Dateisystem mit der Endung TER findet).

Erst diese TER-Files verweisen dann auf eine oder mehrere echte Texturen (ja, oft auch mehrere, wenn z.B. zwei Texturen „gemischt“ werden sollen, oder eine Textur als Normalmap dient etc. etc.), beinhalten zusätzlich Darstellungsinformationen (z.B. zu Skalierung der Texturen), Shader Parameter, Transparenzeinstellungen etc. etc..Und gerade die Shader haben hier bei der Bodentexturierung eine wichtige Rolle, da sie z.B. dafür sorgen können (eines der vielen möglichen Shader die in einem TER file aktiviert werden können), dass Texturen mit der Hangneigung gedreht werden (was ein enorm wichtiger Effekt im Gebirge ist!).

Und für jene die es ganz genau wissen wollen (oder wenn eventuell auch eingefleischte X-Planer meine Zeilen lesen), sind in Wirklichkeit noch nicht einmal die TER Referenzen in der Scenery fest, sondern werden erst durch ein sogenanntes Library System echten TER Files zugeordnet. Sprich, in der Scenery selber steht wirklich nur so etwas Abstraktes wie ein Label (ein Name). Das Libary System bestimmt dann, welche echte TER Datei diesem zuzuordnen ist, und die TER Datei bringt uns erst zur echten Textur. Also im Endeffekt eine dreifache Indirektion (Label in der Scenery → Library Eintrag → TER Datei → Textur(en) ) . Dieses Library-System hat auch eine sehr mächtige Rolle, da man über sie z.B. auch nachträglich noch problemlos fest in der Scenery „eingebrannte“ Labels auf andere TER Files umbiegen kann (bzw. dies sogar regionalisiert unterschiedlich machen kann!!!).

Feinheiten der Landclass-Zuordnung

Das obige Beispiel ist – wie vielfach betont – natürlich eine starke Vereinfachung dessen, was bei der Scenery-Erstellung gemacht wird. Denn wenn man nur nach der handvoll Landclass-Typen gehen würde, die man für gewöhnlich in solchen Datensätzen vorfindet, wäre die resultierende Landschaft noch meist recht langweilig und undifferenziert. Daher werden zahlreiche andere Faktoren bei der Ermittlung des jeweils zu nutzenden TER Files (Bodentyps) berücksichtigt. Dazu gehören:

• Hochauflösende – echte – Klimadaten, welche mit 1×1 km Genauigkeit besagen, wie viel Niederschlag durchschnittlich in einem Jahr fällt und welche Temperaturen durchschnittlich im Jahr vorherrschen. Diese Klimainformationen teilen wir mit einem selbst erstellten Schema in verschieden Bereiche ein, wodurch bereits eine Vielzahl an Variationen für jeden Landclasstyp ergeben. Im folgenden Bild steht jede Farbe(!) für einen anderen Klimatypen (dieses Bild ist eine Visualisierung der tatsächlich benutzten Daten!):

Im weiteren werden auch Neigungsinformationen bei der TER Zuordnung berücksichtigt. Zum Beispiel wird also jeweils einen anderer TER-Typ für einen Nadelwald im Flachland, auf Hügeln oder im steilen Gelände genommen. Und dementsprechend können dann auch unterschiedliche Texturen angesetzt werden (müssen aber nicht, denn natürlich können mehrere TER Files die selben Texturen referenzieren …. und sie vielleicht nur per Shader-Variation anders darstellen, oder auch nicht mal das).

Insgesamt können aktuell bei der Landclass-Verarbeitung 48 Landclass-Typen unterschieden werden (wovon in einer Region natürlich kaum alle auf einmal vertreten sind). Dazu kommen 36 mögliche Klimavarianten und 2-3-4-5 Neigungsvarianten (die je nach Bedarf und Landclass-Typ eingesetzt werden). Was aktuell (Stand X-Plane Version 10.30) zu 3597 verschiedenen TER-Typen führt welche aber natürlich nicht alle mit völlig unterschiedlichen Texturen belegt sind, sondern sich auch mal nur durch einen Shader Parameter unterscheiden etc. (aber theoretisch könnte man auch alle mit unterschiedlichen Texturen belegen). Dazu kommen noch einige Spezialregionen (hier kommt die Funktionalität des oben ganz kurz angedeuteten Linbrary-System zu tragen!), wo die bestehenden TER-Files noch ein paar „Zwillinge“ bekommen, die dann z.B. im Grand Canyon für alle Fels-Typen auf rötlichere Texturen verweisen (usw.).

All dies soll verdeutlichen, dass bei X-Plane durchaus versucht wird, mit einer recht hohen Vielfalt für genug Abwechslung in der Landschaft zu sorgen, damit diese natürlicher erscheint. Aber auch X-Plane hat immer wieder das Problem, dass in wirklich „langweiligen“ Gebieten mit kaum Höhenänderungen und extrem homogenen Landclass-Typen (man nehme nur den Mittleren Westen der USA), eine Eintönigkeit schwer zu vermeiden ist (auch trotz komplexer Shader, die mehrere Texturen randomisiert, gemischt in solche Gegenden legen).

Außerdem möchte ich noch mal auf die Bedeutung eines besonderen Aspekts des X-Plane Meshs verweisen, welche ich weiter oben bereits angesprochen habe. Und zwar die „Irregularität“ des Dreiecksnetzes. Dieser Eigenschaft verdanken wir auch viel von dem – einigermaßen – natürlichen Erscheinungsbild bei der Texturierung. Denn bei einem regelmäßigen (für gewöhnlich an einer rechteckigen Struktur ausgerichteten) Gitternetz wäre eine gewisse „Kantigkeit“ (trotz transparenter Übergänge etc.) bei der Texturierung kaum vermeidbar (welche man auch unschön im Simulator wahrnehmen könnte).

Abschließend ergibt sich daraus auch – endlich – die Erklärung, was es mit meiner HD Mesh Scenery v2 auf sich hat. Ganz simpel gesagt, ist diese technisch identisch mit der default Global Scenery, aber mit dem Unterschied, dass das Mesh (Dreiecksgitter) deutlich feiner aufgelöst ist, wodurch:

• natürlich das Höhenmodell genauer nachgebildet werden kann
• und eben auch die Landclass-Typen deutlich genauer nachgebildet werden können (womit man eben näher an die Realität heranrückt).

Vier Bilder zeigen, wie die Verbesserung der HD Mesh Scenery v2 im Vergleich zur Default Global Scenery sich auswirken.

Die ersten Beiden Bilder stammen aus der GUI Version der Laminar eigenen RenderFarm Software (ja, es gibt auch eine GUI Variante, die oft während der Scenery Entwicklung zum Einsatz kommt, wenn man nach Fehlern/Problemen/Ungereimtheiten suchen muss). Man erkennt die Dreiecksstruktur des Meshes, und insbesondere auch die Landclass-Zuordnung (mit Andeutung der transparenten Übergänge). Es fällt auch relativ gut auf, wie die HD Mesh mit einer deutlich höheren Anzahl und kleineren Dreiecken arbeitet:

Und dann das Ganze in der Kartenansicht direkt in X-Plane 10 dragestellt (die gleiche Region, um Aosta herum):

Außerdem beinhaltet die HD Mesh Scenery v2 auch – einfach gesagt – viele Verbesserungen an den Rohdaten und den Techniken bei der Umwandlung in der Scenery (welche sich in der Zeit ergaben seit dem die ursprünglich default Global Scenery von XP10 mal entstanden ist). 

Zusammenfassung

Ich möchte an der Stelle noch mal darauf hinweisen, dass dieser Text sich hauptsächlich auf die Mesh und Landclass Aspekte der X-Plane Scenery konzentriert hat. Aber es sollte nicht unerwähnt bleiben (wie bereits einige Screenshots oben angedeutet haben), dass eine Default Global Scenery-Kachel (oder genauso auch meine HD Mesh Scenery v2) deutlich mehr Daten beinhaltet, wie z.B.:

• das komplette Straßen-/Bahn-/Hochspannungsleitung-Netz (basierend auf OpenStreetmap Daten)
• Waldpolygone (das sind durch Polygone umrissene Bereich in denen X-Plane dann 3D Bäume „pflanzt“) – und nein, diese werden hier nicht aus OpenStreetmap übernommen, sondern werden aus der Landclass abgeleitet (weil diese eine deutlich bessere, homogene, weltweite Abdeckung gewährleistet als OSM)
• Autogen Zonen (auch wieder geometrisch durch Punkte / Linien / Polygone markierte Bereiche die X-Plane dann zur Laufzeit mit verschiedenen Autogen-Objekten ausfüllt).
• Objektpositionen (z.B. von Antennen etc.)
• Fassaden (für gewisse markante Gebäude, insbesondere Hochhäuser)
• etc.

All dies wird von dem RenderFarm Tool auch mit in die Scenery integriert (auch abgeleitet von all den einfließenden Rohdaten – Höhendaten, Landclass, Vektordaten etc.). Ein interessanter Aspekt von X-Plane ist übrigens, dass es keinen Zwang gibt, diese verschiedenen Scenery-Elemente (siehe Liste) in einer Datei zu bündeln. Das Scenery-System stellt es einem in sehr weitem Rahmen frei, ob man sie in einer Dateien zusammenfasst oder in mehrere aufteilt (was manchmal hilfreich sein kann bei der Organisation von Projekten).

Zum Schluss möchte ich noch einen simulatorübergreifenden, wichtigen, Punkt ansprechen. Dies wurde bereits von Holger bei seinen Zahlreichen MSFS Testgebieten angesprochen, und dürfte bei einigen der angeführten X-Plane Beispielen sehr ähnlich auffallen. Und zwar, dass in manchen Gegenden eine doch „erstaunliche“ Diskrepanz zwischen der Realität (Fototextur) und der Landclass-Basierten Scenery besteht. Nun, dies liegt sehr häufig weniger an den Verarbeitungsprozessen (+ Texturen), als viel mehr an den Limitierungen die aus den Rohdaten (Landclass Rohdaten) basieren. Diese haben häufig eine Grenze bei ihrer räumlichen Auflösung und sind auch je nach Interpretationstechnik (diese können extrem stark von Forschungseinrichtung zu Forschungseinrichtung variieren) nicht unbedingt auf maximale Detailtreue ausgelegt. Und so kann es dazu kommen, dass eben der Brocken „bewaldet“ wird … denn das sagen die Rohdaten, und dem folgt dann auch natürlich die Scenery.

Hier können letztendlich nur bessere Rohdaten (die aber nicht häufig, und „einfach so“ neu erstellt werden – sie basieren ja oft auf mehrjährigen Projekten) oder manuelle Änderungen der Entwickler helfen. Aber letzteres ist – nach meiner Auffassung – auch nur machbar, wenn man ein entsprechend großes Team hat (und auch dann wird man aufgrund der gigantischen Abdeckung auch nur einen Bruchteil „anfassen“ können) und riskiert dann noch, dass evtl. all die manuelle Arbeit „verloren“ geht, wenn doch mal andere / bessere / neuere Quellen erscheinen.

Allgemein pflege ich gerne zu sagen, dass Landclass basierte Scenery im Prinzip eine – mehr oder weniger starke – verlustbehaftete, semantische (da interpretierende) „Kompression“ der realen Welt darstellt. Und der Simulator versucht beim „Entpacken“ (also beim rendern!) so gut wie möglich das Original wieder herzustellen, was aber je nach eingeflossenen Daten und gewählter „Kompression“ (wie viel man vereinfacht hat, weggelassen hat etc. oder welche Qualität die Texturen haben) natürlich nie perfekt gelingen kann.

Der Vorteil ist trotzdem – im Vergleich zu eine Photoscenery, welche man im Vergleich als sehr leicht komprimierte Realität betrachten kann – die um Größenordnungen geringeren Datenmenge (das ist eben die „Kompression“!) und eine in sich homogenere Darstellung (da man mit einer kleinen, sehr gut abgestimmten Menge an Texturen arbeitet – wohingegen Phototexturen nahezu immer gewisse, regional stark variierende Qualitätsprobleme in der Optik aufweisen, welche nicht oder nur mit großem Aufwand/Kosten minimierbar sind) der Welt.

Die dritte Dimension der Mesh-Struktur

Was im gesamten Text verschwiegen nicht angesprochen wurde, ist die Frage nach der dritten Dimension, also wo/wie die Höheninformation für das Mesh hinterlegt wird. Nach der klassischen Denkweise (und bei X-Plane 9 war das auch so), würde man erwarten, dass das Dreiecksgitternetz natürlich nicht flach ist, sondern jeder Gitterpunkt auch eine Höhenkomponente (z-Koordinate) beinhaltet und damit ein 3D Gitternetz bildet.

Allerdings kam mit X-Plane 10 eine Erweiterung hinzu (zusätzlich zum vorher erwähnten klassischen Ansatz, der auch weiterhin funktioniert), die es erlaubt, dass Dreiecksgitternetz nur noch flach (also effektiv nur in 2D) zu definieren und die Höhendaten zusätzlich in der Raster-Form in der Scenery-Datei eingebettet mitzugeben. X-Plane 10 legt dann zur Laufzeit (beim Laden der Scenery) das “flache” Mesh quasi wie ein Tuch über diese Raster-Höhendaten, wodurch das Mesh die 3D Form annimmt (natürlich kann es nur entlang der durch das Gitternetz definierten Kanten “geknickt” werden, was die effektiv maximale Detailtreue im Endergebnis bestimmt).

Die Vorteile dieses Ansatzes sind:

– die Scenery-Datei wird tatsächlich insgesamt kleiner, weil es doch um einiges effektiver ist, die Höheninformation als Raster-Information zu speichern, statt in den Koordinaten an jedem Gitterpunkt. Auch wird jetzt nicht mehr für jeden Gitterpunkt der Normalvektor  gespeichert, sondern auch zur Laufzeit errechnet, was weiter Speicherplatz erspart.

– außerdem war mal angedacht, aber leider bis jetzt noch nicht umgesetzt: Der Plan bei Laminar Research ist immer noch , X-Plane 10 eines Tages das sogenannte Tessellation  beizubringen. Dies ermöglicht eine “on-the-fly” (auf der Grafikkarte)-Verfeinerung des Dreiecksgitternetzes. Dadurch wird das Mesh noch genauer – auch mit theoretisch noch höher aufgelösten Raster-Höhendaten – und es kann sich der Geländeform besser anpassen (denn wie schon oben erwähnt, beschränkt ja die Auflösung des Gitternetzes, wie genau es die Form der Höhendaten annehmen kann).

Die default Global Scenery und die HD Mesh Scenery v2 benutzen bereits diese Technik mit den Raster-Höhendaten. Aber auch hier gibt es noch eine Ausnahme, wodurch das Mesh dann doch ein Hybrid (und ja, das geht von der Datenstruktur her problemlos) aus der alten und der neuen Technik wird. Denn Gewässer, die ja wie oben erwähnt, Teil des Meshes sind, sind ein Sonderfall, bei dem man sich ungern auf die – natürlich vorhandenen – “Ungenauigkeiten” der Raster-Höhendaten verlassen möchte (und wodurch das Wasser häufig nicht überall gleichmäßig Flach erscheinen würde!). Aus diesem Grund macht RenderFarm (der Scenery Generator) bei Wasser eine Ausnahme und versieht hier die Gitterpunkte doch bereits im Vorfeld mit Höhendaten (die aber auch von den gleichen Raster-Höhendaten abstammen ,die man auch in den Files mit einbettet) und sorgt an der Stelle – also in der Vorverarbeitung – mit ausgepfeilten Algorithmen für eine ausreichende Glättung. Optimal ist dieser Ansatz natürlich nicht, aber gegenwärtig gut genug, um ein optisch ansprechendes Resultat zu bekommen.

Screenshots

 

Zusätzlich zu den Illustrationen habe ich noch einige Screenshots aus X-Plane 10 beigesteuert. Allen ist gemeinsam, dass sie nicht den Simulator in seiner Rohform zeigen, sondern einige Zusätze beinhalten. Aber all diese Extras sind freie Erweiterungen, die jeder ohne viel Aufwand (außer potentiell recht lange Downloadzeiten) installieren kann. Dazu gehören:

• X-Plane 10 HD Mesh Scenery v2, welche ich hier oft erwähnt habe, und zu einer – im Vergleich zum Default – deutlich genauere Landclass-Abbildung (neben zahlreichen, anderen Verbesserungen!!) führen.
• X-Plane 10 Tree Lines and Farms V2, eine weitere Erweiterung von mir, welche basierend auf OpenStreetmap-Daten mit ein paar recht simplen, heuristischen (aber möglichst plausibel erscheinenden) Algorithmen Alleen und Bauernhöfe in der Landschaft platzieren.
• Ein paar Modifikationen bei der Parametrisierung der Atmosphäre und Wolkendarstellung, basierend auf Erkenntnissen aus diesem Forums-Thread:  . Diese Verbesserungen sollen aber in absehbarer Zeit auch direkt – also offiziell – in X-Plane 10 mit einfließen (ein gutes Beispiel dafür, dass die Entwickler durchaus offen sind für Vorschläge aus der Community).

Im Weiteren habe ich noch eine kleine Serie aus den Westalpen (hauptsächlich die Schweiz, aber auch teilweise Italien/Frankreich) angehängt, welche veranschaulichen, wie gut man bei hochwertigen Landclass-Daten und viel Abwechslung in der Landschaft, durchaus eine recht glaubwürdige Abbildung der Realität erreichen kann (hier erinnere ich daran, dass es sich bei den folgenden Bildern garantiert nicht um Photoscenery handelt!):

• Alle Screenshots die mit „c130_“ beginnen … eine beliebige Auswahl.

Wer noch mehr sehen möchte, dem empfehle ich einen Blick in die zahlreichen, „offiziellen“ Bildersammlungen zur HD Mesh Scenery v2  (darin enthalten auch zahlreiche Vorher/Nachher Vergleich zur default Global Scenery):

• X-Plane 10 HD Mesh Scenery v2 – Europe – FINAL,
• X-Plane 10 HD Mesh Scenery v2 – North America – FINAL,
• X-Plane 10 HD Mesh Scenery v2 – default and HD comparisons,
• X-Plane 10 HD Mesh Scenery v2 JAPAN – default and HD comparisons,
• X-Plane 10 – atmospheric experiments (with HD Mesh Scenery v2)

Nachtrag

Für Interessierte möchte ich die Datenquellen nicht vorenthalten, auf die sich all meine (bzw. Laminars) Arbeit stützt, wodurch vielleicht auch noch mal verdeutlicht wird, wie für möglichst viel Abwechslung in der Landschaft gesorgt wird. Diese habe ich – teilweise auch aus rechtlichen Gründen – bereits auf meiner HD Mesh Scenery v2 Seite unten aufgelistet (und halte es dort auch aktuell):
http://www.alpilotx.net/downloads/x-plane-10-hd-scenery-mesh-v2/#Data-Sources-Acknowledgments“

 —Ende des Beitrags—

 

Vielen herzlichen Dank, lieber Andras, für diese Einführung in die Landklassen in X-Plane!