Mapping & Hammer

func_detail oder World-Brush: was in Hammer wohin gehört

func_detail oder World-Brush? Klare Regeln mit Messwerten aus einem Test-Compile: was abdichtet, was Visleafs zerschneidet und welche Fehler zu Leaks führen.

Ein Brush bleibt World-Brush, wenn er die Map nach außen abdichtet oder die Sicht zwischen zwei Bereichen blockiert: Außenwände, Böden, Decken und Trennwände. Die übrigen soliden Brushes werden func_detail, also Säulen, Stufen, Rahmen, Leisten und Möbel. Der Grund ist die Sichtbarkeitsberechnung: Nur World-Brushes zerschneiden den Raum in Visleafs und Portale. In einem Testraum mit 64 Säulen meldete VVIS 180 Portale, mit denselben Säulen als func_detail waren es 4.

Was World-Brushes für die Sichtbarkeit tun

VBSP baut aus den World-Brushes einen BSP-Baum. Jede Ebene, auf der eine Brush-Fläche liegt, kann den Raum teilen. Übrig bleiben konvexe Raumstücke, die Visleafs, und zwischen benachbarten Leafs die Portale. Aus demselben Baum entstehen zwei weitere Dinge:

  • Abdichtung: VBSP füllt den Baum von den Entities aus. Erreicht die Füllung das Void, meldet es **** leaked ****.
  • Flächen: Sichtbare Flächen werden entlang der Schnitte zerteilt, viele Schnitte bedeuten also viele kleine Flächen.

Im Quelltext von VBSP, den Valve mit dem Source SDK 2013 veröffentlicht hat, ist die Reihenfolge eindeutig: Baum, Portale und Leak-Test entstehen ausschließlich aus Brushes ohne Detail-Markierung. Die Detail-Brushes kommen erst danach dazu.

Was func_detail daran ändert

func_detail ist keine Entity, die im Spiel existiert. VBSP verschiebt ihre Brushes beim Laden in die Welt, markiert sie als Detail und verwirft die Entity. Daraus folgt:

  • Kein Einfluss auf die Sichtbarkeit. Detail-Brushes erzeugen keine Visleafs und keine Portale, blockieren aber auch keine Sicht.
  • Keine Abdichtung. Beim Leak-Test fehlen sie.
  • Weiterhin solide. In der BSP tragen sie weiter die Markierung für solide Geometrie. Spieler und Props kollidieren damit wie mit jeder Wand.
  • Kein Name, keine Inputs. Die FGD definiert außer den DirectX-Stufen keine Keyvalues, im Spiel lässt sich func_detail weder bewegen noch ausblenden.
  • Welt-Flächen bleiben ganz. Laut FGD wird eine Wand nicht zerschnitten, wenn ein Detail daran sitzt.

Im Compile-Log erkennst du Detail-Brushes an drei zusätzlichen Zeilen von VBSP:

Chop Details...done (0)
Find Visible Detail Sides...done (0)
Merging details...done (0)

Der Test: 64 Säulen als World-Brush und als func_detail

Für diesen Artikel wurde ein Raum von 2048 mal 2048 Units und 256 Units Höhe mit den Compilern von GMod kompiliert: einmal leer, einmal mit einem Raster aus 64 Säulen (32 mal 32 Units, vom Boden bis zur Decke) als World-Brushes und einmal mit denselben Säulen als func_detail.

MesswertLeerer RaumSäulen als World-BrushSäulen als func_detail
portalclusters (VVIS)41004
numportals (VVIS)41804
Flächen in der BSP96560352
davon Bodenflächen3614036
Brushes in der BSP67070

Für VVIS ist der Raum mit Detail-Säulen identisch mit dem leeren Raum. Die Zahl der Brushes bleibt gleich, func_detail entlastet also nicht die Brush-Grenze aus Source Engine Map-Limits. Die World-Säulen zerteilen außerdem den Boden in viele kleine Flächen, unter Detail-Säulen bleibt er in denselben 36 Stücken wie im leeren Raum.

Die 180 Portale bringen dabei nichts: VVIS meldete im Durchschnitt 92 von 100 Clustern als sichtbar, denn schmale Säulen verdecken kaum etwas.

Beide Varianten kompilieren in unter einer Sekunde. Der Test zeigt also den Mechanismus, nicht die Wartezeit. Auf einer ganzen Map summiert sich der Effekt zu den Compile-Zeiten aus dem Artikel VVIS dauert ewig.

Regeln: was Detail wird und was nie

BauteilTypGrund
Außenwände, Boden und Decke der HülleWorld-Brushdichten die Map ab
Trennwände und Geschossdecken zwischen RäumenWorld-Brushblockieren die Sicht
Säulen, Träger, Kisten, Möbel aus Brushesfunc_detailverdecken fast nichts, erzeugen viele Schnitte
Stufen, Geländer, Fenster- und Türrahmen, Leistenfunc_detailreine Dekoration
Bögen, Zylinder, gedrehte und schräge Formenfunc_detailschneiden den Raum in ungünstigen Winkeln

Die Prüffrage für jeden Brush lautet: Wäre die Map undicht, oder könnte man in einen anderen Bereich sehen, wenn dieser Brush fehlte? Wenn ja, bleibt er World-Brush. Wenn nein, markierst du ihn und machst ihn mit Strg+T (Tie to Entity) zum Detail.

Typische Fehler

Der häufigste Fehler ist ein Detail-Brush als Teil der Außenhülle. Im Test wurde eine der vier Wände zu func_detail. VBSP meldete den Leak und schrieb keine Portal-Datei. Die dritte Zeile stammt von VVIS, das deshalb abbrach (Pfad gekürzt):

**** leaked ****
Entity info_player_start (256.00 256.00 1.00) leaked!
LoadPortals: couldn't read ...\d_wall_detail.prt

Die Lösung: Brush markieren und mit Strg+Umschalt+W (Move to World) zurück in die Welt verschieben. Wie du die Stelle findest, steht in Map-Leak-Fehler beheben. Weitere Fehler mit derselben Ursache:

  • Ein Loch, das nur ein Detail verschließt. Ein Fensterrahmen oder eine Säule in der Ecke füllt eine Lücke in der Hülle. Im Editor sieht das dicht aus, für VBSP ist dort ein Loch.
  • Areaportal im Detail-Rahmen. Auch die Bereiche für Areaportals bestimmt VBSP, bevor die Detail-Brushes dazukommen. Die Öffnung, in der ein func_areaportal sitzt, muss deshalb von World-Brushes umschlossen sein. Mehr dazu in Areaportals, Hints und Occluder.
  • Alles ist Detail. Dann gibt es keine Sichtblocker mehr, und die Engine zeichnet Räume, die hinter Wänden liegen. Den Zusammenhang erklärt GMod Map optimieren.

func_brush, Props und Displacements im Vergleich

TypZerschneidet VisleafsDichtet abIm Spiel ansprechbar
World-Brushjaja, außer mit durchscheinendem Materialnein
func_detailneinneinnein
func_brushneinneinja
prop_staticneinneinnein
Displacementneinneinnein

func_brush nimmst du, wenn ein Brush im Spiel etwas tun soll: Er hat einen Namen, lässt sich über die Inputs Enable und Disable schalten und über den Keyvalue „Solidity“ durchlässig machen. Dafür ist er eine echte Entity und belegt zur Laufzeit einen Platz, siehe Edict-Limit und „no free edicts“. Lightmap-Schatten wirft er laut FGD nur, wenn du „Shadows“ auf „Yes“ stellst.

Fein geformte oder oft wiederholte Objekte sind als Model besser aufgehoben, siehe prop_static, prop_dynamic und prop_physics. Gelände baust du als Displacement mit einem einfachen World-Brush darunter. Im Test führte eine Außenwand mit Displacement-Fläche genauso zum Leak wie die Detail-Wand.

Die Wirkung sichtbar machen

Die wichtigste Kontrolle steht am Anfang der VVIS-Ausgabe. So sah sie im Test mit den World-Säulen aus:

 100 portalclusters
 180 numportals

Notiere numportals vor und nach einer Änderung. Daneben helfen diese Werkzeuge:

  • Portal-Datei laden. Map > Load Portal File zeigt die Portale der letzten Kompilierung im Editor. VBSP schreibt die .prt-Datei neben die VMF, aber nur, wenn die Map keinen Leak hat.
  • Details ausblenden. In der Visgroup-Liste gibt es unter „Auto“ den Eintrag „World Details“. Ohne Haken verschwinden die Detail-Brushes. Die World-Brushes, die übrig bleiben, sind die Hülle, mit der VBSP rechnet.
  • Ohne Details kompilieren. Der VBSP-Parameter -nodetail entfernt laut Hilfetext die gesamte Detail-Geometrie. Was übrig bleibt, bestimmt die Sichtbarkeit.
  • Log prüfen lassen. Der Map Scanner erkennt in VBSP-, VVIS- und VRAD-Logs Ursachen, Folgefehler und passende Lösungswege.

Häufige Fragen

Macht es einen Unterschied, ob ich mehrere Brushes zu einem func_detail zusammenfasse?

Für das Ergebnis nicht. VBSP verschiebt alle Detail-Brushes in die Welt und verwirft die Entity. Wie du gruppierst, ist reine Ordnung im Editor.

Wie baue ich eine runde Außenwand?

In zwei Schichten: außen eine einfache, gerade Hülle aus World-Brushes, die abdichtet, davor die runde Form als func_detail. Die Seiten der Hülle, die niemand sieht, belegst du mit tools/toolsnodraw.

Warum hat mein leerer Raum trotzdem mehrere Visleafs?

Weil VBSP zusätzlich entlang eines festen Rasters schneidet: laut Quelltext des SDK 2013 alle 1024 Units auf der X- und Y-Achse. Der leere Testraum von 2048 mal 2048 Units bestand aus vier Visleafs, und alle vier Portale lagen auf den Linien bei 1024 Units.