Instance paylaşımı: Geometrik fotokopi sistemi

Tek örgü–tek materyal varsayımını somutlaştıran küçük bir proof sahnesi: ayrı mesh (her biri çizim yolu), InstancedMesh (toplu gönderim) ve birleşik örgü (tek blok, parça başı kontrol yok). Sayaç ve modları değiştirerek hem kare hızını hem renderer’ın raporladığı çizim yolu sayısını gözlemleyin.

Özet: Instancing aynı silueti ucuza çoğaltır; birleştirme tek parçada toplar ama animasyon/hiyerarşi bedeli öder; binlerce bağımsız mesh ise ölçeklenmeyi zorlaştırır. Bu panel metindeki «tek geometri + çok örnek → toplu gönderim» cümlesinin görsel kanıtıdır.

Sahnede örneğin 5.000 ayrıntılı ağaç olduğunu düşünün. Her birini bağımsız new THREE.Mesh(geometry, material) ile eklerseniz, motor her düğüm için güncelleme ve çizim yolu hazırlığı yapar; geometri verisi de her mesh için tekrarlanır veya en azından bellek baskısı katlanarak büyür.

• Bellek (RAM / VRAM): Aynı ağaç örgüsü her nesnede yinelenir; örneğin ~1 MB’lık bir örgü, binlerce kopyada gigabayt düzeyine yaklaşan israf yaratabilir.
• CPU yükü: Binlerce bağımsız nesnenin hiyerarşisi, dünya matrisi ve komut hazırlığı CPU’yu boğar; kare süresi dalgalanır.

Instancing çözümü: Bellekte yalnızca bir adet örgü (ve paylaşılan materyal) kalır. Yanına her örnek için yalnızca dönüşüm bilgisi (ve gerekirse renk gibi küçük instance attribute verileri) eklenir; bu ikinci blok genelde örgünün kendisine göre çok küçüktür. Böylece hem bellek hem de çizim yolu sayısı kontrol altına alınır — doğru senaryoda bu, kare hızını dramatik biçimde iyileştiren anahtarlardan biridir.

Aşağıdaki örneklerin ortak özelliği: görsel olarak aynı veya çok yakın örgü, farklı yerlerde çok sayıda bulunması. Bu «çoğalt ama veriyi paylaş» modeli, doğa ve şehir sahnelerinde en sık karşılaşılan instancing gerekçeleridir.

A. Doğal yaşam (ağaçlar ve çimenler)

Bir ormanda ağaçların «genetik kodu» aynı model dosyasından gelir; farklı olan yalnızca konum, dönüş ve ölçektir. Instance ile tek örgüden saniyeler içinde geniş vadiler kurabilir; rüzgâr veya büyüme animasyonu gerekiyorsa matrisleri veya öznitelik tamponunu kare başı güncellemek yeterlidir — her ağaç için ayrı geometry klonu taşımazsınız.

B. Şehir mimarisi (binalar ve sokak lambaları)

Şehir bloklarında aynı pencere modülü, bank veya düşük poligon bina gövdesi yüzlerce kez tekrarlanır. Instancing, bu tekrarı tek çizim yoluna yakın maliyetle sunmanıza yardım eder; modüler kit üretiminden web sahnesine geçişi hızlandırır. Farklı bina tipleri için ayrı örgü setleri tanımlayıp her seti kendi InstancedMesh’iyle yönetmek yaygın bir üst seviye stratejidir.

C. Kalabalık sistemleri (parçacıklar ve kitleler)

Uçan yapraklar, tribün kalabalığı veya asteroit kuşağı gibi sahnelerde hem yoğunluk hem hareket gerekir. Burada instancing, hem örgü paylaşımı hem de (doğru tasarlandığında) GPU tarafında yoğun güncellemelerle uyumlu çalışır; tamamen bağımsız mesh ordusu kurmaya göre bellek ve CPU maliyeti orders-of-magnitude düşer.

• VRAM tasarrufu: Aynı geometri ve materyal paylaşıldığı için ekran kartı belleği örgü kopyalarıyla şişmez; ölçeklenebilirlik belirgin şekilde artar.
• Draw call minimizasyonu: Binlerce ağaç, doğru kurulumda tek bir çizim yoluna yakın gönderilebilir; bu, düşük FPS’i stabil yüksek kareye taşıyan başlıca nedenlerden biridir (materyal ve sürücü koşullarına bağlıdır).
• Dinamik güncelleme: Örnek matrislerini veya instance özniteliklerini güncellemek, binlerce kopyayı tek örgü üzerinden yönetmeyi kolaylaştırır; animasyon mantığını veri tamponuna taşımak, CPU’yu rahatlatır.

Pratikte kazanç; örgü karmaşıklığı, materyal sayısı, gölgeler ve post-processing gibi diğer yüklerle birlikte değerlendirilmelidir. Yine de «aynı modelden çok kopya» problemi için instancing genellikle ilk tercih edilen çözümdür.

Instancing güçlüdür; fakat «tek tip çoğalt» modelinin getirdiği kurallar vardır. Tasarımı buna göre yapmadığınızda beklenen kazanç düşer veya kaybolur.

• Aynı materyal zorunluluğu: Tüm örnekler aynı shader yolunu paylaşır. Bir kopyayı kırmızı, diğerini mavi yapmak için materyal çeşitliliği gerekiyorsa, instanced attribute veya özel shader mantığı gibi ileri adımlar gerekir — bu HoloDepth’te ayrı konu başlıklarına bağlanır.
• Geometrik farklılık yoktur: Bir kopyanın dalını büküp diğerini düz bırakmak, aynı InstancedMesh içinde doğrudan mümkün değildir; farklı siluetler istiyorsanız ya ayrı örgü setleri ya da başka teknikler (ör. LOD, farklı mesh grupları) devreye girer.

Özetle: çeşitlilik örgü seviyesinde isteniyorsa instance tek başına yetmez; çeşitlilik dönüşüm veya hafif öznitelik seviyesinde kalabiliyorsa ideal eşleşmedir.

Aşağıdaki tablo yönetici özetidir. Scene merge tarafındaki ayrıntılar ve diyagram için Scene merge sayfasına; hareketli parçalarda hiyerarşi için Model parenting sayfasına bakın.

Kural başparmak: aynı model, çok sayıda → önce instance; farklı modelleri tek statik blokta toplamak → merge / birleştirme hatları. İkisi de «daha az çizim yolu» hedefler; veri şekli ve kontrol beklentisi farklıdır.

Three.js projelerinde THREE.InstancedMesh sınıfı bu düzeni doğrudan sunar: yüzlerce ayrı mesh yaratıp scene.add etmek yerine, tek InstancedMesh oluşturup örnek sayısını ve dönüşüm matrislerini (setMatrixAt vb.) beslemek, profesyonel web 3B geliştirmede tekrarlayan bir «imza» kalıbıdır.

Bellek düzeni, örnek güncelleme maliyeti ve frustum culling etkileşimi için ileri okuma: Instancing — ileri düzey.