Mission on Mars: Skalierung – Teil 2

Lesezeit: 10 Minuten

Derzeit habe ich nun eine detaillierte Höhenkarte.  Die Skalierung der Breite errechnet sich aus der Pixelbreite der übergebenen Highmap: nämlich 200m pro Pixel.

Nun skaliere ich die Höhe und fasse Ergebnisse strukturell zusammen.

Umrechnung glu <-> Pixel <-> Meter

Wie in Mission on Mars: Skalierung und Optimierung – Teil 1 beschrieben, entspricht ein Pixel meiner NASA-Highmap 200m.

Mappe ich auf eine Tilegröße von 512 GL-Units (glu) eine 1.024 x 1.024 große Highmap, so wäre ein Tile 204,8 km breit. Selbst für eine Übersicht nicht so gut geeignet.

Bei 512 x 512 erhalte ich folglich 102,4 km – sinnvoll erscheint mir also eine Höhenmap von 256 x 256 Pixeln – und damit einer Tilebreite von 51,2 km.

Damit ergibt sich ein Umrechnungsfaktor von 1km = 100glu. Dass das jetzt so schön glatt ist, ist mehr oder weniger Zufall. Falls WordPress es zulässt, nehme ich den Zwinker-Smiley 😉

Anpassung der Höhenberechnung auf BASIS der DEM-Farben

Habe ich meine Höhenfunktion derzeit noch prozentual von -1.0 bis 1.0 für die maximale Tiefe bzw. Höhe, so füttere ich nun diese mit der erarbeiten DEM-Datei:

Nicht wirklich eine herausfordernde Datenstruktur, aber ich löse das über eine separate Klasse – spare ich mir doch einige Doppel-Berechnungen dadurch:

Zwei grundlegende Funktionalitäten habe ich hier zusammengefügt: das Parsen der DEM-DAten und damit die Umrechnung von (r,g,b) <-> Höhenwerte.

Und, falls durch grafische Algorithmen wie z. B. Skalierung und/oder Weichzeichnung, RGB-Werte entstehen, die außerhalb der DEM-Intervalle liegen, so soll der RGB-Wert auf den Wert geändert werden, der dem Wert am nächsten kommt.

GLTile-Berechnung in eigener Klasse

Um aus dem „Jugend forscht“-Status der Erstellung eines Tiles herauszukommen, strukturiere ich das ebenfalls in eine eigene Klasse:

Im Grunde sind das die Essenzen aus den Blog-Beispielen 1-10. Die Funktion decorateUV rückt in den nächsten Blogs in den Mittelpunkt.

Fixiert habe ich auch die Aufrufparameter – Tilegröße, Texturen-Größe und Höhenparameter verschwinden, bzw. werden errechnet, bzw. sind fixiert.

Serveranpassungen

Die Route in diesem Beispiel lautet: http://www.mission-on-mars.com/blog/example/tile11

Hier die Implementierung – deutlich übersichtlicher:

Der letzte Parameter bei der Konstruktion GLTile erzwingt jeweils eine Neuberechnung – zum Testen der App und nach mindestens einem erfolgreichen Berechnen, stelle ich den auf false, was eine Neuberechnung verhindert, wenn Mesh, UV- und Normal-Map bereits berechnet sind.

Modifikationen in der APP

Natürlich muss ich den Pfad in gfxTile3d entsprechend ändern:

Und aufgepasst – habe ich doch nun endlich „uv“ als Bezeichnung für die Textur gewählt – zu ändern in onLoadMeshCompleted:

Spriteposition und Meshposition

Mein gewählter Ausschnitt aus der Höhenmap liegt etwa 3 km unter 0 – das Mesh wird mit z-Werten von um die -379 bestückt. Die Spriteposition liegt ja bei z=0 – um nicht weit über dem Tile zu stehen, passe ich noch den z-Wert vom Kamera-LookAt an:

Mehr ist erst mal nicht passiert. Durch die Skalierung werden die Details größer und klobiger und damit alles unschärfer, aber die Unschärfe, die Skalierung und nun auch die Höhenwerte sind realistisch der Marsoberfläche angepasst:

Revision 68

Android

Weiterführende Links

Aus dem hässlichen braun und der nun schwammigen Darstellung widme ich mich der Oberflächenanalyse und einer darauf aufbauenden Generierung der UV-Maps.

Ein erstes Ergebnis habe ich grob hier beschrieben: Mission on Mars: UV-Map generieren

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.