BSP-Dateigröße verkleinern: was Maps groß macht und was hilft

Eine BSP wird fast immer durch drei Dinge groß: Lightmaps, die bei einem HDR-Compile doppelt gespeichert werden, gepackte Inhalte im Pakfile und HDR-Cubemaps. Miss zuerst, welcher Block bei deiner Map dominiert. Danach helfen gezielt eine höhere Lightmap Scale auf großen Flächen, sparsames Packen und kleine Cubemaps. Die Kompression der fertigen BSP ist der letzte Schritt und ersetzt das nicht.

Was in einer BSP den Platz belegt

Eine BSP besteht aus Datenblöcken, den Lumps. Ihren Aufbau erklärt Was ist eine BSP-Datei?. Für die Größe zählen wenige davon:

Zwei Stock-Maps von GMod zeigen, wie verschieden das ausfällt (1 MB = 1 000 000 Byte):

• gm_construct hat 36,7 MB. Davon sind 24,5 MB Lightmaps: 12,3 MB für LDR und exakt dieselbe Menge noch einmal für HDR. Das Pakfile belegt 3,8 MB, darin 2,1 MB HDR-Cubemaps und 1,4 MB Prop-Licht. Die Kollisionsdaten kommen auf 3,1 MB, die Lumps der 110 Displacements zusammen auf 0,8 MB.
• gm_flatgrass hat 47,4 MB, obwohl die Map fast leer ist. 41,6 MB davon sind das Pakfile, und darin stecken 39,1 MB in nur acht HDR-Cubemaps.

Messen, bevor du kürzt

Am Ende seines Logs listet VRAD alle Datenbereiche auf. In der Spalte Memory steht vor dem Schrägstrich die Größe in Byte. Die Zeilen, auf die es ankommt, sehen so aus (aus einer kleinen Testmap):

Object names       Objects/Maxobjs  Memory / Maxmem  Fullness
LDR lightdata         [variable]       36320/0        ( 0.0%)
HDR lightdata         [variable]       36320/0        ( 0.0%)
pakfile               [variable]       24864/0        ( 0.0%)
physics               [variable]        4178/4194304  ( 0.1%)

Was im Pakfile steckt, zeigt bspzip. Der erste Befehl listet nur die Namen. Der zweite schreibt das Pakfile als ZIP-Datei heraus, in der du im Archivprogramm nach Größe sortieren kannst:

bspzip -dir meinemap.bsp
bspzip -extract meinemap.bsp pakfile.zip

Der Map Scanner zeigt zu einer hochgeladenen BSP ebenfalls die Dateigröße, die Zahl der Pakfile-Dateien und einen Auszug daraus.

Lightmaps: Scale und HDR

Die Lightmap Scale gibt an, wie viele Units ein Lichtpunkt (Luxel) abdeckt. Jeder Luxel belegt vier Byte, und Flächen mit Bumpmap speichern laut Valve-Wiki die vierfache Menge. Halbierst du die Scale, vervierfacht sich die Zahl der Luxel ungefähr. In unserer Testmap mit zwei Räumen belegte das Licht bei Scale 32 rund 10 KB, beim Standardwert 16 rund 36 KB und bei Scale 4 rund 564 KB.

• Erhöhe die Scale auf großen, gleichmäßig beleuchteten Flächen auf 32 oder 64. Der Preis sind weichere, ungenauere Schattenkanten.
• Senke sie nur dort, wo ein Schatten wirklich scharf sein muss.
• Belege Flächen, die niemand sieht, mit tools/toolsnodraw. VBSP entfernt sie, und damit entfällt ihre Lightmap.
• In Hammer zeigt die 3D-Ansicht „3D Lightmap Grid“ die Luxel-Dichte jeder Fläche.

Der zweite große Hebel ist HDR. VRAD kennt -ldr, -hdr und -both. Der Hilfetext des VRAD von GMod führt die drei Parameter nicht auf, das Programm nimmt sie aber an. Ohne einen davon rechnet es nur LDR. Mit -both schreibt VRAD einen zweiten Lighting-Lump derselben Größe, bei -StaticPropLighting zusätzlich eine zweite .vhv-Datei pro Prop, und du baust die Cubemaps zweimal. Eine reine LDR-Map ist deshalb deutlich kleiner, verzichtet aber für alle Spieler auf HDR. Die Abwägung beschreibt Source Engine Beleuchtung.

Pakfile: Inhalte und Cubemaps

Packe nur, was die Map benutzt, und nichts, was jeder Spieler mit dem Spiel ohnehin hat. Den größten Anteil haben fast immer Texturen. Auflösung, Format und die Prüfung der Liste behandelt Custom Content in BSP packen.

Unterschätzt werden Cubemaps. buildcubemaps schreibt pro env_cubemap eine Textur ins Pakfile, bei einer HDR-Map zusätzlich eine .hdr.vtf. Die HDR-Fassung speichert 16 Bit pro Kanal und ist in den beiden Stock-Maps rund sechzehnmal so groß wie die komprimierte LDR-Fassung: Bei 32x32 sind es rund 77 KB, bei 256x256 dagegen 4,9 MB. Jede Stufe im Feld „Cubemap Size“ vervierfacht die Datei. Lass die Größe deshalb auf „Default“ und erhöhe sie nur für einzelne Stellen mit großen spiegelnden Flächen. Mehr zu Cubemaps steht in Cubemaps und Reflexionen beheben.

Finger weg von bspzip -deletecubemaps bei einer gepackten Map: Laut Valve-Wiki löscht der Befehl alle VTF-Dateien im Pakfile und nicht nur die Cubemaps.

Die BSP komprimieren: bspzip -repack -compress

bspzip kann eine fertige BSP neu packen und dabei mit LZMA komprimieren. Die Datei bleibt eine .bsp. Laut Valve-Wiki lädt die Engine von GMod solche Maps, und im Änderungsprotokoll von GMod vom März 2025 ist die LZMA-Dekompression für BSP-Dateien ausdrücklich erwähnt.

Der Haken liegt beim Werkzeug. Das bspzip von GMod nennt die Option in seinem Hilfetext, in unserem Test (Build vom 3. September 2026, 32 und 64 Bit) beendete es sich bei -repack -compress aber mit Exit-Code 1, ohne Ausgabe, und ließ die Datei unverändert. -repack allein funktionierte. Das Valve-Wiki verweist für GMod deshalb auf das bspzip von Team Fortress 2. Damit haben wir Kopien der beiden Stock-Maps komprimiert:

Ob GMod genau diese Dateien fehlerfrei lädt, haben wir nicht im Spiel geprüft. Teste eine komprimierte Map deshalb selbst auf Client und Server. Das Valve-Wiki nennt außerdem drei Einschränkungen, aus denen sich die Reihenfolge ergibt:

1. Packe zuerst alle Inhalte. In eine komprimierte BSP lässt bspzip nichts mehr packen, du müsstest sie mit -repack ohne -compress wieder entpacken.
2. Baue danach die Cubemaps für LDR und HDR. Auf einer komprimierten Map stürzt buildcubemaps ab.
3. Komprimiere als Letztes und prüfe die Sounds. Für gepackte Sounds im ADPCM-Format dokumentiert das Wiki Wiedergabefehler, dort getestet in Team Fortress 2 und Counter-Strike: Source.

Warum die Größe für Server zählt

Jeder Spieler braucht die BSP lokal, bevor er beitreten kann. Bei FastDL fragt der Client zuerst nach einer .bz2-Fassung, und beim Workshop wird das Addon beim Hochladen komprimiert. Die Größe auf der Festplatte ist also nicht die Download-Größe. Die Wege im Einzelnen stehen in FastDL oder Workshop.

Die Tabelle oben zeigt, was daraus folgt: Die LZMA-komprimierte BSP ist nur 9 bis 19 Prozent kleiner als die .bz2 des Originals, und eine komprimierte BSP zusätzlich als .bz2 zu verpacken, änderte die Größe in unserem Test um weniger als ein Prozent. Eine der beiden Dateien wurde dabei sogar etwas größer. Die Kompression spart also vor allem Speicherplatz auf dem Server und beim Spieler sowie Download-Zeit dort, wo keine .bz2 bereitliegt. Was du dagegen an Lightmaps, Cubemaps und Texturen einsparst, wirkt auf jedem Weg und verringert auch, was das Spiel beim Laden in den Speicher holen muss.

Häufige Fragen

Warum ist meine Map nach buildcubemaps plötzlich viel größer?

Die Cubemaps werden als Texturen ins Pakfile geschrieben, bei einer HDR-Map in zwei Fassungen. Hohe Werte bei „Cubemap Size“ und viele env_cubemap summieren sich schnell auf zweistellige Megabyte. Prüfe die Größen mit bspzip -extract.

Macht eine kleinere BSP die Map im Spiel schneller?

Nicht direkt. Die Bildrate hängt vor allem davon ab, wie viel die Engine pro Bild zeichnet. Gröbere Lightmaps und kleinere Texturen sparen aber Speicher und Ladezeit. Was die Bildrate bestimmt, steht in GMod Map optimieren.

Gibt es eine maximale Dateigröße für eine BSP?

Eine feste Obergrenze für die ganze Datei können wir für GMod nicht belegen. Begrenzt sind einzelne Datenbereiche, siehe Source Engine Map-Limits, und der direkte Download vom Gameserver. In der Praxis setzt die Wartezeit der Spieler die Grenze.

Kann ich eine komprimierte BSP später noch ändern?

Ja, aber nicht direkt. Entpacke sie mit bspzip -repack ohne -compress, nimm die Änderung vor und komprimiere erneut. Nach einem neuen Compile entsteht ohnehin eine frische, unkomprimierte BSP.