Quake 3 Radiant: Performanceoptimierung mit -vis und Hint

Last Updated on 31. January 2023 by Victor Karp

Was ist eigentlich -vis?

Wenn ihr eure Map über das Build Menü kompiliert, seht ihr vor allen Einträgen immer die drei Kürzel BSP, -vis oder -light. Was -vis bedeutet, werdet ihr vermutlich noch nicht herausgefunden haben. Dabei ist -vis sehr wichtig, wenn eure Map erstmal fertig ist. In diesem Tutorial erkläre ich euch genau, was -vis macht und wie man es positiv beeinflussen kann.

Für dieses Tutorial habe ich eine kleine Testmap mit vielen abknickenden Gängen angelegt. Darin sind einige Munitionspakete verstreut. Von oben sieht das so aus:

Wenn ich die Map nur mit BSP -meta kompiliere, sie dann starte und in die Konsole /r_showtris 1 eintippe, sind auf einmal weiße Linien um sämtliche Geometrie zu sehen.

Oberflächen werden in Spielen immer in Dreiecke aufgeteilt. Jedes Dreieck wird als Triangle bezeichnet. Je mehr Triangles gleichzeitig berechnet werden müssen, desto mehr muss euer PC ackern. Im schlimmsten Fall fängt es sogar an zu ruckeln.

Man sieht deutlich, dass der PC auch Triangles berechnet, die hinter mehreren Wänden liegen und somit für den Spieler uninteressant sind. Auf dem nächsten Bild habe ich eingezeichnet, was der Spieler tatsächlich sehen kann, wenn er sich in alle Richtungen vom Startpunkt aus dreht.

Wäre die Map voll mit Details, würden wir unnötig Performance verlieren. Deshalb gibt es den Compileschritt -vis. Der sorgt dafür, dass eure Map in Sichtbarkeitsareale unterteilt wird. Das geschieht alle 1024 Units automatisch. In unserer Map bringt uns das aber nicht weiter, da sie sehr klein ist. Außerdem muss man den Compiler immer ein bisschen an die Hand nehmen, damit er weiß, wo er Areale erstellen soll.

Hint und hintskip

Dafür gibt es die Texturen common/hint und common/hintskip. Belegt ihr einen Brush mit der hint Textur, so wird der Compiler während der -vis Berechnung an allen Oberflächen, an denen er diese Textur findet, einen Schnitt machen und einen neuen Sichtbarkeitsbereich erzeugen.

Das Problem dabei: ein Brush hat 6 Faces, wir brauchen aber nur eins davon, um eine neue portal area zu erzeugen. Belegen wir jedoch alle Faces mit hint, werden an allen sichtbaren Oberflächen des Brushes unnötige, zusätzliche Portalbereiche erzeugt.

Die Lösung liefert die hintskip Textur. Sie funktioniert genau wie die nodraw Textur – Oberflächen, die mit ihr belegt werden, sind unsichtbar, nicht massiv und erzeugen keine neuen portal areas. Der wichtige Unterschied: hintskip ist transparent und erleichtert somit das Navigieren im Editor, wenn die Darstellung von hint Brushes aktiviert ist (hint Brushes lassen sich mit [Strg]+[H] ein- und ausblenden).

Die Map wird zerlegt

Wir werden unsere Map mit Hilfe dieser hint und hintskip Brushes in sinnvolle Abschnitte unterteilen. Dabei müsst ihr versuchen, die Areale so abzugrenzen, dass man von einem Areal in möglichst wenige andere Areale sehen kann. Je besser ihr die Map mit Portalen ausstattet, umso flüssiger wird sie später laufen.

Auf den folgenden zwei Bildern seht ihr, wie ich die Map unterteilen würde. Die Brushes habe ich dazu erst einmal komplett mit der hintskip Textur belegt. Nur die eine Oberfläche, an der ich eine neue portal area erzeugen möchte, ist mit hint belegt.

Ladet euch die Map jetzt herunter, um dem Tutorial besser folgen zu können.

Die Brushes schließen die Gänge “luftdicht” ab. Das ist wichtig, da die Portale sonst nicht funktionieren. Achtet in der Beispielmap auf die Oberflächen, die mit hint texturiert sind: sie gehen haargenau an den Ecken der Wände vorbei. Was durch diese Verteilung von hint Brushes im Detail passiert, zeigt euch folgendes Bild:

Ich habe jedes Areal eingefärbt. Mit Hilfe dieser Farben kann ich am Einfachsten erklären, wie die hint Portale funktionieren.

Stellt euch vor, der Spieler steht im grünen Areal. Er kann nur in die gelbe Areale und das kleine braune Areal sehen, alle anderen haben keine direkte Sichtlinie – und werden im Spiel auch nicht berechnet. Im dunkelgrauen Areal sieht er nur rot, gelb und braun, im pinkfarbenen Areal nur hellgrau, türkis und blau usw.

Kompiliert ihr die Map mit BSP -meta und -vis und startet sie, sieht man den Unterschied zur Version ohne hint portale sofort (mit eingeschaltetem /r_showtris):

Man kann gut erkennen, dass die ganzen anderen Munitionspakete und viele Wände nicht mehr berechnet werden, unser Ziel ist somit erreicht.

Portale mit prtview überprüfen

Wie die tatsächliche Portalstruktur letzten Endes aussieht, lässt sich mit dem bereits vorinstallierten Plugin prtview herausfinden. Bevor wir es benutzen können, müssen wir ein paar Vorbereitungen treffen.

Während eines -vis Compiles wird eine .prt Datei erstellt. Diese wird normalerweise nach dem Compile wieder gelöscht. prtview kann diese Datei laden und im Editor grafisch darstellen. Daher müssen wir zuerst dafür sorgen, dass die Datei überhaupt gespeichert wird. Damit das gelingt, müsst ihr die Map mit dem Parameter -vis und zusätzlich -saveprt in der vis Stage kompilieren. Wie ihr eigene Compileparameter benutzen könnt, steht in Tutorial 26 im Abschnitt “Die Variablen des Menüs anpassen”. Wenn ihr das Tutorial gelesen habt, können wir weitermachen.

Kompiliert die Map erneut mit BSP -meta und daraufhin mit -vis -saveprt. Klickt dann oben in der Werkzeugleiste auf Plugins – prtview – Load .prt File. Im folgenden Fenster könnt ihr angeben, ob die Portale in den 2D und der 3D Ansichten gezeigt werden sollen. Nach einem Klick auf OK müsstet ihr dieses Ergebnis angezeigt bekommen:

In einer richtigen Map kann diese Funktion zum Aufspüren von Portalproblemen genutzt werden. Sehr kleine Portale sind zu vermeiden, und die Anzahl der Portale ist so niedrig wie möglich zu halten. Portale sind zwar in die .bsp einkompiliert, müssen aber während des Spiels abgerufen werden. Ein simples aber effizientes Portallayout bringt mehr Performancegewinn als viele kleine Portale, die das Spiel eher ins Stottern bringen.

Wirklich nutzen könnt ihr das in diesem Tutorial erlangte Wissen erst, wenn ihr das folgende Tutorial über Detailbrushes gelesen habt. Darin lernt ihr eine elementar wichtige Komponente von VIS, die dieses Tutorial gesprengt hätte.

Was man unbedingt beachten muss

Die -vis Berechnung funktioniert nur dann, wenn eure Map kein Leak besitzt. Viele Anfänger ziehen deshalb einen großen dichten Kasten um ihre Map. Das solltet ihr aus folgendem Grund nicht tun.

Angenommen, ihr habt eine verschachtelte Map, die eigentlich super für vis-Berechnungen geeignet wäre, weil die Sicht nie allzu weit reicht, durch Ecken und Kurven abgeschnitten ist und unterteilt werden kann. Wenn ihr aber ungenau gearbeitet habt und überall Ritzen und Löchen in den Wänden sind, werden diese beim vis-Compiling mit einbezogen. Für den vis-Compiler sind dann große Bereiche sichtbar, die man eigentlich gar nicht sehen müsste. Der bsp Kompiler kann durch diese Löcher auch nicht entscheiden, wo die Außenseiten eurer Map liegen und diese deshalb nicht löschen. Als Lösung einen großen Kasten um die Map zu bauen ist so, als wollte man ein Loch in einem Eimer flicken, indem man ihn in einen größeren Eimer stellt.

Weitere -vis Texturen

Es gibt noch zwei andere Texturen für die vis-Optimierung, common/areaportal und common/clusterportal. Auf die werde ich jedoch in einem anderen Tutorial eingehen. Fürs Erste könnt ihr ein wenig mit den Hintportalen herumexperimentieren.

Automatisches Setzen von vis Portalen konfigurieren

Wie am Anfang des Tutorials geschrieben, unterteilt der Compiler jede Map standardmäßig alle 1024 Units. Wer volle Kontrolle über vis Portale haben will, kann dieses Feature beeinflussen.

Markiert dazu einen beliebigen Brush, der kein Brush Entity ist und drückt [N]. Ihr habt dann den so genannten Worldspawn selektiert und könnt einige wichtige Dinge, die die gesamte Map betreffen, konfigurieren.

Gebt als neuen Key _blocksize an. Als Wert brauchen wir drei Zahlen. Die Standardeinstellung ist 1024 1024 0. Das bedeutet, dass auf der x- und y-Achse alle 1024 Units ein Portal erstellt wird, auf der z-Achse hingegen keine Unterteilungen gemacht werden. Gebt testweise einen Wert von 512 512 0 an und schaut euch das Ergebnis mit prtview an.

Wer gar keine regelmäßig gesetzten Portale haben will, gibt als Value einfach nur 0 (Null) an. Das Feature wird dann komplett deaktiviert.

Auf keinen Fall solltet ihr es mit den automatischen Portalen übertreiben. Zu kleine Werte führen zum Abbruch des Compilevorgangs, da zu viele Portale vorhanden sind. Ein geschicktes Hinting mit wenigen Portalen ist effizienter als unkonfiguriertes “Schachbrett-Hinting”.

Mehr Informationen über weitere Einstellungen im Worldspawn gibt es in Tutorial 29.

Besuche die Quake 3 Mapping Tutorial Hauptseite für weitere Tutorials.