TransDEM Forum

Seit der allerersten Version für Trainz aus 2005 gibt es in TransDEM eine „Basemap“-Funktionalität. Das sind die großen universellen Texturträgerobjekte, auf deren Oberfläche automatisch das Abbild großmaßstäbiger Karten, Gleispläne oder Orthofotos aufgebracht wird. In TransDEM heißen sie aus historischen Gründen „UTM-Kacheln“ (und sind am UTM-Koordinatengitter ausgerichtet). Seit TransDEM 1.2 (2006) werden diese Kacheln nicht nur automatisch „bedruckt“, sondern auch automatisch an der richtigen Stelle in der Strecke platziert.

Solche „Basemaps“ stellen eine Alternative für Bodentexturen dar, deren Auflösung aufgrund der Datenstruktur bei Trainz begrenzt ist, wenn ganze Baseboards und ganze Streckenmodule mit Karten oder Luftbildern versehen werden sollen.

Wie bei fast allen Basemap-Lösungen verwendet TransDEM für seine UTM-Kacheln vorgefertigte Meshes als Texturträger, die von Natur aus eine große flache Ebene bilden. In bergigem Gelände ist dies weniger ideal, da die Kacheln auf die Höhe der tatsächlichen Geländeoberfläche am jeweiligen Arbeitspunkt angehoben oder gesenkt werden müssen.

Die Texturen sind für jede Kachel individuell, aber die Kachel-Meshes sind immer dieselben. 2010 kamen zu den ursprünglichen 1000m-Kacheln kleinere mit 500 m Kantenlänge hinzu, aber die sind an Berghängen immer noch reichlich unhandlich.

Für den Streckenbauer wäre es deutlich einfacher, würden die UTM-Kacheln die Textur für Karte oder Luftbild auf einer am tatsächlichen Gelände orientierten Oberflächenform wiedergeben. Das bedeutet natürlich, dass nicht mehr nur die Texturen individuell erzeugt werden, sondern auch die Texturträger, die Meshes selbst, individuell für jede Kachel gefertigt werden. Ein nicht ganz unbescheidener Rechenaufwand.

Vor etwa einem Jahr hat Trainz-Anwender ModelerMJ ein Projekt für solche individuellen Gelände-Basemaps gestartet, wobei sein Ansatz eng verflochten ist mit Google-Earth und anderen Google-Diensten. ModelerMJ hat jetzt angeboten und angekündigt, auf diesem Ansatz basierend ein Softwarewerkzeug für Streckenbauer zu entwickeln.

Langjährige TransDEM-Nutzer werden möglicherweise bemerkt habe, dass ich sehr zurückhaltend bin, wenn es um engere Kopplung mit Internet-Diensten von Google und anderen Anbietern geht. Die beiden Clients für Onlinedienste in TransDEM, WMS und Kachelkarten, arbeiten auf der untersten Ebene des HTTP-Protokolls, ohne Benutzerkonto, ohne API, ohne Cookies, ohne jede Übertragung persönlicher oder „statistischer“ Daten. Aus dem selben Grund ist auch die Kopplung mit Google-Earth eine sehr lose. Sie beschränkt sich auf den rein lokalen Transfer simpler JPEG- und Placemark-Dateien.

Unter Beibehaltung dieser Datenschutzpolitik bedeutet das, dass auch geländegeformte UTM-Kacheln auf jede Abhängigkeit von Google und Co. verzichten müssen. Bei genauerem Hinsehen sollte TransDEM eigentlich schon alles selbst bieten, was hierzu an Daten benötigt wird.

Diese Woche habe ich das nun näher untersucht und ein wenig probiert. Folgendes ist dabei herausgekommen, die erste individuell geformte UTM-Kachel in TransDEM, im wohlbekannten Tal der Wupper zu Müngsten:




Im Moment ist dies noch ein reiner Laborversuch, aber ich plane, diese Funktionalität in die nächste Version von TransDEM einzubauen. Sie wird „3D UTM-Kacheln“ getauft. Die bisherigen Kacheln werden als Alternative erhalten bleiben, zukünftig bezeichnet als „2D“. 2D- und 3D-Kacheln werden so kompatibel wie möglich werden, einschließlich der beiden Größen 1000 und 500m.

Wie einleitend bereits bemerkt, die Fertigung der 3D-Kachel wird rechenintensiv. Für jede Kachel fallen drei zusätzliche Schritte an:

1. Die Höhen aus der Trainz-Streckendatei extrahieren, an der Position und für die gesamte Ausdehnung der jeweiligen Kachel. Der einfachste Weg in TransDEM dazu sind kleine individuelle DEMs für jede Kachel. Dieser Schritt ist mit minimalem Kodieraufwand verbunden, die Klassen dazu existieren alle schon.
2. Die individuelle Datenstruktur für das Mesh aufbauen. Der Standardansatz in Trainz für 3D-Geometrie und Drittsoftware läuft über eine Klartextbeschreibung in einem Trainz-spezifischen XML-Dialekt. In diesem Schritt erzeugt TransDEM die Vertices, Normalen und Texturkoordinaten dieses Meshes in XML-Form, an Hand der Höhen des kacheleigenen DEMs. Das Mesh wird als komplettes 10m-Raster gebildet. Eine nachfolgende Optimierung mit Streichung überflüssiger Vertices scheint aus momentaner Sicht nicht erforderlich.
3. Der letzte Schritt ist die Generierung des eigentlichen Trainz-Meshes, der .im-Datei. Das Importwerkzeug dazu wird von N3V/Auran bereit gestellt. Die Anwender werden sich dieses Werkzeug selbst herunterladen müssen, da die Lizenzbedingungen die Weitergabe nicht gestatten. Meine Vorstellung ist natürlich, das Importwerkzeug dann vollautomatisch aus TransDEM heraus aufzurufen.

Wenn alles nach Plan verläuft, wird der einzig sichtbare Unterschied – abgesehen von der größeren Rechenzeit – eine neue Auswahlmöglichkeit als 2D/3D-Radioknopf im UTM-Kachelexportdialog sein.

Noch zwei Anmerkungen:

• In diesem Frühjahr habe ich für unsere amerikanischen Freunde die Importmöglichkeit für GeoPDF geschaffen. Hierbei nutzt TransDEM komplett unabhängige externe Software, die GDAL-Werkzeuge. Der dafür benutzte Ansatz sollte sich auf den Trainz-Mesh-Importer übertragen lassen, der ebenfalls als eigener Prozess gestartet werden soll, aber unter der Kontrolle des TransDEM-Prozesses bleibt.
• Die drei genannten zusätzlichen Schritte werden Rechenzeit kosten. Am notwendigen Ablauf selbst kann ich wenig ändern, deswegen müssen Möglichkeiten zur Parallelisierung untersucht werden, Ideen dazu habe ich. Schon die letzten beiden TransDEM-Versionen lassen bereits etliche Rechenalgorithmen parallel laufen, wobei dann alle verfügbaren CPU-Kerne genutzt werden. Die Aufgabe hier wird etwas abweichen, weil mehr Kontrolle über die Worker-Threads erforderlich sein wird, aber ich denke, das ist lösbar.

Wie immer möchte ich keinerlei Prognosen über den Zeitbedarf zur Umsetzung abgeben. Wie oben erwähnt, im Moment ist es ein Labormuster, eine bestandene Machbarkeitsuntersuchung, mit einer ganzen Reihe von Ideen für das endgültige Design, aber mehr auch nicht. Die eigentliche Arbeit beginnt erst.

Die Implementierung macht Fortschritte. Das Texturmesh wurde zum richtigen 3D-Objekt, mit Unterbau und individuell triangulierten Seitenwänden, siehe die folgenden beiden Bilder aus dem Mesh Viewer.





Die 3D-Kacheln wird es wie bisher bei 2D als 1000m- oder als Vierergruppen von 500m-Kacheln geben. (Mit 500er Kacheln und 4096-Pixel-Textur lassen sich Objekte bis zu 10cm auflösen.) Bei den 500er Kacheln liegen die Ankerpunkte auch weiterhin an den Schnittpunkten der 1000m-UTM-Gitterlinien. Das bedeutet, dass auch zukünftig mit Ausnahme der Südwestkachel die anderen beim Einbau um 90° bis 270° gedreht werden. Dadurch können exakt dieselben Texturen wie für die 2D-Kacheln verwendet werden. Nicht eine Zeile Code muss somit für die Texturgenerierung geändert werden.

Außerdem habe ich Vertex-Normalen hinzugefügt, was Schattierung im Surveyor ermöglicht, man vergleiche das folgende Bild mit denen aus dem ersten Beitrag zum Thema.



(Der Mesh-Viewer unterstützt anscheinend nur Umgebungslicht - ambient - und ignoriert die Normalen.)

Schließlich noch ein Bild aus der Müngsten-Teststrecke, die hier komplett mit 3D-Kacheln versehen wurde. Einen Kachelbaustein habe ich angehoben, um die quadratische Fliesenstruktur zu illustrieren.

Die Implementierung geht fleißig weiter und umfasst diverse, sich wiederholende Tests. Ein paar weitere Bilder aus dem Software-Labor:

Bahnhofsareal Menden im Sauerland. Im Vordergrund ein maßstäblicher Gleisplan 1:1000 aus den 1950er Jahren, und drei andere Texturquellen im Hintergrund, Erläuterung siehe weiter unten.

Die 3D-Kacheln wurden 10 cm über Grund positioniert, hoch genug, um Flimmern weitgehend zu unterdrücken, aber auch tief genug, um den Gleis-Spline noch sichtbar zu haben.



Alle vier Texturquellen aus Vertikalperspektive, mit einem Lineal von 100 m Länge als Maßstabsorientierung.

• Oben links: Gleisplan, 1:1000, manuell georeferenziert, Preußische Katasterkoordinaten (Cassini/Soldner-Projektion)
• Unten links: Bing Maps Luftbild (in TransDEM unter dem ursprünglichen Namen Virtual Earth geführt), Zoomstufe 18, ca 1:4000, über den Kachelkartendienst abgerufen, automatisch georeferenziert, sphärische Mercator-Projektion
• Oben rechts: Luftbild 40cm Auflösung, Geoportal NRW, abgerufen über WMS des Geoportals, automatisch georeferenziert, Gauß/Krüger-Projektion
• Unten rechts: Topografische Karte 1:5000 (Deutsche Grundkarte), abgerufen über WMS des Geoportals, automatisch georeferenziert, UTM-Projektion

Mit Bedacht ist unter den für das Beispiel ausgewählten Datenquellen keine von Google. Das soll verdeutlichen, dass es nicht nur überhaupt Alternativen sondern oft genug auch Alternativen mit besserer Qualität gibt.

Alle Kacheln im Beispiel haben die Größe 500 m. Die inneren vier wurden jetzt etwas nach unten geschoben, um die Bodentextur sichtbar zu machen. Auf dem 5m-Geländeraster wurde die topografische Karte 1:25000 aufgebracht, wiederum vom Geoportal NRW mittels WMS. Bei dem geringen Betrachtungsabstand erscheint die Bodentextur naturgegeben ziemlich unscharf.



Weiter herausgezoomt ergibt sich ein klareres Bild, jetzt mit etwas schärfer erscheinenden Bodentextur und den restlich 3D-UTM-Kacheln darum herum, diese immer noch 10cm über Grund.



Die Bandbreite von Datenquellen, Kartenprojektionen und den verschiedenen Formen der Vorverarbeitung ist TransDEM-Nutzern hinlänglich bekannt. Die gesamte Mathematik dazu bleibt unter der Oberfläche. Und unabhängig von der Geodatenquelle bleiben die TransDEM-Funktionen für den Export zu Trainz immer dieselben. Besonders hier von Belang: zur Erzeugung von 3D-UTM-Kacheln sind keine zusätzlichen Handlungen des Benutzers erforderlich, außer der einmaligen Auswahl, überhaupt 3D-Kachel erzeugen zu wollen.


Wie schon zuvor angedeutet, erfordert die Erzeugung von 3D-UTM-Kachelen mit individuellem Mesh pro Kachel intern erheblich mehr Rechenaufwand als das einfache Applizieren von Texturen auf vorgefertigte 2D-Kacheln. Um das ganze schneller ablaufen zu lassen, wird der Mesh-Erzeugungsprozess parallelisiert. Erste Performanz-Daten zeigen die nächsten beiden Bilder.

Das erste ist der Auszug der Prozess-Liste, wie sie im Process Explorer angezeigt wird, mit mehreren Instanzen des Trainz XML Mesh Importers als Tochterprozesse von TransDEM. Die mögliche maximale Anzahl der Tochterprozesse wird durch die Zahl der verfügbaren CPU-Kerne bestimmt.


Das zweite Bild zeigt die CPU-Auslastung für TransDEM und für das gesamte System, wieder mit Hilfe des Process Explorers angefertigt.



Auf meinem Rechner mit vier Kernen plus Hyper-Threading werden alle Kerne während der Kachelgenerierung gut ausgenutzt. Der Grund, warum die Auslastung unter 100% bleibt, liegt an den intensiven Ein-/Ausgabe, siehe linkes Diagramm, die den Ablauf verlangsamt.



Schließlich die Dialogoberfläche für den Kachelexport, wie sie sich im Moment darstellt (wird noch ins Deutsche übersetzt):



Wir finden einen neuen Radioknopf, der zwischen 2D- und 3D-Kacheln umschaltet. Bei der Auswahl von 3D-Kacheln erscheinen zwei zusätzliche Optionen, die dann die bisherigen 2D-Optionen an dieser Stelle ersetzen. Die erste Option bestimmt die Höhe der Kacheloberfläche über Grund. Die Voreinstellung von 10 cm verhindert bereits weitgehend das Flimmern.

Die zweite Option lässt das Erzeugen von Meshes mit 5m-Raster für die Texturträgerfläche zu, wenn ein oder mehrere Baseboards als Quelle für diese Kachel das 5m-Geländeraster aufweisen. Normalerweise sollte diese Option ausgeschaltet bleiben, da sie Komplexität des Meshes und Rechenzeit um den Faktor 4 erhöht. Verwendet man allerdings höchauflösende DEMs – bei uns eher selten – so kann diese Option von Nutzen sein.

Außerdem muss man das Verzeichnis angeben, wo TransDEM dem Trainz XML Mesh Importer findet. Da der Importer nicht formal installiert wird, würde sich TransDEM schwer tun, nach ihm zu suchen. TransDEM prüft aber jeden hier angegebenen Ort, ob sich dort der Importer tatsächlich befindet und ob TransDEM ihn laufen lassen kann.

(Mit etwas Verzögerung zum englischen Gegenstück dieses Beitrags vom letzten Wochenende)

In der nächsten Version von TransDEM wird es die dreidimensionalen UTM-Kacheln geben. Deren Oberfläche entspricht der Geländeform. Die 3D-Kacheln werden damit im hügeligen oder gebirgigen Gelände deutlich handlicher als die flachen, zweidimensionalen Kacheln, die wir bisher haben.

Als Streckenbauhilfe könnten die 3D-Kacheln die Rolle übernehmen, die bisher die Bodentexturen innehatten. Daraus ergibt sich die Frage, wie dann die Bodentexturen zukünftig genutzt werden sollen. Für sie könnte eine neue Aufgabe gefunden werden. Wie wäre es mit Hintergrundtexturen? Wenn man da eine geeignete Quelle nutzt – Orthofotos/Luftbilder bieten sich an – könnte man die Geländeoberfläche in den Farben anpinseln, die sich auch in der Natur finden, und so eine Menge Arbeit sparen.

Für Orthofotos/Luftbilder sind die eingebauten und mitgelieferten TransDEM-Bodentexturen allerdings weniger geeignet, denn sie sind ausgerichtet auf topographische Karten, die mit wenigen Farben auskommen. Orthofotos benötigen andere Farben und auch deutlich mehr davon. Das erfordert einen neuen Satz von Texturen.

Das Prinzip der Bodentexturierung aus Geodaten in Trainz – unverändert seit HOG-Zeiten – basiert darauf, eine Palette einfarbiger Texturen festzulegen und für jeden Rasterpunkt auf dem Baseboard diejenige Texturfarbe zu bestimmen, die der Vorlage (Karte oder Luftbild) an dieser Stelle am nächsten kommt.

In TransDEM – wie zuvor in HOG – kann man einen eigenen Satz Bodentexturen einsetzen. ModelerMJ hat vor einiger Zeit bereits einen solchen Satz erzeugt, ebenfalls für Luftbilder, und dafür jedoch eine universelle Farbpalette mit nach meinem Kenntnisstand insgesamt 140 Farben gewählt.

Für meine zugeschnittenen Luftbildtexturen habe ich mich für einen Umfang von 128 Farben entschieden. (Wir können jedem Baseboard maximal 250 verschiedene Bodentexturen zuweisen. Bis zu 128 davon würde TransDEM vergeben, also blieben mindestens 122 für eigene Zwecke.) Um die einzelnen Farbwerte zu bestimmen, habe ich eine kleine Sammlung unterschiedlicher Luftbilder von Orten rund um den Globus angelegt, und diese mit einem Octree-Quantisierer verarbeitet, der meine spezifische Farbpalette erzeugt.

Das sind meine Ausgangsbilder (hier für die Darstellung verkleinert):




Und dies ist das Ergebnis, wenn man diese Bilder mit meiner Farbpalette transformiert, als Gegenprobe dafür, wie gut die Farbauswahl gelungen ist.




Das Original hatte 197352 verschiedene Farbwerte, nach der Transformation blieben davon genau 128.

Das ist die Farbpalette, die dabei entstanden ist:




Um einen eigenen Satz Bodentexturen nutzen zu können, benötigt man neben den Texturobjekten selbst noch eine Abbildungstabelle in Form einer Textdatei, in der RGB-Werte den Textur-KUIDs zugewiesen werden.

Code:

...

rgb 183,198,180
kuid <KUID2:126773:21208:1>

rgb 226,179,156
kuid <KUID2:126773:21209:1>

rgb 198,185,196
kuid <KUID2:126773:21210:1>

rgb 229,197,155
kuid <KUID2:126773:21211:1>

...

Orthofotos/Luftbilder als Bodentexturen In Trainz werden immer unscharf und verwaschen aussehen, weil die Auflösung nun mal nur 5 oder sogar 10 m per Pixel, d. h. per Baseboard-Vertex beträgt. Als Streckenbauhilfe ziemlich ungeeignet. Allerdings werden mit den 3D-UTM-Kacheln die Bodentexturen als Vorlage im Surveyor ja nicht mehr unbedingt benötigt. Stattdessen können wir sie nutzen, um sehr effizient das gesamte Terrain mit einem Farbanstrich zu überziehen, der zumindest für die Baseboards im Hintergrund vielleicht sogar die einzige Texturierung ist, die diese Baseboards je erfahren werden.

Daraus folgt, dass Orthofotos/Luftbilder als Bodentexturen somit als endgültige Texturierung in Betracht kommen. Diese Texturen werden dann Teil der fertigen Strecke. (Aber Vorsicht, hier können Urheberrechtsfragen noch eine Rolle spielen.) Weil sie auf Dauer angelegt sind, erhalten meine neuen Texturen für diesen Zweck kein 10m-Raster mehr. Bei einem realen Streckenprojekt würde man zudem auch auf das Zeichnen des (violetten) 1000m-Rasters verzichten.

Das orange 10m- (und violette 1000m-)Raster wird zukünftig übrigens als Option für die UTM-Kacheln angeboten.

Einige Beispielbilder:

Ein weiterer Versuch mit 3D UTM-Kacheln und Ortho-Fotos. Das folgende Beispiel ist der Bonneville-Staudamm am Columbia River, Bundesstaatengrenze Oregon/Washington. Die Ecke habe ich schon früher benutzt um zu experimentieren und Funktionalität zu erläutern.

Die Luftbilder, die jetzt zum Einsatz kamen, stammen vom USGS und sind zu finden unter "NAIP National Agriculture Imagery Program". Die USGS-Bilder habe ich gewählt, weil sie frei verwendbar sind und nicht unter Urheberrecht stehen. Allerdings werden diese Bilder im Format JPEG2000 (.jp2) geliefert, das von TransDEM nicht unterstützt wird.

(JPEG2000 steht zwar schon länger auf meiner Aufgabenliste, aber für die anstehende Version 2.5 wird das noch nichts.)

Für diesen Test habe ich das .jp2 manuell in gewöhnliches .jpg konvertiert (IrfanView) sowie aus dem Original mit GDALinfo die Metadaten ausgelesen, und mit deren Angaben einen World-File erzeugt. Jpg-Bild und World-File reichen TransDEM für die automatische Georeferenzierung.

Das DEM hat 1/9 Bogensekunden Auflösung. Deshalb habe ich die 3D UTM-Kacjheln mit 5m-Gitterweite anlegen lassen – was ewig dauert. Außerdem habe ich als Absteckhilfe das 10m-Gitter auf die Textur zeichnen lassen.

Es ist eine recht überschaubarer Landschaftsausschnitt von etwa 70 Quadratkilometern:



Ein paar Eindrücke mit den Luftbildtexturen auf 3D-UTM-Kacheln. Luftbildauflösung ist 1 m per Pixel:








Interessanterweise ist die Zeichentiefe für Objekte in TS12 deutlich höher als für das Terrain selbst, das auf Maximum 5km steht. Derselbe Blickpunkt wie zuvor, aber TransDEM-UTM-Layer ausgeschaltet: