Outdoormapping (Terrain und Felsen)

Dieses Tutorial beschäftig sich mit einer speziellen Methode zum Outdoor-Mapping, vorallem für low-poly Landschaften mit hohen Sichtweiten. Da ich keine Lust habe, ein weiteres Felsen-Tutorial zu schreiben, setze ich Kenntnisse zum Vertex- und Clipping-Tool vorraus, sowie eine gewisse Erfahrung bei der Landschaftsgestaltung mit Dreiecken. Außerdem solltet ihr etwas Wissen über die Engine (z.B. Leafs) und die Funktionsweise der Compiler (Zerschneidung, Sichtbarkeitsberechnung) mitbringen. Bevor wir starten, bitte ich, sich diese Offlineversion des Tutorials herunterzuladen. Ich werde hier und da auf die Beispielmaps verweisen und man sollte diese Methode auf jedem Fall auch einmal „live“ gesehen haben.

• Kurviges Terrain bei hohen Sichtweiten und niedrigen wpolys, sodass genug Platz für Details bleibt.
• Effizientes Vis-System, bei geschickten Vis-Blockern berechnet die Engine nicht viel mehr, als der Player wirklich sieht.
• Planes sparend, da viele Back- und Void-Faces auf einer Ebene liegen.
• Clipbrushes verringern die clip-nodes und beseitigen viele Kanten, die den Player blockieren könnten.
• Viel mehr Textur-Variationen möglich, ohne dass man bestimmte Faces nochmals trennen muss, um zwei versch. Texturen aufzutragen.
• Sauberes Brushwork und niedrige wpolys sorgen für humane Compile-Zeiten.

• (Starke) Einschränkungen beim Erstellen des Map-Layouts. Das gilt für Gameplay und Optik. Dieser Aspekt ist nicht zu unterschätzen!
• Zum Teil grobe Landschaft, wirkt eintöning ohne große Erfahrung mit dieser Methode.
• Nicht für jedes Setting und jeden Map-typ geeignet.
• Sehr Zeitaufwendig, Brush-Errors und Leaks kommen öfter vor, ist aber auch von der Erfahrung des Mappers abhängig.
• In-Game Qualitäts-Verlust bei den Texturen (224²) oder aber zeitaufwendiges Textur-Alignment (256² auf 224²-Faces).

Warnung: Die Beispiel-RMFs und Texturen dienen zur Verdeutlichung bzw. Selbsterklärung dieser Methode, die Map und Texturen dürfen NICHT in einer Map übernommen werden !!!

Hinweis: Zum korrekten Anschauen der .rmfs werden folgende .wads benötigt: * halflife.wad * zhlt.wad * rock_tut.wad

Die rock_tut01.rmf zeigt das grobe Layout der Beispiel-Map ohne Terraforming. Wie man sieht, sind erstmal alle Faces 224² Units groß, die Kanten liegen alle auf identischen Linien, sodass es keine zusätzlichen Zerschneidungen gibt.

„Show hidden objects“ sollte die Hint-Brushes zum Vorschein bringen und zeigen wie jedes Leaf zu einer Größe von 224x224x224 Units gebracht wird. Zusätzlich liegen die Kanten der Hint-Brushes genau auf den Kanten der umliegenden Brushes. Jedes Hint-Brush ist sozusagen mindestens ein Leaf mit der Größe 224³. Da zwei benachbarte Hintbrush-Würfel miteinander verschmelzen würden, liegen alle Hint-Brushes versetzt zueinander und berühren sich nur mit ihren Kanten. Liegt solch ein Hint-Brush nun an Dreiecken, entstehen in diesem 224³ großen Raum mehrere Leafs, die aber dank dem Hint-Brush nicht größer als 224 werden. Somit entstehen keine außergewöhlichen Leaf-Formen, die zu einem „Leaf Portal saw into Leaf…Error“ führen könnten. Dieses Hintbrush-System sorgt nicht nur für ein effizientes Vising, sondern dämmt zusätzliche Zerscheidungen ein, die durch Brushes entstehen, welche nicht genau in dieses System passen (z.B. beim Bau von Gebäuden).

Wie man sieht, kann man jeder 224²-Fläche theoretisch eine andere Texturvariation geben, sodass man nur durch Texturen schon eine gewisse Abwechslung erreichen kann. Die Variationen in der rock_tut.wad sind nur ein kleiner Teil der Variationen in meiner Map und dienen nur zum Verständnis, was alles möglich ist.

Hinweis: Wieso ausgerechnet 224? Bei einem Textur-Scaling von 1 darf ein Face maximal 240² Units groß sein. Allerdings teilt hlbsp größere Faces wieder in 224² Polygone ein, sodass ich für mein System 224² bzw. 224³ gewählt habe. Wer es verstanden hat, kann das ganze auch auf ein 240³-System übertragen, bzw. sich daran versuchen oder aber ein beliebiges anderes System wählen (z.B.: 128³!

Die rock_tut02.rmf zeigt den gleichen Mapabschnitt nach dem Terraforming:

Die meisten 224²-Faces wurden in Dreiecke geteilt und mit dem Vertex-Tool bearbeitet. Hier gibt es zwei Möglichkeiten:

• Sind zwei Dreiecke/Faces konkav zueinander muss das komplette Brush in zwei Dreiecks-Brushes geteilt werden, damit kein Error entsteht.
• Wie in der .rmf zu sehen, sind zwei oder mehr Dreiecke oft ein einziges Brush! Solange diese Dreiecke konvex zueinander sind, gibt es kein Error und es spart Planes, die bei der Teilung in mehrere Brushes entstehen würden.

Diese komplexere Form eines Brushes kann man durch Clipping (ohne Erklärung) oder das Vertex-Tool erreichen. Wer Erfahrung mit dem Vertex-Tool hat, weiss, dass man mit „strg+f“ Brush-formen manipulieren kann wie in folgendem Beispiel:

Damit ist aber viel mehr möglich. Man kann zwei gelbe oder zwei weisse Punkte eines Faces markieren und dort in dieses Face eine Kante einfügen! Beispiele:

Viele Brushes in der Beispiel-rmf haben diese Form. Vor dem Spalten des Faces sollte man wissen wie man das Terrain dort gestalten will, damit die beiden Dreiecke eines Brushes im Nachhinein nicht konkav zueinander sind. Also immer die richtige Diagonale des 224²-Faces wählen, um dort eine Kante einzufügen. ;)

Hier werden erst zwei gelbe Punkte markiert und eine Kante eingefügt. Durch Verschmelzen zweier weisser Eckpunkte entsteht dann die gewünschte Form. Der letzte Schritt sorgt dafür, dass die beiden neu entstandenen Dreiecks-Faces nicht coplanar sind.

Zum einen spart man ein paar Planes, wenn man zwei oder mehr Dreiecke aus einem Brush baut, außerdem ist die Wahrscheinlichkeit geringer, dass man an dieser Kante hängenbleibt, wenn man zu nahe daran vorbeiläuft.

Wichtig: WC stürzt öfter mal ab, wenn man zwei oder mehr Kanten hintereinander einfügt ohne vorher das Vertex-Tool kurz abzustellen. Also zwischen dem Einfügen der Kanten kurz Kamera o.ä. anwählen und dann wieder zum Vertex-Tool, damit WC nicht abstürzt. Häufiges Abspeichern wird empfohlen. Dazu kommt, das man öfter mal „coplanar Faces“ oder „invalid solid“ Errors bekommt, auch wenn man recht gut aufpasst. Selten korrigieren die Compiler auch selbst ein Brush, durch Verschiebung von ein/zwei Eckpunkten. Dadurch entstehen manchmal Leaks, die man nur in-game sieht, wenn diese Eckpunkte unglücklich verschoben wurden.

In allen drei Richtungen (x,y,z) muss man darauf achten, dass die Kanten der Faces weiterhin genau auf den Leaf-Kanten liegen. Das ganze zu Erklären wäre zu kompliziert, da es sehr viele Möglichkeiten gibt, das Terrain zu gestalten und trotzdem die vorhandenen Kanten beizubehalten. Ich habe versucht, genug Varianten in diese rmf einzubauen, damit man genug Möglichkeiten erfassen kann und versteht worauf es ankommt beim „entwickeln“ eigener Variationen. Wichtig ist zu wissen, dass zwischen den Leaf-Kanten alles mögliche gebastelt werden kann, Faces dürfen nur nicht über diese Kanten gehen, dann entstehen nämlich zusätzliche Zerschneidungen, die im Einzelfall aber nicht weiter tragisch sind! Auch hier zeigt „Show hidden objects“ die gruppierten Hint-Brushes und man kann Brush für Brush beobachten, wie die Kanten auf einer Linie liegen.

Da es bei dieser Methode meist um weitflächige Outdoor-Bereiche geht, sollte man auch beim Benutzen von Visblockern etwas umdenken. Sofern man nicht einen Höhlengang oder ähnliches mit S-Kurve als Visblocker benutzt, muss man das Zusammenspiel von Visblockern auf einer viel größeren Fläche entwickeln. Höhenunterschiede spielen eine größere Rolle, so kann man z.B. einen hohen, überquerbaren Berg/Hügel als Visblocker benutzen, wenn er ins Hintbrush-System passt. Ein guter Visblocker ist auch folgende Konstruktion, da er auch die Höhenunterschiede nutzt, zusätzlich nicht ganz soviel Platz einnimmt und für Abwechslung sorgt.

An der Linie auf dem zweiten Bild sieht man, dass man nicht auf die andere Seite sehen kann, sobald man auf dem Hügel über der Linie steht. Wichtig ist, dass sich genau auf dieser Linie die Kanten von zwei Hint-Brush Ebenen treffen. Außerdem muss der Visblocker mindestens auf oder sogar unter der Linie enden. Damit ist gegeben, dass der Visblocker die Leafs auf dem Hügel über der Linie blockiert.

Wer auf schönere 256²-Texturen setzen will, muss eine Menge Arbeit auf sich nehmen, aber es ist möglich, was zählt! Damit die Texturen weiterhin auf 224²-Flächen passen und man viele Variationen benutzen kann, muss man eine 224²-Textur nehmen/erstellen und einen 16 Units/Pixel Rand anfügen, um auf die 256² Pixel zu kommen!

In dem Beispiel-Pic sieht man, dass der äußere Rand der Textur zur eigentlichen Textur passen muss! Der Bilineare Filter und die Mip-Maps mit niedrigen Auflösungen für weite Entfernungen bringen sonst den Rand um ein oder mehr Pixel auf den in-game sichbaren Teil der Textur. Auf die Entfernung sieht man dann unschöne Ränder um jede Textur, was man vermeiden kann, indem der Rand um den sichtbaren Teil herum genauso wie die Textur aussieht, zumindest farblich!

In der rock_tut.wad sind ein paar Texturen als 224²- und 256²-Version enthalten. In vielen Fällen kann man die 256²-Textur durch centern (C im tex.-application-tool) anpassen! Hier sind die Beispielstellen in der rock_tut02.rmf:

Ein weiteres Mittel für schönes Terrain sind Texturübergänge ohne hässliche Ränder bzw. ohne sichtbare Kanten. Im folgenden Beispiel sieht man bei „1.“ , dass die Textur nicht genau an die umliegenden Texturen passt:

• Die Textur wird von einer anderen Achse aus auf das Face projeziert als die umliegenden Texturen.
• Mit Vertex-Mode den markierten Eckpunkt verschieben, sodass sich das betroffene Face mehr zu der Achse neigt, von der auch die umliegenden Texturen auf die umliegenden Faces projeziert werden.
• Vertex-Mode verlassen, das Face mit dem Tex-App-Tool auswählen. Der Haken bei „world“ ist durch das Neigen des Faces verschwunden. Jetzt bei „world“ einen Haken hinmachen, sodass die Textur von der naheliegensten Achse auf das Face projeziert wird.
• Mit Vertex-Mode den Eckpunkt wieder in die Ursprungslage bringen, sodass das Face wieder genau ins umliegende Brushwork passt. Der Haken bei „world“ sollte wieder verschwunden sein, aber die Textur wird jetzt von der gleichen Achse projeziert wie die benachbarten Texturen.

Bei zu stark geneigten Faces kann es passieren, dass die Textur nach dieser Behandlung zu verzerrt ist. Entweder man ändert die Neigung bzw. Das komplette Brushwork etwas ab oder man gibt sich mit hässlichen Texturkanten zufrieden!

In der 2. .rmf sind auch Clip-Brushes enthalten, die durch „show hidden objects“ sichtbar werden. Diese Clip-Brushes dienen zum einen der Reduzierung der Clip-Nodes, da sich die Berg-Brushes in ihnen befinden und somit deren Clip-Nodes durch die des Clip-Brushes ersetzt werden. Außerdem werden so einige Kanten entschärft, an denen der Spieler hängenbleiben oder aber auf die Berge kommen könnte. Trotzdem kann der Player an manchen Stellen blockiert werden, was möglicherweise an benachbarten Kanten liegt. Manchmal hilft schon das Verschieben von bestimmten Eckpunkten, um den Fehler zu beseitigen. Clip-Brushes sollte man in seiner eigenen Map erst setzen, wenn man den Error max_clipnodes bei hlbsp bekommt, oder aber das Layout wirklich fertig ist, sodass man diese Clip-Brushes nicht so oft löschen oder abändern muss.

Hinweis: es gibt einen wichtigen Compile-Parameter zu dieser Methode: hlbsp -maxnodesize 4096 (1024=default , 4096=maximal). Das bedeutet hlbsp macht spätestens alle 4096 Units einen Schnitt durch annähernd die komplette Map! Leider fallen diese Schnitte sogut wie nie auf eine der vielen Kanten alle 224 Units, deshalb darf es davon nur wenige geben, um niedrige wpolys beizubehalten! Ein weiterer Nachteil sind „Leaf Portal saw into Leaf…Error“ die manchmal an diesen Schnitten entstehen. Wird ein schiefes Dreieck/Face geschnitten entstehen darauf zwei neue Eckpunkt, welche nicht immer genau auf dem Grid liegen wodurch der Error ensteht ! Durch leichtes Um-vertexen beseitig man schon öfter den Error. Es kann sehr lästig sein, wenn sich die Positionen dieser langen Schnitte während der Entwicklung der Map verändern. Schon kleine Änderungen an der Map, können dazu führen, dass die Kanten alle 4096 Units von anderen Punkten aus beginnen.

Der .zip liegt auch eine rock_tut02.bsp bei, die man sich in Half-Life anschauen kann, um mit r_speeds 1 und gl_wireframe 1 bzw. 2 diese Methode in Aktion zu betrachten. In-Game sieht man auch die Unterschiede zwischen 224²- und 256²-Texes, die ich an zwei Stellen, statt 224² angebracht habe.

Ich wünsche jedem viel Spass und Erfolg beim Terrain-Mappen. Wer das ganze System verstanden hat, kann auch nur bestimmte Teile seiner Map damit bauen. Vorallem bei engen Indoor-Bereichen ist das System mehr lästig als nützlich!