VVIS dauert ewig? So verkürzt du die Compile-Zeit

VVIS rechnet stundenlang, wenn deine Map zu viele Visleafs und Portale enthält. Die häufigste Ursache ist Detailgeometrie, die als Welt-Brush gebaut wurde. Wandle alles, was die Sicht nicht großflächig blockiert, in func_detail um. Das senkt die Zahl der Portale und damit die Rechenzeit meist drastisch.

Was VVIS eigentlich berechnet

VBSP zerlegt den Innenraum deiner Map in Visleafs. Das sind konvexe Raumstücke, die durch die Flächen der Welt-Brushes begrenzt werden. Wo zwei Visleafs aneinandergrenzen, entsteht ein Portal. VVIS berechnet anschließend, welche Visleafs sich über diese Portale gegenseitig sehen können. Die Engine nutzt das Ergebnis im Spiel, um nicht sichtbare Bereiche gar nicht erst zu rendern.

Der Aufwand wächst nicht gleichmäßig mit der Größe der Map. Mit jedem zusätzlichen Portal steigt die Zahl der Kombinationen, die geprüft werden müssen, überproportional. Deshalb kann eine einzige unglücklich gebaute Halle mehr Zeit kosten als der gesamte Rest. Den Zusammenhang der drei Compile-Tools erklärt der Artikel VBSP, VVIS und VRAD.

Portal-Zahl im Log lesen

Zu Beginn nennt VVIS zwei Zahlen, bevor die eigentliche Rechnung startet. Das folgende Beispiel zeigt den Aufbau:

 842 portalclusters
2302 numportals
BasePortalVis:       0...1...2...3...4...5...6...7...8...9...10 (3)
PortalFlow:          0...1...2...3...

numportals ist dein wichtigster Messwert. Einen festen Grenzwert gibt es nicht, weil die Rechenzeit auch von Prozessor und Raumaufteilung abhängt. Entscheidend ist der Vergleich: Notiere die Zahl vor einer Änderung und danach. Sinkt sie deutlich, bist du auf dem richtigen Weg.

Die lange Phase ist PortalFlow. Solange dort weitere Ziffern erscheinen, arbeitet VVIS noch und hängt nicht. Wie du die übrigen Zeilen deutest, zeigt der Artikel Compile-Log lesen.

Warum zu viele Portale entstehen

• Details als Welt-Brushes: Jede Fläche eines Welt-Brushes kann den Raum weiter zerschneiden. Säulen, Treppenstufen, Fensterrahmen, Zierleisten, Geländer und Möbel aus Brushes erzeugen dadurch viele winzige Visleafs.
• Schräge und runde Formen: Zylinder, Bögen und gedrehte Brushes schneiden den Raum in besonders ungünstigen Winkeln.
• Große offene Bereiche: In einer weiten Außenfläche sehen sich fast alle Visleafs gegenseitig. VVIS muss trotzdem jede Kombination prüfen.
• Unnötiger Hohlraum: Ein riesiger Kasten um die Map oder weite Lufträume über dem Spielbereich vergrößern das Volumen, das zerlegt wird.
• Zu viele Hints: Jeder Hint-Brush fügt Schnitte und damit Portale hinzu.

Lösungen in der Reihenfolge ihrer Wirkung

1. Details umwandeln. Markiere die Brushes, drücke Strg+T und wähle func_detail. Die Faustregel: Welt-Brush bleibt nur, was die Map abdichtet oder die Sicht großflächig blockiert, also Außenwände, Böden, Decken und Trennwände zwischen Räumen.
2. Die Hülle vereinfachen. Baue Räume aus geraden, einfachen Welt-Brushes und setze die sichtbare Form als func_detail davor. Runde Wände und Bögen gehören nie in die Welt-Geometrie.
3. Props und Displacements nutzen. Models und Displacements zerschneiden den Raum nicht. Gelände baust du als Displacement mit einem einfachen Brush darunter, der tools/toolsnodraw trägt.
4. Offene Bereiche zusammenfassen. Mit func_viscluster markierst du ein Volumen, in dem sich ohnehin alles gegenseitig sieht. VVIS behandelt die Visleafs darin als gegenseitig sichtbar und spart sich die Einzelprüfung.
5. Hints gezielt setzen. Ein Hint-Brush trägt auf der Schnittfläche tools/toolshint und auf allen anderen Seiten tools/toolsskip. Setze ihn nur dort, wo ein bestimmter Schnitt die Sichtbarkeit wirklich verbessert, zum Beispiel an einer Flurecke.
6. Ergebnis kontrollieren. Über Map → Load Portal File zeigt Hammer die Portale der letzten Kompilierung an. Im Spiel blendet mat_leafvis 1 das Visleaf ein, in dem du gerade stehst; der Befehl braucht sv_cheats 1.

Achte bei Schritt 1 darauf, dass func_detail nicht abdichtet. Wandelst du versehentlich eine Außenwand um, meldet VBSP einen Leak. Was dann zu tun ist, steht im Artikel Map-Leak-Fehler beheben.

Was -fast bewirkt und wann es sinnvoll ist

Mit dem Parameter -fast überspringt VVIS die genaue Berechnung und liefert nur ein grobes Ergebnis. In Hammer entspricht das der Einstellung „Fast“ bei „Run VIS“. Der Compile ist schnell fertig, aber die Engine hält im Spiel deutlich mehr für sichtbar, als tatsächlich zu sehen ist. Die Bildrate leidet.

Eine Map, die du veröffentlichst oder verkaufst, braucht die volle Berechnung. Wenn die nur mit -fast in vertretbarer Zeit durchläuft, ist das ein Zeichen für ein Strukturproblem und kein Grund, die Abkürzung zu behalten. Weitere Maßnahmen für die Bildrate findest du im Artikel GMod-Map optimieren.

Wenn VVIS trotzdem lange braucht

• Kompiliere mit dem Cordon-Werkzeug einzelne Abschnitte und vergleiche numportals. So findest du den Bereich, der die meisten Portale erzeugt.
• Lade die Portal-Datei in Hammer und suche Stellen, an denen sich die Linien stark verdichten. Dort steht fast immer vergessene Detailgeometrie.
• Prüfe, ob im Log zusätzlich Warnungen oder Fehler stehen. Im Map Scanner kannst du ein Compile-Log einfügen. Er erkennt in VBSP-, VVIS- und VRAD-Logs Ursachen, Folgefehler und passende Lösungswege.

Häufige Fragen

Wie lange darf VVIS dauern?

Einen festen Wert gibt es nicht. Eine sauber aufgebaute Map ist meist in Minuten fertig, sehr große Maps brauchen entsprechend länger. Rechnet VVIS über Stunden, liegt das fast immer an der Geometrie und nicht an der Hardware.

Kann ich VVIS einfach überspringen?

Für schnelle Tests ja. Für einen Release nein, denn ohne Sichtbarkeitsdaten rendert die Engine jederzeit die gesamte Map. Auf größeren Maps bricht die Bildrate dann ein.

Verkürzen Areaportale die VVIS-Zeit?

Nein. Areaportale wirken zur Laufzeit und blenden im Spiel Bereiche aus, die hinter einer Öffnung nicht zu sehen sind. Sie verbessern die Bildrate, lösen aber kein Compile-Problem.

Macht func_detail die Map im Spiel langsamer?

Nein, solange du es richtig einsetzt. func_detail blockiert allerdings keine Sicht. Wände, die zwei Räume voneinander trennen, müssen deshalb Welt-Brushes bleiben, sonst rendert die Engine beide Räume gleichzeitig.