VBSP, VVIS ve VRAD nedir: üç derleme adımı

Derleme, VMF dosyanı üç adımda oynanabilir bir BSP'ye dönüştürür: VBSP geometriyi kurar ve leak olup olmadığını kontrol eder, VVIS neyin nereden görünür olduğunu hesaplar, VRAD ise ışıklandırmayı hesaplar. Sürenin çoğunu VVIS ve VRAD alır. Testler için hızlı ayarları, yayın için tam bir derlemeyi kullanırsın.

Genel bakış: kim ne yapar

vbsp.exe, vvis.exe ve vrad.exe adlı üç program oyunun bin klasöründedir. F9'a bastığında Hammer bunları art arda çalıştırır ve bitmiş BSP'yi maps klasörüne kopyalar. Programların yazdırdığı her şey ayrıca VMF dosyanın yanındaki bir log dosyasına da düşer.

VBSP: geometri ve leak'ler

VBSP brush'larını yüzeylere dönüştürür, haritanın dışında kalan yüzeyleri kaldırır ve iç hacmi visleaf'lere böler. Ayrıca entity'leri, statik prop'ları, overlay'leri ve displacement'ları BSP'ye yazar.

Bunu yaparken VBSP haritanın kapalı olup olmadığını da kontrol eder. Entity'lerden başlayarak hacmi doldurur ve dışarıdaki boşluğa ulaştığı anda bir leak bildirir. O zaman log'da **** leaked **** görünür ve VBSP, Hammer'da Map > Load Pointfile ile leak'e giden bir çizgi olarak görüntüleyebileceğin bir pointfile yazar. Bu durumda portal dosyası oluşturulmaz. Sonuçları: VVIS çalışamaz, motor her zaman haritanın tamamını çizer ve ışıklandırma ancak eksik olarak hesaplanır. Leak'i nasıl bulacağın Harita leak hatasını düzeltme yazısında gösteriliyor.

-onlyents parametresi testlerde işe yarar. Geometriyi yeniden kurmadan, zaten derlenmiş bir BSP'deki entity'leri günceller. Yalnızca mantığı ya da entity ayarlarını değiştirdiysen bu sana zaman kazandırır. Brush entity'lerinkiler de dahil olmak üzere brush'lar olduğu gibi kalır. GMod'un VBSP'siyle yaptığımız testte statik prop'lar da güncellendi, overlay'ler güncellenmedi.

VVIS: görünürlük

VVIS, visleaf'ler arasındaki portal'ları okur ve her alan için oradan başka hangi alanların görünür olabileceğini hesaplar. Motor bu sonucu daha sonra neyi çizmesi gerektiğine karar vermek için kullanır.

Log'da iki aşamayı ayırt edebilirsin: BasePortalVis kaba bir ön hesaplamadır, PortalFlow ise kesin ve genellikle çok daha uzun süren hesaplamadır. Bundan önce log portal sayısını verir. Süreyi her şeyden çok bu sayı belirler. Çok sayıda küçük dünya brush'ı ve büyük açık alanlar çok sayıda portal yaratır.

• -fast ile VVIS kesin hesaplamayı atlar. Derleme hızlı biter ama motor oyunda gereğinden fazlasını çizer. Bu bir yayın için uygun değildir, bununla yapılan FPS ölçümleri de değersizdir.
• VVIS çok uzun sürüyorsa detayları func_detail yap ve dünya geometrisini sadeleştir. Büyük açık alanlar için func_viscluster var. Ayrıntılar VVIS çok uzun sürüyor yazısında.

VRAD: ışıklandırma

VRAD her yüzey için doğrudan ışığı hesaplar, ardından onu yüzeylerden birkaç kez yansıtır ve sonucu lightmap olarak kaydeder. Bunlara statik prop'lar ve hareketli nesneler için ışıklandırma verileri de eklenir.

En önemli parametreler:

• -fast: testler için hızlı, gözle görülür biçimde daha kaba hesaplama.
• -final: yayın için daha hassas hesaplama, belirgin biçimde daha yavaş.
• -ldr, -hdr, -both: hangi parlaklık aralığının hesaplanacağını belirler. -both ile hesaplama iki kez çalışır.
• -StaticPropLighting, -StaticPropPolys, -textureshadows: statik prop'lar için daha iyi ışıklandırma ve daha doğru gölgeler.

Süre; haritanın boyutuna, ışık sayısına ve lightmap scale değerine bağlıdır. Büyük yüzeylerdeki küçük lightmap scale değerleri, çok uzun süren çalıştırmaların yaygın bir nedenidir. Log'da önce doğrudan ışıklandırmayı (BuildFacelights), sonra tek tek ışık yansımalarını ve son olarak BSP'nin veri bölümlerinin ne kadar dolu olduğunu gösteren bir tabloyu görürsün. Işıklandırmayla ilgili her şey Source Engine ışıklandırma rehberinde anlatılıyor.

Test ve yayın için ayarlar

Normal "Run Map" penceresinde VIS için "No", "Normal" ve "Fast" arasında seçim yaparsın. RAD, Hammer++'ta aynı üç kademeye sahiptir; oyunla gelen Hammer'da bunlara "Faster" ve "Final" eklenir. BSP'de ise üçüncü seçenek hızlı bir mod değil, "Only entities" seçeneğidir. "Expert" seni hazır profillere götürür ve parametreleri tek tek düzenlemene izin verir.

Yayın derlemesinden sonra, üç programın parçası olmayan iki iş daha gelir: cubemap'leri oyun içinde oluşturmak ve özel içeriği BSP'ye paketlemek. Bunun nasıl yapıldığı Özel içeriği BSP içine paketleme yazısında anlatılıyor.

Derleme başarısız olduğunda

Log'u yukarıdan aşağıya oku ve ilk hatayı ara. Sonraki mesajlar çoğu zaman yalnızca onun sonucudur. Örneğin VBSP'deki bir leak, VVIS'in portal dosyasını bulamaması demektir. Yalnızca son mesajı okursan yanlış yerde arama yaparsın.

Log'u Map Scanner aracına da yapıştırabilirsin. VBSP, VVIS ve VRAD log'larındaki temel nedenleri, zincirleme hataları ve uygun çözümleri tespit eder.

Sık sorulan sorular

VVIS neden bu kadar uzun sürüyor?

Süre portal sayısına bağlıdır ve bu sayı, hacmi bölen her dünya brush'ıyla artar. Detayları func_detail yap ve haritayı kapatan geometriyi sade tut. Büyük açık alanlar genel olarak dolambaçlı iç mekânlardan daha pahalıdır.

VVIS'i ya da VRAD'ı atlayabilir miyim?

Testler için evet. VVIS olmadan motor her zaman haritanın tamamını çizer, VRAD olmadan harita eşit parlaklıkta ve gölgesiz olur. Yayınlanan bir haritanın her iki adıma da eksiksiz ihtiyacı vardır.

Log'daki "leaked" ne anlama geliyor?

Haritanın iç hacmi dünya brush'larıyla tamamen çevrelenmemiştir ya da bir entity dışarıda duruyordur. O zaman VBSP portal dosyası oluşturmaz ve sonraki adımlar işe yarar bir sonuç vermez. Başka hataları araştırmadan önce leak'i düzelt.

Her değişiklikten sonra her şeyi yeniden derlemem gerekir mi?

Brush'larda yapılan değişikliklerden sonra evet, çünkü geometri, görünürlük ve ışıklandırma birbirine bağlıdır. Yalnızca ışıklandırmayı etkilemeyen entity ayarlarını değiştirdiysen bir test için -onlyents ile bir VBSP çalıştırması yeter. Bu çalıştırma overlay'leri ve brush'ları güncellemez; yayın için tam derleme gerekir.