Buffer merging: Merge ve instancing — bütünleşik güç

Birleştirme işlemi, motor açısından sahneyi sadeleştirir: çok sayıda küçük örgü yerine tek bir Mesh ve tek büyük öznitelik tamponu görürsünüz. Üç.js tarafında bu genelde BufferGeometryUtils.mergeGeometries gibi yardımcılarla veya dış araçlarda önceden üretilmiş birleşik varlıkla yapılır; amaç her zaman aynıdır — GPU’ya giden çizim yolu sayısını düşürmek.

Burada «merge»ten kastımız, oyun içi runtime’da her karede yapılan dinamik birleştirme değil; çoğu dokümanda olduğu gibi ön üretim veya yükleme anında bir kez uygulanan, sonuçta tek örgüye indirgenmiş statik bloktur. İsterseniz bu adımı Blender / glTF export zincirinde de verebilirsiniz; motor tarafında yine tek Mesh okursunuz.

Avantajlar ve karakteristik

• Draw call: 1. GPU’ya giden tek bir emirle tüm birleşik yapı çizilir; komut trafiği minimuma iner. CPU tarafında da düğüm gezintisi ve dünya matrisi güncellemeleri tek blok için hesaplanır; özellikle statik dekorasyon katmanlarında kare süresine yansıması okunaklıdır.
• Geometrik çeşitlilik: Birleştirilen objelerin aynı olması gerekmez; bir masa, bir sandalye ve bir lambayı tek bir «oda» mesh’i olarak birleştirebilirsiniz — yeter ki sonuçta uyumlu öznitelik düzeni ve (çoğu durumda) paylaşılan materyal stratejisi ile tek çizim yoluna indirgenebilsin. Pratikte farklı örgülerden gelen öznitelikler (ör. biri uv taşır biri taşımaz) aynı shader imzasına uydurulmalıdır; aksi halde yine birden fazla materyal veya ek vertex düzenlemesi gerekir.
• Basitlik: Motor açısından yönetmesi kolaydır; sahnede tek bir Mesh olarak görünür, seçim ve dışa aktarma akışları sadeleşir. Raycasting veya sınır kutusu hesapları da tek hedefe indirgenir — tabii kazanç, parça parça seçim ihtiyacını sizin için kabul edilebilir olduğunda anlamlıdır.

Dezavantajlar — neden «rigid»?

«Rigid» ifadesi abartı değil: birleştirme, kimlik bilgisini (hangi üçgen hangi objeye aitti) sahnede artık taşımaz; veri düz bir listedir. Bu yüzden oyun mantığı veya UI «şu parçaya tıklandı» diye soramayabilir — ya hiç sormazsınız ya da ayrı bir eşleme tablosu üretirsiniz.

• Sıfır esneklik: Birleştirme işleminden sonra masayı sandalyeden ayıramaz veya tek bir parçanın rengini bağımsız değiştiremezsiniz; geometri artık kaynaklanmış (baked) halde kabul edilir. Parça başı animasyon veya picking ihtiyacı varsa bu model uygun değildir. İleride «sadece şu duvarı yık» gibi bir gereksinim çıkarsa, genelde ya kaynak projeden yeniden export ya da önceden ayrılmış alt blokları koruyarak yeniden planlama gerekir.
• Bellek yükü: Birleştirme, RAM üzerinde yeni ve büyük bir geometri tamponu oluşturur; kaynak örgüler serbest bırakılsa bile toplam VRAM / bellek ayak izi tek blokta toplanmış olur — özellikle devasa sahnelerde üst sınır planı gerekir. Ayrıca birleştirme anı CPU maliyeti doğurur; bu yüzden mobil veya düşük güçlü cihazlarda yükleme ekranında yapılması sık tercih edilir.

Instancing, aynı geometrik verinin GPU belleğinde bir kez tutulup, farklı dönüşüm verileriyle (konum, dönüş, ölçek) tekrar tekrar çizilmesidir. Three.js’te tipik karşılığı InstancedMesh veya özel özniteliklerle genişletilmiş örgülerdir.

Önemli ayrım: instancing «birleştirilmiş gibi görünür» ama veri modeli farklıdır — hâlâ çoklu dönüşüm vardır; sadece örgü paylaşılır. Bu yüzden aşağıdaki avantajlar «tek blokta donma» ile değil, «tek örgü + çok matris» ile ilişkilidir.

Avantajlar ve karakteristik

• Dinamik esneklik: Her kopya (instance) sahnede bağımsız bir dönüşüm matrisine sahiptir. Bir ağaç rüzgarda sallanırken diğeri sabit durabilir; bir bina iki katlıyken diğeri beş katlı ölçeklenebilir — yeter ki aynı «DNA» örgüsünü paylaşsınlar. İsteğe bağlı instance renkleri veya hafif ölçek farklarıyla görsel çeşitlilik de üretilebilir; yine de aynı örgü sınırı geçerlidir.
• Hafıza dostu: On bin adet aynı objeyi çizmek için gereken VRAM, neredeyse tek obje kadardır; ek olarak yalnızca küçük bir konum / matris listesi taşınır. Özellikle yüksek poligonlu tek bir varlığı sahneye serpmek istediğinizde merge’e göre bellek profili çoğu zaman daha iyimserdir.
• Ölçeklenebilirlik: Devasa ormanlar veya asteroid kuşakları için tek gerçekçi çözüm yollarından biridir; Instance paylaşımı sayfasındaki canlı panel bu fikri sayısal olarak pekiştirir. Sınır genelde CPU tarafındaki güncelleme ve öznitelik yazma sıklığında ortaya çıkar, ham üçgen sayısında değil.

Dezavantajlar

• Aynı tip zorunluluğu: Yalnızca birbirinin kopyası olan objelerde çalışır; bir taşı bir ağaçla «instance» yapamazsınız. Farklı örgüleri aynı çizim yolunda toplamak istiyorsanız yine birleştirme, atlas veya multi-material stratejilerine dönersiniz.
• Karmaşıklık: Kod tarafında yönetimi (instance ID’ler, öznitelik güncellemeleri, bazen shader uçları) merge işlemine göre daha komplekstir. Örneğin her karede binlerce örneğin matrisini güncelliyorsanız, veri yapınızı (typed array, havuzlama) önceden tasarlamak gerekir.

Doğru stratejiyi seçmek için kendinize şu soruyu sorun: «Bu objelerin her birini ayrı ayrı manipüle etmem gerekecek mi?» — aynı düşünceyi aşağıdaki etkileşimli kutuda canlı senaryo ile deneyebilirsiniz. Aşağıdaki tablo yönetici özeti niteliğindedir; ayrıntılı draw call diyagramı için Scene merge sayfasına bakın.

Tablodaki «minimum draw call» satırı, uygun materyal ve örgü paylaşımı varsayımıyla geçerlidir; farklı shader veya blend durumları her tekniği yeniden bölebilir. Bu yüzden hücreleri mutlak garanti değil, tasarım sırasında kontrol edeceğiniz başlangıç hipotezi gibi okuyun.

Aşağıdaki maddeler «evet / hayır» listesi değil; üretimde sık tekrarlanan iyimser senaryolardır. Şüphede kaldığınızda önce prototipte ölçüm, sonra karar vermek daha güvenlidir.

Merge seçin, eğer

• Sahnede hiç hareket etmeyecek, statik ve benzer materyalleri paylaşan bir çevreniz varsa (ör. bir evin duvarları, zemini ve tavanı). Işık animasyonu bile tüm blokta aynı şekilde işlenebiliyorsa bu yol genelde sorunsuzdur.
• Objeleriniz geometrik olarak birbirinden tamamen farklıysa ama tek bir grup gibi davranmaları gerekiyorsa. Örneğin «katalog vitrini»nde parça parça seçim yok, yalnızca dönen veya zoom’lanan tek kütle yeterli ise merge mantıklıdır.

Instancing seçin, eğer

• Aynı objeyi (ör. çimen, mermi kovanları, yıldızlar) yüzlerce veya binlerce kez kullanacaksanız. Dağılım deterministik veya prosedürel olabilir; önemli olan aynı örgü tanımının paylaşılmasıdır.
• Objelerin her birinin farklı konumu, farklı dönüş açısı veya farklı bir «durumu» olması gerekiyorsa. Bu «durum» bazen sadece ölçek veya renk tonu kadar hafif olabilir; yine de instancing sınırınız aynı örgüdür.
• Modelinizin poligon sayısı yüksekse ve bellek tasarrufu hayati önem taşıyorsa. Aynı varlığı yüzlerce kez kopyalamak yerine tek örgü + matris listesi, hem bellek hem de yükleme süresinde hissedilir.