Source harita limitleri: brush, entity ve boyut sınırları

Bir Source haritası birkaç yönden sınırlıdır: koordinat alanında (eksen başına ±16384 birim), brush, brush entity, yüzey, displacement ve overlay sayısında ve çalışma zamanında entity sayısında. Garry's Mod bu limitlerin birkaçını Source SDK 2013'ün varsayılan değerlerinin epey üzerine çıkardı. Bir limiti aşarsan derleyici MAX_MAP_BRUSHES gibi bir mesajla durur ya da oyun yüklenirken veya oynanırken çöker. Başlıca önlemler, brush yerine prop kullanmak ve entity'leri birleştirmektir.

En önemli limitlere genel bakış

Garry's Mod sütunu, derleme limitleri için GMod'un kendi derleme araçlarının doluluk tablosunda azami değer olarak yazdıklarını gösterir (Eylül 2026 sürümü). Tablo displacement'lar için azami değer vermez, bu yüzden 16384 Valve Developer Community wiki'sindeki rakamdır ve bir test derlemesi bunu doğrulamıştır. Edict limiti de aynı wiki'nin GMod için verdiği değerdir. SDK sütunu, eski listelerin çoğunlukla alıntıladığı, Source SDK 2013 kaynak kodundaki varsayılan değerleri içerir. Topluluk derleyicileri yine farklılık gösterir. Her zaman esas alınacak olan, aşağıda anlatılan, kendi derleyicinin log'undaki tablodur.

Koordinat alanı ne anlama gelir

Hammer'daki grid her yönde 16384 birimde biter. Dolayısıyla bir harita en fazla 32768 birim uzunluğunda, genişliğinde ve yüksekliğinde olabilir. Birim başına yaklaşık 1,9 santimetreyle bu, her kenar boyunca 600 metrenin biraz üzerinde eder. Bunun dışında geometri oluşturulamaz.

Pratikte ilk çarptığın duvar nadiren bu olur. Çok büyük, açık haritalar daha önce görünürlük hesabı ve kare hızı yüzünden tıkanır. Geniş manzaraları, 1:16 ölçeğinde kurulduğu için az yer kaplayan bir 3D skybox ile taklit etmek daha iyidir.

Bir limite dayandığını nasıl anlarsın

• Derleme hataları: VBSP ya da VRAD durur ve ilgili limiti söyler, örneğin MAX_MAP_BRUSHES veya MAX_MAP_PLANES. Bu tür mesajları nasıl bulacağın Compile log nasıl okunur yazısında gösteriliyor.
• Doluluk tablosu: VRAD log'unun sonunda, BSP'nin her veri bölümü için kullanılan ve azami miktarı, ayrıca yüzde olarak doluluk oranını gösteren bir tablo bulunur. Bir değer azami sınırına yaklaştığında derleyici o satırı VERY FULL! ile işaretler. dispinfos ve ışık verisi gibi sabit bir azami değeri olmayan bölümler orada 0 gösterir ve hiç işaretlenmez. Her yayından önce bu tabloya bak.
• Oyunda çökme: Çalışma zamanında tüm edict'ler kullanılıyorsa oyun ED_Alloc: no free edicts gibi bir mesajla kapanır. Bu çoğu zaman ancak dolu bir sunucuda, birçok oyuncu prop spawn'ladığında olur.
• Hammer izin vermez: Nesneler grid'in kenarının ötesine taşınamaz.

Bir mesajı yorumlayamıyorsan log'u Map Scanner aracına yapıştır. VBSP, VVIS ve VRAD log'larındaki temel nedenleri ve zincirleme hataları tespit eder. Bilinen mesajlar ayrıca hata veritabanında listelenir.

Geometri için önlemler

1. Brush yerine prop. Korkuluklar, borular, mobilyalar, kemerler ve çok yüzeyli diğer detayların yeri modellerdir. Bir prop_static ne brush olarak ne de çalışma zamanı entity'si olarak sayılır, çünkü kalıcı olarak BSP'ye yazılır.
2. Brush yapısını sadeleştir. Birkaç büyük brush, çok sayıda küçük brush'tan iyidir. Carve aracının bıraktığı dilimlenmiş artıklar brush ve yüzey sayısını boş yere yükseltir.
3. func_detail işlevini doğru anla. Visleaf'leri ve portal'ları azaltır, böylece VVIS süresini kısaltır. Brush limitini ise hafifletmez, çünkü bir detail brush yine de bir brush'tır. Daha fazlası GMod harita performans optimizasyonu yazısında.
4. Displacement'ları idareli kullan. Çok sayıda küçük yüzey yerine birkaç büyük yüzey kullan ve gereğinden yüksek çözünürlük seçme. Uzaktaki arazi 3D skybox'a ya da bir modele taşınır.
5. Lightmap'lerin yükünü hafiflet. Keskin gölgelere ihtiyaç duymayan büyük yüzeylerde lightmap scale değerini yükselt. Araçlar ışık verisi için sabit bir azami değer belirtmez, ama bu veri BSP'yi büyütür.

Entity'ler için önlemler

1. Brush'ları tek bir entity'de birleştir. On ayrı func_brush entity'si olarak on pencere camı on slot kaplar. Hepsini seçip birlikte tek bir entity'ye bağlarsan bir slot olur. Entity işlevine ihtiyaçları yoksa func_detail olurlar ve hiç slot kaplamazlar.
2. Statik prop'ları tercih et. Hiç hareket etmeyen her şey prop_dynamic ya da prop_physics yerine prop_static olur.
3. Işıkları adsız bırak. Adı olmayan bir light, lightmap'lere işlenir ve oyunda artık bir entity olarak var olmaz. Yalnızca gerçekten açıp kapatmak istediğin ışıklara ad ver.
4. Efektleri say. Sprite'lar, halatlar, particle'lar ve ses kaynakları tek tek zararsızdır ama sayıları çoğaldığında etkisi hissedilir. Bazı entity'ler oyunda ek yardımcı entity'ler oluşturur.
5. Bir pay bırak. Bir sunucuda bunlara oyuncular, silahlar, araçlar ve spawn'lanan prop'lar da eklenir. Boşken limite yakın olan bir harita, gerçek kullanımda güvenilir şekilde çalışmaz.

Sık sorulan sorular

Bir GMod haritası en fazla ne kadar büyük olabilir?

Koordinat alanı her eksende -16384 ile +16384 birim arasındadır, yani her kenar boyunca 32768 birim. Bu, 600 metrenin biraz üzerine denk gelir. Daha büyük dünyalar yalnızca bir 3D skybox sayesinde daha büyük görünür.

func_detail brush olarak sayılır mı?

Evet. Bir func_detail brush limitine dahil edilir, ama brush entity'lere dahil edilmez ve çalışma zamanında entity olarak sayılmaz. Faydası görünürlük hesabındadır.

Compile log'daki VERY FULL! ne anlama geliyor?

Bu işaret log'un sonundaki doluluk tablosunda çıkar ve BSP'nin bir veri bölümünün neredeyse dolduğunu gösterir. Harita yine çalışır ama daha fazla içerik için neredeyse hiç payı kalmamıştır. O satırda adı geçen bölümü azalt.

Limitleri yükseltebilir miyim?

Haritadaki ayarlarla yükseltemezsin. Limitler derleme araçlarında ve motorda tanımlıdır. Garry's Mod bunların birkaçını güncellemelerle yükseltti, örneğin overlay limitini Mart 2024'te 8192'ye çıkardı. Güvenilir tek yol, haritayı limitlerin altında bir payla kalacak şekilde kurmaktır.