BSP dosya boyutunu küçültme: haritaları ne büyütür, ne işe yarar

Bir BSP neredeyse her zaman üç şey yüzünden büyür: HDR derlemede iki kez saklanan lightmap'ler, pakfile'a paketlenmiş içerik ve HDR cubemap'ler. Önce haritanda hangi bloğun baskın olduğunu ölç. Ardından büyük yüzeylerde daha yüksek bir lightmap scale, özenli paketleme ve küçük cubemap'ler asıl fark yaratan yerde işe yarar. Bitmiş BSP'yi sıkıştırmak son adımdır ve bunların hiçbirinin yerini tutmaz.

Bir BSP'de yeri ne kaplar

Bir BSP, lump adı verilen veri bloklarından oluşur. Yapıları BSP dosyası nedir? yazısında açıklanıyor. Boyut açısından bunların yalnızca birkaçı önemlidir:

GMod'un oyunla gelen haritalarından ikisi, bunun ne kadar farklı sonuçlanabildiğini gösterir (1 MB = 1.000.000 bayt):

• gm_construct 36,7 MB'tır. Bunun 24,5 MB'ı lightmap'tir: LDR için 12,3 MB ve HDR için bir kez daha tam olarak aynı miktar. Pakfile 3,8 MB yer kaplar; buna 2,1 MB HDR cubemap ve 1,4 MB prop ışıklandırması dahildir. Çarpışma verileri 3,1 MB tutar, 110 displacement'ın lump'ları ise toplam 0,8 MB.
• gm_flatgrass, harita neredeyse boş olmasına rağmen 47,4 MB'tır. Bunun 41,6 MB'ı pakfile'dır ve onun da 39,1 MB'ı yalnızca sekiz HDR cubemap'te durur.

Kırpmadan önce ölç

VRAD, log'unun sonunda tüm veri alanlarını listeler. Memory sütununda eğik çizgiden önceki sayı bayt cinsinden boyuttur. Önemli olan satırlar şöyle görünür (küçük bir test haritasından):

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%)

Pakfile'ın içinde ne olduğunu bspzip gösterir. İlk komut yalnızca adları listeler. İkincisi pakfile'ı bir ZIP dosyası olarak dışarı yazar; bu dosyayı bir arşiv programında boyuta göre sıralayabilirsin:

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

Yüklenen bir BSP için Map Scanner da dosya boyutunu, pakfile'daki dosya sayısını ve bunlardan bir kesiti gösterir.

Lightmap'ler: scale ve HDR

Lightmap scale, bir ışık örneğinin (luxel) kaç birim kapladığını belirtir. Her luxel dört bayt yer tutar ve Valve wiki'sine göre bump map içeren yüzeyler bunun dört katını saklar. Scale değerini yarıya indirirsen luxel sayısı kabaca dört katına çıkar. İki odalı test haritamızda ışıklandırma scale 32'de yaklaşık 10 KB, varsayılan değer olan 16'da yaklaşık 36 KB, scale 4'te ise yaklaşık 564 KB yer kapladı.

• Büyük ve eşit aydınlatılmış yüzeylerde scale değerini 32 ya da 64'e yükselt. Bedeli, daha yumuşak ve daha az hassas gölge kenarlarıdır.
• Yalnızca bir gölgenin gerçekten keskin olması gereken yerlerde düşür.
• Kimsenin görmediği yüzeylere tools/toolsnodraw uygula. VBSP bunları kaldırır, lightmap'leri de onlarla birlikte gider.
• Hammer'da "3D Lightmap Grid" adlı 3D görünüm modu her yüzeyin luxel yoğunluğunu gösterir.

İkinci büyük kaldıraç HDR'dir. VRAD -ldr, -hdr ve -both parametrelerini tanır. GMod'un VRAD'inin yardım metni bu üç parametreyi listelemez, ama program bunları kabul eder. Hiçbiri verilmezse yalnızca LDR hesaplar. -both ile VRAD aynı boyutta ikinci bir lighting lump'ı yazar, -StaticPropLighting ile ayrıca prop başına ikinci bir .vhv dosyası yazar ve cubemap'leri iki kez oluşturursun. Bu yüzden yalnızca LDR içeren bir harita hatırı sayılır ölçüde daha küçüktür, ama tüm oyuncular için HDR'den vazgeçer. Bu ödünleşim Source Engine ışıklandırma rehberi yazısında anlatılıyor.

Pakfile: içerik ve cubemap'ler

Yalnızca haritanın kullandığını paketle; her oyuncuda oyunla birlikte zaten bulunan hiçbir şeyi paketleme. En büyük payı neredeyse her zaman texture'lar alır. Çözünürlük, format ve listenin kontrolü özel içeriği BSP içine paketleme yazısında ele alınıyor.

Cubemap'ler hafife alınır. buildcubemaps, her env_cubemap için pakfile'a bir texture yazar, HDR haritada buna ek olarak bir .hdr.vtf yazar. HDR sürümü kanal başına 16 bit saklar ve oyunla gelen iki haritada sıkıştırılmış LDR sürümünün yaklaşık on altı katı büyüklüğündedir: 32x32'de yaklaşık 77 KB, 256x256'da ise 4,9 MB. "Cubemap Size" alanındaki her kademe dosyayı dört katına çıkarır. Bu yüzden boyutu "Default" olarak bırak ve yalnızca büyük yansıtıcı yüzeylerin bulunduğu tek tek noktalar için yükselt. Cubemap'ler hakkında daha fazlası cubemap yansımalarını düzeltme yazısında.

Paketlenmiş bir haritada bspzip -deletecubemaps komutundan uzak dur: Valve wiki'sine göre komut yalnızca cubemap'leri değil, pakfile'daki tüm VTF dosyalarını siler.

BSP'yi sıkıştırmak: bspzip -repack -compress

bspzip bitmiş bir BSP'yi yeniden paketleyebilir ve bu sırada LZMA ile sıkıştırabilir. Dosya bir .bsp olarak kalır. Valve wiki'sine göre GMod'un motoru bu tür haritaları yükler; GMod'un Mart 2025 tarihli changelog'u da BSP dosyaları için LZMA sıkıştırmasının açılmasından açıkça söz eder.

Sorun araçta. GMod'un bspzip'i bu seçeneği yardım metninde anar, ama testimizde (3 Eylül 2026 tarihli build, 32 ve 64 bit) -repack -compress verildiğinde hiçbir çıktı üretmeden 1 çıkış koduyla sonlandı ve dosyayı değiştirmeden bıraktı. -repack tek başına çalıştı. Valve wiki'si bu yüzden GMod için Team Fortress 2'nin bspzip'ine yönlendirir. Oyunla gelen iki haritanın kopyalarını onunla sıkıştırdık:

GMod'un tam olarak bu dosyaları hatasız yükleyip yüklemediğini oyunda kontrol etmedik. Bu yüzden sıkıştırılmış bir haritayı istemcide ve sunucuda kendin test et. Valve wiki'si ayrıca üç kısıtlamadan söz eder; sıralamayı da bunlar belirler:

1. Önce tüm içeriği paketle. bspzip sıkıştırılmış bir BSP'ye hiçbir şey paketlemez; onu -compress olmadan -repack ile yeniden açman gerekirdi.
2. Ardından LDR ve HDR için cubemap'leri oluştur. Sıkıştırılmış bir haritada buildcubemaps çöker.
3. En son sıkıştır ve sesleri kontrol et. ADPCM formatındaki paketlenmiş sesler için wiki oynatma hatalarını belgeliyor; bunlar orada Team Fortress 2 ve Counter-Strike: Source'ta test edilmiş.

Boyut sunucular için neden önemli

Her oyuncunun katılmadan önce BSP'ye yerel olarak sahip olması gerekir. FastDL'de istemci önce bir .bz2 sürümünü ister, Workshop'ta ise addon yükleme sırasında sıkıştırılır. Dolayısıyla diskteki boyut indirme boyutu değildir. Yolların her biri FastDL mi Workshop mu yazısında anlatılıyor.

Yukarıdaki tablo bundan ne çıktığını gösterir: LZMA ile sıkıştırılmış BSP, orijinalin .bz2 sürümünden yalnızca %9 ila %19 daha küçüktür; sıkıştırılmış bir BSP'yi ayrıca .bz2 olarak paketlemek de testimizde boyutu %1'den az değiştirdi. Hatta iki dosyadan biri biraz büyüdü. Yani sıkıştırma en çok sunucuda ve oyuncunun makinesinde disk alanından, bir de hazır .bz2 bulunmayan yerlerde indirme süresinden tasarruf sağlar. Lightmap'lerde, cubemap'lerde ve texture'larda yaptığın tasarruf ise her yolda karşılığını verir ve oyunun belleğe yüklemek zorunda olduğu miktarı da azaltır.

Sık sorulan sorular

Haritam buildcubemaps sonrasında neden birden çok daha büyük?

Cubemap'ler pakfile'a texture olarak yazılır, HDR haritada iki sürüm hâlinde. Yüksek "Cubemap Size" değerleri ve çok sayıda env_cubemap entity'si hızla onlarca megabayta ulaşır. Boyutları bspzip -extract ile kontrol et.

Daha küçük bir BSP haritayı oyunda hızlandırır mı?

Doğrudan değil. Kare hızı en çok motorun kare başına ne kadar şey çizdiğine bağlıdır. Yine de daha kaba lightmap'ler ve daha küçük texture'lar bellekten ve yükleme süresinden tasarruf sağlar. Kare hızını neyin belirlediği GMod harita performans optimizasyonu yazısında anlatılıyor.

Bir BSP için azami dosya boyutu var mı?

GMod'da dosyanın tamamı için sabit bir üst sınırı doğrulayamıyoruz. Sınırlı olan, tek tek veri alanları (Source harita limitleri yazısına bak) ve oyun sunucusundan doğrudan indirmedir. Pratikte sınırı oyuncuların bekleme süresi belirler.

Sıkıştırılmış bir BSP'yi sonradan değiştirebilir miyim?

Evet, ama doğrudan değil. Onu -compress olmadan bspzip -repack ile aç, değişikliği yap ve yeniden sıkıştır. Yeni bir derleme zaten taze, sıkıştırılmamış bir BSP üretir.