VBSP, VVIS und VRAD erklärt: die drei Compile-Schritte

Beim Kompilieren wird aus deiner VMF in drei Schritten eine spielbare BSP: VBSP baut die Geometrie und prüft auf Leaks, VVIS berechnet, was von wo aus sichtbar ist, und VRAD berechnet das Licht. Die meiste Zeit kosten VVIS und VRAD. Für Tests nutzt du schnelle Einstellungen, für das Release einen vollständigen Compile.

Überblick: wer macht was

Die drei Programme vbsp.exe, vvis.exe und vrad.exe liegen im bin-Ordner des Spiels. Hammer ruft sie über F9 nacheinander auf und kopiert die fertige BSP in den Maps-Ordner. Alles, was die Programme ausgeben, landet zusätzlich in einer Log-Datei neben deiner VMF.

VBSP: Geometrie und Leaks

VBSP wandelt deine Brushes in Flächen um, entfernt Flächen, die außerhalb der Map liegen, und teilt den Innenraum in Visleafs auf. Außerdem schreibt es Entities, statische Props, Overlays und Displacements in die BSP.

Dabei prüft VBSP, ob die Map dicht ist. Es füllt den Raum ausgehend von den Entities und meldet ein Leak, sobald es den leeren Raum außerhalb erreicht. Im Log steht dann **** leaked ****, und VBSP schreibt eine Pointfile, die du in Hammer über Map > Load Pointfile als Linie zum Leck anzeigen kannst. Eine Portal-Datei entsteht in diesem Fall nicht. Die Folgen: VVIS kann nicht arbeiten, die Engine zeichnet immer die ganze Map, und das Licht wird nur unvollständig berechnet. Wie du das Leck findest, zeigt Map-Leak-Fehler beheben.

Nützlich für Tests ist der Parameter -onlyents. Er aktualisiert nur die Entities in einer bereits kompilierten BSP, ohne die Geometrie neu zu bauen. Das spart Zeit, wenn du nur Logik oder Einstellungen von Entities geändert hast. Brushes, auch die von Brush-Entities, bleiben dabei unverändert. In unserem Test mit dem VBSP von GMod wurden auch statische Props aktualisiert, Overlays nicht.

VVIS: Sichtbarkeit

VVIS liest die Portale zwischen den Visleafs und berechnet für jeden Bereich, welche anderen Bereiche von dort aus sichtbar sein könnten. Mit diesem Ergebnis entscheidet die Engine später, was sie überhaupt zeichnen muss.

Im Log erkennst du zwei Phasen: BasePortalVis ist eine grobe Vorberechnung, PortalFlow die genaue und meist deutlich längere Rechnung. Davor nennt das Log die Zahl der Portale. Sie bestimmt die Dauer am stärksten. Viele kleine World-Brushes und große offene Flächen erzeugen viele Portale.

• Mit -fast überspringt VVIS die genaue Rechnung. Der Compile ist schnell, die Engine zeichnet im Spiel aber mehr als nötig. Für ein Release ist das ungeeignet, und FPS-Messungen sind damit wertlos.
• Dauert VVIS zu lang, wandelst du Details in func_detail um und vereinfachst die World-Geometrie. Für große offene Bereiche gibt es func_viscluster. Details stehen in VVIS dauert ewig.

VRAD: Licht

VRAD berechnet für jede Fläche das direkte Licht, lässt es anschließend mehrfach von Oberflächen zurückwerfen und speichert das Ergebnis als Lightmaps. Dazu kommen Lichtdaten für statische Props und für bewegliche Objekte.

Die wichtigsten Parameter:

• -fast: schnelle, sichtbar gröbere Berechnung für Tests.
• -final: genauere Berechnung für das Release, deutlich langsamer.
• -ldr, -hdr, -both: legt fest, für welchen Helligkeitsumfang gerechnet wird. Mit -both läuft die Berechnung zweimal.
• -StaticPropLighting, -StaticPropPolys, -textureshadows: besseres Licht und genauere Schatten bei statischen Props.

Die Zeit hängt von der Größe der Map, der Zahl der Lichter und der Lightmap Scale ab. Kleine Werte für die Lightmap Scale auf großen Flächen sind ein häufiger Grund für sehr lange Laufzeiten. Im Log siehst du zuerst die direkte Beleuchtung (BuildFacelights), dann die einzelnen Bounces und am Ende eine Tabelle, die zeigt, wie voll die Datenbereiche der BSP sind. Alles zum Thema Licht steht in Source Engine Beleuchtung.

Einstellungen für Test und Release

Im normalen Dialog „Run Map“ wählst du für VIS zwischen „No“, „Normal“ und „Fast“. RAD hat in Hammer++ dieselben drei Stufen, im mitgelieferten Hammer kommen „Faster“ und „Final“ dazu. Bei BSP ist die dritte Option „Only entities“ statt eines schnellen Modus. Über „Expert“ kommst du zu fertigen Profilen und kannst die Parameter einzeln bearbeiten.

Nach dem Release-Compile folgen noch zwei Arbeiten, die nicht zu den drei Programmen gehören: Cubemaps im Spiel bauen und eigene Inhalte in die BSP packen. Wie das geht, steht in Custom Content in BSP packen.

Wenn der Compile scheitert

Lies das Log von oben nach unten und suche den ersten Fehler. Spätere Meldungen sind oft nur Folgen davon. Ein Leak in VBSP führt zum Beispiel dazu, dass VVIS die Portal-Datei nicht findet. Wer nur die letzte Meldung liest, sucht dann an der falschen Stelle.

Du kannst das Log auch im Map Scanner einfügen. Er erkennt in VBSP-, VVIS- und VRAD-Logs Ursachen, Folgefehler und passende Lösungswege.

Häufige Fragen

Warum dauert VVIS so lange?

Die Dauer hängt von der Zahl der Portale ab, und die steigt mit jedem World-Brush, der den Raum zerschneidet. Wandle Details in func_detail um und halte die abdichtende Geometrie einfach. Große offene Flächen sind grundsätzlich teurer als verwinkelte Innenräume.

Kann ich VVIS oder VRAD überspringen?

Für Tests ja. Ohne VVIS zeichnet die Engine immer die ganze Map, ohne VRAD ist die Map gleichmäßig hell und schattenlos. Für eine veröffentlichte Map brauchst du beide Schritte vollständig.

Was bedeutet „leaked“ im Log?

Der Innenraum der Map ist nicht vollständig von World-Brushes umschlossen, oder ein Entity liegt außerhalb. VBSP erzeugt dann keine Portal-Datei, und die folgenden Schritte liefern kein brauchbares Ergebnis. Behebe das Leck, bevor du andere Fehler untersuchst.

Muss ich nach jeder Änderung alles neu kompilieren?

Nach Änderungen an Brushes ja, denn Geometrie, Sichtbarkeit und Licht hängen voneinander ab. Hast du nur Entity-Einstellungen ohne Lichtwirkung geändert, reicht für einen Test ein VBSP-Lauf mit -onlyents. Overlays und Brushes aktualisiert er nicht, und für das Release kompilierst du vollständig.