VVIS çok mu uzun sürüyor? Derleme süresini kısaltmanın yolları

Haritanda çok fazla visleaf ve portal varsa VVIS saatlerce çalışır. En sık görülen neden, world brush olarak kurulmuş detay geometrisidir. Görüşü geniş bir alanda kesmeyen her şeyi func_detail'e çevir. Böylece portal sayısı düşer ve hesaplama süresi çoğunlukla çarpıcı biçimde kısalır.

VVIS aslında neyi hesaplar

VBSP haritanın iç kısmını visleaf'lere böler. Bunlar, world brush'ların yüzeyleriyle sınırlanan dışbükey hacim parçalarıdır. İki visleaf'in birbirine değdiği her yerde bir portal oluşur. VVIS ardından hangi visleaf'lerin bu portallar üzerinden birbirini görebildiğini hesaplar. Motor bu sonucu oyunda, görünmeyen alanları çizmemek için kullanır.

İş yükü haritanın büyüklüğüyle aynı oranda artmaz. Eklenen her portalla birlikte kontrol edilmesi gereken kombinasyonların sayısı orantısız biçimde büyür. Bu yüzden kötü kurulmuş tek bir salon, geri kalan her şeyin toplamından daha fazla zamana mal olabilir. Üç derleme aracının birbiriyle ilişkisi VBSP, VVIS ve VRAD yazısında anlatılıyor.

Log'da portal sayısını okumak

VVIS, asıl hesaplama başlamadan önce en başta iki sayı yazdırır. Aşağıdaki örnek bunun düzenini gösteriyor:

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

numportals senin için en önemli ölçüttür. Sabit bir eşik değeri yoktur, çünkü hesaplama süresi işlemciye ve oda düzenine de bağlıdır. Önemli olan karşılaştırmadır: sayıyı bir değişiklikten önce ve sonra not et. Belirgin biçimde düşüyorsa doğru yoldasın.

Uzun süren aşama PortalFlow aşamasıdır. Orada yeni rakamlar belirmeye devam ettiği sürece VVIS hâlâ çalışıyordur, donmamıştır. Geri kalan satırların nasıl yorumlanacağını compile log okuma yazısı gösteriyor.

Neden çok fazla portal oluşur

• World brush olarak detaylar: Bir world brush'ın her yüzeyi hacmi daha da bölebilir. Brush'lardan yapılmış sütunlar, merdiven basamakları, pencere çerçeveleri, süs çıtaları, korkuluklar ve mobilyalar bu şekilde çok sayıda minik visleaf üretir.
• Eğik ve yuvarlak biçimler: Silindirler, kemerler ve döndürülmüş brush'lar hacmi özellikle elverişsiz açılarla keser.
• Geniş açık alanlar: Geniş bir dış mekânda neredeyse tüm visleaf'ler birbirini görür. VVIS yine de her kombinasyonu kontrol etmek zorundadır.
• Gereksiz boş hacim: Haritayı saran dev bir kutu ya da oyun alanının üzerindeki uçsuz bucaksız hava boşlukları, bölünen hacmi büyütür.
• Çok fazla hint: Her hint brush'ı yeni kesimler, dolayısıyla yeni portallar ekler.

Etkisine göre sıralı çözümler

1. Detayları dönüştür. Brush'ları seç, Ctrl+T'ye bas ve func_detail'i seç. Temel kural: yalnızca haritayı kapatan ya da görüşü geniş bir alanda kesen şeyler world brush olarak kalır, yani dış duvarlar, zeminler, tavanlar ve odalar arasındaki bölme duvarlar.
2. Kabuğu sadeleştir. Odaları düz ve basit world brush'lardan kur, görünen biçimi ise func_detail olarak önüne yerleştir. Yuvarlak duvarların ve kemerlerin world geometrisinde hiçbir zaman yeri yoktur.
3. Prop ve displacement kullan. Modeller ve displacement'lar hacmi bölmez. Araziyi displacement olarak kur ve altına tools/toolsnodraw kaplı basit bir brush koy.
4. Açık alanları grupla. func_viscluster ile, içinde zaten her şeyin her şeyi gördüğü bir hacmi işaretlersin. VVIS içerideki visleaf'leri karşılıklı görünür kabul eder ve onları tek tek kontrol etmeyi atlar.
5. Hint'leri bilinçli yerleştir. Bir hint brush'ı, kesen yüzeyde tools/toolshint, diğer tüm yüzlerde tools/toolsskip kullanır. Yalnızca belirli bir kesimin görünürlüğü gerçekten iyileştirdiği yere koy, örneğin bir koridor köşesine.
6. Sonucu kontrol et. Hammer, Map → Load Portal File ile son derlemenin portallarını gösterir. Oyunda mat_leafvis 1, o anda içinde durduğun visleaf'i gösterir; komut sv_cheats 1 gerektirir.

Birinci adımda func_detail'in haritayı kapatmadığını aklında tut. Yanlışlıkla bir dış duvarı dönüştürürsen VBSP leak bildirir. O durumda ne yapılacağı harita leak hatasını düzeltme yazısında anlatılıyor.

-fast ne yapar ve ne zaman mantıklıdır

-fast parametresiyle VVIS hassas hesaplamayı atlar ve yalnızca kaba bir sonuç üretir. Hammer'da bu, "Run VIS" altındaki "Fast" ayarına karşılık gelir. Derleme çabuk biter, ama oyunda motor, gerçekte görülebilenden çok daha fazlasını görünür sayar. Kare hızı bundan zarar görür.

Yayınladığın ya da sattığın bir haritanın tam hesaplamaya ihtiyacı vardır. Harita yalnızca -fast ile makul bir sürede tamamlanıyorsa, bu yapısal bir soruna işaret eder ve kestirme yolu sürdürmek için bir gerekçe değildir. Kare hızı için başka önlemleri GMod harita performans optimizasyonu yazısında bulursun.

VVIS hâlâ uzun sürüyorsa

• Cordon aracıyla tek tek bölümleri derle ve numportals değerlerini karşılaştır. Böylece en çok portal üreten bölge ortaya çıkar.
• Portal dosyasını Hammer'da yükle ve çizgilerin çok sıklaştığı yerleri ara. Unutulmuş detay geometrisi neredeyse her zaman orada bulunur.
• Log'da ayrıca uyarı ya da hata olup olmadığını kontrol et. Compile log'unu Map Scanner aracına yapıştırabilirsin. Araç, VBSP, VVIS ve VRAD log'larında temel nedenleri, zincirleme hataları ve uygun çözümleri tespit eder.

Sık sorulan sorular

VVIS ne kadar sürmeli?

Sabit bir değer yok. Temiz kurulmuş bir harita çoğunlukla dakikalar içinde biter, çok büyük haritalar ise buna göre daha uzun sürer. VVIS saatlerce çalışıyorsa nedeni neredeyse her zaman donanım değil, geometridir.

VVIS'i tamamen atlayabilir miyim?

Hızlı testler için evet. Yayın için hayır, çünkü görünürlük verisi olmadan motor her an tüm haritayı çizer. Büyükçe haritalarda kare hızı o zaman çöker.

Areaportal'lar VVIS süresini kısaltır mı?

Hayır. Areaportal'lar çalışma zamanında devreye girer ve oyunda, bir açıklıktan görülemeyen alanları gizler. Kare hızını iyileştirirler ama bir derleme sorununu çözmezler.

func_detail haritayı oyunda yavaşlatır mı?

Hayır, doğru kullandığın sürece. Ancak func_detail görünürlüğü engellemez. Bu yüzden iki odayı ayıran duvarlar world brush olarak kalmak zorundadır, yoksa motor iki odayı aynı anda çizer.