Kime: Oleg Sidorkin
Konu: app.cinevva.com/blog/2026-03-04-sketch-to-animated-3d-character
Karşılaştırılan kaynak: cinevva-site deposu (pazarlama sitesi + worker)

Doğrulandı ✓

• Araç adları (Image Generator, Video Generator, 3D Model Generator) ve bağlantı /tr/tools/hunyuan3d kod tabanıyla eşleşiyor.
• Yazar (Oleg Sidorkin, CTO) bilgisi doğru.
• Video iş akışı: Başlangıç ve bitiş kareleri arasında geçiş, 9:16, 3–15 saniyelik süre ve storyboard modu destekleniyor.
• 3D işlem hattı: Hunyuan3D ve "3D Model Generator" adları doğru; otomatik rigleme (Tripo) ve "GLB yükle → riglenmiş model + animasyon kütüphanesi" ifadeleri uygulamayla eşleşiyor.
• Cinevva Engine ve "2026'nın başlarındaki durumu yansıtır" ifadeleri doğru.

Düzeltilmesi gerekiyor

"Seedance 1.5 Pro" — Bu depoda video özelliği Seedance 1.5 Pro ile değil, Kling 3.0 Pro (fal.ai) ile uygulanmıştır:

• worker/src/genai/fal-video.ts, fal-ai/kling-video/v3/pro/... kullanıyor
• worker/src/index.ts, maliyeti model: 'kling-3.0-pro' olarak takip ediyor
• tools/video.md şöyle diyor: "Metin veya görsellerden Kling 3.0 Pro kullanarak kısa yapay zekâ videoları oluşturun"

API/ürün adı "seedance" (ör. /genai/seedance/generate), ancak altyapıda kullanılan model Kling 3.0 Pro'dur. Seedance 1.5 Pro farklı bir modeldir (ByteDance). Herkese açık kaynaklarda Seedance 1.5 Pro genellikle yaklaşık 10 saniyeyle sınırlı gösterilirken burada Kling için 15 saniye destekleniyor.

Öneri: Pazarlama sitesi ve dokümantasyonla tutarlı olması için makalede video modelini "Kling 3.0 Pro" (veya örneğin "Video Generator (Kling 3.0 Pro)") olarak adlandırın. Uygulamanın arka ucu gerçekten Seedance 1.5 Pro kullanıyorsa uygulama metnini ve tools/video.md dosyasını aynı modeli açıklayacak şekilde uyumlu hâle getirin.

Depoda doğrulanamayanlar

Cubcoats, Kali the Kitty, Mimi Chao ve bunlarla ilgili ticari iddialar harici bilgilerdir; kontrol edilmemiştir.

Oyun Oluşturucu'daki {{ spikeId }} spike'ına yönlendiriliyorsunuz. Yönlendirilmezseniz buradan açın.

Oyun Oluşturucu'yu açın.

← Seri rehberine dön

Cinevva CTO'su ve Kurucu Ortağı Oleg Sidorkin tarafından

Yakın zamanda Game Creator'a bir WeChat mini oyun modu ekledik: Yapay zekâ tarafından üretilen oyunları, web platformunun WeChat çalışma zamanına taşındığında çalışmaya devam eden alt kümesi içinde tutan bir derleme profili. Profil, bir dizi üretim kuralından oluşuyor. DOM tabanlı kullanıcı arayüzü yok, Pointer Lock yok, yalnızca mp3 ses, dinamik kod yok. Model bu kurallara, modellerin kurallara uyduğu şekilde uyuyor; yani genellikle.

Her ihlal tarayıcıda görünmezken dışa aktarımdan sonra ölümcül oluyorsa "genellikle" yeterli değildir. HTML sağlık çubuğu olan bir oyun önizlememizde kusursuz çalışır, ancak WeChat mini oyunlarında hiç DOM bulunmadığı için WeChat'te boş ekran üretir. Bu nedenle söz konusu kuralları öneriden fiziğe dönüştüren şeyi geliştirdik: Tarayıcının, WeChat'in yapamadığı şeyleri yapmayı reddetmesini sağlayan katı modda bir korumalı alan. Bu yazı, onun nasıl çalıştığını anlatıyor.

Temel karar: varlığı değil, yokluğu simüle etmek

Bariz yaklaşım WeChat'i taklit etmek olurdu: wx.createCanvas, wx.onTouchStart, wx.setStorageSync işlevlerini uygulamak ve oyunları taklit edilen wx.* yüzeyinde çalıştırmak. Biz bunun tersini yaptık ve bunun nedeni dışa aktarma işlem hattımızın yapısı.

WeChat modundaki oyunlar hâlâ tarayıcı API'lerine göre yazılıyor. Paketleme sırasında bir adaptör (topluluk standardı weapp-adapter yaklaşımı) bu tarayıcı API'lerini wx.* üzerine eşliyor. Bu, oyunlarımızın hiçbir zaman doğrudan wx.* çağırmadığı anlamına geliyor; dolayısıyla bir wx emülatörü, var olmayan kod yollarını test ederdi. Bir taşıma işlemini asıl bozan şey, tarayıcıda wx.* bulunmaması değildir. Üretim sırasında sessizce kullanılan, WeChat'te karşılığı olmayan tarayıcı API'lerinin varlığıdır. document.createElement('div'). requestPointerLock(). IndexedDB. Chrome'da sorunsuz çözülen ancak WeChat iOS'ta hiçbir zaman çözülmeyecek bir .ogg dosyası.

Bu nedenle korumalı alan yokluğu simüle ediyor. WeChat'te bulunmayan her şey önizlemede kaldırılıyor, engelleniyor veya işaretleniyor; böylece oyun daha ilk karesinden itibaren iki platformun kesişim kümesi içinde geliştiriliyor.

Nerede çalışıyor: zaten mevcut olan bir service worker

Editör önizlememizin alışılmadık sunum yolu, bunu neredeyse bedavaya getirdi. Editördeki oyunlar ağ üzerinden sunulmuyor. Bir service worker, /game/* isteklerini yakalayıp dosyaları IndexedDB'den sunuyor; önizleme iframe'inin ağ gidiş dönüşü olmadan anında yeniden yüklenmesini sağlayan da bu. Bu worker zaten her oyun sayfasına iki sanal dosya enjekte ediyor: konsol çıktısını ve çökmeleri editöre ileten bir hata yakalama betiği ile canlı sahne inceleyicisi.

Korumalı alan, üçüncü sanal dosya olan _wechat-strict.js; yakalama betiğinden hemen sonra ve herhangi bir oyun kodu çalışmadan önce sayfanın <head> bölümüne enjekte ediliyor. Sıralama iki açıdan kritik. console.error çağrılarının önceden yakalanıp editöre akabilmesi için yakalama betiğinden sonra, engellerin ilk oyun kodu satırı çalıştırıldığında devrede olması için de oyun modüllerinden önce çalışmalı.

Etkinleştirme tek satırlık bir numaraya dayanıyor. Oluşturucudaki WeChat anahtarı localStorage içinde saklanıyor ve önizleme iframe'i editörle aynı origin'i kullandığından test düzeneği bayrağı doğrudan okuyabiliyor:

try {
  if (localStorage.getItem('cinevva-gc-profile') !== 'wechat-minigame') return;
} catch (e) { return; }

WeChat dışındaki her oyun için betik yalnızca tek bir dize karşılaştırması yapıp erkenden çıkıyor. Derleme bayrağı yok, sunucu gidiş dönüşü yok, service worker ile eşitlenecek durum yok.

Engelleme listesi ve iki katmanlı sınıflandırma

Her ihlal aynı tepkiyi hak etmiyor; bu nedenle test düzeneği iki katmanı birbirinden ayırıyor. WeChat'te hiç bulunmayan API'ler hata fırlatıyor; çünkü dışa aktarımdan sonra olan da bu ve üretim sırasında yaşanan bir çökme, inceleme sırasında yaşanacak çökmenin dürüst bir önizlemesidir. Var olup daha sonra bozulan şeyler ise davranışları değiştirilmeden yüksek sesli konsol hataları olarak işaretleniyor; çünkü bunları engellemek, oyunun gerçek durumunu üzerinde çalışan kişiden gizlerdi.

Hata fırlatma katmanı: Hem createElement hem de createElementNS üzerinden herhangi bir HTML kullanıcı arayüzü öğesi oluşturmak (Three.js kendi canvas'ını NS varyantıyla oluşturduğu için her iki yolun da aynı kapıdan geçmesi gerekiyor), eval, new Function, requestPointerLock ve service worker kaydı. Fırlatılan her hata, mesajında çözümü de taşıyor:

throw violate("document.createElement('" + tag + "') — WeChat mini oyunlarında DOM bulunmaz. " +
  "Kullanıcı arayüzünü canvas üzerine çizin (ekran dışı 2D canvas -> ekran uzayında bir dörtgen üzerinde THREE.CanvasTexture) " +
  "ve dokunma isabet testini kendiniz yapın.");

İşaretleme katmanı: indexedDB okuma (tam WeChat'teki gibi undefined döndürür ve ayrıca localStorage kullanımını öneren bir hata verir), WeChat iOS'un çözemediği herhangi bir biçimdeki sesler (üç yerde kontrol edilir: Audio kurucusu, medya öğesi prototipindeki src ayarlayıcısı ve getirilen URL'ler), oyunun kendi origin'i veya varlık CDN'imiz dışındaki herhangi bir origin'e yapılan ağ istekleri (WeChat'te bunlar beyaz listeye alınmış, ICP kaydı yapılmış bir alan adı gerektirir) ve Tone.js'in herhangi bir şekilde ortaya çıkması.

Ayrıca sayfa yerleştikten kısa süre sonra çalışan bir yükleme sonrası denetim de var: <body> içinde gezinir ve dinamik oluşturma yerine oyunun kendi işaretlemesiyle gelen tüm HTML öğelerini bildirir. Statik HUD'lar bir createElement kapısından kaçabildiği için yalnızca kapı yeterli değildir.

Her rapor mesaj bazında yinelenen kayıtları kaldırıyor ve oturum başına elli raporla sınırlandırılıyor. Her karede bir div oluşturan ters çevrilmiş döngü hatası, sinyali boğan bir hata seli değil, tek bir hata üretiyor.

Bize en çok şey öğreten dört istisna

Korumalı alan oluşturmak çoğunlukla neyin engellenmeyeceğine karar vermektir ve eklediğimiz her istisna, geliştirme sırasında kendi araçlarımızın bozulmasından doğdu.

Hata ayıklayıcımız eval üzerinde çalışıyor. Yapay zekânın çalışan oyunu incelemek için kullandığı execute_js aracı, kodu eval çağıran yakalama betiğinin mesaj işleyicisi üzerinden değerlendiriyor. eval işlevini safça engellemek, yapay zekânın kendi gözlerini kör ederdi. Çözüm: Test düzeneği, engellemeden önce gerçek işlevi numaralandırılamayan bir özellikte saklıyor ve yakalama betiğinin işleyicisi gerektiğinde buna geri dönüyor:

Object.defineProperty(window, '__cinevvaRealEval', { value: window.eval, enumerable: false });
window.eval = function () { throw violate('WeChat mini oyunlarında eval() yasaktır.'); };
// capture script, at message time:
returnValue = (window.__cinevvaRealEval || eval)(e.data.code);

eval kullanmaya çalışan oyun kodu yine duruyor. Hata ayıklayıcı ise çalışmaya devam ediyor.

Kaydedici de öğeler oluşturuyor. Reel kaydedicimiz, iframe'in kendi document.createElement işleviyle oluşturulan bir <script> olarak oyun iframe'ine enjekte ediliyor ve tamamlanan videoları sentetik bir <a> tıklaması aracılığıyla indiriyor. Bu etiketleri engellemek, kayıt özelliğini yalnızca ve tam olarak WeChat modunda bozardı. Bu nedenle script etiketine izin veriliyor ve a hata fırlatmadan uyarı veriyor. Gerçek bir bağlantıyla yayımlanan oyun yine işaretleniyor, araçlar da çalışmaya devam ediyor.

Klavye olayları kalıyor. Yapay zekâ, tuş basımlarını taklit eden ve oyun durumunun nasıl değiştiğini geri okuyan bir araçla kontrolleri doğruluyor. Telefonu simüle etmek için klavye girişini bastırmak, ters çevrilmiş kamera hatalarını yakalayan kontrol doğrulama döngüsünü yok ederdi. Önceliğin dokunmatik kontrollerde olması korumalı alan tarafından değil, üretim kuralları ve profilin kontrol şeması tarafından zorunlu tutuluyor.

WebGL2 kalıyor ve nedeni aşağıda kendine ait bir bölümü hak ediyor. Engelleme listesinin taslağı, profilin talep ettiği "WebGL1 uyumlu" işlemeyi zorlamak için getContext('webgl2') çağrısını engelliyordu. Ancak Three.js r163 sürümünde WebGL1 desteğini tamamen kaldırdı ve biz r181 sürümünü sabitliyoruz: WebGL2'yi engellemek bu moddaki her 3D oyunu boş ekrana dönüştürürdü. Profilin işleme kuralı tutarsızdı ve platforma dair güncelliğini yitirmiş bir zihinsel modele göre yazılmıştı. Korumalı alan denetimi, korumalı alanın kendi teknik şartnamesini denetlemiş oldu ve bu ipin ucunu çekmek bizi önemli bir yere götürdü.

WebGL2 sorusunun doğru yanıtı

Bağlam oluşturma işlemini olduğu gibi bırakmak, bariz bir devam sorusu doğurdu: Motorumuz WebGL2 gerektiriyorsa oyunlar yalnızca WebGL1'e sahip WeChat cihazlarında bozulur mu? Bu sorunun peşine düşmek, platformun minimum işleme kapasitesi hakkında şimdiye kadarki en net tabloyu ortaya çıkardı; kaynaklarıyla birlikte durum şöyle.

Android'de WeChat'in mini oyun çalışma zamanı, güncel herhangi bir temel kitaplıkta WebGL2 sunuyor ve alttaki GLES3 donanımı fiilen evrensel durumda. Asıl mesele iOS. WeChat'in WebGL2 desteğine ve yüksek performans+ moduna ilişkin kendi mühendislik belgeleri, iPhone'da WebGL2'nin yalnızca güncel bir WeChat istemcisi (8.0.45 ve üzeri, iOS 14'te daha yüksek) ve fiilen iOS 15.5 veya üzerini gerektiren yüksek performans+ çalışma zamanında düzgün biçimde kullanılabildiğini açıkça belirtiyor. Tencent'in kendi tanımına göre düz yüksek performans modu WebGL2'yi "daha fazla sorunla" çalıştırıyor ve normal iOS çalışma zamanında WebGL2 hiç bulunmuyor.

Asıl tehlikeli olan, hatanın ortaya çıkış biçimi. Desteklenmeyen ortamlarda getContext('webgl2'), null yerine truthy ama bozuk bir bağlam döndürebiliyor; geliştiriciler Tencent'ten doğrudan düzeltmesini istediği bir davranış bu. Dönüş değerine güvenen bir oyun burada temiz biçimde hata vermiyor. Bozuk grafikler veya sessiz bir siyah ekran oluşturuyor.

Bunu üç katmanda ele alıyoruz. Korumalı alan, kendi motorumuzla çatışacağı için WebGL2 bağlam oluşturma işlemini olduğu gibi bırakıyor. Üretim profili artık her oyunda bir açılış kapısı bulunmasını şart koşuyor: Renderer oluşturma işlemi try/catch içine alınıyor, ardından işlevsel bir kontrol yapılıyor (typeof gl.createVertexArray === 'function'; yalancı bir bağlamda bulunmayacak, yalnızca WebGL2'ye özgü bir özellik) ve başarısızlık durumunda boş ekran yerine canvas üzerine çizilmiş, kullanıcı dostu bir "lütfen WeChat'i güncelleyin" mesajı gösteriliyor. Bu, Unity'den dönüştürülen mini oyunların kullandığı kalıbın aynısı; bu yüzden gerçek dünyada siyah ekranlar yerine yükseltme istemleri görüyorsunuz. Dışa aktarıcı hazır olduğunda da yetenekli yolun varsayılan olması için game.json içinde yüksek performans+ modunu sabitleyecek.

WebGL2 taban çizgisinin kitle üzerindeki maliyeti nedir? Yaklaşık olarak iOS 15.5'in altındaki veya 8.0.45'ten eski WeChat istemcilerini kullanan kullanıcılar; 2026'da düşük tek haneli yüzdeler, ancak eski cihazlarda yoğunlaşıyor ve bu bazı oyun türleri için diğerlerinden daha önemli. Gerçek dağıtım verileri bir gün bu uzun kuyruğun peşinden gitmeye değdiğini gösterirse ucuz bir kaçış yolunu hazır tutuyoruz: WeChat profilini WebGL1'i destekleyen son sürüm olan three r162'ye sabitlemek. Profil oyunları yalnızca kararlı temel API'lere dokunduğu için sürüm düşürmek, veriler gerektirene kadar bilinçli olarak kullanılmadan bekletilen tek satırlık bir import map değişikliğinden ibaret.

Model ile döngüyü kapatmak

Yapay zekâ öncelikli bir ürün için bunu geliştirmeye değer kılan kısım şu. Her derlemeden sonra oluşturucunun ajanı, oyunun konsolunu okuyan ve açılışın tamamlanmasını bekleyen bir aracı çağırıyor. Yakalama betiği console.error çıktılarını bu akışa iletiyor. Dolayısıyla bir [wechat-strict] ihlali, insanın kaydırıp geçebileceği bir uyarı değildir. Modelin bir derlemenin tamamlandığını ilan etmeden önce zaten kontrol ettiği kanala, aynı tur içinde ve çözümü mesajda açıkça yazılmış hâlde ulaşır.

Üretim profili son boşluğu tek bir talimatla kapatıyor: Her [wechat-strict] mesajını derlemeyi bozan bir hata olarak ele al, nedenini düzelt ve test düzeneğini hiçbir zaman tespit etmeye veya atlatmaya çalışma. Yalnızca korumalı alan kapalıyken çalışan bir oyun, dışa aktarımdan sonra başarısız olacak bir oyundur ve modele tam olarak bu söylenir.

Korumalı alan böylece muğlak bir uyumluluk sorununu ("model on dört kuralın tümüne uydu mu?"), sistemin zaten iyi olduğu hata ayıklama döngüsüne ("konsolda bir hata var, düzelt") dönüştürüyor.

Tarayıcının simüle edemeyecekleri

Dürüstlük bölümü. Bu korumalı alan, tahminimize göre bir taşıma işlemini bozan sorunların büyük çoğunluğunu oluşturan API yüzeyi ihlallerini yakalıyor. Şunları yakalayamaz: gerçek bir telefondaki performans, iOS'un JavaScript'i JIT olmadan çalıştırması, WeChat'in WebGL uygulamasına özgü tuhaflıklar veya dosya uzantılarının ötesindeki codec davranışı farkları. Bunlar gerçek çalışma zamanını gerektiriyor.

Bu nedenle korumalı alan üç halkanın ilki. İkinci halka, dışa aktarıcımız WeChat DevTools projeleri üretmeye başladığında, DevTools CLI ve miniprogram-automator aracılığıyla başsız olarak yönetilen resmî simülatör olacak: Dışa aktarılan paketi başlat, ilk karenin işlendiğini doğrula, bir dokunma işlemini betikle. Üçüncü halka ise önizleme QR kodları ve fiziksel telefonlarda uzaktan hata ayıklamadan oluşan resmî cihaz yolu; başka hiçbir şeyin ortaya çıkaramadığı gerçekler burada yaşar. Her halka öncekinden daha yavaş ve gerçeğe daha yakındır; her birinin görevi, bir sonrakine gitme ihtiyacını azaltmaktır.

Modu denemek isterseniz Game Creator içindeki "WeChat mini oyun modu" anahtarını kullanabilirsiniz. Tüm bunların pazar ve mevzuat bağlamı için WeChat'in yarım milyar oyuncusuna ulaşma saha rehberimize göz atın.

Kaynaklar

• WeChat resmî belgeleri: Mini oyunlarda JavaScript desteği
• WeChat resmî belgeleri: Adaptör katmanı
• WeChat resmî belgeleri: Yüksek performans+ modu
• WeChat mühendislik belgeleri: Mini oyunlarda WebGL2 işleme desteği
• WeChat mühendislik belgeleri: iOS yüksek performans ve yüksek performans+ modları
• WeChat geliştirici topluluğu: Bozuk webgl2 bağlamları null döndürmelidir
• WeChat resmî belgeleri: miniprogram-automator
• Three.js r163 sürüm notları (WebGL1 desteği kaldırıldı)

Oleg Sidorkin, Cinevva CTO'su ve Kurucu Ortağı

Web oyunları geliştiriyorsanız, mobil desteğiniz ne kadar iyi olursa olsun oyunlarınızın erişemeyeceği, aylık yarım milyar oyuncuya sahip bir pazar var. Bu pazar WeChat'in içinde yer alıyor, geçen yıl geliri neredeyse ikiye katlandı ve buraya girmek hem teknik bir portlama sürecini hem de Batılı geliştiricilerin çoğunun hiç duymadığı düzenleyici bir süreci gerektiriyor.

Buna yönelik çözümümüzün ilk parçasını kısa süre önce kullanıma sunduk: Cinevva Game Creator'da deneysel bir WeChat mini oyun modu. Bu yazıda konuyu daha ayrıntılı ele alıyoruz: platformun gerçekte ne olduğunu, kuralların neler olduğunu ve Çin dışındaki bir geliştirici için gerçekçi bir yolun nasıl göründüğünü anlatıyoruz.

Küçümsenmesi kolay rakamlarla pazar

WeChat, 1,4 milyarı aşan toplam aylık aktif kullanıcı tabanıyla Çin'in varsayılan iletişim uygulamasıdır. Mini oyunlar, dokunup anında oynanan deneyimler olarak uygulamanın içinde yer alır: kurulum veya uygulama mağazası gerekmez; bir sohbet mesajından, aramadan ya da paylaşımdan başlatılırlar. Tencent, 2025'te mini oyun platformunun aylık 500 milyon aktif kullanıcıyı aştığını, bir milyardan fazla kayıtlı oyuncuya ve yaklaşık 500.000 geliştiriciye ulaştığını duyurdu.

Ortada ciddi bir gelir de var. Çin'in mini oyun pazarı 2024'te yıllık %99 artışla 39,8 milyar yuan, yani yaklaşık 5,6 milyar dolar gelir elde etti. Bunun yaklaşık %69'u uygulama içi satın alımlardan, %31'i ise reklamlardan geldi. Bu dağılımı aklınızda tutun; çünkü reklam payı yabancı geliştiriciler açısından son derece önemli.

Ölçek açısından bakıldığında, yalnızca bir yıllık mini oyun geliri; Poki, CrazyGames ve itch.io gibi platformların üzerinde yer aldığı küresel web oyunları pazarının tamamıyla karşılaştırılabilir düzeyde. Bu, niş bir alan değil. Kendi kuralları olan paralel bir evren.

Web oyununuzu neden öylece portlayamazsınız?

Bir WeChat mini oyunu, web oyununa benzer ve JavaScript ile yazılır. Bu nedenle doğal varsayım, portlama işinin bir hafta sonunda tamamlanabileceğidir. Öyle değildir ve bunun nedenleri yapısaldır.

Mini oyunlar tarayıcıda çalışmaz. Size bir canvas, WebGL ve bir dizi wx.* API'si sağlayan WeChat'in kendi çalışma zamanı ortamında çalışırlar. DOM ve CSS yoktur. Oyununuzdaki her düğmenin, can göstergesinin, menünün ve iletişim kutusunun canvas üzerine çizilmesi ve tıklama/dokunma algılamasının kendi kodunuz tarafından yapılması gerekir. Oyununuzun kullanıcı arayüzü HTML ise bu arayüz WeChat'te mevcut değildir.

Girdi modeli de farklıdır. Pointer Lock ve fare yoktur; bu nedenle masaüstü tarzı bir FPS kamerası, sürükleyerek bakma kontrolüne dönüştürülmelidir. Birincil cihazda klavye de yoktur. Oyununuz yalnızca dokunmatik kontrollerle tamamen oynanamıyorsa oynanabilir değildir.

Ana paket için 4 MB, alt paketlerle birlikte toplamda 20 MB sınırı vardır ve oyununuzun çalıştırdığı her şeyin incelenen paketin içinde bulunması gerekir. Bu da bizi tüm platformu şekillendiren kurala getiriyor: WeChat, dinamik olarak çalıştırılan kodu yasaklar. eval, new Function, çalışma zamanında JavaScript indirme yoktur ve Tencent, bu kısıtlamayı aşmak için JS yorumlayıcıları yerleştiren uygulamaları aktif olarak reddeder. Her oyun, kapalı ve incelenmiş bir yapıttır.

Bu son kural nedeniyle, bizim ya da başka birinin web oyunlarını WeChat'e aktaran bir “portal uygulaması” hiçbir zaman olmayacak. Her oyun, bağımsız bir mini oyun olarak ayrı ayrı incelemeden geçer. Bu alanda size yardımcı olmak isteyen herhangi bir aracın temiz, kendi kendine yeten ve yalnızca canvas kullanan paketler üretmenize yardımcı olması gerekir. Yeni modumuzu bu tasarım kısıtı etrafında geliştirdik.

Düzenleyici gerçeklik

Şimdi kodla hiçbir ilgisi olmayan kısma geçelim. Çin, oyunları yayımlanmış medya olarak düzenler ve gereklilikler katmanlar hâlinde birikir. Bunların hiçbiri gizli değil, ancak Çin dışında neredeyse hiç kimse bunları açıkça anlatmıyor. Dolayısıyla gereklilikler şöyle:

ICP kaydı. 2023'ün sonlarından bu yana her mini program ve mini oyun, ICP kaydını tamamlamak zorunda (WeChat platformu üzerinden Çin makamlarına yapılan bir kayıt). Bu süreç genellikle bir ila üç hafta sürer.

Her oyun için telif hakkı kanıtı. Her oyun için ya yazılım telif hakkı kaydı ya da daha hızlı alınabilen elektronik telif hakkı sertifikası gerekir. Elektronik yöntem, oyun başına yaklaşık on ila on beş gün sürer. Çok sayıda küçük oyun yayımlamayı planlıyorsanız bunun her oyun için ayrı bir maliyet oluşturduğunu hesaba katmanız gerekir.

Ücret alıyorsanız banhao. Uygulama içi satın alım içeren her oyun, Ulusal Basın ve Yayın İdaresi'nden, yaygın adıyla banhao olarak bilinen bir oyun yayın lisansı almalıdır. Yabancı bir geliştirici açısından bu süreci iki gerçek tanımlar. Birincisi, yalnızca Çinli bir şirket başvurabilir. İkincisi, ithal oyunlar ayrı ve daha yavaş bir onay sürecinden geçer; bu süreç işlediğinde tarihsel olarak altı ila sekiz ay sürmüştür. Uygulamada Çin dışındaki bir geliştirici, para kazandıran bir oyunu ancak başvuruyu yapan, lisansı elinde bulunduran ve oyunu işleten lisanslı bir yerel yayıncı aracılığıyla yayımlayabilir.

Reklamlı ücretsiz oyun istisnası. Hiçbir türde ödeme içermeyen ücretsiz bir oyun için banhao gerekmez. Oyun yine de WeChat'in kendi reklam bileşenleri aracılığıyla gelir elde edebilir. Unutmayın: reklamlar, 2024'teki mini oyun gelirlerinin %31'ini, yani 1,7 milyar dolardan fazlasını oluşturdu. Bu, küçük bir geliştiricinin Çinli bir kurumsal ortak olmadan ilerleyebileceği tek yoldur ve pazarın uzun kuyruğundaki oyunların büyük bir bölümü tam olarak bu şekilde faaliyet gösterir.

Dürüstçe özetlemek gerekirse: ücretsiz ve reklam destekli bir mini oyun yayımlamak, haftalarla ölçülen bir evrak sürecidir. Para kazandıran bir oyun yayımlamak ise dikkatle seçmeniz gereken bir ortakla birlikte aylarla ölçülen bir iş geliştirme projesidir.

Cinevva'nın mini oyun modu bu konuda ne yapıyor?

Evrak işlemlerinizi sizin yerinize yapamayız. Ancak daha ilk istemden itibaren oyunun kendisinin hiçbir zaman engel oluşturmamasını sağlayabiliriz.

WeChat mini oyun modu açıkken Game Creator, taşınabilir alt kümenin sınırları içinde oyun oluşturur: HTML yerine canvas üzerinde çizilen kullanıcı arayüzü; pointer lock yerine sürükleyerek bakma özelliğine sahip, dokunmatik öncelikli kontroller; gerçek WebGL2 desteğinin bulunmadığı durumlarda uygun bir yedek ekran sunan ve orta segment telefonlara göre bütçelenmiş render işlemi; yalnızca mp3 seslerini destekleyen katı bir varlık bütçesi; dinamik import ve çalışma zamanında kod yükleme olmaması; ayrıca WeChat'in depolama API'sine eşlenen kayıtlar. Oyun, diğer tüm Cinevva oyunları gibi tarayıcıda çalışmaya devam eder; böylece oyunu normal şekilde oluşturabilir, test edebilir ve paylaşabilirsiniz. Tek fark, portlama işleminden sağ çıkabilecek alt kümenin sınırları içinde kalmasıdır.

Bu oyunlardan birinden, WeChat DevTools'ta doğrudan açılmaya hazır bir proje üreten dışa aktarma aracı üzerinde çalışmalar devam ediyor. Sıralamayı bilinçli olarak bu şekilde yaptık. Bir dışa aktarma aracı kodunuzu paketleyebilir, ancak HTML ile hazırlanmış bir HUD'ı ortadan kaldıramaz veya yalnızca fareyle çalışan kontrolleri yeniden tasarlayamaz. Taşınabilirlik, oyunun nasıl oluşturulduğuna bağlı bir özelliktir; bu nedenle önce modu geliştirdik.

Mini oyun motorları rehberimizi veya WeChat ve Douyin için yayınlama kılavuzunu okuduysanız burada üretim sürecine uygulanan yaklaşımı biliyorsunuzdur: en ucuz portlama, hiç yapmak zorunda kalmadığınızdır.

Çin dışındaki bir geliştirici için gerçekçi bir yol haritası

İlk oyun için bizim gerçekten yapacağımız şey şu olurdu: küçük ve kısa oturumlu bir oyun geliştirmek. Çünkü platform bunları ödüllendiriyor; başarılı oyunlar destansı maceralar değil, oyuncuya “bir tur daha” dedirten oyunlardır. Dikey ekranı ve yalnızca dokunmatik kontrolleri önceliklendirerek tasarım yapın. Oyunu reklamlı ve ücretsiz olarak yayımlayın; böylece Çinli oyuncuların oyununuzu isteyip istemediğini öğrenirken banhao sürecinin dışında kalırsınız. ICP kaydını ve elektronik telif hakkı sertifikasını kendiniz halledin; bunlar zahmetlidir ancak yönetilebilir. Yalnızca oyun oyuncuları elde tutabildiğini kanıtladığında ve gerçek bir uygulama içi satın alım potansiyeli gördüğünüzde, elinizde verilerle yayıncı görüşmelerine başlayın. Çünkü oyununuz zaten bir kitleye sahipse yayıncıyla yapılacak müzakere çok farklı ilerler.

Yeni mod, tam olarak bu stratejiyi desteklemek için geliştirildi: aday oyunları üretmenin maliyetini neredeyse sıfıra indirmek ve böylece düzenleyici harcamalar başlamadan önce neyin işe yaradığını keşfedebilmenizi sağlamak.

Bu pazara girmeyi planlıyorsanız mod henüz şekillenme aşamasındayken sizden gerçekten haber almak isteriz. Bizimle iletişime geçin veya Game Creator'da oyun geliştirmeye başlayın.

Kaynaklar

• PocketGamer.biz: WeChat Mini Games aylık 500 milyon aktif kullanıcıyı aştı
• iChongqing: WeChat Mini Games 1 milyar kullanıcıya ulaştı
• Oreate: 2025 WeChat mini oyun ekosistemi gelişim raporu (2024 pazar verileri)
• Resmî WeChat belgeleri: JavaScript desteği ve dinamik kod yasağı
• Resmî WeChat belgeleri: tarayıcı tarzı kod için uyarlama katmanı
• Niko Partners: Çin'deki oyun düzenlemeleri
• ClearLaunch: Çin'de oyun onayı (banhao) gereklilikleri ve yaptırımlar
• AppInChina: kapsamlı WeChat mini oyunları rehberi

Mariana Muntean, Cinevva CEO'su

Oyun sektörü 2025'te yaklaşık 195,6 milyar dolar kazandı. Şimdiye kadarki en iyi yılıydı. Aynı dönemde yaklaşık her üç geliştiriciden biri işini kaybetti.

Bu iki cümleyi tekrar okuyun. Bir arada var olmamaları gerekirdi ama geldiğimiz nokta bu. Son iki yılda işten çıkarıldıysanız, bu hesabın bir durgunluk gibi hissettirmediğini zaten biliyorsunuz. Daha çok, denize düşen sizken size teknenin gayet iyi olduğunun söylenmesine benziyor.

Ben de bağımsız bir geliştiriciydim. Arkadaşlarımın on sekiz ay içinde üç kez “iş arıyor” rozetini paylaştığını gördüm. Dolayısıyla bu, kenardan ortaya atılmış iddialı bir yorum değil. Gerçekte ne olduğuna, ardından da şu anda iş arıyorsanız en önemli olan kısma bakalım: İnsanların gerçekten yeniden işe alınmasını sağlayan şey ne?

Rakamlar, hissedilenden de kötü

İşten çıkarma dalgası 2022'de başladı ve aslında hiç durmadı. Bu, kötü geçen tek bir çeyrek değil. Dört yıllık yapısal bir yeniden yapılanma.

Hangi takip kaynağına güvendiğinize bağlı olarak bu dönem boyunca yaklaşık 44.000 ila 55.000 iş ortadan kalktı (Wikipedia, GamesBeat). GDC'nin 2.300'den fazla profesyonelle yaptığı ankete dayanan 2026 Oyun Sektörünün Durumu raporu, dünya genelindeki geliştiricilerin %28'inin son iki yılda işini kaybettiğini, ABD'de ise bu oranın %33 olduğunu ortaya koydu (GamesIndustry.biz). Katılımcıların yarısı, mevcut ya da en son çalıştıkları işverenin son on iki ay içinde işten çıkarma yaptığını söyledi.

En ağır darbeyi Kuzey Amerika aldı. Bu sektörün düzenli bir nüfus sayımına en yakın kaynağı olan Amir Satvat'ın iş gücü takibi, küresel çalışan sayısı neredeyse hiç değişmezken bölgesel iş gücünün küçüldüğünü gösteriyor. Kuzey Amerika'daki oyun sektörü çalışanlarının yaklaşık %19'u bu durumdan etkilendi (GamesBeat).

İşe alımlar “toparlanmış” olsa bile iş aramanın neden imkânsız gibi hissettirdiğini açıklayan istatistik şu: Satvat, bu dönem boyunca yaklaşık 288.000 kişinin oyun sektöründe iş aradığını tahmin ediyor. Yeni mezunlar, işten çıkarılmış deneyimli çalışanlar ve kariyer değiştirenler; hepsi aynı sınırlı sayıdaki ilana başvuruyor. Artık bir iş ilanına özgeçmiş gönderdiğinizde bir düzine insanla yarışmıyorsunuz. Bir stadyum dolusu insanla yarışıyorsunuz.

Rekor bir yıl neden yine de işten çıkarmalarla sonuçlandı?

Gelir ortadan kaybolmadı. Belirli ellerde yoğunlaştı. Giderek azalan sayıdaki dev canlı servis oyunu, gelirin orantısız ölçüde büyük bir bölümünü alıyor; bu da daha az yeni yatırım, daha az yeni ekip ve eskiden yetenekleri bünyesine katan orta ölçekli projelerin daha az olması anlamına geliyor. Oyun sektöründeki özel yatırımlar 2025'te yarıdan fazla düştü (Outlook Respawn). Stüdyolar da her zamanki gibi karşılık verdi: Projeleri iptal ettiler, bütçeleri kıstılar ve işleri yüklenicilere devrettiler.

Yani kâr da gerçek, acı da gerçek ve ikisi de aynı nedene işaret ediyor. Gelen kutunuzu sürekli yenileyen kişi sizken bu pek teselli sayılmaz ama size yararlı bir şey söylüyor. Bu piyasa, 2021'e geri dönmeyi beklemiyor. Yeniden işe alınan insanlar da bunu beklemiyor. İşe alımların artık gerçekte nasıl yürüdüğüne uyum sağlıyorlar.

İş piyasasının bir özgünlük sorunu var

Bugün adayları değerlendiren herhangi biriyle konuşun, aynı şikâyeti duyarsınız. Başvuruların altında eziliyorlar. İş ilanları birkaç saat içinde yüzlerce başvuru alıyor ve bunların çoğu aynı kişi tarafından yazılmış gibi görünüyor; çünkü bir bakıma aynı araç tarafından yazıldılar.

İşe alım uzmanları TechRound'a, asıl zorluğun yapay zekâ kullanımını tespit etmek olmadığını; “iyi optimize edilmiş, bağlamdan yoksun içerik” selinin pozisyonu gerçekten anlayan kişiyi bulmayı neredeyse imkânsız hâle getirdiğini söyledi (TechRound). LinkedIn de artık genel geçer, yapay zekâ tarafından yazılmış içerikleri vakaların yaklaşık %94'ünde tespit ettiğini ve bunların erişimini sessizce sınırladığını söylüyor (TechRound).

Buna tersinden bakınca, tüm bu yazının en iyi haberi ortaya çıkıyor. Her şey birbirinin aynısı gibi duyulduğunda, somut olmak bir süper güçtür. Birbirinin aynı cilalı içeriklerle dolu bir akışta gerçek işini ve gerçek düşünce sürecini gösteren kişi yalnızca öne çıkmaz. Gürültünün içindeki tek sinyal hâline gelir.

Kanıt, her seferinde ciladan üstündür

Özellikle oyun sektöründeki roller için fark yaratan şey daha şık bir PDF değil. Birinin bizzat deneyimleyebileceği kanıttır. 12 yıllık bir işe alım uzmanı bunu açıkça ifade etti: Oynanabilir bir yapı veya demo videosu, başvurunuzdaki neredeyse her şeyden daha fazla katkı sağlar.

Değişim tam olarak bu. Bir özgeçmiş, işe alım uzmanına tasarımdan anladığınızı söyler. Oynanabilir kısa bir bölüm ise bunu 30 ila 90 saniye içinde hissetmesini sağlar. Çalışan bir mekaniği, özgeçmişteki bir maddeyi taklit edebildiğiniz gibi taklit edemezsiniz. İçinde yürünebilen bir seviyeyi, çalışan bir gölgelendiriciyi, gerçekten hareket eden bir iskelet sistemini veya gerçek bir sahneye eşlenmiş etkileşimli bir ses ipucunu taklit edemezsiniz. Etkileşim, ayrıntılı incelemeye dayanabilen bir kanıttır; çünkü arkasında her kararını savunabilen bir kişi vardır.

İşe alım uzmanlarının aslında sınadığı şey de bu son kısımdır. Yapay zekâyla şişirilmiş portföyleri yakalamak için kullandıkları yöntem basit: Çıktıyı değil, süreci sorun. Bir vaka çalışması oluşturan kişi, metinde ne yazdığını anlatabilir ama arkasındaki kararları açıklayamaz. Bu nedenle 2026'nın en güçlü portföylerinin hepsi aynı dört unsuru taşıyor:

“Koruduğunuz, değiştirdiğiniz ve reddettiğiniz” kısmı çoğu insanın atladığı, fakat zevkinizi kanıtlayan bölümdür. Zevk, taklit edilmesi en zor şeydir ve bir stüdyonun satın aldığı şey de tam olarak budur: Olası görünen on fikir arasından doğru olanı seçebilen biri. “Çok şey öğrendim” şeklindeki sonuç bölümünü atlayın. Verdiğiniz kararı ve bunun oyuncuya neden daha iyi hizmet ettiğini gösterin.

Yapay zekâ hakkında birkaç söz; çünkü bu sektör öfkelenme hakkını kazandı

Yapay zekâ araçları kullanan bir platform yönetiyorum ve bu gerilim yokmuş gibi davranmayacağım. Aynı GDC anketi, üretken yapay zekânın sektör üzerinde olumsuz etkisi olduğunu düşünen geliştiricilerin oranının iki yıl önceki %18'den bugün %52'ye çıktığını ve en güçlü karşı çıkışın sanatçılardan, yazarlardan ve programcılardan geldiğini ortaya koydu (GamesIndustry.biz). İşten yeni çıkarıldıysanız ve size eski işinizin bir bölümünü bir modelin yapabileceği söylendiyse, “portföyün için yapay zekâ kullan” demek tavsiye değil, hakarettir.

O yüzden açıkça söyleyeceğim. Hiç kimse, işe alım uzmanına bir makinenin ürettiği ve kendisinin açıklayamadığı bir şey sunarak işe alınmaz. İş size ait olmalı. Kararlarınız, zanaatınız, sorumluluğunuz. Bir projenin herhangi bir aşamasında araç kullandıysanız bunu söyleyin ve onun üzerine kendi muhakemenizi gösterin: Neyi korudunuz, neyi attınız, verdiğiniz karar oyuncu için neden daha iyiydi? İşe alım yöneticileri, aracın arkasına saklanan kişiye değil, araca yönlendirilmesi gereken bir stajyer gibi davranan kişiye güvenir. Süreciniz konusunda dürüst olmak profesyonellik olarak algılanır ve profesyonellik çoğu zaman yalnızca “yayımlamadan önce sonuçlarını düşündüm” demektir.

Kanıtı nereye koymalı?

Bu konuşmaların çoğu LinkedIn'de başladığı için pratik bir öneri: Akış, dış bağlantıların erişimini ciddi biçimde düşürür ama profilinizdeki Öne Çıkanlar bölümü bunu yapmaz. Bağlantıyı herhangi bir ceza olmadan temiz bir önizleme kartına dönüştüren tek yer burasıdır ve işe alım uzmanlarının ilk baktığı, profilinizin en üst kısmında bulunur. En iyi çalışmanız ilk sırada olacak şekilde üç ila beş öğeyi sabitleyin ve çoğu insanın bunlara telefondan baktığını unutmayın. İlk sıraya, birinin saniyeler içinde açıp deneyimleyebileceği öğeyi koyun.

Hızlı ve dürüst olun. İki saniyeden kısa sürede yüklenen ve tek bir net fikir gösteren demo; takılan veya 404 hatası veren iddialı bir projeden daha iyidir. Bir öğleden sonra otuz portföy inceleyen işe alım uzmanları beklemez ve bozuk bir bağlantı, özensiz bir alışkanlığın göstergesi olarak algılanır.

Bunu neden önemsiyoruz?

Cinevva'da tarayıcı tabanlı, anında oynanabilen oyunlar geliştiriyoruz. Bu da ürettiklerimizin çoğunun, modern bir portföyün tam olarak ihtiyaç duyduğu şey olmasını sağlıyor: İşe alım uzmanının tek bir bağlantı üzerinden, indirmeden ve kurmadan açıp oynayabileceği gerçek çalışmalar. Bu sorunu yakından takip ediyoruz çünkü bundan etkilenen insanlar bizim insanlarımız. İşten çıkarıldıysanız becerileriniz yok olmadı. Piyasa daha gürültülü hâle geldi ve kendinizi kanıtlama biçiminiz değişti.

Eski soru “nerede çalıştın?” idi. Yeni soruysa “bana oynayabileceğim bir şey göster ve onu neden bu şekilde geliştirdiğini anlat.” İkinci soruyu yanıltmak daha zordur ve işi gerçekten yapabilen insanlar için daha iyidir. Eğer siz de onlardan biriyseniz bu piyasa acımasızdır ama kapalı değildir. Güvenebileceği bir kanıt bekliyor.

Kaynaklar

• GDC 2026 Oyun Sektörünün Durumu: işten çıkarmalar, yapay zekâ ve sendikalaşma
• GamesBeat: Küresel oyun sektörü iş gücü 4 yılda %0,6 büyürken Kuzey Amerika küçüldü
• Wikipedia: 2022–2026 video oyunu sektöründeki işten çıkarmalar
• Outlook Respawn: Rekor kârlar, rekor işten çıkarmalar
• Game Developer: İşten çıkarmalar yavaşlıyor ama hasar çoktan oluştu
• TechRound: LinkedIn, yapay zekâ içeriklerinin istilasıyla karşı karşıya

İlgili içerikler:

• İş piyasası dönüşüyor: diplomalardan becerilere
• Oyunlar için yapay zekâ tartışmaları, güven ve yapay zekâ sonrası ekonomi
• Yapay zekâ çağında sezgisel zihin

Cinevva CEO'su Mariana Muntean tarafından

Tamam, itch.io'da koca bir haftayı tüketmeyi kesinlikle planlamamıştık. Hızlı bir araştırma olarak başlayan şey... on ikinci saat civarında saymayı bıraktığımız bir sürece dönüştü. Amacımız, hemen oynayabileceğiniz oyunları bulmaktı — indirme yok, arka planda ağır ağır çalışan kurulum programları yok. Tıklıyorsunuz ve oyundasınız. Bu kadar.

İşte seçtiklerimiz.

En Yüksek Puanlı Etkileşimli Deneyimler

Adventures With Anxiety! — Etkileşimli Hikâye 6.500'den fazla değerlendirmede 4,9 ortalama. Sizi kaygıyla yüzleşmeye zorlayan bir şeyin bu kadar çok hayranı olması çılgınca, değil mi? İyi anlamda rahatsız edici — aklınızdan çıkmayan türden. Buradan oynayın

We Become What We Behold — Toplumsal Eleştiri 7.600 değerlendirmede 4,8/5. Bitirmesi on dakika. Üzerine düşünmeyi bırakması günler sürüyor. Buradan oynayın

Six Cats Under — Bulmaca Macera Sıcacık ve zekice. Görseller burada işin büyük kısmını üstleniyor ve bu da oyunun lehine işliyor. 6.400'den fazla kişiden 4,8/5. Buradan oynayın

Friday Night Funkin' — Ritim Oyunu Artık bu oyun her yerde. 11.700'den fazla değerlendirme, 4,7/5. Buradan oynayın

Sort the Court! — Krallık Simülasyonu Tek göreviniz evet ya da hayır demek. Kulağa pek bir şeymiş gibi gelmiyor. Sonra siz hâlâ küçücük bir krallığı yönetirken iki saat ortadan kayboluyor. Buradan oynayın

Dragonsweeper — Bulmaca Roguelike Mayın Tarlası'nı alın ve RPG sistemleriyle harmanlayın. 4,9/5 — bu gerçekten de listedeki en iyi oyun olabilir. Buradan oynayın

Roguelike ve Strateji (Tarayıcıda Oynanabilir)

Backpack Hero — Envanter Roguelike Tarayıcı sürümü tamamen ücretsiz. Ücretli sürüm daha fazla içerik ekliyor ama ücretsiz web sürümü tek başına da gayet yeterli. Buradan oynayın

Vampire Survivors — Bullet Heaven Yalnızca demo — tek bölüm, yedi karakter. Yine de bu oyunun neden herkesin boş zamanını yuttuğunu anlamaya yetiyor. Buradan oynayın

Dome Romantik — Madencilik ve Savunma Bir game jam projesi olarak başladı. Dome Keeper'a dönüştü. Sonra devasa bir başarıya ulaştı. Orijinal prototip hâlâ çok iyi. Buradan oynayın

Neden Özellikle Bunlar?

Her bağlantıyı tek tek test ettik. Şöyle bir göz atıp geçmedik — gerçekten oturup bu oyunları oynadık. Sorunsuz yükleniyorlar. Tarayıcı kaynaklı gariplikler yok. Binlerce değerlendirme, indirme düğmesine hiç dokunmadan tıklayıp doğrudan oyuna giren insanlardan geldi. “Hmm, ilginçmiş” düşüncesinden gerçekten oynamaya uzanan bu sıfır sürtünmeli yol mu? Çoğu insan bunun ne kadar büyük bir fark yarattığını hafife alıyor.

Daha Fazla Web Oyununa Göz Atın

Hâlâ daha fazlasını mı istiyorsunuz?

• itch.io'daki en yüksek puanlı HTML5 oyunları
• En iyi HTML5 platform oyunları
• 2024-2025 döneminden oyunlar

Dikkate Değer Bağımsız Oyunlar (İndirme Gerekir)

Bazı harika oyunlar tarayıcınızda çalışmıyor. Bunlar, fazladan zahmete değer:

Slice & Dice — Zar Roguelike Windows, Mac ve Android'de çalışıyor. itch.io'dan edinin

Stacklands — Kartlarla Köy Kurma Windows ve Mac. itch.io'dan edinin

Luck be a Landlord — Slot Makinesi Roguelike Kulağa geçici bir numara gibi geliyor. Ama değil. O slot makinesi görünümünün altında gerçek bir strateji var. itch.io

Patrick's Parabox — Özyinelemeli Bulmacalar Beyninizin ağrımasını bekleyin. Buna rağmen oyunu sevmeyi de bekleyin. itch.io

Dome Keeper — Madencilik ve Savunma Sözünü ettiğimiz game jam prototipinin tam sürümü. Steam'de bulun

Brotato — Arena Hayatta Kalma Steam'de mevcut

Oyun geliştiriyorsanız üzerine düşünmeniz gereken bir şey var: tarayıcı sürümleri, oyuncularla eseriniz arasındaki tüm engelleri kaldırır. Unutup gidecekleri bir indirme kuyruğu yok. Tıklayıp geçmeleri gereken bir kurulum ekranı yok. Tek tıklama ve yaptığınız oyun hakkında fikir edinmeye çoktan başladılar. Bu tür bir anındalık yeterince konuşulmuyor — ama her şeyi değiştiriyor.

Kendi oyununuz için de bunu ister misiniz? Cinevva oyun oluşturucu ile doğrudan tarayıcıda bir oyun geliştirebilirsiniz; öne çıkardığımız oyunlar da topluluk Arcade'imizde yerini alır.

• Oyun geliştiricileri için
• Hızlı yüklenen bir web oyunu geliştirin

Cinevva CTO’su ve Kurucu Ortağı Oleg Sidorkin tarafından

2026’da tarayıcıda çalışan bir 3D oyun yayımlamak istiyorsanız, önünüzde dört yaygın seçenek ve birkaç yeni alternatif var. Bunların hepsi “web oyun motorları” başlığı altında toplansa da aslında farklı sorunları çözen, gerçekten farklı araçlar. Yanlış seçim size aylar kaybettirebilir. Bu, geçimini bir web 3D motoru geliştirerek sağlayan ve kendi motorumuzu oluşturmadan önce bu seçeneklerin hepsini değerlendirmiş kişiler tarafından hazırlanmış, güncel ve doğruluğu kontrol edilmiş bir karşılaştırmadır.

Her seçeneğin gerçekte ne olduğunu, kimlere uygun olduğunu ve hangi alanlarda yetersiz kaldığını ele alacak, sonunda da kısa bir karar rehberi sunacağız. Belirttiğimiz sürüm numaraları Temmuz 2026 itibarıyla günceldir.

Tüm seçenekleri mi görmek istiyorsunuz? Bu yazı, yaygın dört 3D seçeneğe odaklanıyor. Phaser, Defold ve Construct gibi 2D seçenekler de dâhil olmak üzere sıralanmış ve karşılaştırılmış 11 web motorunun tamamı için 2026’nın en iyi web oyun motorları rehberimize bakın.

Hızlı karşılaştırma

Yazının geri kalanı bu tabloyu ayrıntılı olarak açıklıyor.

PlayCanvas

PlayCanvas, web dünyasında Unity tarzı bir iş akışına en çok yaklaşan seçenek. Motor, MIT lisansı altında açık kaynaklıdır ve Temmuz 2026 itibarıyla v2.20.6 sürümündedir. Bir varlık-bileşen sistemi kullanır, oyun mantığını TypeScript veya JavaScript ile yazarsınız ve varlıklar, GLB üreten sunucu taraflı bir işlem hattından geçer. Gerçek ticari oyunlar PlayCanvas üzerinde çalışıyor ve büyük şirketler onu üretimde kullanıyor; Snap bunun kamuya açık örneklerinden biri.

PlayCanvas hakkında sıkça yanlış anlaşılan iki noktayı düzeltmekte yarar var. Birincisi, motor MIT lisanslı olsa da çoğu ekibin kullandığı barındırılan görsel editör açık kaynaklı değil, ticari bir üründür. Motoru editör olmadan ücretsiz kullanabilirsiniz ancak editör ve bulut iş akışı ücretli kısımdır. İkincisi, PlayCanvas öncelikle WebGL2’yi hedefler. Bir WebGPU yolu mevcut olsa da varsayılan render altyapısı olmaktan ziyade hâlâ olgunlaşma aşamasındadır. Bu nedenle bugün üretimde WebGPU compute shader’ları kullanmayı bekleyerek PlayCanvas’ı seçmeyin.

PlayCanvas’ın gerçekten önde olduğu alan, 3D Gaussian splatting’dir. Ekibin açık kaynak hâline getirdiği SuperSplat editörü ve görüntüleyicisi, büyük taramaları WebGPU tabanlı akışla sunabilmesi sayesinde splat sahnelerini yakalayıp web’de yayımlamak için mevcut en iyi araçlar arasındadır. Fotogerçekçi taranmış ortamlarla ilgileniyorsanız, bu PlayCanvas ile başlamak için güçlü bir nedendir.

PlayCanvas’ı seçin: Tarayıcı için Unity benzeri bir editör ve yönetilen bir varlık işlem hattı istiyorsanız ve bir stüdyonun geliştireceği türden oyun yayımlıyorsanız. Başka seçeneklere bakın: Bugün WebGPU compute özelliklerine ihtiyacınız varsa veya barındırılan ticari bir editörden kaçınmak istiyorsanız.

Three.js

Three.js bir oyun motoru değildir. Bir render kütüphanesidir ve bu alanda açık ara en yaygın kullanılan seçenektir. Size sahne grafiği, kameralar, ışıklar, materyaller, geometri, yükleyiciler ve bir renderer sunar; sonra da burada durur. Editör, fizik sistemi veya varlık sistemi yoktur ve oyununuzu nasıl yapılandırmanız gerektiği konusunda herhangi bir yaklaşım dayatmaz. Bunları kendiniz eklersiniz ya da ekosistemden edinirsiniz.

Bu tercih, Three.js’in tüm hikâyesini özetliyor. Render katmanının üzerindeki her şeyi geliştirme veya bir araya getirme maliyeti karşılığında azami kontrol ve web 3D alanındaki en büyük topluluğu elde edersiniz. WebGPU renderer’ı istikrarlı biçimde gelişiyor ve bugün kullanılabilir durumda; ancak diğer seçeneklerde olduğu gibi WebGL2 yolu hâlâ olgun ve varsayılan seçenektir. Three.js, MIT lisanslıdır.

Three.js’i seçin: Tam kontrol ve asgari bir temel istiyorsanız ve oyun sistemlerinizi bunun üzerinde geliştirecek mühendislik kapasitesine sahipseniz. Başka seçeneklere bakın: Editörün ve oyun sistemlerinin hazır sunulmasını istiyorsanız.

Babylon.js

Babylon.js, Apache 2.0 lisanslı ve Microsoft bünyesindeki bir ekip tarafından desteklenen tam kapsamlı bir motordur. Three.js’in aksine, normalde kendinizin bir araya getirmesi gereken parçalarla birlikte gelir: bir bileşen modeli, entegre Havok fizik motoru, ücretsiz web tabanlı editör ve varlık işlem hattı. WebGPU çalışmaları hızlı ilerledi ve genel amaçlı motorlar arasında en gelişmiş seçeneklerden biri hâline geldi; ancak geniş uyumluluk yolu olarak WebGL2’yi desteklemeyi de sürdürüyor. Babylon.js 9.0 (Mart 2026), her iki arka uçta kümelenmiş aydınlatma, WebGPU compute shader’ları üzerine kurulu hacimsel aydınlatma ve 3D Gaussian splat’ler için gölge desteğiyle bu üstünlüğü daha ileri taşıdı.

“Eksiksiz bir motor ve yerleşik fizik istiyorum, motorun kuralları içinde çalışmakta da sakınca görmüyorum” diye düşünüyorsanız Babylon güçlü bir varsayılan seçenektir ve bu alandaki en kapsamlı ücretsiz alternatif olduğu söylenebilir.

Babylon.js’i seçin: Her şeyin hazır gelmesini, yerleşik fizik sistemini ve ücretsiz bir editörü istiyorsanız. Başka seçeneklere bakın: Çok küçük bir bağımlılık boyutu istiyorsanız veya özellikle Unity tarzı, barındırılan bir iş akışı arıyorsanız.

Unity WebGL

Unity WebGL bir web motoru değil, dışa aktarım hedefidir. Unity masaüstü editöründe C# ile geliştirme yapar, ardından projenizi WebAssembly aracılığıyla tarayıcıda çalışan bir WebGL paketine derlersiniz. Bu durum, Unity WebGL’yi belirli bir senaryo için bariz seçenek hâline getiriyor: Hâlihazırda bir Unity oyununuz var ve bunun tarayıcı sürümünü oluşturmak istiyorsunuz.

Ancak web öncelikli bir proje için ciddi maliyetleri vardır. Çalışma zamanı ve indirme boyutu yüksektir, başlatma süresi yerel bir web motorundan daha uzundur ve mobil tarayıcı performansı bilinen bir sorundur. Unity tescilli bir yazılımdır ve WebGL çıktısı WebGL2’yi hedefler. Unity 6’da deneysel bir WebGPU arka ucu bulunuyor ancak varsayılan olarak kapalıdır ve üretime hazır değildir.

Unity WebGL’yi seçin: Tarayıcıya taşımak istediğiniz mevcut bir Unity projeniz varsa veya ekibiniz zaten tamamen Unity ile çalışıyorsa. Başka seçeneklere bakın: Orta segment telefonlarda anında yükleme kesin bir gereksinimse ya da sıfırdan, web öncelikli bir proje başlatıyorsanız.

Yapay zekâ odaklı ve dünya içi üretim bu tabloya nasıl uyuyor?

Yukarıdaki seçeneklerin tamamı aynı varsayıma dayanıyor: Bir geliştirici oyunu masa başında, bir editörde oluşturur ve bir çalışma zamanı olarak yayımlar. Bu varsayım çoğu proje için doğrudur ve sizin projenizi de tanımlıyorsa yukarıdaki dört seçenekten birini tercih edin.

Ancak artık tek seçeneğin bu olmadığını bilmekte yarar var; çünkü farklı bir kategori ortaya çıkıyor. Biz, oyunların doğrudan dünyanın içinden oluşturulduğu, yalnızca WebGPU kullanan bir dünya platformu olan Cinevva’yı geliştiriyoruz. Bir editör açmak yerine, mekânda duran bir avatar olarak ne istediğinizi tarif ediyorsunuz; yapay zekâ oluşturucu da siz oradayken bunu araziye, nesnelere ve davranışlara dönüştürüyor. Üretim ve oyun aynı oturum içinde gerçekleşiyor. Altyapıda bu yaklaşım, compute shader tabanlı araziyle yalnızca WebGPU kullanmayı, genel amaçlı bir fizik motoru yerine özel bir karakter çözücüsü geliştirmeyi ve bir animasyon ile yeniden hedefleme sistemi oluşturmayı gerektirdi. Bunları neden kendi WebGPU motorumuzu geliştirdik yazımızda anlattık.

Bu, PlayCanvas veya Babylon’ın yerini alacak bir seçenek değildir. Belirli bir oyun geliştiren bir yazılımcıysanız doğru araçlar onlardır. Cinevva ise motor geliştiricisi olmayan kişilerin, tarif ederek oynanabilir alanlar oluşturup paylaşabilmesi gibi farklı bir hedef içindir. Burada bundan bahsediyoruz çünkü “Hangi web oyun motorunu kullanmalıyım?” sorusunun giderek yaygınlaşan beşinci bir yanıtı var ve bu yanıt aslında bir motor değil.

Tam özellik matrisi

Yukarıdaki hızlı tablo ana hatları sunuyor. Aşağıdaki ayrıntılı sürüm ise alt sistemlere göre gruplandırılmıştır. Tabloyu nasıl okuyacağınıza dair birkaç açık not düşelim. “Kendiniz eklemelisiniz”, motorun ilgili özelliği hazır sunmadığı ancak ekosistemden veya kendi kodunuzla ekleyebileceğiniz anlamına gelir. Bu özellikle, tasarım gereği bir render kütüphanesi olan Three.js için önemlidir; dolayısıyla oradaki “Kendiniz eklemelisiniz” ifadeleri bir eksiklik değil, yaklaşımın özelliğidir. Unity için “Yalnızca dışa aktarım”, özelliğin masaüstü editöründe bulunduğu ve web’e özgü olmak yerine WebGL derlemesine dâhil edildiği anlamına gelir. Rakiplere ait hücreler, 2026 ortası itibarıyla kutudan çıktığı hâliyle sunulan özellikleri ve iyi belgelenmiş davranışları yansıtır. Cinevva hücreleri yayımlanmış derlememizde çalışan özellikleri gösterir; “planlanıyor” ifadesi ise tasarlanmış ancak henüz geliştirilmemiş özellikleri belirtir.

Render

Dünya ve arazi

Fizik ve karakter

Animasyon

Çok oyunculu sistemler ve arka uç

Üretim ve geliştirme

Varlıklar ve dağıtım

Matristeki örüntü asıl hikâyeyi anlatıyor. Genel amaçlı motorlar güçlerini yatay olarak dağıtıyor: Her biri çoğu işi yeterince iyi yaparken dünyayı, arka ucu ve üretim akışını size bırakıyor. Cinevva ise dikey olarak yoğunlaşıyor: Daha az işi üstleniyor ancak renderer’dan, içinden üretim yaptığınız paylaşımlı dünyaya kadar tüm süreci sahipleniyor. Bu yaklaşımların hiçbiri soyut olarak diğerinden daha iyi değil. Farklı sorulara yanıt veriyorlar.

Nasıl seçim yapılır?

Aracı bir özellik kontrol listesine göre değil, içinde bulunduğunuz duruma göre seçin. Zaten bir Unity oyununuz varsa Unity WebGL ile dışa aktarın ve dosya boyutunu kabullenin. Tarayıcı oyunları için editör odaklı bir iş akışı isteyen bir stüdyoysanız PlayCanvas kullanın. Fizik desteği dâhil, tamamen ücretsiz bir motor istiyorsanız Babylon.js kullanın. Tam kontrol istiyorsanız ve yalın bir render motoru üzerine geliştirme yapabilecek ekibiniz varsa Three.js kullanın. Amacınız tek bir oyun geliştirmek değil de insanların bir şeyleri tarif ederek ortak bir dünyada içerik oluşturmasını ve oynamasını sağlamaksa, bu bizim çalıştığımız kategori; Cinevva'yı deneyebilirsiniz.

Hangisini seçerseniz seçin, karar vermeden önce gerçek prototiplerle değerlendirme yapın. Bunların her biri gerçek bir oyunun altından kalkabilir ve geliştirme sürecinin ortasında geçiş yapmanın bedeli, oyunu yayınlamak için harcamadığınız aylardır.

Cinevva CTO'su ve Kurucu Ortağı Oleg Sidorkin tarafından

Cinevva World'e bakan teknik bilgili herkes beş dakika içinde aynı soruyu soruyor. Küçük bir ekipsiniz. Olgun web 3D motorları zaten var. Neden PlayCanvas veya Babylon'ı temel alıp daha hızlı yayınlamak yerine kendi işleyicinizi, karakter fiziğinizi ve animasyon sisteminizi yazdınız?

Bu makul bir soru ve buna verilecek yanlış cevap “burada icat edilmedi” sendromudur. Biz gerekli araştırmayı yaptık. Karar vermeden önce mevcut motorları çalıştırdık, kaynak kodlarını okuduk ve ikisinin üzerinde deneme sürümleri geliştirdik. Bu yazı, söz konusu kararın dürüst anlatımıdır: hazır seçeneklerin gerçekten iyi olduğu alanlar, ihtiyaçlarımızın kendi çözümümüzü geliştirmeyi haklı çıkaracak kadar ayrıştığı dört nokta ve bizi örnek almak yerine bu seçeneklerden birini tercih etmeniz gereken durumlar. Geliştirme sürecinin kendisini uzun soluklu tarayıcıda açık dünya mühendisliği serisinde belgeledik; dolayısıyla aşağıdaki bir iddiayı destekleyen çalışma günlüğü varsa ona bağlantı vereceğim.

Gerçekten değerlendirdiğimiz seçenekler

Dört farklı şeye “web oyun motoru” deniyor ve bunların hepsi aynı türde değil.

Three.js bir oyun motoru değil, işleme kütüphanesidir. Size bir sahne grafiği, materyaller, yükleyiciler ve işleyici sunar, ardından yolunuzdan çekilir. Editörü, fizik sistemi veya varlık sistemi yoktur ve oyununuzun nasıl yapılandırılması gerektiği konusunda herhangi bir yaklaşım dayatmaz. Hem cazibesi hem de bedeli budur. İşleyicinin üzerindeki her şeyi kendiniz geliştirirsiniz ama hiçbir şey de size karşı koymaz. MIT lisanslıdır, bu alandaki en büyük ekosisteme sahiptir ve gece saat 02.00'de sıra dışı bir gölgelendirici hatasıyla karşılaştığınızda forumda sizi bekleyen bir cevap vardır.

Babylon.js, sahne grafiği, fizik entegrasyonu (Havok), varlık işlem hattı ve web editörü içeren tam kapsamlı bir motordur. MIT lisanslıdır, Microsoft bünyesindeki bir ekip tarafından desteklenir ve WebGPU çalışmaları hızla ilerlemektedir. Her şeyin hazır gelmesini istiyorsanız ve motorun yapısı içinde çalışmaktan memnunsanız güçlü bir varsayılan tercihtir.

PlayCanvas, “web için Unity” tanımına en çok yaklaşan çözümdür. Bu yazının yazıldığı sırada motor, 5 Haziran 2026'da yayınlanan v2.19.6 sürümündedir ve motorun kendisi MIT kapsamında açık kaynaklıdır. Ancak çoğu kişinin gerçekten kullandığı şey barındırılan görsel editördür ve bu editör açık kaynaklı değil, ticari bir üründür. PlayCanvas bir varlık-bileşen sistemi kullanır; TypeScript veya JavaScript ile betik yazarsınız, varlıklar sunucu tarafındaki bir GLB işlem hattından geçer ve bununla gerçek ticari oyunlar yayınlanmıştır (örneğin Snap, üretim çalışmalarında PlayCanvas kullanıyor). İşleyicisi WebGL2 üzerinde çalışır; WebGPU yolu ise varsayılan olmak yerine hâlâ olgunlaşma aşamasındadır. Bu son ayrıntı göründüğünden daha önemli ve ona birazdan geri döneceğim.

Unity WebGL aslında bir web motoru değildir. Bir dışa aktarma hedefidir. Oyunu Unity masaüstü editöründe geliştirip bir WebGL paketi olarak derlersiniz. Zaten bir Unity oyununuz varsa ve onu tarayıcıya taşımak istiyorsanız doğru araçtır. Ancak “orta sınıf bir telefonda, bir sekmede anında yüklenmesi” kesin bir gereksinimse yanlış araçtır; çünkü çalışma zamanı ve indirme boyutu da beraberinde gelir.

Bunların herhangi biri normal bir web oyunu için makul bir temel olabilir. Bizimki normal bir web oyunu değildi.

Birinci karar: WebGPU bizim için bitiş çizgisi değil, alt sınır

Bizi tüm hazır çözümlerden uzaklaştıran ayrım şu: Bizim için WebGPU, zamanla geçeceğimiz bir özellik değil, bir gereksinim.

Arazi sistemimiz statik bir yükseklik haritasından ibaret değil. Akışla yüklenen bir yükseklik haritası alanı ile işaretli uzaklık alanıyla desteklenen marching cubes parçalarının hibritinden oluşuyor; böylece dünyada gerçek mağaralar ve çıkıntılar bulunabiliyor, içerik üreticileri de araziyi canlı olarak şekillendirebiliyor. Şekillendirme fırçaları, bitki örtüsü dağıtımı ve arazi ağ oluşturma işlemlerinin tümü hesaplama gölgelendiricileri olarak çalışıyor. Hesaplamayı kaldırdığınızda dünya daha düşük kalitede çalışmıyor; hiç çalışmıyor.

Bu, genel amaçlı motorların bugün bulunduğu noktanın tam tersi. Bu motorların WebGPU desteği, WebGL2 öncelikli bir işleyici üzerine aşamalı iyileştirme olarak tasarlanıyor ve bunu desteklemeyen tarayıcılar için bir geri dönüş yolu bulunuyor. Özellikle PlayCanvas, WebGL2 önceliklidir ve WebGPU hâlâ beta aşamasındadır. Bu onlar için doğru karardır; çünkü görevleri mümkün olan en geniş oyun yelpazesini, mümkün olan en geniş cihaz yelpazesinde çalıştırmaktır. Bizim görevimiz daha dar ve daha derin olduğu için tersini yaptık: 13. denemede yalnızca WebGPU'ya geçtik ve bir daha arkamıza bakmadık. WebGPU'suz tarayıcılarda kalite düşürülmüyor; bu tarayıcılar desteklenmiyor. Bunu, WebGL2 geri dönüşü tek bir yapılandırma seçeneği uzağındaymış gibi davranmak yerine erişim oranı olarak takip ediyoruz. Çünkü öyle değil. Böyle bir geri dönüş, arazi ve bitki örtüsü aşamalarımızın kısmen yeniden yazılmasını gerektirirdi.

WebGL2 öncelikli bir motorun üzerine inşa etmek, ya her hesaplama özelliğinde motorun geri dönüş varsayımlarıyla mücadele etmek ya da sonsuza kadar iki işleme yolu sürdürmek anlamına gelecekti. İşleyicinin bize ait olması, hesaplamayı temel kabul etmemizi sağladı.

İkinci karar: fizik motoru değil, karakter çözücüsü

Ders kitaplarındaki standart yaklaşım, bir fizik motorunu projeye eklemektir. Bunu denedik. İlk denemelerden biri Rapier'ın bir worker içinde çalışmasını doğruladı ve gayet iyi hissettirdi.

Yine de kendi çözümümüzü yazdık ve yayınlanan sürümün hiçbir yerinde Rapier, Cannon veya Ammo yok. Bunun nedeni kapsam. Katı cisimlere, eklemlere, ragdoll sistemlerine veya kısıt çözücüsüne ihtiyacımız yok. Bir kapsülün arazi üzerinde doğru hareket etmesine ihtiyacımız var; ayrıca yürüme, kayma, süzülme, tırmanma ve yüzme sistemlerinin “yere basıyor muyum, hangi yüzeydeyim ve hangi açıdayım?” sorusuna verilen tek bir ortak cevapta uzlaşması gerekiyor. Genel amaçlı bir fizik motoru bunu kolaylaştırmak yerine zorlaştırıyor; çünkü bu hareket modları sonunda motorun dahili yayları ve sönümleyicileriyle mücadele ediyor.

Bu nedenle karakter denetleyicimiz takılıp çıkarılabilir, çok kanallı bir durum makinesi. Her mod, o karede denetimi isteyip istemediğini belirten ve kazanırsa hızı ve bakış yönünü yazan küçük bir birimdir. Üç kanalda önceliğe göre hakemlik yaparlar: önce kaynak, ardından duruş, sonra hareket. Hepsi aynı arazi sorgusunu okur. Çarpışma, parçaya bağlı olarak yükseklik haritasına veya işaretli uzaklık alanına karşı yapılan bir kapsül yoklamasıdır.

En çok gurur duyduğum ayrıntı pek gösterişli değil. Zemin algılama sistemi, SDF gradyanına güvenmek yerine ayaklarınızın altındaki dikey sütunda bulunan her yüzeyi tarıyor ve kapsül hizasında veya altında bulunan en yüksek yüzeyi seçiyor. Bir çıkıntının kenarında, yan yöndeki en yakın yüzey uçurum duvarıdır. Bu nedenle gradyan tabanlı normal, “zemin” ile “duvar” arasında gidip gelir ve hayalet kaymalar yaşanır. Sütun sorgusu, bir çıkıntının üzerinde durmayı sıkıcı hâle getiriyor ki istediğiniz şey de tam olarak budur. Hazır bir yükseklik alanı çarpıştırıcısı bunu bize kendiliğinden sunamazdı, çünkü öncelikle arazimizi göremez. Arazi, bizim formatımızda GPU üzerinde yaşar. Her düzenlemede alanın tamamını harici motorun çarpıştırıcı formatına kopyalamadan hiçbir harici motor bununla çarpışma hesabı yapamaz.

Üçüncü karar: iskeletler arasında taşınabilen animasyon

Avatarlar Synty POLYGON iskeletini kullanıyor ve hareket kliplerimiz geniş bir açık animasyon kütüphanesinden geliyor. İskelet ve klipler aynı kemik adlarını paylaştığı için yaygın durumda çalışma zamanında yeniden hedefleme gerekmiyor; izler doğrudan ada göre bağlanıyor. Karakter işlem hattının tamamını evrensel karakterler yazısında anlattık.

Asıl ilginç çalışma, bunların eşleşmediği durumda başlıyor. Bir iskeleti diğerine eşleyen bir yeniden hedefleme geçişi geliştirdik ve bunu doğru yapmak üç özel sorunu çözmemizi gerektirdi. Önce bağlama pozlarını hizalarsınız; çünkü A pozu ile T pozu arasındaki fark, her ekleme fark ettirmeden yaklaşık otuz derece ekler. Kök hareketini ve adım uzunluğunu iki ayrı oranla ölçeklersiniz: dikey eksen için kalçadan zemine olan mesafe, yatay eksen içinse genel vücut oranı. Ayrıca yeniden hedeflenmiş klipleri sabit bir örnekleme hızında kaynaklarıyla karşılaştırarak test edersiniz; böylece gerilemeler oyuncudan önce ortaya çıkar. Bu işlem hattı, her klibi elle düzeltmeden yeni animasyon kaynakları ve nihayetinde içerik üreticilerinin sağladığı karakterler ekleyebilmemizi sağlıyor.

Bunun üzerinde, her karede hareket durumuna göre doğru klip ailesini seçen bir animasyon durum makinesi bulunuyor: hıza göre sıçrama çeşidi, darbenin şiddetine göre iniş, hızın arazi gradyanıyla skaler çarpımından eğim yönü, dururken ay yürüyüşü yapmamanız için ayak fazına uygun duruşlar ve bir duvara çarpmanın yürüme ile düşme arasında gidip gelmenize yol açmaması için yüz milisaniyelik gecikme filtresi. Bunların hiçbiri sıra dışı değil, ancak ancak bu katmana sahip olduğunuzda elde edebileceğiniz türden ayrıntılar.

Dördüncü karar: hiçbir motorun sunmadığı bölüm

Diğer üç karar dünyanın nasıl çalıştığıyla ilgili. Bu karar ise ürünün ne olduğuyla ilgili ve PlayCanvas karşılaştırmasının nihayetinde neden bir kategori hatası olduğunu açıklıyor.

PlayCanvas, Babylon, Unity ve elle geliştirilmiş bir Three.js uygulamasının tümü aynı modeli varsayar: Oyununuzu bir masa başında, 2D editörde, dünyaya dışarıdan bakarak geliştirirsiniz; ardından oynat düğmesine basıp ayrı bir çalışma zamanı yayınlarsınız. Motor içi düzenleme özelliklerinde bile bir iş istasyonunun başında oturur ve baktığınız sahneyi değiştirirsiniz.

Cinevva World bunu tersine çeviriyor. Dünyanın içinden, oyuncularınızın duracağı alanın aynısında duran bir avatar olarak; istediğiniz şeyi tarif edip ortaya çıkışını izleyerek üretim yaparsınız. Üretim ve oyun, bir çalışma zamanına bağlanan geliştirme adımı değil, kesintisiz tek bir oturumdur. Buna en yakın örnekler web 3D motorları değil; Roblox, Rec Room ve Horizon Worlds'tür. Üstelik onlar bile üretimin büyük bölümünü masa başında tutar. Fareyle kullanılan bir editör olmadan bunu uygulanabilir kılan şey, “buraya fenerlerle aydınlatılmış bir iskele yerleştir” ifadesini geometriye ve yerleşime dönüştüren yapay zekâ destekli oluşturucudur.

Bunu genel amaçlı bir motora sonradan ekleyemezsiniz; çünkü bu bir işleme özelliği değildir. Arazinin çalışma zamanında nasıl düzenlenebildiğinden ağ sisteminin her nesneyi yakında duran bir kişinin az önce yaptığı bir şey olarak ele almasına kadar tüm teknoloji yığınının temel varsayımıdır.

Bizim yaptığımızı ne zaman yapmamalısınız?

“Kendi motorumuzu geliştirdik” türündeki yazıların genellikle atladığı bölüm şudur: Bu çeyrekte bir tarayıcı oyunu yayınlamak istiyorsanız bizi örnek almayın. Unity tarzı bir editör ve yönetilen bir işlem hattı istiyorsanız PlayCanvas kullanın. Fizik sistemi dâhil tam kapsamlı bir motor istiyorsanız ve onun yapısı içinde çalışmaktan memnunsanız Babylon kullanın. En yüksek denetimi, en az dayatmayla istiyorsanız ve bunun üzerindeki katmanları geliştirecek ekibiniz varsa Three.js kullanın. Zaten bir Unity oyununuz varsa onu taşıyın.

Kendi işleyicinizi, fizik sisteminizi ve animasyon sisteminizi yazmak yalnızca ürününüzün temel fikri hazır çözümlerle bağdaşmıyorsa; geliştirdiğiniz şey bir motor üzerinde çalışan oyun değil, bir motordan oluşan bir mekânsa doğru karardır. Bizim durumumuzda bu doğruydu. Muhtemelen sizin durumunuzda doğru değil ve bunda bir sorun yok. Dürüst bir değerlendirme yapmanın amacı, ilk kod satırını yazmadan önce hangi durumda olduğunuzu bilmektir.

Oleg Sidorkin, CTO ve Cinevva Kurucu Ortağı

Artık dünyalar üretebiliyoruz ve bir demo videosundan söz etmiyorum. Yukarıdaki görsel bizim editörümüz. Biri sohbet kutusuna "ikinci katı inşa et" yazdı ve yapay zekânın döşemeyi yerleştirmesini, ön, yan ve arka duvarları yükseltmesini, ardından merdivenler ve çatıyla devam etmeyi önermesini izledi. Dekorlar veya dokular değil; başka insanların içine girip dolaşabildiği bir dünyaya yerleştirilen bütün yapılar. İşlem hattımız parçaları da üretiyor: 3D modeller, müzik, ses ve materyaller.

Dolayısıyla Cinevva World'ü halka açmaya çok yakınız. Bunu yapmadan önce gidip ölüm ilanlarını okudum.

Çünkü geliştirdiğimiz şeyle ilgili rahatsız edici gerçek şu: On beş yıldır çok zeki ve çok iyi finanse edilmiş ekipler, paylaşımlı yaratıcı dünyaları işler hâle getirmeye çalışıyor. Bunlardan birkaçı insanlığın bugüne kadar inşa ettiği en büyük şeylerden bazılarına dönüştü. Çoğu ise öldü. Bu iki sonuç arasındaki fark yetenek değil, para da değil; çünkü ölenlerden bazılarında bizim sahip olabileceğimizden çok daha fazlası vardı. Farkı yaratan, neredeyse hiç kimsenin ilk denemede doğru veremediği az sayıdaki karar. Benim bulduklarım bunlar.

Mezarlık

Başarısızlıklarla başlayalım; çünkü onlar başarı hikâyelerinden daha dürüsttür. Kazananlar geçmişlerini derli toplu bir anlatıya dönüştürerek yeniden yazar. Kaybedenlerin şirket içi yazışmaları sızar.

Meta Horizon Worlds: şimdiye kadar inşa edilmiş en pahalı boş oda

Meta, metaverse iddiasına onlarca milyar dolar harcadı. Reality Labs, 2026'nın başlarında açıklanan tek bir çeyrekte $6,02 milyar faaliyet zararı bildirdi ve yıllardır her çeyrekte milyarlarca dolar kaybediyordu. Amiral gemisi Horizon Worlds'tü. İşte bu paranın karşılığında alınanlar.

Fortune ve Ryan Schultz tarafından haberleştirilen sızdırılmış bir şirket içi yazışma, içerik üreticilerinin oluşturduğu dünyaların yalnızca yaklaşık yüzde 9'unun 50 veya daha fazla kişi tarafından ziyaret edildiğini ortaya koydu. Ezici çoğunluğu, kendi üreticisi dışında hiç ziyaretçi almadı. Bir yazışma, etkileşim sorununu bu alandaki her kurucunun bedenine dövme yaptırması gereken bir cümleyle özetliyordu: "Boş bir dünya hüzünlü bir dünyadır." Aktif kullanıcılarla anket yapmak isteyen araştırmacılar yalnızca 514 kişi bulabildi; çünkü oyuncu kitlesi bu kadar küçüktü.

Kullanıcı tutma rakamları daha da kötüydü. Sızdırılan veriler, kullanıcıların yalnızca yaklaşık 10'da 1'inin geri döndüğünü gösteriyordu. Meta, 2022 için belirlediği aylık 500.000 kullanıcı hedefini sessizce 200.000'e indirdi; buna rağmen platformun eş zamanlı kullanıcı sayısı VRChat'ten ve hatta 2003 yapımı bir oyun olan Second Life'tan daha düşüktü. Şirket içi deneme panoları, Meta'nın kendi çalışanlarının bile platformu kullanmadığını gösteriyordu. Bunun üzerine yönetim, yöneticileri haftalık girişlerden sorumlu tutmaya başladı. Bir başkan yardımcısı ekibi yılın geri kalanı boyunca "kalite karantinasına" aldı ve ürün-pazar uyumunu bulamamış bir ürün üzerinde çalıştıklarını yazılı olarak kabul etti.

Meta, Mart 2026'da VR desteğini tamamen sonlandıracağını duyurdu ve Horizon Worlds'ü neredeyse yalnızca mobil bir uygulamaya, yani başlığı olmayan insanlar için kendi ifadeleriyle Roblox gibi işleyen bir giriş noktasına dönüştürdü. Şimdiye kadar inşa edilmiş en pahalı metaverse, hayatını ilk günden olması gereken şeye dönüşmeye çalışarak noktaladı.

Buradan çıkarılacak ders, öyle olsa bile, "VR için çok erkendi" değil. Ders şu: Hiçbir sermaye miktarı boş bir dünyayı dolduramaz. İçerik yoğunluğu, pazarlama bütçesiyle satın alabileceğiniz bir şey değildir. Dünyalar boşsa insanlar gider; insanlar gidince de dünyalar boş kalır. Bu döngü Meta'yı canlı canlı yedi.

Decentraland ve The Sandbox: milyar dolarlık hayalet kasabalar

Ekim 2022'de tek bir veri noktası kripto dünyasını ateşe verdi. DappRadar'ın bildirdiğine göre Decentraland'in günlük 38 aktif kullanıcısı vardı. The Sandbox'ın ise 522. O sırada bu projelerin her biri yaklaşık 1,3 milyar dolarlık piyasa değerine sahipti.

Projeler buna itiraz etti ve işin ayrıntısı aslında alay konusu olmalarından daha önemli. 38 rakamı, giriş yapıp blokzincirle hiç etkileşime girmeden dolaşanları değil, yalnızca bir gün içinde zincir üzerinde işlem yapan benzersiz cüzdanları, yani DappRadar'ın "ödeme yapanlar" dediği kişileri sayıyordu. Decentraland ise aylık 56.697 giriş yapan kullanıcısı olduğunu ve diğer tahminlere göre günlük kullanıcı sayısının yaklaşık 8.000'e ulaştığını açıkladı. The Sandbox, 14. gün kullanıcı tutma oranının yüzde 40 olduğu bir alfa sezonunda günlük 39.000 kullanıcıya sahip olduğunu öne sürdü.

Ancak bu fark üzerinde bir an durun; çünkü bu makaledeki en önemli rakam bu. En iyimser rakamları kabul etsek bile, en fazla birkaç bin günlük kullanıcının üzerinde duran milyar dolarlık değerlemelerle karşı karşıyayız. Karşılaştırmak gerekirse araştırma, blokzincir kullanmayan Roblox'un aynı dönemde günlük 52 milyon aktif kullanıcıya, ancak aylık yalnızca 11,3 milyon ödeme yapan kullanıcıya sahip olduğunu ortaya koydu. Ücretsiz sanal dünyalardaki çoğu insan nadiren işlem yapar veya hiç yapmaz. Bu iki yönlü bir durum. Günlük 38 aktif kullanıcı üzerinden yapılan alayın haksız olduğu anlamına geliyor; ama aynı zamanda milyar dolarlık değerlemenin de bir hayal olduğu anlamına geliyor. İkisi de yanlış şeyi ölçüyordu. Değerleme token spekülasyonunu ölçüyordu. Alay konusu olan rakam ise cüzdan işlemlerini. Hiçbiri insanların eğlenip eğlenmediğini ölçmüyordu.

Bu, gösteriş metrikleri tuzağının en saf hâlidir. Kayıtlı hesaplar, token piyasa değeri, toplam adreslenebilir pazar, basındaki görünürlük: Bunların hiçbiri size dünyanızın canlı olup olmadığını söylemez. Bunu gösteren yegâne rakamlar, kaç kişinin geri geldiği ve bir şeyler üreten insanların üretmeye devam edip etmediğidir.

Dreams: kimsenin içinde kalamadığı en güzel araç

LittleBigPlanet'ın arkasındaki stüdyo Media Molecule, yaklaşık on yılını o kadar kapsamlı bir üretim aracı olan Dreams'i geliştirmeye harcadı ki insanlar onun içinde oynanabilir oyunlar, animasyon kısa filmleri ve müzik albümleri yaptı. Eleştirmenler ona bayıldı. Stüdyo, Eylül 2023'te canlı hizmeti sonlandırdı ve sürdürülebilir bir iş modeli bulamadığını açıkça belirtti.

Bu başarısızlık değerlendirmesi, kendi kendine açılan yaralardan oluşan bir kontrol listesi ve bunu büyük bir saygıyla söylüyorum; çünkü biz de bunların her birini yapabiliriz. Dreams içerik üreticilerinin çalışmalarından para kazanmasına hiçbir zaman izin vermedi. Vadedilen oyun içi mağaza hiçbir zaman yayınlanmadı. Kozmetikler, savaş bileti, hiçbir şey yoktu. Bir aracı platforma dönüştürebilecek türden ciddi içerik üreticilerinin, karşılığında hiçbir kazanç ihtimali yokken yıllarını yatırmak için bir nedeni yoktu. Yalnızca PS4'te çıktı; PC sürümü ve çıkışta yerel PS5 sürümü yoktu. Bu da ulaşabileceği kitleyi ciddi biçimde sınırladı. Kurucu ortak Mark Healey daha sonra en büyük pişmanlığının çok oyunculu deneyime odaklanmamak olduğunu söyledi; ayrıca ekip, yarattıkları şeyin bir üretim aracından ziyade oyun olarak daha iyi işlediğini anladı.

Bu son kısmı tekrar okuyun. Dünyanın en yetenekli kullanıcı üretimli içerik stüdyosu, olup bittikten sonra, bu şeyin önce oyun, sonra araç olması gerektiği sonucuna vardı. Bu, çalışmanın tamamındaki en önemli cümle ve buna geri döneceğiz.

Mezarlığın geri kalanı

Aynı kalıp acımasız bir tutarlılıkla tekrarlanıyor.

Ortak çalışmaya dayalı bir kullanıcı üretimli içerik platformu olan Crayta, Mart 2023'te kapandı ve kullanıcılar ürettikleri her şeyi kaybetti. Geliştiricisi 2021'de Meta tarafından satın alınmıştı ama platform yine de kapatıldı. Doğrudan neden şuydu: Google Stadia'da çıkmıştı ve Stadia ölünce Crayta da onunla birlikte öldü. Platform bağımlılığı, kendi başınıza doğrulttuğunuz dolu bir silahtır.

Microsoft'un kullanıcı üretimli oyun geliştirme aracı Project Spark, yıllar önce aynı gidişatla kapandı: güçlü bir araç, ancak kalmaya devam eden yeterince insan yoktu. Linden Lab'in Second Life'ın VR halefi olarak geliştirdiği Sansar, kitle bulamayınca satıldı. Second Life'ın kurucusu Philip Rosedale'in ikinci metaverse şirketi High Fidelity ise sanal dünyalardan tamamen uzaklaşarak yön değiştirdi.

Şu anda gerçekleştiği için görmezden gelemeyeceğiniz başka bir işaret de Rec Room'un, hiçbir zaman kalıcı kârlılığa ulaşamadığını belirterek 1 Haziran 2026 itibarıyla kapanacağını duyurmasıdır.

Metaverse inşa eden metaverse şirketlerinin kurucuları kendi metaverse'lerinde bile kalamadı. Zor kısmın render almak olduğunu düşünen herkes bundan dehşete kapılmalı.

Hayatta kalanlar ve onları gerçekte neyin kurtardığı

Şimdi de hayatta kalanlar. Öğretici olan şu ki hiçbiri beklediğiniz şekilde kazanmadı; hatta birkaçı, başarısız olanların uyduğu kuralları çiğnemesine rağmen kazandı.

Roblox: on iki yılda gelen bir gecelik başarı

Herkes model olarak Roblox'u gösteriyor. Gerçekte yaşananları ise neredeyse hiç kimse kopyalamıyor, çünkü gerçekte yaşanan şey on iki yıl boyunca başarısız görünmekti.

Roblox'un 2006 betası, eşzamanlı oyuncu sayısı 30 ila 40 arasında zirve yaparken yaklaşık 100 teknoloji meraklısını çekti. Ardından on yılı aşkın süre boyunca ağır ağır ilerledi. 2016'nın başlarında 9 milyon olan kullanıcı sayısı, 2019'da 90 milyona, 2023'te ise 214 milyona ulaştı. Kurucu David Baszucki, Minecraft 2009'da hızla yükselip kendisini geride bıraktığında bile kullanıcı üretimi içerik vizyonundan sapmayı reddetti. Bunu bilinçli biçimde ağır ağır olgunlaşan bir süreç olarak gördü ve fark yaratan tek hamle, oyunları şirket içinde geliştirmek yerine topluluğun tüm oyunları geliştirmesine izin verme kararıydı. Bu, içerik maliyetini ortadan kaldırdı ve her içerik üreticisini bir büyüme motoruna dönüştürdü.

Ancak ezbere taklit edenlerin gözden kaçırdığı kısım şu; bu yüzden ikinci bir kaynağı hep açık tutuyorum. Matthew Ball'un 2024 tarihli ayrıntılı incelemesi, Roblox'un devasa ölçekte bile yaklaşık yüzde eksi 38 faaliyet marjıyla çok ağır zarar ettiğini, herhangi bir ayda kullanıcıların yalnızca yüzde 6'sının oyun içi para birimini satın aldığını ve kullanıcı başına gelirin konsol platformlarının çok altında kaldığını gösteriyor. Roblox dünyanın en büyük oyunu ama hâlâ para kazanmakta zorlanıyor. Çark gerçekten işliyor, fakat ekonomisi zorlu. Bir içerik üretici platformunun para basma ruhsatı olduğunu söyleyen herkes size bir şey satmaya çalışıyordur.

Yine de daha derin ders, bu kullanıcı sayılarında apaçık ortada duruyor. Roblox'un yüz milyonlarca kullanıcısının ezici çoğunluğu hiçbir şey geliştirmiyor. Başkalarının yaptığı on milyonlarca oyundan oluşan bir kataloğu oynamaya geliyorlar. Bu kataloğun büyümesi için on yıl ve geliştiricilere ödeme yapan bir ekonomi gerekti. Roblox, insanların tesadüfen oynadığı bir geliştirme aracı değil. İnsanların oynamaya geldiği ve küçük bir kısmının tesadüfen içerik geliştirdiği bir yer. Bu sıralama her şey demek.

Minecraft: boş kalması mümkün olmayan dünya

Minecraft hiçbir zaman boş dünya sorunu yaşamadı ve nedenini anlamak meselenin tamamını çözmek demek.

Minecraft, prosedürel üretime sahip bir hayatta kalma oyunu olarak çıktı. Dünya sonsuza dek kendi kendini kuruyor ve daha ilk dakikada ne yapacağınızı düşünerek boş bir tuvale bakmıyorsunuz. Gece çöküyor ve bir şey sizi öldürecek; bu yüzden kazmaya başlıyorsunuz. Oyun, sıfır başka kullanıcı ve sıfır kullanıcı üretimi içerikle tek bir kişi için sonsuza dek eğlenceli; çünkü prosedürel üretici tükenmez bir içerik makinesi. Modlar, sunucular, özel haritalar ve tüm yaratıcı ekosistem, zaten kendini sattırabilen bir oyunun üzerinde büyüdü. Yaratıcı mod, milyonlarca kişi hayatta kalma moduna çoktan bağlandıktan sonra geldi. Gerisini kulaktan kulağa yayılma ve YouTube halletti.

Minecraft, soğuk başlangıç sorununu hiç yaşamayarak çözdü. Hile kodu bu ve biz de onu ödünç alacağız.

Tarayıcı oyunları: rekabet üstünlüğünün tamamı olarak dağıtım

Bir de gerçek dağıtım mekanizmamıza en yakın tür var: indirme gerektirmeyen tarayıcı oyunları.

Agar.io, 2015'teki çıkışından sonraki birkaç hafta içinde günde yaklaşık 5 milyon oyuncuya ulaştı. Slither.io, 68 milyon mobil indirmeye ve tarayıcıda 67 milyon oynanmaya ulaştı. Araştırma bunun nedenini açıkça söylüyor: ".io türünün rekabet üstünlüğü oyun mekaniği değil, dağıtımın kendisidir." Bir bağlantıya tıklıyorsunuz ve oynamaya başlıyorsunuz. Kurulum yok, hesap yok, uygulama mağazası yok. Agar.io'ya başlamak için tek tıklama yeterliydi: bir ad yazın, oyna düğmesine basın ve içeridesiniz. TikTok'ta videoların yayıldığı gibi sohbet uygulamalarında yayıldı.

Fakat bu hediyenin içinde bizim tarafımızı da kesen bir bıçak var. İndirme olmaması, bağlılık da olmaması demek. Birini içeri sokan aynı pürüzsüzlük onu dışarı da çıkarıyor; çünkü bir sekmeyi kapatmanın hiçbir bedeli yok. Tarayıcıda viral yayılma gerçek, fakat varsayılan olarak yüzeysel. .io oyunları, ilk on saniyede anında ve açıkça eğlenceli olarak bunun üstesinden geldi. Ölen tarayıcı dünyalarına girmek zahmetsizdi ama vardığınızda kalmanız için hiçbir neden sunmuyorlardı.

Among Us, Figma, Townscaper, VRChat: kazanmanın dört yolu daha

Dört kısa örnek daha; çünkü her biri farklı bir kaldıracı ayrıştırıyor.

Among Us 2018'de çıktı ve iki yıl boyunca ticari açıdan hiçbir varlık gösteremedi. Geliştiriciler oyunu neredeyse terk ediyordu. Ardından Eylül 2020'de giderek daha büyük yayıncılardan oluşan bir zincir oyunu keşfetti; bu süreç saatler süren bir Sodapoppin yayınıyla zirveye ulaştı ve oyun küresel bir fenomene dönüştü. İlk can suyu, itch.io ana sayfasında öne çıkarılmaktan ve satışlarının yarısını oluşturan Koreli bir kitleden geldi. Ders: Yeterince uzun süre ayakta kalıp keşfedilebilirseniz büyük çıkış, lansmandan yıllar sonra ve hiç planlamadığınız bir kanaldan gelebilir.

Figma yaklaşık üç yıl gizli geliştirme sürecinde kaldı, ücretsiz olarak kullanıma sunuldu ve ücret almaya başlamadan önce iki yıl daha bekledi. Aktivasyon anı çok oyunculu kullanımdı: bir tasarımcının aynı dosyayı başka birinin de düzenlediğini hissettiği o an. Asıl önemli kısım da şu. Figma'nın ücretsiz katmanı başlangıçta sizi 2 ortak çalışanla sınırlıyordu; bu da ürünü sattıran o büyülü anı boğuyordu. İnsanların bu deneyimi gerçekten yaşayabilmesi için ortak çalışan sayısını sınırsız hâle getirerek sorunu çözdüler. Twitter'daki tasarım alanı kanaat önderlerini doğrudan hedefleyerek topluluğun ilk tohumlarını attılar. Ders: Aydınlanma anınızı bulun, ardından yeni kullanıcıyla o an arasındaki tüm engelleri kaldırın.

Townscaper, ekran görüntülerinin gücüyle başarıya ulaşan küçük bir yaratıcı oyuncaktı. Geliştiricisi, geliştirme sürecinde yalnızca kısa videolar paylaşarak Twitter takipçi sayısının yaklaşık 20.000'den 90.000'e yükseldiğini gördü ve bunu oyunun başarılı olacağına dair erken bir işaret olarak yorumladı. Ders: Ürününüz güzelse ve siz daha piyasaya bile sürmeden insanlar onu kendiliğinden paylaşıyorsa, bu alabileceğiniz en gerçek doğrulamadır.

Ayrıca Meta'nın milyarlarıyla Rec Room'un aynı aylarda çöktüğü dönemde VRChat, yaklaşık 160.000 eşzamanlı kullanıcıyla rekor kırdı. Topluluk odaklı, içerik üretici odaklı ve çevresinde ölen ürünler kadar güçlü bir finansmana uzaktan yakından sahip değil. VRChat, ayakta kalmasını sermayeden çok topluluk sadakatine ve yaratıcılığa borçlu olduğunu söylüyor. Hayatta kalanın kendi ağzından ders şu: bağlılık gösteren içerik üreticilerinin tutkusu paradan daha uzun ömürlüdür.

Hayatta kalanlarla ölenleri gerçekte ayıran şey

Hikâyeleri yan yana koyduğunuzda örüntü son derece açık.

Yaratıcı dünyaları öldüren şey boş odadır. Horizon Worlds, Decentraland, Dreams, Crayta, Project Spark ve Sansar'ın hepsi aynı şekilde öldü: yeterince insan yok, yeterince içerik yok, geri dönmek için yeterince neden yok; üstelik bunların hepsi birbirini besleyen bir döngünün içinde. Soğuk başlangıç sorunu asıl bölüm sonu canavarıdır. Geri kalan her şey eğitim bölümüdür.

Onları kurtaran şeyse kalabalık gelmeden önce var olmak için bir nedene sahip olmaktır. Minecraft'ın prosedürel hayatta kalma sistemi vardı. Roblox'un sabırla filizlendirilmiş on yıllık oyun birikimi vardı. .io oyunları ilk on saniyede eğlence sunuyordu. Hayatta kalanların her biri, katalogları boşken bile zaman ayırmaya değerdi. Kaybedenlerin her biri ise başkalarının ziyaret edilmeye değer hâle getirmesini bekleyen güzel birer kaptı. Bu, Dreams'in itirafının genelleştirilmiş hâli: önce bir oyun, sonra bir platform geliştirin. Platform ikinci perdedir. Onu, önce insanların sırf kendisi için kullandığı bir şey olarak hak edersiniz. Hayatta kalmayı gerçekten öngören metrikler, basın bülteninde yer alanlar değildir. Araştırmalar bu konuda tutarlı. Ürün-pazar uyumunun belirleyici işareti, elde tutma eğrinizin yataylaşmasıdır: bir kullanıcı kohortu sonsuza dek geri gelmeye devam eder. Huninin üst kısmı ne kadar büyük olursa olsun, sıfıra inen bir eğri uyum olmadığını gösterir. Sektördeki kabaca referans değerler 1. günde yüzde 40, 7. günde yüzde 20, 30. günde yüzde 10 elde tutmadır ve uzun vadeli sağlığı öngören değer 30. gündeki orandır. Üretici tarafı olan her şeyde ölüm noktası arz tarafıdır: başarısız pazar yerlerinin yaklaşık yüzde 67'si talep değil, arz yüzünden çöker. Üreticileri elde tutmak hayati göstergedir. Kayıtlı hesaplar ve değerlemeler ise gösteriş metrikleridir.

Bu hikâyelerden çıkarılabilecek birkaç ders daha var. Üreticilerinizin para kazanmasını sağlayın, yoksa onları kaybedersiniz; çünkü Dreams, yetenekli insanların hiçbir getirisi olmadan yıllarını harcamayacağını kanıtladı. Media Molecule'ün kendi pişmanlığının da gösterdiği gibi, çok oyunculu deneyim genellikle bir özellik değil, asıl meseledir. Crayta'nın gösterdiği üzere, evinizi sizi kapı dışarı edebilecek bir platformun üzerine asla kurmayın. İndirme gerektirmemek de iki ucu keskin bir kılıçtır: var olan en iyi kullanıcı edinme kanalı ve en zayıf bağlılık aracıdır; dolayısıyla ilk altmış saniyenin iyi olması konusundaki yükün tamamı size düşer.

Tüm bunların altında yatan tuzak

Bir katman daha var ve bu, tam da içinde bulunduğumuz ana özgü; çünkü artık yok olup gidenlerin hiç sahip olmadığı bir aracımız var. Yapay zekâyla dünyalar üretebiliyoruz. Bu da haftalardır zihnimde evirip çevirdiğim bir paradoks doğuruyor.

Eğer işin içinde yapay zekâ varsa her dünya benzersiz, her kişi için sıfırdan üretilmiş ve ona göre ayarlanmış olmamalı mı? Ama herkesin dünyası benzersizse, paylaşılan bir an paylaşılan bir mekân gerektirdiğine göre insanlar birbirleriyle nasıl karşılaşacak? Dünya zaten ortak olmak zorundaysa neden gerçek bir stüdyo gibi elle güzel bir mekân tasarlamak yerine yapay zekâ kullanalım?

Bu yaklaşımların her biri sonuna kadar götürüldüğünde işe yaramayan bir yere varıyor. Yalnızca sizin için üretilmiş bir dünya, içinde kimsenin olmadığı bir dünyadır. Google'ın Genie'si tek bir cümleden oynanabilir bir ortam oluşturabiliyor ve bu ortam bir dakika sonra yok oluyor: tek oyunculu, hafızasız, komşusuz. Bu, yalnızlığa çıkan çıkmaz sokak. Ancak tek bir sabit dünyayı elle tasarlamak da çıkmaz sokak: iki kilometrekareyi elle doldurmak yüz kişilik, yıllar süren bir iştir ve bittiğinde dünya donup kalır; yüzüncü ziyaretinizde de ilk ziyaretinizdeki gibidir ve insanlar geldikçe büyüyemez.

Çıkış yolu, "dünyayı" tek bir şey olarak görmekten vazgeçmek. Dünya üç katmandan oluşur ve benzersizlik ile ortaklık birbiriyle çatışmadan farklı katmanlarda yaşayabilir. Herkesin üzerinde durduğu zemin, yüksek bir kalite standardıyla seçilip düzenlenen tek bir ortak dünya, yani buluşma yeridir. Oraya getirdiğiniz şeyler—yapay zekâyla ürettiğiniz varlıklar, yaptığınız bina—son derece benzersizdir ve bunları ortak dünyanın içine bırakırsınız; böylece sizin benzersizliğiniz herkesin keşfine dönüşür. Dünyadaki rotanız, aldığınız görevler ve sizi yönlendirdiği şeyler ise kendiliğinden kişiselleşir; çünkü rota, mekân değildir. Yanlış ikilem, çok oyunculu deneyimi öldüren "kişiselleştirilmiş bir dünya" ile onu derinleştiren "ortak bir dünyada kişiselleştirilmiş bir rota" arasındaydı. Biz ikincisini istiyoruz.

Dolayısıyla yapay zekânın görevi hiçbir zaman herkese özel bir dünya vermek değildi. Görevi, tek bir ortak dünyayı sonsuz, canlı ve içinde ilerleyen kişiye özel hissettirmek. Benzersizlik, zaman içinde orada biriken her şeyden, her üreticinin türünün tek örneği katkısından doğar. Her Minecraft sunucusu benzersizdir. Belirli bir sunucudaki herkes onu paylaşır. Bu bir çelişki değildir. İşin bütün sırrı budur ve bu yazının en üstündeki ekran görüntüsü—yapay zekânın, başka insanların girebildiği bir dünyada yerinde kalacak bir ev inşa etmesi—bu sırrın gerçeğe dönüşmüş hâlidir.

Cinevva World'ü nasıl kullanıma açıyoruz?

Tüm bunların bizim açımızdan dönüştüğü şey şu. Bu bir pazarlama planı değil. Bu yazının ilk yarısında herkesi öldüren beş şeye karşı bilinçli olarak ortaya koyduğumuz beş iddia. Her birini, kanıtların onu ne ölçüde desteklediğine göre değerlendireceğim; çünkü değerlendiremeyeceğiniz bir plan, iyi ışıklandırılmış bir dilekten ibarettir.

Birinci iddia, şirketi üzerine koyabileceğim iddia: bir platform değil, oyun çıkarıyoruz. Bu bir tercih değil; araştırmanın tamamındaki en tutarlı bulgu. Minecraft, Roblox ve Fortnite önce yapması eğlenceli bir şey sundu, ardından üretici katmanını bunun üzerine kurdu. Hayattaki en yetenekli üretim stüdyosu Media Molecule bile daha sonra Dreams'in önce bir oyun olması gerektiği sonucuna vardı. Dolayısıyla yeni birinin Cinevva World'de yapacağı ilk şey boş bir arsaya bakmak olmayacak. Bir hedefi olan, neredeyse hiç kimsenin çevrimiçi olmadığı bir salı günü bile orada bulunmak için sebep sunan bir oyun döngüsüne girecek. Gelen insanların çoğu oynayacak ve hiçbir şey inşa etmeyecek; bu bir başarısızlık değil, tasarımın kendisi. Roblox'un gerçek yapısı da budur: üretim yapan ince bir katmanın üzerinde oynayan yüz milyonlar. Büyüme çarkı ikinci perdedir ve ona ulaşmayı hak etmemiz gerekir. Bu iddiadan eminim, çünkü mezarlık bu deneyi çoktan yaptı.

İkinci iddia, dürüst olmak gerekirse gerçek bir bahis: yapay zekâ, başkalarının beklerken yok olduğu arzı üretmemizi sağlıyor. Bunun neden bir garanti değil de bahis olduğunu net biçimde açıklamak istiyorum; çünkü bu araştırmadaki hiçbir platform üretken yapay zekâyla ilk ivmesini kazanmadı. Elimde kanıt değil, bir mekanizma var. Mekanizma şu: iki taraflı platformların yaklaşık üçte ikisi talep değil, arz tarafında ölür. Klasik çözüm, DoorDash'in yemekleri bizzat taşıması, Reddit ekibinin sahte kullanıcı adlarıyla paylaşım yapması ve Roblox kurucularının ilk oyunları yıllarca kendi elleriyle geliştirmesi gibi, gerçek arz oluşana kadar arzı taklit etmektir. Biz bunu, hiçbirinin sahip olmadığı bir maliyet ve hız avantajıyla üretim yoluyla yapabiliriz. Fakat beni dürüst tutan kısım—Decentraland'ın mezar taşı—şu: Decentraland üretilmiş şeylerle doluydu ama günde yaklaşık otuz kişi çekiyordu; çünkü güzel olmak, harcadığınız zamana değmekle aynı şey değildir. Bu yüzden yapay zekânın dünyayı eğlenceli hâle getireceğine bahse girmiyorum. Bunu yapamaz. Ben, yapay zekânın varlık üretimindeki darboğazı kaldıracağına ve böylece kıt insan emeğimizin her saatini insanları gerçekten elde tutan tek şeye, yani oyun döngüsüne ayırabileceğimize bahse giriyorum. Yapay zekâ tepeyi ucuza inşa eder. Biz o tepeye tırmanma sebebini elle inşa ederiz. Ayrıca sentetik başlangıç arzını yaklaşık yüzde 30'la sınırlandırıp yaklaşık 60 gün içinde gerçek üretici içeriğine dönüştüreceğiz; çünkü hiçbir zaman gerçeğe dönüşmeyen sahte arz, biri bunu fark ettiği anda güveni yok eder.

Üçüncü iddia: kendi sonlandırma kriterlerimizi yayımlıyoruz. Gerçekçi bir planla umut dolu bir plan arasındaki fark budur. Her vakada hayatta kalmayı öngören metrik, elde tutma eğrisinin yataylaşıp yataylaşmadığı, yani bir kohortun sıfıra doğru azalmak yerine geri gelmeye devam edip etmediğiydi. Bu yüzden kendimizi açıkça bu testle değerlendireceğiz. Alfa sürümünde 7. gün elde tutma oranı yataylaşmazsa, hiçbir şey inşa etmeyen oyuncular geri dönmezse, yapay zekâyla başlangıçta eklenen içerik yanından geçilip görmezden gelinirse tez yanlıştır; onu değiştirir ya da dururuz. Oyuncular ile üreticileri, iki ayrı aydınlanma anına sahip iki ayrı huni olarak takip edeceğiz; çünkü veriler bunların aynı kişi olmadığını açıkça gösteriyor. Ayrıca paranın ilk aşamadaki işi yapıyormuş gibi davranmayacağız. Elli, hatta bin kullanıcı varken bahşişler ve pazar yeri kazançları sıfıra yuvarlanır; dolayısıyla henüz kimseyi elde tutamazlar. İlk dönem elde tutma oyun döngüsünden gelir ya da hiç gelmez. Bunun tersini yapmanın faturası Dreams'tir.

Dördüncü iddia: bilinçli olarak dar bir alanda başlıyoruz. Ağ tabanlı ürünlerle ilgili araştırmalar bu konuda hemfikir. Bir pazara değil, kendi başına canlı kalabilecek yoğunluktaki en küçük gruba, yani bir "atomik ağa" açılırsınız. Facebook tek bir okulda başladı. Bizimki zaten var: 3D varlıklar, müzik ve ses üretmiş, yerleştirmeye hazır içerik stoğuna sahip Cinevva üreticileri. Aynı saatte, bir hedef ve keşfedilecek bir sınırla tek bir dünyada bulunan elli kişi, dağınık hâlde duran elli bin kayıttan çok daha yoğun ve canlıdır. Kanıtlar bu iddiayı güçlü biçimde destekliyor.

Beşinci iddia, en zayıfı ve bunu açıkça söylüyorum: boşluğu saklamak yerine onun hakkında gerçeği anlatıyoruz. Cilalı ama sessiz bir dünya ölü görünür ve başarısız olanların hepsi bunu ortam efektleriyle örtmeye çalıştı. Biz tersini deneyeceğiz. Bu, beş hamle içinde en az kanıtlanmış olanı; bir bulgudan çok sezgiye yakın. İlk gelenler bitmemiş bir ürünü ziyaret etmiyor. Burası, onlar erken geldiği için boş olan bir yer ve onlar da bu yerin kurucu sakinleri; inşa ettikleri şeyler sonraki bin kişi geldiğinde hâlâ ayakta olacak.

Dürüstçe değerlendirilmiş plan budur. Mezarlığın güçlü biçimde desteklediği dört iddia ve ölülerin hiçbirinde bulunmayan bir araç üzerine gerçek bir bahis; üstelik onların yoksun olduğu disiplinin ta kendisiyle sınırlandırılmış durumda. Tepeyi üretebiliriz. Tepeye ilk çıkan olma hissini ya da zirveden el sallayan yabancıyı üretemeyiz. Görevimiz bu el sallamayı mümkün kılmak, bunu elde tutma eğrisinde kanıtlamak ve eğri hayır dediği anda kendimizi kandırmayı bırakmaktır.

Oleg Sidorkin, Cinevva CTO'su ve Kurucu Ortağı

Burada yeni misiniz? Seri rehberini kullanın. Rehber, prototip denemesinin ne olduğunu açıklıyor ve tüm bölümlere bağlantı veriyor.

Bölüm 29, herhangi bir gövdeyi yönetebilen tek bir denetleyici sunmuştu. Artık gövde doğru hareket ediyor. Yürüyor, kayıyor, yüzüyor, süzülüyor, mağaralara tırmanıyor ve çıkıntıların altından eğilerek geçiyor. Sorun, onu neyin izlediği. Yirmi dokuz bölüm boyunca kamera, oyuncuyu takip eden standart bir yörünge düzeneğiydi ve utanç verici durumlardan kaçınmak için yalnızca tek bir akıllıca şey yapıyordu: düz zeminin altına kayamasın diye ufkun altına eğilmeyi reddediyordu. Bu sınırlama, asıl sorunu ele veriyor. Kamera, dünya geometrisinin gerçekte nerede olduğunu bilmiyordu; bu yüzden içinden geçmeye karşı tek savunma, bunun en olası olduğu açıları yasaklamaktı. Bir tepeye yaklaştığınızda kamera tepenin içinde kalıyordu. Bölüm 7'deki marching cubes mağaralarından birine girdiğinizde bir kayanın iç yüzeyine bakıyordunuz. Bölüm 16'daki üretim araçlarıyla bir ev inşa edip odanın içinde durduğunuzda kamera duvarın dışında süzülerek dış cephe kaplamasına bakıyordu. Bu bölüm, kameranın da gövdenin zaten gösterdiği geometri hassasiyetine sahip olmasını sağlıyor.

Sorunun biçimi ve çözümün biçimi

Üçüncü şahıs kamerasının bir zor, bir düzine de kolay görevi vardır. Kolay olanlar takip, yumuşatma ve yörünge girdisidir; bunlara zaten sahiptik. Zor olanı ise akademik literatürün görünürlük kısıtı dediği şeydir. Herkesin atıfta bulunduğu Christie ve Olivier imzalı Camera Control in Computer Graphics araştırması, tüm alanı bunun etrafında çerçeveler: dünyaya saygı gösterirken özneyi kadrajda ve engelsiz tutmak. Çalışma zamanında bu, her karede sorulan ve aldatıcı derecede basit görünen bir soruya indirgenir. Oyuncu dönme noktasıdır. Kullanıcı, kamerayı döndürmüş ve yakınlaştırarak oyuncunun arkasında belirli bir mesafede istenen kamera konumuna getirmiştir. Kamera, katı bir şeye saplanmadan önce bu çizgi boyunca gerçekte ne kadar geride durabilir? Bu soruyu dürüstçe yanıtladığınızda kamera tepenin önüne çekilir, bir köşeye doğru geri giderken bom boyunca içeri kayar ve mağara tavanını delip geçmek yerine orada durur.

Bunu çözen kalıp eski ve kendini kanıtlamıştır. Unreal buna yay kolu der, Godot bir SpringArm3D düğümü sunar, Unity'nin Cinemachine'i ise bunu üçüncü şahıs takip düzeneği ile engel giderici bir uzantı arasında paylaştırır. Fikir her zaman aynıdır. Kamerayı, dönme noktasına sabitlenmiş bir bomun ucuna asın. Yol açıkken istenen uzunlukta tutun, araya bir şey girdiğinde dönme noktasına doğru geri çekin ve yol yeniden açıldığında yay etkisiyle tekrar dışarı uzatın. Metroid Prime'ın kamera lideri tarafından yazılan Mark Haigh-Hutchinson'ın Real-Time Cameras kitabı, bunun basit bir sürümünü oyuncıların midesini bulandıran bir şeye dönüştüren hata biçimlerine bölümler ayırır. Bu kalıbı alıp tek oturuşta okunabilecek kadar küçük olan kendi sürümümüzü public/world/src/camera-rig.mjs içinde oluşturduk.

Yalnızca kendi uzunlığını yöneten bir bom

Düzeneği küçük tutan tasarım kuralını Bölüm 29'daki denetleyici çalışmasından ödünç aldık: tek bir şeyi tamamen yönet ve geri kalanını reddet. Düzenek, bomun uzunluğunu ve yalnızca bunu yönetiyor. Yatay dönüş, dikey dönüş, yörünge sönümlemesi, dokunma ve tekerlek hareketleri; bunların tamamı, zaten iyi çözümler sunan ve yeniden yazmak istemediğimiz OrbitControls'da kalıyor. Dolayısıyla bu düzenek bir kamera denetleyicisi değil. Yörünge hesaplamalarından sonra çalışan ve tam olarak tek bir sayıyı, dönme noktası ile kamera arasındaki mesafeyi düzelten bir son işlem.

Bu karar düzenli görünüyor ve OrbitControls'un düşünme biçimi nedeniyle daha en başta neredeyse her şeyi bozuyordu. Her güncellemenin başında kameranın mevcut konumunu okur ve yörünge yarıçapını bundan türetir. Bu normalde görünmezdir. Ancak düzeneğimiz bir duvardan kaçınmak için kamerayı kısalttığı anda, sonraki karede OrbitControls bu kısaltılmış konumu okur, kullanıcının yakınlaştırmış olması gerektiği sonucuna varır ve kısaltmayı kullanıcının istediği yakınlaştırmaya işler. Birkaç kare sonra kamera oyuncunun başına çöker ve bir daha dışarı çıkmaz. Çözüm, yörünge güncellemesini çevreleyen iki çağrıdan ibaret ve tüm entegrasyon da bu. OrbitControls çalışmadan önce beforeControls(), kamerayı önceki karenin tam, kısaltılmamış mesafesine geri getirir; böylece yörünge hesaplaması her zaman kullanıcının gerçek yakınlaştırma değerini okur. OrbitControls çalıştıktan sonra afterControls(dt), yörüngesi yeni hesaplanmış bu istenen konumu okur, çarpışmayı çözer, uzunluğu sönümler ve kamerayı gerçekten görüntü oluşturması gereken yere yazar. Kullanıcının niyeti ile çarpışma düzeltmesi hiçbir zaman birbirine karışmaz ve ileri-geri hareket, düzenek kurulmadan önceki kadar duyarlı kalır. Düzenek için yazdığımız başsız test tam olarak bunu sabitler: bomu altmış kare boyunca bir duvara doğru sürün, duvarı kaldırın; uzunluk çarpışma mesafesinde takılı kalmak yerine yay etkisiyle kullanıcının on metrelik tam yakınlaştırmasına geri döner.

Tek sözleşme, her tür çarpıştırıcı

Düzenek, dünyanın neyden yapıldığını asla sormaz. Çarpıştırıcı, yalnızca probe metoduna sahip bir nesnedir. Düzenek ona bir ışın, azami mesafe ve kameranın prob yarıçapını verir; karşılığında kamera o çarpıştırıcı tarafından engellenmeden önce gidebileceği en uzak mesafeyi belirten tek bir sayı alır. Düzenek kayıtlı tüm çarpıştırıcıları sorgular ve en yakın çarpmayı seçer. Sözleşmenin tamamı bundan ibaret ve karakter denetleyicisinin hareket sistemini takılabilir davranışlara dönüştürürken yaptığı hamlenin aynısı. Arazi, nesneler ve bina kabukları aynı probe arayüzünün arkasından sisteme bağlanır; düzenek ise bunların hiçbirinden haberdar olmaz. Yeni bir engel türü eklemek, kamerayı düzenlemek değil, bir listeye çarpıştırıcı eklemektir.

Sözleşmedeki bir ayrıntı sağladığı faydayı fazlasıyla karşılıyor: prob yarıçapı. Dönme noktasından kameraya ince bir ışın göndermiyoruz; kameranın yakın düzlemini içine alacak kadar büyük bir küre gönderiyoruz. Tek bir ışın kamera merkezini duvarda durdurur, ancak yakın düzlemin bir genişliği vardır; dolayısıyla merkez ışını bir çarpma bildirmeden önce düzlemin köşeleri çoktan duvara gömülmüş olur. Işın yerine küçük bir küre süpürmek, yayımlanmış her uygulamanın yaptığı şeydir. Unreal bunu prob boyutu olarak sunar ve ekranın kenarlarından duvarın arkasını gösteren bir kamera ile yüzeye temizce dayanan bir kamera arasındaki farkı yaratır.

Bu yarıçapı tahmin etmiyor, hesaplıyoruz. Yakın düzlemin kameradan en uzak noktası köşelerinden biridir ve bu noktaya olan mesafe doğrudan projeksiyondan çıkar. Yakın düzlem $n$ ve dikey görüş alanı $\theta$ olduğunda yarı yükseklik $h=n\tan (\theta /2)$, yarı genişlik $w=h\cdot \text{en-boy oranı}$ olur ve köşe şu mesafede bulunur:

Prob yarıçapı, bu köşe mesafesinin küçük bir güvenlik payıyla çarpılmasıyla elde edilir. Ayrıca çok dar bir görüş hacminde makul bir asgari değerin altına asla düşmemesi için sabit bir alt sınır kullanılır. Görüş alanı, en-boy oranı veya yakın düzlem her değiştiğinde yarıçap yeniden hesaplanır; böylece pencerenin yeniden boyutlandırılması ya da projeksiyonu etkileyen bir yakınlaştırma, probu koruması gereken köşeleri kapsayamayacak kadar küçük bırakamaz.

Mağaralardan haberdar olan çarpıştırıcı

Arazi çarpıştırıcısında işler ilginçleşiyor, çünkü motorumuzdaki arazi bir yükseklik haritası değil. Bölüm 7'den beri bir işaretli mesafe alanı kullanıyoruz: uzaydaki herhangi bir noktanın en yakın katı yüzeye ne kadar uzak olduğunu ve kayanın içinde mi dışında mı bulunduğunu döndüren bir fonksiyon. Pozitif hava, negatif kaya anlamına geliyor. İşte bu tek gerçek, kameramızın bir yükseklik haritası kamerasının yapısal olarak yapamayacağı bir şeyi yapabilmesini sağlıyor. Yükseklik haritası, belirli bir x ve z konumundaki zemin yüksekliğini bilir. Tavan diye bir kavramı yoktur, çünkü herhangi bir noktanın üzerinde her zaman yalnızca tek bir yüzey bulunur. Bu nedenle bir yükseklik haritası kamerası bir tepenin içine girmenizi engelleyebilir, ancak dönme noktasının üzerinde asılı duran bir çıkıntı kenarı ya da mağara tavanı hakkında hiçbir fikri yoktur ve her ikisinin de içinden geçer. Mesafe alanı, üç boyuttaki her yüzeyden haberdardır; dolayısıyla kamerayı yamaca çarpınca durduran aynı prob, tek bir özel durum gerektirmeden mağara tavanında da durdurur.

Probu alan boyunca ilerletmenin bir adı ve arkasında bir makalesi var. John Hart'ın 1996 tarihli Sphere Tracing çalışması, bir ışını mesafe alanı üzerinde ilerletmenin standart yöntemidir. İşin püf noktası, alanın size yalnızca bir şeye çarpıp çarpmadığınızı söylememesi, aynı zamanda hiçbir şeye çarpmadan ilerleyebileceğiniz güvenli mesafeyi de bildirmesidir. Böylece küçük, sabit adımlarla sürünmek yerine alanı örnekler, bildirdiği boşluk kadar ileri gider ve bunu tekrarlarsınız; açık havada uzun adımlar, bir yüzeye yaklaşırken ise kısa ve dikkatli adımlar atarsınız. Yine de arazimizin bizi zorladığı bir nokta var. Gerçek bir mesafe alanı, en yakın yüzeye olan gerçek Öklid mesafesini bildirir ve bu boşluk kadar tam bir adım atmak her zaman güvenlidir. Ancak arazinin oyulmuş vokseller yerine hâlâ bir yükseklik haritası olduğu yerlerde, düşük maliyetle örnekleyebildiğimiz alan gerçek mesafe değil, dikey açıklıktır; yani zemine dümdüz aşağı yöndeki boşluktur. Eğimli bir yüzeyde bu değer, kameranın gerçekte ne kadar hareket edebileceğini olduğundan fazla gösterir; çünkü en yakın kaya doğrudan aşağıda değil, yandadır. Gerçek mesafe, gradyanla birlikte büyüyen $\sqrt{1+\Vert \mathrm{\nabla }h{\Vert }^2}$ çarpanı kadar daha küçüktür; dolayısıyla bildirilen boşluğa göre ayarlanan bir adım hedefi aşabilir ve bir sırtın temizce üzerinden atlayabilir. Çözüm, eksik gevşetmedir: bildirilen boşluğun tamamı yerine yalnızca bir bölümü kadar ilerlemek. Bu, yaklaşık altmış derecelik eğimlere kadar güvenli kalır ve gerçek mesafeli voksel bölgelerinde birkaç ek örnek dışında hiçbir maliyet oluşturmaz. Bunu bir minimum adım uzunluğuyla eşleştiriyoruz; böylece bir ya da iki hücre kalınlığındaki mağara duvarı tek adımda aşılmaz. Daha sıkı bir üst sınır da yürüyüşü düşük maliyetli tutar. Küre sonunda yüzeye değdiğinde kısa bir ikili arama temas noktasını hassaslaştırır; ardından kamera kendi yarıçapı kadar geri çekilip orada durur.

Matematiksel olarak bom, pivot $\mathbf{p}$ noktasından birim yön $\mathbf{d}$ boyunca uzanan $\mathbf{r}(t)=\mathbf{p}+t\mathbf{d}$ ışınıdır ve yürüyüş, alanın temasa kadar bildirdiği boşluğun eksik gevşetilmiş bir bölümüyle, iki uçtan da sınırlandırılarak ilerler:

Burada $\mathrm{\Phi }$, havada pozitif ve kayada negatif olan işaretli mesafedir; $r$ prob yarıçapıdır; $\lambda \in (0,1]$, yükseklik haritası alanının mesafeyi fazla bildirmesi nedeniyle yürüyüşün bir eğimin üzerinden atlamasını önleyen eksik gevşetme katsayısıdır; $s_{min},s_{max}$ ise ince bir duvarın atlanmasını ve yürüyüşün gereğinden uzun sürmesini önleyen adım sınırlarıdır. Temas, $\mathrm{\Phi }(\mathbf{r}(t))\le r$ koşulunu sağlayan ilk $t$ değeridir; yani kürenin yüzeyi kayaya ulaşmıştır. Kamera da bu yay uzunluğundan kendi yarıçapı çıkarılmış konumda tutulur.

Çarpışma sistemi güvenlik ağı olarak bir yöntem daha taşır: iç içe geçmeyi giderme. Çarpışma, kamerayı baştan katıların dışında tutmalıdır; ancak birkaç durum bunu aşabilir: bomun içinden başlayacağı kadar ince bir duvarın iki yanında kalan bir pivot, kamera kayanın içindeyken arazi araçlarıyla yeni oyulmuş bir mağara ya da kameranın çevresine bırakılmış bir yapı parçası. Bu durumlarda çarpışma sistemi, kameranın kareyi katının içinde, yani $\mathrm{\Phi }(\mathbf{c})<r$ olduğu yerde bitirip bitirmediğini denetler. Öyleyse alanın gradyanını okur; $\mathrm{\Phi }$ kayadan uzaklaştıkça büyüdüğü için bu gradyan doğrudan açık havaya işaret eder. Ardından kamerayı bu doğrultuda dışarı çıkarır:

Bu işlemin birkaç yinelemesi $r$-eş yüzeyine yakınsar. Böylece bir şekillendirme aracı kameranın altındaki zemini oyduğunda görüntü kararmak yerine bir sonraki karede toparlanır.

İçeri sıçramak, dışarı yumuşakça açılmak ve çit direklerinde irkilmemek

Her karede doğrudan çarpışma mesafesine sıçrayan bir bom, hiç bom olmamasından daha kötüdür. Çünkü dünya, kameranın yalnızca tek kareliğine arkasından geçtiği ince nesnelerle doludur: bir çit direği, bir lamba, bir ağaç gövdesi. Her birinden kaçmak için ileri atılıp ardından geri sıçrayan bir kamera mide bulandırır. Haigh-Hutchinson'ın kitabı ile Itay Keren'in çok sevilen kamera hareketi konuşması aynı sezgide buluşur: kamera, tehdit ve tehlikelere onlardan uzaklaşırken gevşediğinden daha hızlı tepki vermelidir. Bu yüzden sönümleme bilinçli olarak asimetriktir. Bir engelleyici belirdiğinde ve bomun kısalması gerektiğinde kamera neredeyse anında içeri sıçrar; çünkü tek karelik kırpılma çirkindir ve oyuncu hızlı bir geri çekilmeyi tolere eder. Engel kalkıp bom uzamak istediğindeyse kamera yavaşça dışarı açılır ve bunu ancak kesintisiz açıklığın kısa bir bekleme süresi boyunca korunmasından sonra yapar. İrkilme hareketini ortadan kaldıran histerezis işte bu beklemedir. Kamerayı ince bir direğin yanından hızla çevirirseniz direk, yavaş uzamayı tetikleyecek kadar uzun süre görüşten çıkmaz; böylece kamera sanki direk orada değilmiş gibi yumuşakça yanından geçer. Gözün istediği tam olarak budur. Cinemachine de aynı fikri, çarpışmaya girerken ve çarpışmadan çıkarken kullanılan ayrı sönümleme değerleri olarak sunar. Sistemi bir yaydan çok kamera operatörü gibi hissettiren kısım bu asimetridir.

Kodda bu, değişimin işaretine göre hızı değiştiren tek satırlık üstel yumuşatmadır. $\ell$ mevcut bom uzunluğu, $a$ çarpışmanın bu karede izin verdiği uzunluk ve $\mathrm{\Delta }t$ kare süresi ise

olur ve dışarı yumuşakça açılma dalı yalnızca açıklık $\tau$ bekleme süresi boyunca korunduktan sonra çalışır. $1-e^{-k\mathrm{\Delta }t}$ biçimi yalnızca düzenli göründüğü için önemli değildir. Tepki zaman sabitini kare hızından bağımsız olarak $1/k$ değerine sabitler; böylece kamera saniyede 30 ve 144 karede aynı hissi verir. Oysa basit sabit karışım $\ell \leftarrow \ell +\alpha (a-\ell )$ hızlı bir makinede daha çabuk sıçrar, yavaş bir makinede ise hantallaşırdı.

Son davranış, bu bölümün çıkış noktası olan dar iç mekânlar içindir. Bom, kamera oyuncunun hemen üzerine gelecek kadar kısaldığında oyuncunun kendi avatarını gizler ve görüntüyü birinci şahıs görünümüne yakın bir konuma taşırız. Breath of the Wild dar bir tapınakta bunu yapar ve üçüncü şahıs oyunlarının çoğu köşelerde bu çözüme başvurur; çünkü alternatifi, duvara sıkışıp bir kafanın arkasına bakan kullanışsız bir kameradır. Kamera düzeneği bunun için tek bir bayrak sunar; dünya döngüsü de bu bayrağı okuyup yerel avatarın görünürlüğünü açıp kapatır. Bom uzunluğu bir metrenin altına düştüğünde fiilen birinci şahıs görünümündesinizdir, duvarlara saygı gösterilir ve yeterli alan bulunan bir odaya geri adım attığınız anda avatar yeniden belirir, bom da uzar.

Sırada ne bağlanacak?

Arazi çarpışma sistemi bugün kullanıma giriyor ve işin zor yarısı da bu; çünkü arazi her yerde, mesafe alanı ise sorgulaması zahmetli olan kısım. İçerik üretimi denemelerindeki dekor nesneleri ve yapı kabukları kolay yarıdır; sözleşme de şimdiden onları bekliyor. İkinci bir çarpışma sistemi olan ışın izleme çarpışma sistemi, pivottan kameraya doğru bir ağ listesi üzerinde ışın gönderir ve en yakın çarpmayı arazi çarpışma sistemiyle aynı biçimde bildirir. Ucuz sürüm tek bir ışın gönderir; dekor nesnesi sayısı artana kadar bu yeterlidir. Sonraki geliştirme, bu ışını Garrett Johnson'ın bir ağı sınırlayıcı hacim hiyerarşisiyle sarmalayan ve böylece uzamsal sorguların kaba kuvvet yerine logaritmik zamanda çalışmasını sağlayan three-mesh-bvh kütüphanesini kullanarak süpürülen bir küreyle değiştirmektir. Her iki durumda da kamera düzeneği değişmez. Daha uzun bir çarpışma sistemi listesini sorgular ve en yakın çarpmayı seçer. Önce sözleşmeyi, sonra çarpışma sistemlerini inşa etmemizin bütün amacı budur.

Bu bölümde başvurulan teknolojiler

Tek bir değere sahip olan bom. Kamera düzeneği, OrbitControls'ün yerine geçen bir sistem değil, onun üzerinde çalışan bir son işlemdir. Bomun uzunluğunu yönetir; sapma, eğim, yakınlaştırma ve hareket girdilerini ise zaten güvendiğimiz yörünge denetleyicisine bırakır. Entegrasyon, iki kuşatıcı çağrıdan oluşur: beforeControls(), önceki karenin tam mesafesini geri yükler; böylece yörünge hesabı, çarpışma nedeniyle oluşan kısalmayı yakınlaşma sanmak yerine kullanıcının gerçek yakınlaştırma değerini okur. afterControls(dt) ise çarpışmayı çözümler ve ekranda gösterilecek konumu yazar. Bu ikili olmadan kamera birkaç kare içinde oyuncunun üzerine çöker.

Takılıp çıkarılabilir bir çarpışma sistemi sözleşmesi. Çarpışma sistemi, “sen engellemeden önce kamera pivottan bu ışın boyunca ne kadar ilerleyebilir?” sorusunu yanıtlayan bir probe içeren herhangi bir nesnedir. Kamera düzeneği her çarpışma sistemini sorgular ve engelin arazi, dekor nesnesi ya da duvar olmasına aldırmadan en yakın çarpmayı seçer. Bu, hareket için takılıp çıkarılabilir karakter denetleyicisinin kullandığı, tek bir şeyi yönetme disiplininin aynısıdır. Prob ince bir ışın değil, yakın düzlemi kapsayacak boyuttaki süpürülen bir küredir; böylece görüş hacminin köşeleri, merkez ışının gözden kaçıracağı bir yüzeyi asla kırpmaz. Yarıçapı projeksiyondan türetilir: yakın düzlemin bir köşesine olan $\sqrt{n^2+w^2+h^2}$ mesafesi bir güvenlik payıyla çarpılır ve görüş alanı, en-boy oranı ya da yakın düzlem her değiştiğinde yeniden hesaplanır.

Çıkıntılara ve mağaralara uyan işaretli mesafe arazi probu. Arazi bir yükseklik haritası değil, işaretli mesafe alanı olduğundan, kamerayı yamaçta durduran prob mağara tavanında da durdurur; yükseklik haritası ışın testinin yapısal olarak göremeyeceği durum budur. Yürüyüş, Hart tarzı küre izlemeyle yapılır: alanın bildirdiği boşluğun eksik gevşetilmiş bir bölümü kadar ilerler ve iki uçtan da sınırlandırılır. Bunun nedeni, yükseklik haritası bölgelerinin gerçek mesafe yerine dikey açıklığı bildirmesi ve kameranın bir eğimde ne kadar hareket edebileceğini olduğundan fazla göstermesidir; tam bir adım bir sırtın üzerinden atlardı. Gradyan güdümlü iç içe geçme giderme geçişi ise kameranın altındaki zemin şekillendirildiğinde görüntüyü toparlayan güvenlik ağıdır.

Bekleme zamanlayıcılı asimetrik sönümleme. Bir engelleyici belirdiğinde bom hızla içeri sıçrar, engel kalktığında ise yalnızca kısa bir kesintisiz açıklık süresinden sonra yavaşça dışarı açılır. Böylece bir çit direğinin yanından hızla geçmek kameranın ileri atılmasına yol açmaz. Bom belirli bir çökme eşiğinin altına indiğinde düzenek birinci şahıs görünümüne yakın olunduğunu işaretler ve dünya döngüsü yerel avatarı gizler. Bu, dar iç mekânlarda duvara gömülmüş bir kamera yerine kullanılan standart geri dönüş çözümüdür.

Kaynaklar

Kamera denetiminin bir görünürlük kısıtı olarak çerçevelenmesi Marc Christie ve Patrick Olivier'nin Bilgisayar Grafiklerinde Kamera Denetimi çalışmasından gelir (Computer Graphics Forum, 2008). Mesafe alanı yürüyüşü John C. Hart'ın Küre İzleme: Örtük Yüzeylerin Kenar Yumuşatmalı Işın İzlemesi İçin Geometrik Bir Yöntem çalışmasına dayanır (The Visual Computer, 1996). Yaylı kol örüntüsü ve prob küresi çarpışması Epic'in Yaylı Kol Bileşeni ile Unity'nin Cinemachine Engel Gidericisi ve Üçüncü Şahıs Takibi belgelerinde açıklanır. Hareket ve sönümleme sezgisi Mark Haigh-Hutchinson'ın Gerçek Zamanlı Kameralar kitabından (Morgan Kaufmann, 2009) ve Itay Keren'in Geri Kaydırma: Yandan Kaydırmalı Oyunlarda Kameraların Kuramı ve Uygulaması konuşmasından gelir (GDC 2015). Ağ çarpışma sisteminin geliştirme yolu Garrett Johnson'ın three-mesh-bvh kütüphanesidir.

30 bölümün 30. bölümü. Önceki: Bölüm 29 - Tek denetleyici, her gövde Seri rehberi: /tr/blog/2026-02-25-open-world-browser-series-guide

Cinevva CTO'su ve Kurucu Ortağı Oleg Sidorkin tarafından

28. Bölüm, Spike 57'yi tanıttı ve dört ayıklama yolunun kıyaslamasını birkaç paragrafta sundu. Bu, uzun versiyonu: neden bu dört yöntemi seçtiğimiz, diğer dört yöntemin ne olduğu ve yayınlayacağımız yöntemin arkasındaki gerekçeler.

Kamera ile bir çayır arasında bir tepe var. Çayırı render etmeniz gerekmez. Her modern AAA motoru bunu bilir. Geçen haftaya kadar bizimki de dahil olmak üzere çoğu tarayıcı tabanlı 3D motor bunu bilmez.

Bu yazı; araştırmayı gerektiği gibi yapmanın, onu gerçek kod tabanımıza dayandırmanın, çalışan bir spike geliştirmenin ve teknikleri bugün WebGL, yarın WebGPU ile yayın yaptığımızı göz önünde bulundurarak özellikle bize ne kadar yardımcı olduklarına göre değerlendirmenin sonucu.

Okumaya devam etmeden önce aşağıdaki canlı spike'ı kurcalayabilirsiniz. T/Y/U/I ayıklama yolları arasında geçiş yapar, C kamera ön ayarları arasında dolaşır, B ise testin neleri çıkardığını görebilmeniz için gizlenen chunk'ları kırmızı tel kafes olarak boyar. HUD, her aşamanın kaç instance'ı elediğini gösterir.

Spike 57'yi yeni sekmede aç ↗ · Kaynak kodunu görüntüle

Motorumuz bugün ne yapıyor (ve ne yapmıyor)

Akış tabanlı chunk yöneticimiz, oyuncunun çevresinde üç LOD kademesinde 64 metrelik chunk'lardan oluşan bir halka yükler. Her chunk, yükseklik haritasına dağıtılmış instanced ağaçlara sahiptir. Chunk.updateObjectVisibility içinde bulunan ayıklama mantığı basit bir mesafe kontrolüdür: 60 metre içindeki ağaçlar tam mesh olarak, 60 ile 140 metre arasındakiler billboard olarak render edilir; daha uzaktakiler ise hiç render edilmez.

Bu ayıklama, iki büyük israf kategorisini gözden kaçırıyor:

1. 60 metrelik diskin içinde ama kameranın arkasında olan her şey. Oyuncu 4 metreden fazla hareket ettiğinde instance buffer'ını yeniden sıralıyoruz, ancak görüş frustum'unu test etmiyoruz. Bu nedenle diskin ortalama yarısı, vertex dönüşümünden sonra kırpılmak üzere GPU'ya gönderiliyor.
2. 60 metrelik diskin içinde ama bir tepenin arkasında olan her şey. Arazimizin dikey aralığı 80 metre ve çok sayıda vadisi var. Kamera bir vadideyken, ayıklama yarıçapındaki bitki örtüsünün çoğu en yakın sırt tarafından geometrik olarak gizleniyor. Yine de hepsini çiziyoruz.

Bu yazı ikinci kategoriye odaklanıyor. Bu aynı zamanda AAA motorlarının, ilk bakışta tarayıcıya kolayca uyarlanamayan bir dizi akıllı yöntemle çözdüğü kategori.

Guerrilla'dan Gilbert Sanders, Horizon Zero Dawn'ın açık dünya bitki örtüsünü nasıl render ettiğini anlatıyor. Son 20 dakika ayıklama yığınına ayrılmış ve "daha hızlı çizmek" yerine neden "daha az çizmenin" üstün olduğunu gösteren usta işi bir ders niteliğinde.

Bizim kullanım senaryomuz için değerlendirilen sekiz teknik

Modern örtülme ayıklama yığınını inceledim ve her parçayı prosedürel, yükseklik haritası tabanlı, tarayıcı içinde çalışan bir açık dünyaya ne kadar yardımcı olduğuna göre değerlendirdim. İki ölçüt kullandım: değer (sahnemiz düşünüldüğünde ne kadar israfı ortadan kaldırdığı) ve maliyet (mühendislik emeği ile yığınımızın ne kadarını değiştirmeye zorladığı). Tüm gerekçeler bu yazının arkasındaki araştırma dosyasında bulunuyor; kısa versiyonu şöyle.

1. Instance başına frustum ayıklaması. Yüksek değer, düşük maliyet. Şu anda instanced bitki örtümüz için frustum'u hiç test etmiyoruz. Bunu eklemek herhangi bir görünümde işi yaklaşık yarıya indiriyor, yaklaşık otuz satır kod gerektiriyor ve bugün WebGL ile yayınlanabiliyor. Bu, en büyük ve en ucuz kazanım; aylar önce yapmış olmalıydık.

2. Yükseklik haritasında ufuk ışını taraması. Yüksek değer, düşük–orta maliyet. Kameradan her aday instance'a doğru bir ışın ilerletin ve yol boyunca arazi yüksekliğini örnekleyin. Arazi herhangi bir noktada ışının üzerine çıkarsa instance örtülmüştür. Bunun düzgün çalışmasının nedeni, dünyamızın bir yükseklik haritası olması ve görünürlük problemini yatay yön boyunca 1B bir probleme indirgemesidir. Yoğun sürüm, her karede instance başına O(adım) maliyetlidir. Hızlandırılmış sürüm (bir sonraki madde) bunu O(log adım) seviyesine düşürür.

3. Maksimum yükseklik piramidiyle hızlandırma. Yüksek değer, orta maliyet. Her texel'in kendi kapsama alanındaki maksimum arazi yüksekliğini sakladığı, yükseklik haritasının 2B bir mipmap'i. Ufuk ışını taramasının çevre düzken kaba adımlarla ilerlemesini ve yalnızca tepelerin üzerinde hassaslaşmasını sağlar. 2 numaralı yöntemi üretimde ucuz hâle getiren yapı budur.

4. Hiyerarşik Z örtülmesi (Hi-Z / HZB). Yüksek değer, yüksek maliyet. Bir depth buffer mipmap'i oluşturun, her instance'ın sınırlarını ekran uzayına yansıtın ve doğru mip seviyesine karşı test edin. Bu, Unreal'ın Nanite'ı, Bevy'nin sanal geometrisi ve VTK'nın WebGPU portu tarafından kullanılan modern GPU tarafı standardıdır. Yalnızca arazi için değil, her şey için çalışır; ancak WebGPU, indirect draw'lar ve bir compute pass gerektirir. Binlerce ağaç değil, milyonlarca çim yaprağı render ettiğimizde karşılığını verir.

5. İki geçişli Hi-Z (Nanite tarzı). 4 numaraya kıyasla marjinal kazanç, yüksek maliyet. Bir karelik yeniden görünür olma artefaktını önlemek için 1. geçişten sonra bu karenin derinliğini yeniden render eder. Yalnızca GPU güdümlü yolda yeterince ilerlediğimizde ve maliyet artımlı hâle geldiğinde buna değer.

6. Yazılımsal örtülme rasterizer'ı (Frostbite/Intel MOC). Orta değer, yüksek maliyet. Büyük örtücülerin düşük çözünürlüklü depth buffer'ını CPU'da rasterize edin. Readback gecikmesi sıfırdır. Referans uygulamalar AVX/SSE C++ ile yazılmıştır; bunları WASM'a port etmek başlı başına gerçek bir projedir ve yükseklik haritası ışını taramamız, işin çok küçük bir bölümüyle aynı kazanımların çoğunu sağlar.

7. Önceden hesaplanmış PVS. Düşük değer, yüksek maliyet. Quake döneminin statik haritaları için harikadır. Arazimiz prosedürel ve sonsuz olduğundan her türlü ön işleme chunk akışı sırasında yapılmak zorunda; bunun maliyeti de çalışma zamanında görünürlük hesaplamak kadar yüksek. Atla.

8. Cesium tarzı ufuk ayıklaması. Bizim için değeri yok, orta maliyet. Gezegen elipsoidleri için tasarlanmıştır. Dünyamız nispeten düz ve sınırlıdır; matematik burada geçerli değildir ve ya hiçbir şey yapmaz ya da yanlış ayıklamaya yol açar. Atla.

Sonuç olarak: 1 ile 2+3'ü şimdi, CPU'da ve WebGL ile yapın. 4'ü WebGPU geçişi için planlayın. Geri kalanları atlayın.

Tarayıcı arazisi için yükseklik haritası ışını taraması neden kazanıyor?

Herhangi bir modern render sunumundaki standart tavsiye "bir Hi-Z buffer oluşturun" şeklindedir. Brian Karis'in Nanite üzerine SIGGRAPH 2021 derinlemesine incelemesi bu konudaki temel kaynaktır ve en az bir kez izlemelisiniz.

Her şeyi zaten GPU güdümlü indirect draw'lardan geçiren bir motor için doğru yanıt budur. Bizimki de dahil olmak üzere çoğu tarayıcı motoru böyle bir motor değildir. CPU tarafında instance buffer'larımız, WebGL draw call'larımız var ve compute aşamamız yok. Bu yığına Hi-Z eklemek; aynı anda WebGPU'ya port etmeyi, bitki örtüsü pipeline'ını indirect draw'larla yeniden yazmayı ve depth pyramid oluşturma pass'i eklemeyi gerektirir. Fikri doğrulayan ilk kare için üç aylık iş demektir.

Yükseklik haritası ışını taraması CPU'da, WebGL ile ve zaten sahip olduğumuz verilerle çalışır. Dünyamızla ilgili AAA motorlarının yararlanamadığı tek bir olguyu kullanır: örtücülerimiz 1B bir yükseklik fonksiyonuyla tanımlanıyor. Bu fonksiyonu bir ışın boyunca örneklemek, iki dizi erişimi ve bir çarpma işleminden ibarettir. Hi-Z buffer'ın aynı olguyu piksel piksel keşfetmesi gerekirdi.

Teknik ilk olarak IEEE Visualization 2002'de "Hiyerarşik Araziler için Ufuk Örtülme Ayıklaması" adıyla yayımlandı (PDF). Yirmi yıldır araç kutusunda kalmasının nedeni doğru yapıya sahip olmasıdır: arazi düzken ucuz, yalnızca gerçekten tepelerin bulunduğu yerlerde pahalı ve kolayca paralelleştirilebilir.

Çizimle maksimum yükseklik piramidi

Naif ışın taraması, her ışın boyunca yaklaşık 24 noktada terrainHeight değerini örnekler ve arazi ışını keserse erkenden sonlandırılır. Bu, binlerce ağaç için yeterlidir. Yüz binlerce çim yaprağında çöker.

Çözüm, her texel'in kendi kapsama alanındaki maksimum yüksekliği sakladığı bir yükseklik haritası mipmap'idir:

seviye 0 (256×256, texel başına 2.25m): 4×4 sapmalı örneğin maks. h değeri
seviye 1 (128×128, texel başına 4.5m):  maks(0,0), maks(1,0), maks(0,1), maks(1,1)
seviye 2 ( 64×64, texel başına 9.0m):  bir üst seviyede aynı indirgeme
...
seviye 8 (   1×1, texel başına 576m):  global maksimum

Işın segmenti uzun ve düz olduğunda kaba bir seviyeyi örnekleyin: tek bir erişim size "bu 9 metrelik karede hiçbir arazi 12 metre rakımı aşmıyor ve ışın burada 30 metrede, dolayısıyla devam et" bilgisini verir. Yalnızca kaba bir texel "arazi ışının üzerinde olabilir" dediğinde bir seviye aşağı iner ve hassaslaştırırsınız. Yapının tamamı birkaç yüz KB boyutundadır ve onlarca milisaniyede oluşturulur.

Şematik olarak:

                                            gözden çıkan ışın
        göz 1.7m                          o─────────────────────►
              o─────────────────────────·─·─·─·─·─·──────────────
              │                          \                       │
              │   seviye 3 (dev adım)     \   seviye 0 (hassas)  │
              │   "8m üstü arazi yok"      \   "burada 9m tepe!" │
              │                              \                   │
        ──────┴────────────/▔▔▔\─────────────/▔▔▔▔▔\─────────────
                                 tepe A (8m)   tepe B (12m)
                                                ↑
                                                burada engeller

A tepesinin çevresinden geçen ışın segmentinde, seviye 3 erişimi ("18 metre genişliğindeki bu kutunun maksimum yüksekliği 8 metre") bize 1,7 metre rakımdaki ve birkaç metre yükselen ışının önünün açık olduğunu zaten söyler. Tek bir sorguyla 36 metrelik ilerlemeyi atlarız. B tepesi üzerinde seviye 3 "buradaki maksimum 12 metre" der; aşağı ineriz, seviye 0 "evet, tam olarak bu texel'de 12 metre" der ve instance'ı eleriz.

Piramit oluşturma kodu height-pyramid.mjs, onu kullanan ayıklama yolları ise cull.mjs içindedir. Her ikisini de spike kaynak tarayıcısında okuyabilirsiniz.

Spike gerçekte ne gösteriyor?

Yukarıdaki Spike 57'yi açın ve dört yolu deneyin:

• T0, üretimde bugün yaptığımız şeydir. Yalnızca mesafe. C1'den (vadi tabanı) bakıldığında HUD, yaklaşık 12.000 çim yaprağının görünür olduğunu bildirir.
• T1, instance başına frustum ayıklaması ekler. Kameranın arkasında veya yanlarda kalan her şey GPU'ya ulaşmadan elendiği için görünür öğe sayısı yaklaşık yarıya düşer.
• T2, kaba kuvvet kullanan yükseklik haritası ışını taramasını ekler. C1'de sayı bir %60-80 daha azalır; çünkü alanın çoğu en yakın sırtın diğer tarafındadır. Instance başına yaklaşık 24 kez terrainHeight örneklediğimiz için Cull-ms sütunundaki değer yükselir.
• T3, kaba kuvvet yönteminin yerine maksimum yükseklik piramidini koyar. Görünürlük kazanımını korurken Cull-ms tekrar T1'e yakın bir seviyeye düşer. Gerçekte yayınlayacağınız yol budur.

Bu örüntü, üretim motorlarında görülenlerle örtüşüyor. Acerola'nın çim render etme üzerine iki bölümlük serisi (Oyunlar Bu Kadar Çok Çimi Nasıl Render Ediyor?, Oyunumdaki Çimleri Optimize Etmek İçin Ne Yaptım?), mühendislik emeğinizi shading aşamasına değil neden ayıklama aşamasına harcamanız gerektiğini anlatan YouTube'daki en anlaşılır içeriktir.

C3 kamerası ve "tepe üstü" başarısızlık senaryosu

Spike'ın üçüncü kamera ön ayarı, kamerayı oyun alanına bakan bir tepenin üzerine yerleştirir. Ufuk ayıklamasının neredeyse hiçbir şey yapmadığı senaryo budur; çünkü kamera ile dünyanın büyük bölümü arasında arazi yoktur. HUD, T2/T3'ün görünür öğe sayısını T1'e kıyasla yalnızca %5-10 kadar azalttığını gösterir.

Bu bir hata değil, özelliktir. Teknik tam da durması gereken yerde çalışmayı bırakır: örtecek hiçbir şey olmadığında. Frustum ayıklaması hâlâ gerçek iş yapar, mesafe ayıklaması hâlâ bütçeyi sınırlar ve ufuk testi sorunsuzca no-op davranışına geri döner. Bunu uygularsanız no-op durumunun da ucuz olduğunu doğrulamanız gerekir. Hiçbir ışın elenmeyecek olsa bile maksimum yükseklik piramidinin önemli olmasının nedeni budur: en kaba seviye çoğu zaman "hiçbir şey engellenmiyor" sonucunu doğrulamaya yeter.

Sırada neyi yayınlayacağız?

Sırayla yapılması gereken üç şey var.

İlk olarak T1 ve T3'ü üretimdeki Chunk.updateObjectVisibility içine port etmek. Piramidin chunk yöneticisinde, bir üst seviyede bulunması gerekiyor; çünkü birden fazla chunk'a yayılıyor. Mevcut chunk başına batching çalışmaya devam etsin diye ayıklama Chunk içinde kalacak. Tahmini süre: testler dahil bir gün. İkinci olarak, çimler hazır olduğunda aynısını onlar için de yapacağız. Mevcut prototip, 576 metrelik oyun alanına 12.000 çim yaprağı dağıtıyor; üretim sürümündeki yoğunluk bunun kabaca on katı olmalı. CPU ayıklama yolları 12.000 örneği bir milisaniyeden kısa sürede işliyor ve bunun 120.000 örnekte de geçerli kalmasını sağlayan piramit hızlandırmasıdır.

Üçüncü olarak, THREE.WebGPURenderer'a geçtiğimizde aynı döngüyü bir compute shader'a taşıyacağız. Meta veriler bir depolama tamponuna dönüşecek. Ayıklama işlemi drawIndirect argümanlarını yazacak. Piramit, maksimum indirgeme önceden uygulanmış bir 2D doku olarak yüklenecek. Kodun yapısı neredeyse tamamen aynı kalacak; zaten asıl amaç da bu: geçişi yeni bir algoritmaya bağlamıyoruz, hâlihazırda sahip olduğumuz bir algoritmayı daha hızlı bir çalışma ortamına taşıyoruz.

Guerrilla, Horizon Zero Dawn'ın prosedürel yerleştirme sistemi için bunun GPU tarafındaki sürümünü ele aldı; render işlem hattından çok veri yapıları önem taşıyor ve onlarınki de aynı yapıya sahip:

Binaları ve yükseklik haritasının tanımlayamadığı yönlerde örtme yapan yoğun dekoratif nesneleri yayınladığımızda Hi-Z yine yerini hak edecek. Ancak yükseklik haritası piramidi işlem hattında kalacak, çünkü zemine yakın örnekler için Hi-Z'den kesin biçimde daha ucuzdur ve bir sırtın silüetini aşan çimler, Hi-Z'nin en kötü başa çıktığı durumlardan biridir.

Kaynaklar

Önceliklendirilmiş gerekçelerin tamamı ve mimari kararlar yukarıda yer alıyor; aşağıda ise yığındaki yaklaşık görünme sıralarına göre her tekniğin temel kaynakları bulunuyor.

• Yalim ve Akman, Hiyerarşik Araziler İçin Ufuk Örtme Ayıklaması (IEEE Visualization 2002, arazi ufuk ayıklamasına ilişkin özgün makale).
• Turitzin, Hiyerarşik Derinlik Tamponları (Hi-Z mip zincirlerinin nasıl oluşturulup sorgulandığını en açık biçimde anlatan yazı).
• VKGuide, Compute Tabanlı Ayıklama (GPU güdümlü ayıklama işlem hattı için referans; WebGPU'ya taşıma işlemi mekaniktir).
• Kruskonja, İki Geçişli Örtme Ayıklaması (Nanite tarzı mimarinin Epic'in sunumları dışında açıklaması).
• Karis ve diğerleri, Nanite — Derinlemesine İnceleme (SIGGRAPH 2021) (GPU güdümlü ayıklamanın AAA ölçeğinde nasıl göründüğüne ilişkin modern referans).
• Karis, HPG 2022 Açılış Konuşması: Nanite'a Yolculuk (ayıklama aşamasının neden önemli olduğuna ilişkin daha geniş bağlam).
• Sanders, Teknoloji ile Sanat Arasında: Horizon Zero Dawn'ın Bitki Örtüsü (AAA bitki örtüsü ayıklama yığınının uçtan uca anlatımı).
• Guerrilla, Horizon Zero Dawn'da GPU Tabanlı Çalışma Zamanı Prosedürel Yerleştirme (örneklenmiş yerleştirme ve örnek başına görünürlük).
• Scthe, Nanite WebGPU (HZB dâhil eksiksiz bir WebGPU referans uygulaması).
• Kitware, VTK'da WebGPU Örtme Ayıklaması (bildiğim kadarıyla tarayıcı tarafındaki ilk üretim HZB'si).
• Acerola, Oyunlar Bu Kadar Çok Çimi Nasıl Render Ediyor? ve Oyunumdaki Çimleri Optimize Etmek İçin Ne Yaptım? (erişilebilir YouTube turu).
• RasterGrid, Hi-Z Haritası Tabanlı Örtme Ayıklaması (hâlâ temel kabul edilen Hi-Z başlangıç rehberi).
• Intel, Maskeli Yazılım Örtme Ayıklaması (#6'nın buna değeceğine karar verirseniz CPU rasterleştirici ailesi).

Oleg Sidorkin, Cinevva CTO'su ve Kurucu Ortağı

Burada yeni misiniz? Seri rehberini kullanın. Bu rehber, spike'ın ne olduğunu açıklıyor ve tüm bölümlere bağlantı veriyor.

28. bölüm çim ve örtülmeyi ele aldı. Yirmi sekiz bölüm boyunca içinde durabileceğiniz bir dünya oluşturduk: okuyabildiğiniz arazi, yüzebildiğiniz su, ufka kadar kalitesini koruyan bitki örtüsü ve değiştirdiklerinizi hatırlayan bir sunucu. Bu bölüm, tüm bunların içinde hareket eden şeyle ilgili ve aynı zamanda tüm motorun karşılığını verdiği nokta; çünkü hedef bir oyuncu kontrolcüsü değil. Hangi bedeni yönettiğini, animasyonlarının nereden geldiğini veya direksiyonda bir insanın mı yoksa yapay zekânın mı bulunduğunu önemsemeyen bir kontrolcü. Spike 58, hareketi, lokomasyon hakkında hiçbir şey bilmeyen bir fizik motorunun üzerinde takılabilir davranışlardan oluşan bir yığın olarak kuruyor, ardından üç farklı bedeni aynı motor kopyasıyla çalıştırarak mimariyi kanıtlıyor. Spike 59, tek bir satırını bile değiştirmeden bu kontrolcüye gerçek ve yeniden hedeflenmiş bir avatar bağlıyor. Spike 60 ise hiç yeniden hedefleme gerektirmeyen farklı bir animasyon paketi bağlıyor ve klip seçme mantığını gerçekten test edebileceğiniz bağımsız bir yapıya çıkarıyor.

Yürüme hakkında hiçbir şey bilmeyen bir fizik motoru

Spike 58'i yeni bir sekmede aç ↗ · Kaynak kodunu görüntüle

Tasarım kuralı katı ve meselenin özü de bu: kapsül motoru hiçbir lokomasyon davranışına sahip değil. Yürüme yok, koşma yok, zıplama yok, sürtünme yok, azami hız sınırı yok, hatta yerçekimi bile yok. Kinematik bir kapsülü araziye göre entegre ediyor ve bundan fazlasını yapmıyor. Yürüme, kayma, süzülme, tırmanma, yüzme, çömelme ve dayanıklılık gibi tüm lokomasyon davranışları, motora kaydedilen bağımsız bir kontrolcüde yaşıyor. Motor her karede tüm kontrolcüleri güncelliyor, her birine kontrolü isteyip istemediğini soruyor ve hızı en yüksek öncelikli talip olan kontrolcünün yazmasına izin veriyor. Yürümenin özel bir konumu yok. Yalnızca her zaman evet diyen en düşük öncelikli kontrolcü; dolayısıyla başka hiçbir şey devreye girmediğinde varsayılan davranış oluyor. Bir kontrolcü altı küçük işlevden oluşuyor: etkin olmasa bile her karede kendi iç durumunu güncelleyen bir tick, kare üzerinde hak iddia eden saf bir wantsControl koşulu, yalnızca kazananın çalıştırdığı, hızı yazan ve isterse kendi yerçekimini uygulayan bir applyForces ile isteğe bağlı onEnter, onExit ve stateName. Yüzme, kaldırma kuvveti yayı motorun ayağı zemine oturtma işlemiyle çakışmasın diye arazi işleme kontrolünü devralmak üzere applyForces içinden ownsCollision: true döndürüyor.

Lokomasyon olmayan şeyler bile bu sözleşmeye sızıyor ve bu da bir sonraki fikri zorunlu kıldı. Mimariyi değerli kılan parça kanallar. Daha önceki tek kanallı tasarım her şeyi aynı hakemlikten geçiriyordu; bu da bir dayanıklılık izleyicisinin veya çömelme duruşunun, yalnızca kendi hesaplamalarını yapabilmek için lokomasyonmuş gibi davranıp ardından false döndüren bir wantsControl hilesiyle kontrolü reddetmesi gerektiği anlamına geliyordu. Çözüm, kontrolcüleri birbirinden bağımsız olarak hakemlik yapan ve sabit bir sırayla uygulanan adlandırılmış kanallara ayırıyor: önce kaynak, ardından duruş, sonra lokomasyon. Kaynak önce çalışıyor, çünkü dayanıklılığın azalması gibi yazdığı değerleri diğerleri okuyor. Duruş ikinci sırada çalışıyor, çünkü çömelmenin kapsül yüksekliğini küçültmesi, yürüme kontrolcüsü azami hızı sınırlamak için bu değeri okumadan önce gerçekleşmek zorunda. Lokomasyon en son çalışıyor ve kare başına hız yazımının sahibi oluyor. Böylece bir dayanıklılık gözlemcisi, bir çömelme değiştiricisi ve etkin bir yüzme kontrolcüsü, her biri kendi kanalında olacak şekilde sorunsuzca birlikte var oluyor; hiçbir kontrolcünün ne olduğu konusunda yalan söylemesi gerekmiyor. Demo, tüm bunları etkin kontrolcüye göre renk değiştiren çıplak bir kapsülle görselleştiriyor; böylece hakemliğin gerçekleşmesini izleyebiliyorsunuz: yeşil yürüme, dik bir yamaçta kayma kontrolü devraldığında turuncuya; gölde yüzme kazandığında camgöbeğine; havadayken süzülmeye dokunduğunuzda krem rengine dönüyor.

Tek motor, üç beden

“Hiçbir lokomasyona sahip değil” iddiasının asıl sınavı oyuncu değil. Asıl mesele, aynı motorun hiç değiştirilmeden oyuncu olmayan bir şeyi de yönetip yönetemediği. createCapsuleEngine, modül düzeyinde durumu, singleton'ı ve örneğe özgü yan etkileri olmayan saf bir fabrika olduğundan spike bunu üç kez örnekliyor. Oyuncu, eksiksiz kontrolcü kümesine sahip bir örnek. Binilebilir at, yalnızca bir yürüme kontrolcüsü kaydeden ikinci bir örnek; bu da tüm fikri kelimenin tam anlamıyla hayata geçiriyor: bir bedenin hareket repertuvarı yalnızca kaydettiğiniz kontrolcülerden oluşuyor. Dolayısıyla at düz zeminde daha hızlı ve fiziksel olarak tırmanamıyor, yüzemiyor veya süzülemiyor; çünkü bu kontrolcüler hiç eklenmedi. Otonom NPC ise oyuncuyla birlikte her karede güncellenen üçüncü bir örnek. Kendi girdisini üreten bir gezinme kontrolcüsü tarafından yönetiliyor; böylece beden, klavyede kimsenin eli olmadan kendi kendine yön buluyor. Motor, bedenlerinden birinin at veya diğerinin yapay zekâ tarafından yönetildiğini asla öğrenmiyor. Hepsi, yalnızca farklı kontrolcü listelerine sahip aynı kapsül entegratörü.

Binme, kasıtlı olarak motorun dışında yaşayan tek parça. Kontrolü oyuncu ile at arasında değiştirmek iki motorun koordinasyonunu gerektiriyor; bir kontrolcü ise tek bir motorun içinde çalışıyor ve bu sınırın ötesini göremiyor. Bu nedenle binme mantığı ana sistem düzeyinde bulunuyor: bu karede hangi motorun ilerletileceğine karar veren, diğerini donduran, biniciyi saniyenin dörtte üçü boyunca smoothstep ile yumuşakça eyere taşıyan ve kameraya hangi bedeni izleyeceğini söyleyen küçük bir durum makinesi. Motor fabrikası bunların hiçbirinden haberdar olmuyor. Mimari tam olarak bu sınırı çiziyor ve koruyor. Tek bir bedene ait davranışlar kontrolcüdür; bedenler arasındaki koordinasyon ise ana sistemin görevidir. Bunları birbirinden ayrı tutmak, dördüncü veya kırkıncı bir bedenin hiçbir yeni maliyet getirmemesini sağlıyor.

Tarayıcı olmadan test edildi

Motor hiçbir window, document veya Three.js nesnesine erişmediği için tüm sistem başsız çalışıyor. Spike; arazi arayüzünün sahtesini oluşturan, motoru betiklenmiş girdilerle kare kare çalıştıran ve ortaya çıkan durum üzerinde doğrulamalar yapan bir Node test düzeneğiyle geliyor. Böylece oynayarak test ederken yakalanması son derece zahmetli olan regresyonlar bunun yerine bir betikte yakalanıyor: zıplama ve yere inme geçişi, yüzmeye giriş ve çıkış eşikleri, yüzey düzleştiğinde tırmanmanın otomatik olarak temizlenmesi, dayanıklılık tükenme oranları. Aynı girdi ve zaman adımı dizisini iki kez besleyip çıktı durumlarının bayt düzeyinde aynı olduğunu kontrol etmek, motorun deterministik olduğunu sabitliyor; gelecekte ağ bağlantılı bir yapının dayanacağı özellik de bu. Test düzeneğinin yakaladığı bir regresyonu özellikle saklamakta fayda var: yürünebilir zeminden yürünemeyecek kadar dik bir yamaca geçmek eskiden kayma kontrolcüsünü etkinleştiriyor ve oyuncuyu yokuş yukarı geri sektiriyordu. Çözüm, bir alçalma kapısı oldu. Kayma yalnızca kapsül gerçekten yamacın üzerine düşüyorsa başlıyor; dolayısıyla dik bir yüzeye yatay olarak yürümek artık kaymayı tetiklemek yerine hareketi düzgünce engelliyor. “Yürünemeyen bir yamaca doğru yürümek oyuncuyu engeller” doğrulamasını yapan test de bu düzeltmenin kalıcı olmasını sağlıyor.

Kontrolcülere dokunmadan gerçek bir avatar bağlamak

Spike 59'u yeni bir sekmede aç ↗ · Kaynak kodunu görüntüle

Spike 59, kontrolcü katmanının bedenden gerçekten ayrıştırılıp ayrıştırılmadığını sınayan test. Renkli kapsülü gerçek bir iskeletli karakterle değiştiriyor: Quaternius Universal Animation Library kliplerinin üzerine yeniden hedeflendiği 3MIKE FBX iskeleti. Kontrolcüler ise hiç değişmiyor. Bağlantı noktası tek bir dize. Her kontrolcü zaten stateName üzerinden bir durum adı bildiriyor: idle, walk, run, jump, fall, land, slide, glide, swim, swimIdle. Avatar katmanı bu adı bir takma ad tablosu üzerinden yeniden hedeflenmiş klibe eşliyor ve geçiş sırasında çapraz soldurma uyguluyor. Yürüme kontrolcüsü kendi alt durumunu yerde olma durumu, dikey hız ve yatay hıza göre dinamik olarak seçiyor. Böylece tek bir yürüme kontrolcüsü bekleme, yürüme, koşma, zıplama, düşme ve yere inme durumlarını yönetiyor; avatar da yalnızca bildirilen adı izliyor. Bu spike tek oyunculu olduğundan avatar, önceki ağ bağlantılı spike'lardaki kablo tamsayısı dolaylamasını ve çok karakterli soyutlamayı kaldırıyor ve durum adını doğrudan bir klibe eşliyor. Bunun kanıtı, kapsülden iskeletli insana yapılan tüm görsel yükseltmenin lokomasyon kodunda sıfır satırı değiştirmiş olması; takılabilir bir kontrolcünün sağlaması gereken fayda da tam olarak bu.

Yeniden hedefleme gerektirmeyen bir paket ve test edilebilir bir seçici

Spike 60'ı yeni bir sekmede aç ↗ · Kaynak kodunu görüntüle

Spike 60 üçüncü bir beden olan Synty'nin POLYGON Base Locomotion paketini bağlıyor ve yükleyici neredeyse hiçbir şey yapmıyor. Her klip, aynı Synty iskeletinin gömülü bir kopyasını ve tek bir işlenmiş animasyonu taşıyan bağımsız bir FBX olarak geliyor. Karakter iskeletiyle her klip aynı kemik adlarını kullandığından klibi fbx.animations[0] üzerinden alıp arada herhangi bir yeniden hedefleme kütüphanesi olmadan doğrudan karakterin mixer'ında oynatabiliyorsunuz. Three.js, animasyon izi hedeflerini nesne kimliği yerine kemik adına göre çözümlüyor; dolayısıyla eşleşen iskelet için hazırlanmış Synty veya Mixamo tarzı bir paket doğrudan çalışıyor. Bu, önceki spike'taki UAL yoluyla bilinçli olarak oluşturulan karşıtlık. Kaynak klipler ve hedef iskelet farklı iskelet sistemleri için hazırlandığından UAL yolu kapsamlı bir yeniden hedefleme gerektiriyor. Aynı kontrolcü, aynı durum adı bağlantısı, arkasında ise tamamen farklı iki animasyon hattı.

Spike 60'ın diğer yarısı, klip seçme mantığını test edilebilir hâle getiriyor. Hangi klibin oynatılacağını seçmek yoruma açık çok sayıda eşik içeriyor ve bu mantık, test edilemediği FBXLoader ve DOM'un yanında avatar katmanının içine gömülmüştü. Spike, seçiciyi ne Three.js'e ne de window'a dokunan saf işlevlere çıkarıyor: bu işlevler yalın bir oyuncu kaydı (hız, yatay hız, bakış yönü, yerde olma durumu, zemin normali, çarpma hızı) ve klip eylemi yerine geçen bir nesne alıp bir klip takma adı dizesi döndürüyor. Bu da eşiklerin adlandırılmış ve doğrulanan sabitler olarak yaşamasını sağlıyor. Zıplama, yürüme kontrolcüsünün gerçek sprint eşiğiyle uyumlu hız aralıklarına göre yürüme, koşma ve sprint varyantlarına ayrılıyor; inişler çarpma hızına göre yumuşak, orta ve sert olarak ayrılıyor; yokuş yukarı ve yokuş aşağı klip varyantları, yaklaşık yedi derecenin altında düz klibin kullanıldığı bir ölü bölgeye sahip eğim izdüşümü nokta çarpımından etkinleşiyor; beklemeden harekete geçiş köprüsü her zaman ileri yönü seçiyor, böylece hareketsiz başlangıçta hiçbir zaman geriye doğru bir klip oynatılmıyor; durma köprüsü ise minimum döngüde kalma süresiyle sınırlandırılıyor, çünkü Synty'nin ayak fazına göre hazırlanmış durma klipleri yaklaşık bir saniyelik tasarlanmış yavaşlama içeriyor ve oyuncunun zar zor attığı bir adıma eklendiğinde gülünç görünüyor. Küçük bir durum debounce mekanizması, birkaç kare boyunca düşme durumunu geciktiriyor; böylece bir birleşim noktasında zemin temasının tek kareliğine kaybolması animasyonun titremesine neden olmuyor. Tüm bunları görüntüleme kabuğundan çıkarmak, kuralların GPU olmadan birim testine tabi tutulabilmesini sağlıyor. Bu, motorun Spike 58'de kazandığı başsız çalışma disiplininin aynısı ve tahmin ederek ayarladığınız hareket hissiyle kesin biçimde sabitleyebildiğiniz hareket hissi arasındaki farkı oluşturuyor.

Bu bölümde değinilen teknoloji

Lokomasyondan bağımsız bir fizik motoru. Kapsül motoru, kinematik bir bedeni araziye göre entegre ediyor ve yürüme, koşma, zıplama, sürtünme, hız sınırı veya yerçekimi davranışlarından hiçbirine sahip değil. Her davranış; tick, wantsControl, applyForces ve isteğe bağlı onEnter/onExit/stateName sunan kayıtlı bir kontrolcü. Yürüme yalnızca her zaman evet diyen, en düşük öncelikli varsayılan davranış ve bir kontrolcü arazi işleme kontrolünü devralmak için ownsCollision: true döndürebiliyor (yüzme bunu yapıyor, böylece kaldırma kuvveti yayı ayağı zemine oturtma işlemiyle çakışmıyor).

Bağımsız hakemlik kanalları. Kontrolcüler, birbirinden ayrı olarak hakemlik yapan ve sabit bir sırayla uygulanan adlandırılmış kanallara (kaynak, duruş, lokomasyon) kaydoluyor. Böylece dayanıklılık gibi gözlemciler ve çömelme gibi değiştiriciler, kontrolü alıyormuş gibi yapıp ardından reddetmek yerine etkin lokomasyonla birlikte var olabiliyor. Kaynak yazımları (dayanıklılık), duruş ve lokomasyon tarafından okunuyor; duruş yazımları (çömelme kapsülünün yüksekliği), lokomasyonun hız sınırı tarafından okunuyor; lokomasyon ise en son çalışıyor ve hız yazımının sahibi oluyor. Tek fabrika, birçok gövde. createCapsuleEngine, singleton içermeyen saf bir fabrikadır; böylece aynı motor oyuncuyu, yalnızca yürüyebilen binilebilir bir atı ve yapay girdilerle kendi kendini yöneten bir NPC'yi çalıştırır. Bir gövdenin hareket repertuvarı, tam olarak kayıtlı kontrolcü kümesinden oluşur; dolayısıyla at tırmanamaz veya yüzemez, çünkü bu kontrolcüler hiç eklenmemiştir. Binme mekaniği bir kontrolcüde değil, ana uygulama katmanında bulunur; çünkü birbirinin iç durumunu göremeyen iki motoru koordine eder. Bkz. GPU güdümlü LOD.

Başsız, deterministik testler. Motor window, document veya Three.js'e dokunmaz; böylece bir Node test düzeneği onu kare kare çalıştırarak zıplama ve yere iniş, yüzme eşikleri, tırmanmanın otomatik olarak sonlandırılması ve dayanıklılık tüketimi hakkında doğrulamalar yapar. Aynı girdiyi iki kez yeniden oynatıp çıktının aynı olduğunu kontrol etmek determinizmi kanıtlar. Ayrıca bir regresyon testi, dik bir yüzeye doğru yatay yürüyüşün oyuncuyu geriye kaydırmasını önleyen alçalma geçidini sabitler.

Test edilebilir bir seçiciye sahip, gövdeden bağımsız avatar bağlama. Kontrolcüler bir durum adı dizesi bildirir ve görsel katman bunu bir kliple eşler; böylece kapsülü yeniden hedeflenmiş bir 3MIKE + UAL avatarıyla değiştirmek, hareket kodunda hiçbir değişiklik gerektirmez. Synty POLYGON klipleri rig ile aynı kemik adlarını paylaşır ve UAL yolundaki ağır yeniden hedefleme işleminden farklı olarak yeniden hedefleme olmadan oynatılır (Three.js, izleri kemik adına göre bağlar). Klip seçici; zıplama hızı aralıkları, iniş şiddeti, eğim izdüşümü varyantları, her zaman ileri yönlü bir boşta bekleme geçişi, durma geçişi için minimum süre koruması ve düşme durumu debounce mekanizmasına yönelik adlandırılmış sabitler içeren saf fonksiyonlara ayrılmıştır. Böylece hareket hissi tahmin edilmek yerine birim testleriyle doğrulanabilir.

30 bölümün 29. bölümü. Önceki: Bölüm 28 - Ufka uzanan çimler ve kendini gizleyen zemin Sonraki: Bölüm 30 - Duvarlara saygı duyan bir kamera Seri rehberi: /tr/blog/2026-02-25-open-world-browser-series-guide

Yazan: Oleg Sidorkin, Cinevva CTO'su ve Kurucu Ortağı

Burada yeni misiniz? Seri rehberine göz atın. Rehber, spike'ın ne olduğunu açıklıyor ve tüm bölümlere bağlantı veriyor.

27. Bölüm adayı oluşturdu ve ona döşeme gibi görünmeyen bir zemin kazandırdı. Bu bölüm, araziyi boş değil de yaşamla dolu hissettiren iki şeyi ele alıyor. Spike 56, dokulu bir yamacı içinde yürümek isteyeceğiniz bir yere dönüştüren yüzey ayrıntısı olan çimlere odaklanıyor; buradaki sorun, çim alanını dağınık çizgiler yerine gerçekten bir tarla gibi göstermek. Spike 57 ise daha fazla çizmenin tam tersini ele alıyor: Bir tepenin zaten gizlediği şeyleri çizmemek. İlginç sonuçsa bunu test etmenin hızlı yolunun aynı zamanda doğru yol olduğunun ortaya çıkması.

Konfeti değil, tarla gibi görünen çimler

Spike 56'yı yeni sekmede aç ↗ · Kaynak kodunu görüntüle

Temel karar geometrik. Tek bir ince ve uca doğru daralan çim bıçağı, çoğu kamera açısından piksel altı boyutta kalıyor; dolayısıyla yarım milyon düz bıçak, bir tarla yerine seyrek yeşil konfetiler gibi görünüyor. Çözüm, çapraz dörtgenlerden oluşan bir küme: Yerel yukarı eksenin etrafında birbirinden altmış derece farklı açılara döndürülmüş üç daralan dörtgen. Böylece her bakış yönünde en az bir dörtgen kameraya neredeyse dik duruyor ve her örnek, ekranda yaklaşık üç çim bıçağı genişliğinde gerçek alan kaplıyor. Yeşil çizgiler görmekle çim görmek arasındaki farkı yaratan da bu.

Bir WebGPU compute çekirdeği, başlangıçta her kümeyi bir kez yerleştiriyor. Örnek indeksini birbiriyle korelasyonsuz beş rastgele akışa hash'liyor, alan içinde bir XZ konumu seçiyor, CPU'daki zemin örgüsünün kullandığı aynı FBM'den zemin yüksekliğini örnekliyor (değerlerin birebir eşleşmesi ve bıçakların yüzeyin üzerinde havada durmak yerine yüzeye oturması için işareti koruyan mod kullanan bir TSL uyarlaması), merkezi fark yöntemiyle bir normal hesaplıyor ve her küme için genişlik, yükseklik ve renk tonu belirliyor. Render tarafında, örnek matrisini tamamen atlayıp doğrudan clip space'e yazan bir TSL vertex grafiği bulunuyor: Birim çapraz dörtgeni ölçekliyor, Rodrigues formülüyle yerel yukarı yönünü zemin normaline döndürüyor ve küme konumuna taşıyor. Mesafe LOD'u, bir ayıklama geçişine gerek kalmadan elde ediliyor; çünkü vertex grafiği kümenin yüksekliğini $1-\text{smoothstep}(\text{fadeNear},\text{fadeFar},\text{dist})$ ile çarpıyor. Böylece uzaktaki kümeler sıfır yüksekliğe kadar düzleşiyor ve fill maliyeti oluşturmamaya başlıyor. Rüzgâr, kümenin dünya XZ konumu ile zaman üzerinde hesaplanan iki oktav sinüs ve kosinüsten oluşuyor; yatay olarak uygulanıyor ve yükseklik oranıyla sınırlandırılıyor. Böylece taban sabit kalırken uçlar hareket ediyor. Kamerayı hesaba katan çok hafif bir eğim de her kümeyi izleyiciye doğru yatırarak düz kartlar gibi görünmek yerine perspektifte açılmalarını sağlıyor.

Renk tarifi, NedMakesGames'in Breath of the Wild URP shader'ından alındı: Çim bıçağı rengi, yükseklik oranı boyunca kök tonundan uç tonuna lerp edilen düz gölgelendirme kullanıyor; kök ve uç tonlarının kendileri de küme başına renk tonu değerine göre iki palet arasında lerp ediliyor. Bu, gerçek bir BotW çim alanındaki benekli iki tonlu görünümü sağlıyor. Stilize görünümde çapraz dörtgenlerin ayrı ayrı normalleri tek tek gölgelendirmek için fazla gürültülü olduğundan diffuse, ortam ışığı alt sınırıyla birlikte zemin normalinin güneşe göre yönünü kullanıyor. Tüm alan, bütünüyle GPU üzerinde yerleştirilip canlandırılan tek bir draw çağrısıyla çiziliyor.

Bir tepenin gizlediği öğeleri ayıklamanın dört yolu

Spike 57'yi yeni sekmede aç ↗ · Kaynak kodunu görüntüle

Spike 57, prodüksiyon istemcisinin stream ettiği aynı prosedürel dünya üzerinde dört ayıklama yöntemini karşılaştırıyor; tepelerin bitki örtüsünü gerçekten kapatabilmesi için dünya dikey eksende 1,8 kat ölçeklenmiş. T0 yalnızca mesafeyi kullanıyor ve yayınlanan sürümdeki chunk görünürlüğünün hâlihazırda yaptığı işle eşleşiyor. T1, düşük maliyetle en büyük kazancı sağlayan frustum ayıklamasını ekleyerek görüş konisinin dışındaki her şeyi eliyor. T2, araziyi hesaba katan bir ufuk testi ekliyor: Gözden her örneğe bir ışın ilerletiyor ve yolun herhangi bir noktasında heightmap ışının üzerine çıkarsa örneği eliyor. Böylece bir sırtın arkasındaki ağaç, frustum içinde olsa bile ayıklanıyor. T3 aynı ufuk testini koruyor ancak maksimum yükseklik piramidiyle hızlandırıyor. T4 ise mesafe, frustum ve ufuk testlerinin tamamını, bitki örtüsü materyalinin gizli vertex'leri daraltmak için okuduğu örnek başına görünürlük ölçeğini yazan bir TSL compute çekirdeğine taşıyor. İki karelik görünür kalma sayacı, kamera hafifçe oynadığında bir örnekleme noktasının texel'ın hemen içine veya dışına düşmesinden kaynaklanan tek karelik titremeyi yumuşatıyor. Bu süre özellikle kısa tutuluyor; çünkü daha uzun süreler algoritmik hataları düzeltmek yerine gizliyor.

Spike'ın asıl değerini ortaya koyduğu yer piramit ve buradaki ders, testi ekranda gerçekten görünen şeyle eşleştirmekle ilgili. Render edilen arazi, vertex'leri sabit iki metrelik bir ızgara üzerinde bulunan üçgen örgüden oluşuyor ve rasterizer vertex'ler arasında doğrusal enterpolasyon yapıyor. Dolayısıyla herhangi bir dikdörtgen içindeki gerçek render yüksekliği, aradaki sürekli gürültü tepesinin değil, o dikdörtgen içindeki vertex'lerin maksimumu oluyor. Örtülme piramidi gürültüyü daha sık bir ızgarada örneklerse örgünün hiç göstermediği hayali tepeler buluyor ve kameranın açıkça ötesini görebildiği ışınları engellemeye başlıyor. Bu nedenle piramidin taban texel'ları tam olarak vertex ızgarasına oturuyor; her biri dört köşe vertex'inin maksimumunu saklıyor ve üst seviyeler standart 2x2 maksimum indirgemelerini kullanıyor. Bu da piramidi render edilen örgü açısından kesin hâle getiriyor. Kod, her ışın adımındaki test için piramidi sorgulamak yerine örgüyü bilineer enterpolasyonla noktasal olarak örnekliyor. Çünkü texel altı bir AABB sorgusu tüm texel'ın maksimumunu döndürerek dik sırtlarda yüksekliği birkaç metre artırıyor; bu da görünür nesneleri gizleyecek aşırı örtülmenin ta kendisi.

Şaşırtıcı sonuç, kaba kuvvet referansı olan T2'nin hatalı yöntem olması. T2, sürekli gürültüyü doğrudan noktasal olarak örneklediği için örgü vertex'leri arasında kalan ve render edilmeyen tepeleri yakalıyor; dolayısıyla biraz fazla örtülme uygulayıp oyuncunun gerçekte görebildiği bitki örtüsünü gizliyor. Piramit yöntemi, chunk düzeyindeki testlerde kullanılan $O(\log N)$ AABB indirgemesi sayesinde hem daha hızlı hem de geometrik olarak daha doğru; çünkü yalnızca örgünün gerçekten gösterdiği yükseklikleri döndürebiliyor. Spike'ın vermek istediği mesaj tam olarak bu: Hızlandırılmış yapı, hız uğruna kabul edilen bir kalite ödünü değil; gerçeklikle eşleşen sürüm. Chunk ayıklaması, her chunk için beş noktalı bir test çalıştırıyor (chunk'ın maksimum yüksekliğinde dört üst köşe ve merkez) ve chunk'ın kendini asla örtmemesi için kendi kapladığı alanı örtücü kümesinden çıkarıyor. Önerilen prodüksiyon yöntemi T4: Renderer zaten WebGPU'ya geçtiği için örnek metadata'sını ve yükseklik alanını storage buffer'lara aktarıp aynı döngüyü indirect draw kullanan bir compute shader'da çalıştırmak.

Bu bölümde kullanılan teknolojiler

Çapraz dörtgenli GPU çimleri. Her kümede birbirinden altmış derece farklı açılara döndürülmüş üç daralan dörtgen, her açıdan bakıldığında bir dörtgenin neredeyse dik görünmesini garanti ediyor. Böylece yarım milyon örnek, piksel altı konfetiler yerine bir tarla gibi algılanıyor. Bir compute çekirdeği her kümeyi yerleştiriyor (CPU örgüsüyle aynı işareti koruyan mod kullanılarak örneklenen FBM zemin yüksekliği, merkezi fark normali, küme başına boyut ve renk tonu); bir TSL vertex grafiği ise ölçeklemek, Rodrigues yöntemiyle normale döndürmek, taşımak ve yüksekliğe bağlı rüzgâr uygulamak için örnek matrisini atlıyor. Mesafe LOD'u ücretsiz: Kümeler $1-\text{smoothstep}(\text{fadeNear},\text{fadeFar},\text{dist})$ ile sıfır yüksekliğe daralıyor. Renk, NedMakesGames'in BotW tarifini izliyor: renk tonları karıştırılmış iki palet üzerinde kökten uca uzanan bir gradyan. Bkz. GPU güdümlü LOD.

Arazi ufku örtülme ayıklaması. Prodüksiyon dünyasında dört yöntem karşılaştırıldı: mesafe; buna eklenen frustum; sırtın arkasındaki örnekleri eleyen bir heightmap ışın testi; bunu hızlandıran maksimum yükseklik piramidi ve bir TSL compute uyarlaması. Piramit, örgünün tessellation için kullandığı iki metrelik vertex ızgarasının tam üzerinde örnekleme yapıyor (taban texel'ı = dört köşe vertex'inin maksimumu, üst seviyelerde 2x2 maksimum indirgeme). Böylece yalnızca rasterizer'ın gerçekten gösterdiği yükseklikleri döndürüyor.

Ödün vermeden hem hızlandırılmış hem doğru. Sürekli gürültünün noktasal olarak örneklenmesi (kaba kuvvet T2 yöntemi), örgü vertex'leri arasında kalan ve asla render edilmeyen tepeleri bulup görünür bitki örtüsünü gereğinden fazla örtüyor. Vertex ızgaralı piramit hem daha hızlı ($O(\log N)$ AABB indirgemesi) hem de geometrik olarak kesin. Bu nedenle her ışın adımındaki testler, dik sırtlarda yüksekliği metrelerce artırabilecek texel başına piramit maksimumunu sorgulamak yerine örgüyü bilineer olarak örnekliyor. Chunk ayıklaması beş noktalı bir test kullanıyor ve her chunk'ın kendi kapladığı alanı hariç tutarak kendini örtmesini önlüyor. Prodüksiyon yöntemi, metadata ile yükseklik alanını storage buffer'lara aktararak indirect draw kullanan bir compute shader ayıklaması gerçekleştiriyor.

29 bölümün 28'incisi. Önceki: 27. Bölüm - Gürültüden bir ada, zemine benzeyen bir zemin Sonraki: 29. Bölüm - Tek kontrolcü, her beden Seri rehberi: /tr/blog/2026-02-25-open-world-browser-series-guide

Yazan: Oleg Sidorkin, Cinevva CTO'su ve Kurucu Ortağı

Burada yeni misiniz? Seri rehberini kullanın. Rehber, spike'ın ne olduğunu açıklıyor ve tüm bölümlere bağlantı veriyor.

Bölüm 26 dünyaya su ekledi. Bu bölüm, gerçek bir yerin oluşumunu yansıtan iki aşamada suyun altındaki karayı inşa ediyor. Spike 54, arazinin kendisi: elle şekillendirilmiyor, gürültüden oluşturuluyor ve ardından suyun gerçekten üzerinden aktığı bir yere ait drenaj sistemine ve kıyı şeridine kavuşana kadar aşındırılıyor. Spike 55 ise bu arazinin yüzeyi: neredeyse tüm prosedürel zeminleri ele veren sorunu, yani döşenen bir dokunun döşenmiş gibi görünmesini çözüyor. İkisi birlikte şu soruyu yanıtlıyor: Bir içerik üreticisi, bir sanatçı ikisine de dokunmadan makul bir ada ve gerçekten zemin gibi görünen bir yüzey elde edebilir mi? Doğru tarifleri kopyalarsanız yanıt evet.

Gürültünün tek başına veremeyeceği bir kıyı şeridi

Spike 54'ü yeni sekmede aç ↗ · Kaynak kodunu görüntüle

Yükseklik haritası, her biri ham gürültüdeki belirli bir kusuru gideren küçük dönüşümler yığını olan Red Blob Games tariflerini izliyor. Kesirli Brown hareketi, birkaç Perlin gürültüsü oktavını toplayarak araziye hem geniş tepeler hem de ince ayrıntılar kazandırıyor; ancak düz FBM yumuşak ve ızgaraya hizalı göründüğü için önce örnekleme noktasına alan bükme uygulanıyor: her koordinatı başka bir gürültü alanıyla kaydırıyorsunuz, $p^{\prime }=p+\text{noise}(p)\cdot s$; bu da sırtları eksenlere kilitli görünmek yerine organik bir biçimde büküyor. Ardından yükseltiyi $e^k$ kuvvetine çıkaran yeniden dağıtım, orta tonları aşağı itiyor; böylece her yer aynı yumuşak eğimde kalmak yerine dünya düz vadilere ve keskin zirvelere kavuşuyor. Araziyi sonsuz tepeler yerine ada yapan parça ise radyal düşüş: merkezden Öklid uzaklığını $d=min(1,\sqrt{n_x^2+n_y^2})$ olarak hesaplıyor ve yükseltiyi $1-d$ yönünde harmanlıyorsunuz; böylece arazi kenarlarda okyanusa doğru alçalıyor. İkinci bir bağımsız gürültü alanı, biçimi etkilemeyen ancak daha sonra biyom adımını besleyen bir nem haritasına dönüşüyor.

Bu size bir biçim veriyor, ancak bu hâlâ bir gürültü biçimi. Ne nehirleri ne suyun oyduğu vadileri ne de tortu yelpazeleri var; çünkü üzerinden henüz hiçbir şey akmadı. Çözüm, Sebastian Lague'ın MIT lisanslı uygulamasından taşınan hidrolik erozyon. Binlerce su damlası rastgele noktalarda oluşup yokuş aşağı yuvarlanıyor. Her biri sert, dik açılı dönüşler yapmamak için atalet taşıyor; hızlandığında tortu topluyor, yavaşladığında veya göllendiğinde bunu bırakıyor. Önceden hesaplanan dairesel bir fırça, her erozyon olayını küçük bir yarıçapa yayarak oyuğu tek piksellik bir çizik yerine pürüzsüz hâle getiriyor; buharlaşma ise kullanım ömrü boyunca damlayı ortadan kaldırıyor. Yeterince damla çalıştırıldığında arazi, gürültünün taklit edemeyeceği özellikler kazanıyor: birleşen drenaj ağları, aşağı akış yönünde genişleyen vadiler ve tortunun çöktüğü düzlükler.

GPU'da erozyon ve nerede olduklarını bilen nehirler

CPU erozyonu doğru ancak yavaş; bu nedenle spike bunu bir WebGPU hesaplama gölgelendiricisine de taşıyor. İlginç olan kısım, GPU atomik işlemlerinin sizi neye zorladığı. Yükseklikler, bir milyon ölçekli sabit noktalı i32 değerleri olarak saklanıyor; çünkü WGSL'de kayan noktalı değerler üzerinde atomik toplama yok ve binlerce damlanın aynı hücreye paralel biçimde, yarış durumlarına yol açmadan tortu bırakıp kaldırabilmesinin tek yolu tamsayılar üzerinde atomicAdd ve atomicSub kullanmak. Sabit noktalı gidiş dönüş, yoğun eşzamanlı sürükleme altında bir hücrenin zaman zaman biraz negatife düşebileceği anlamına geliyor; bu zararsız ve geri okumada sınırlandırılıyor. CPU sürümü her hücre için bir fırça tablosunu önceden hesaplıyor, ancak ${1001}^2$ boyutundaki bir ızgarada bu tablo yaklaşık 100 MB tutuyor. Bu yüzden GPU uyarlaması, az miktarda ek hesaplama karşılığında büyük miktarda bellek tasarrufu yapmak için her damlanın fırçasını anında yeniden hesaplıyor. Damla başlangıç konumları, çalıştırmaların deterministik kalması için hâlâ CPU'daki bir Mulberry32 üretecinden geliyor.

İki ek geçiş, aşınmış araziyi okunabilir bir haritaya dönüştürüyor. Drenaj, Red Blob D8 akış birikimi yöntemini kullanıyor: her hücreye bir birim yağmur bırakıyor, tüm hücreleri yükseltiye göre azalan sırada diziyor ve her hücrenin biriken suyunu tek en alçak komşusuna aktarıyorsunuz. Böylece su doğal vadiler boyunca birikiyor ve birikimi belirli bir eşiği aşan her hücre nehir olarak işaretleniyor. Ancak aşınmış bir yükseklik haritasında çukurlar, yani yokuş aşağı çıkışı olmayan yerel çöküntüler bulunur. Bir çukura giren su orada durur ve birikim zincirini bozar. Bu nedenle drenaj çalıştırılmadan önce Planchon-Darboux çukur doldurma yöntemi, her çukuru en alçak komşusunun hemen üzerine, $\text{minNeighbour}+ϵ$ seviyesine yükseltiyor ve her hücrenin suyu tahliye edebileceği bir yer oluşana kadar yirmiden az geçişle yineliyor. Son olarak biyomlar Red Blob yöntemiyle, yükselti ve nem üzerinden iki eksenli bir aramayla atanıyor. Böylece yüksek ve kuru bir hücre kayaya, alçak ve ıslak bir hücre bataklığa dönüşüyor. Buna eğimi hesaba katan geçersiz kılmalar ekleniyor: dik yüzeyler nemden bağımsız olarak kayaya zorlanıyor, su çizgisi şeridi plaja dönüşüyor ve en yüksek bölgeler karla kaplanıyor. Sonuç, iki gürültü tohumundan uçtan uca üretilmiş ve tek bakışta okunabilen bir ada.

Tekrarlamayı bırakmayan döşeme

Spike 55'i yeni sekmede aç ↗ · Kaynak kodunu görüntüle

Bir arazinin, yalnızca birkaç metre genişliğindeki bir dokuyla kilometrelerce alanı kaplayan bir malzemeye ihtiyacı vardır. Bir döşemeyi zemini kaplayacak biçimde ölçeklediğiniz anda göz, tekrarı fark eder. Spike 55, aynı geometri ve ışıklandırma üzerinde dört örnekleme modunu karşılaştıran bir A/B test düzeneği; dolayısıyla tek değişken dokunun nasıl okunduğu. Temel yöntem plain: ölçeklenmiş UV'den tek bir örnek alıyor, birkaç metrede bir açıkça tekrarlanıyor ve yalnızca aşılması gereken referans olarak bulunuyor. Ücretsiz PBR katmanları Poly Haven'ın CDN'inden geliyor: dağınık renk, paketlenmiş ARM haritası (ortam perdeleme, pürüzlülük, metallik) ve GL normal haritası. Tümü CC0 lisanslı ve anizotropi 8 ile mipmap'ler kullanılarak yükleniyor.

İlginç olan diğer üçü, tekrara farklı biçimlerde saldırıyor. hex-linear modu, Heitz-Neyret üçgen ızgarasıdır: yüzeyin üzerine eğriltilmiş üçgen bir kafes yerleştiriliyor ve her parça, üç köşesinin her birinin rastgele kaydırılmış bir örnek aldığı tek bir üçgenin içinde bulunuyor. Örnekler barisentrik ağırlıklarla harmanlanıyor; böylece komşu bölgeler dokunun farklı kısımlarını örnekliyor ve büyük ölçekli döşeme görünümü dağılıyor. Ancak üç örneğin düz doğrusal harmanı, üçgen kenarlarında renklerinin ortalamasını alıyor. Bu da görünür bir üçgen deseni bırakıyor; Spike 48'in karşılaştığı kusurun aynısı. hex-vp modu, aynı 2018 makalesinde yayımlanan çözüm: barisentrik toplamdan sonra dokunun ortalama rengini çıkarıyor, varyansı sabit tutmak için karesi alınmış ağırlıklar toplamının ters kareköküyle yeniden ölçekliyor ve ardından ortalamayı geri ekliyor. Bu yöntem harman boyunca kontrastı sabit tutarak üçgenleri ortadan kaldırıyor. Bu nedenle malzeme, başlangıçta ortalama rengini tahmin etmek için yüklenen her dokudan 1'e 1 bir geri okuma yapıyor. Dördüncü mod iq-untiled, Inigo Quilez'in Texture Repetition tekniği 3: düşük frekanslı bir varyasyon deseniyle harmanlanan iki kaydırılmış örnek; üç yerine yalnızca iki örnek kullanıyor ve en başta üçgen yapısı içermiyor. Dayanıklılığını koruyan ucuz seçenek bu.

Her modun üzerinde isteğe bağlı triplanar projeksiyon bulunuyor; aynı malzemenin gerilmeden bir uçurumu kaplamasını sağlayan da bu. Gölgelendirici, tek bir UV yerine üç dünya ekseni projeksiyonunu örnekliyor: X'e bakan yüzeyler YZ düzlemini, Y'ye bakanlar ZX'i, Z'ye bakanlar XY'yi okuyor. Ardından bunları, 45 derecelik bir eğimin üç projeksiyonu da bulanık bir karışıma dönüştürmemesi için abs(normalWorld) değerini dört ile sekiz arasında bir keskinleştirme kuvvetine yükselterek harmanlıyor. Test düzeneği ödünleşimi açıkça gösteriyor: varyansı koruyan altıgen harman kalite açısından kazanırken, Quilez'in iki örnekli yöntemi performansı gözeten seçenek oluyor. İkisi de düz yöntemi o kadar büyük farkla geçiyor ki hiçbir içerik üreticisi düz döşemeyi yayımlamamalı.

Bu bölümde başvurulan teknolojiler

Tariflerin üst üste uygulandığı yükseklik haritası üretimi. Red Blob Games tarifleri, ham gürültüyü araziye dönüştürmek için işlemleri birleştiriyor: organik sırtlar için alan bükmeli FBM ($p^{\prime }=p+\text{noise}(p)\cdot s$), düz vadiler ve keskin zirveler için $e^k$ yeniden dağıtımı ve kenarları okyanusa indirip bir ada oluşturmak için $1-d$ yönünde harmanlanan Öklid tabanlı radyal düşüş. İkinci gürültü alanı, biyom atamasında kullanılan nem haritasıdır. Bkz. peyzaj üretimi.

CPU ve GPU'da hidrolik erozyon. Sebastian Lague'ın damla modeli (atalet, taşıma kapasitesi, önceden hesaplanan dairesel birikim fırçası ve buharlaşma), gürültünün taklit edemeyeceği gerçek drenaj kanalları açıyor. WebGPU hesaplama uyarlaması, damlaların aynı hücre üzerinde paralel biçimde atomicAdd/atomicSub kullanabilmesi için yükseklikleri bir milyon ölçekli sabit noktalı i32 değerleri olarak saklıyor; ${1001}^2$ boyutunda yaklaşık 100 MB'lık bir tablodan kaçınmak için her damlanın fırçasını anında yeniden hesaplıyor ve başlangıç konumlarını deterministik bir Mulberry32 üretecinden alıyor.

Çukur doldurmalı D8 drenajı. Red Blob D8 akış birikimi, her hücreye bir birim yağmur bırakıyor, hücreleri azalan yükseltiye göre sıralıyor ve suyu her hücrenin en alçak komşusuna geçirerek eşiğin üzerindeki birikimleri nehir olarak işaretliyor. Planchon-Darboux çukur doldurma yöntemi önce her yerel çöküntüyü $\text{minNeighbour}+ϵ$ seviyesine yükseltiyor (yirmiden az geçişle yineleyerek); böylece su hiçbir zaman hapsolmuyor ve birikim bağlantılı kalıyor. Yükselti ve neme göre iki eksenli bir arama biyomları atarken, eğim geçersiz kılmaları uçurumları kayaya, su çizgisini plaja ve zirveleri kara zorluyor.

Doku döşemesini dört farklı yöntemle kırmak. Aynı geometri ve ışıklandırma üzerinde: plain (tek örnek, açıkça tekrarlanıyor), hex-linear (Heitz-Neyret üçgen ızgarası; doğrusal harman bir üçgen deseni bırakıyor), hex-vp (ortalamayı çıkaran, karesi alınmış ağırlıkların ters kareköküyle yeniden ölçekleyen ve ortalamayı geri ekleyen EGSR 2018 §3.3 varyans koruma çözümü; her doku için 1×1 ortalama geri okuması gerekiyor) ve iq-untiled (Inigo Quilez'in iki örnekli tekniği 3). Triplanar projeksiyon, uçurumların gerilmemesi için üç dünya ekseni düzlemini abs(normalWorld) değerinin 4-8 arasındaki bir kuvvetiyle harmanlayarak örnekliyor. Varyansı koruyan yöntem kalitede, iki örnekli yöntem maliyette kazanıyor. Bkz. arazi malzemeleri.

29 bölümün 27.'si. Önceki: Bölüm 26 - Su yapmanın üç yolu Sonraki: Bölüm 28 - Ufka kadar uzanan çimenler ve kendini gizleyen zemin Seri rehberi: /blog/2026-02-25-open-world-browser-series-guide

Cinevva CTO'su ve Kurucu Ortağı Oleg Sidorkin tarafından

Burada yeni misiniz? Seri rehberini kullanın. Rehber, spike'ın ne olduğunu açıklıyor ve tüm bölümlere bağlantı veriyor.

Bölüm 25 avatarlara kıyafet giydirdi. Bu bölüm suyla ilgili ve üç spike'tan oluşuyor; çünkü su, ucuz bir kestirme yol ile doğru çözümün ekran görüntüsünde aynı, hareket hâlindeyken ise tamamen farklı göründüğü yüzeydir. Spike 51, cazip seçenek olan ekran alanı yöntemiyle yansımayı oluşturuyor ve doğrudan bu yöntemin yapısal sınırlamasına çarpıyor. Spike 52, yayımlanmış her oyunun gerçekte kullandığı yönteme geçiyor. Spike 53 ise “tamamlanmış” bir çözümün bizim bulunduğumuz noktadan ne kadar uzakta olduğunu görmek için hazır bir su kütüphanesini devreye alıyor. Üçü de aynı kırılma katmanını paylaşıyor; dolayısıyla ilk ikisi arasında değişen tek değişken, yansımanın nasıl hesaplandığı.

Elinizdeki ekrandan yansıma üretmek

Spike 51'i yeni sekmede aç ↗ · Kaynak kodunu görüntüle

Ekran alanı yansıması, daha önce işlediğiniz kareyi yeniden kullanır. Her su pikseli için görüş ışınını yüzeyden yansıtır, bu yansıyan ışını derinlik tamponu boyunca ilerletir ve ışın kaydedilmiş bir yüzeyin arkasına geçtiğinde suyun neyi yansıttığını bulursunuz; örnek doğrudan renk tamponundan alınır. Port, three.js'in SSRNode uygulamasını satır satır izliyor; o da lettier'in SSR giriş yazısını temel alıyor. İlerleme, ekran alanında yapılan bir DDA yürüyüşüdür: Işının başlangıcını ve sonunu piksel koordinatlarına yansıtıp daha uzun olan eksen boyunca, piksel başına bir örnek alarak ilerlersiniz. Her adımdaki yansımış ışın derinliği, perspektif düzeltmeli enterpolasyon gerektirir: $\frac{1}{1/z_0+s(1/z_1-1/z_0)}$. Çünkü görünüm-Z değerini doğrusal olarak enterpole etmek düpedüz yanlıştır ve isabetlerin yanlış yerde oluşmasına yol açar.

İki şey bunu bir slayt gösterisi yerine kullanılabilir hâle getiriyor. Kaba ilerleme 64 adımla sınırlandırılıyor; aksi takdirde bin piksele yayılan uzun bir ışın, parça başına yüzlerce yineleme çalıştırır ve milyon parçalı bir su düzlemi, yüzlerce yineleme ve her yinelemede birkaç doku örneğiyle sahneyi 30 fps'ye düşürürdü. Kalite, yineleme sayısı yerine bu sınır içindeki etkili adım aralığını kontrol ediyor. Sınırlandırılmış kaba ilerleme gözle görülür basamaklı şeritler bıraktığı için, altı yinelemeli ikili hassaslaştırma son ıskalama ile isabet arasındaki aralığı ikiye bölüyor. Bu, 64 kat alt adım doğruluğu sağlayarak komşu su parçalarının aynı kaba isabet konumuna kilitlenmesini önlemeye yetiyor. Son bir noktadan doğruya uzaklık denetimi, adayın yalnızca aynı derinlikte bulunmak yerine gerçekten yansıma ışını üzerinde olduğunu doğruluyor. Bunun için, o derinlikteki tek pikselin görünüm alanındaki genişliğine göre otomatik ölçeklenen bir kalınlık toleransı kullanılıyor: yakında daha sıkı, uzakta daha gevşek.

Bu spike'ın dürüst yanı kendi yorumlarına yazılmış durumda: SSR, ana kameranın hiç örneklemediği bir şeyi yansıtamaz. Bir ağacın alt yüzü, ekran dışındaki veya başka bir nesne tarafından kapatılmış herhangi bir şey tamponlarda mevcut değildir; dolayısıyla yansımada da görünemez. Hiçbir ilerleme kalitesinin gideremeyeceği “yanlış taraftaki bilgi kaybı” budur ve bir sonraki spike'ın varlık nedeni de tam olarak budur.

Yalan söyleyemeyen ayna

Spike 52'yi yeni sekmede aç ↗ · Kaynak kodunu görüntüle

Düzlemsel yansıma, sahneyi su düzlemine göre aynalanmış bir kameradan ikinci kez ekran dışı bir hedefe işler ve su gölgelendiricisi bu hedeften örnek alır. Bu, standart yaklaşımdır; UE5 Water, three.js'in kendi WaterMesh bileşeni, ABZÛ ve Sea of Thieves'in tümü bunu kullanır. Çünkü SSR'ın asla göremeyeceği geometri dâhil, sahnenin çizilebilecek her pikseline erişir. TSL'de neredeyse şaşırtıcı derecede basittir: reflector() aynalanmış yardımcı kamerayı ve onun işleme hedefini ayırır, her karede güncellenmesi için hedefini mesh'e eklersiniz ve rengini örneklersiniz. Dalgalar daha sonra eklendiğinde yansıma, yansıtıcının UV düğümüne bir bozulma ofseti eklenerek dalgalandırılır; bu, WaterMesh tarafından kullanılan satırın aynısıdır.

Kayda değer hata aynada değil, güvenlik ağındaydı. Önceki bir sürüm, sıfıra yakın bir yansımanın hedefte hiçbir şey bulunmadığı anlamına geldiği varsayımıyla yansıtıcının çıktısını, yansıyan rengin büyüklüğüne göre ağırlıklandırarak yedek bir prosedürel gökyüzüyle harmanlıyordu. Ancak koyu bir gölgelik gölgesinin büyüklüğü de düşüktür; bu nedenle sınırlama hiçbir zaman tam güce ulaşmıyor ve gerçekten koyu olan bu pikseller parlak gökyüzüyle karışıyordu. Kullanıcının fark ettiği belirti çok netti: Hata ayıklama modundaki ham ayna hedefi kusursuz koyu ağaçlar gösterirken birleştirilmiş görüntüde yansımalar soluk görünüyordu ve teşhis, gölgelendiricinin “koyu renkleri yok ettiği” yönündeydi. Çözüm, kodu silmekti. Yansıtıcı hedefi ilk kareden sonra güvenilirdir; dolayısıyla hiçbir yedeğe gerek yoktur. Her iki spike da altta aynı kırılmayı paylaşır: Yüzeyin arkasındaki sahne örneklenir, her pikselin su çizgisinin ne kadar altında olduğu yeniden oluşturulur ve kanal başına Beer-Lambert sönümlemesi uygulanır; böylece kırmızı birkaç metre içinde kaybolurken mavi kalıcı olur. Uzak düzlemdeki arka planın sislenmemesi için de bir gökyüzü maskesi kullanılır. Schlick Fresnel, suya doğrudan aşağı bakarken kırılmayı, yüzey boyunca bakarken ise yansımayı öne çıkaracak şekilde ikisini harmanlar.

Tamamlanmış bir çözüm nasıl görünür?

Spike 53'ü yeni sekmede aç ↗ · Kaynak kodunu görüntüle

Spike 53, geliştirme ile satın alma arasındaki tercihi sınayan bir çalışmadır. threejs-water-pro kütüphanesini yayımlandığı hâliyle; tropikal ön ayarı, varsayılan okyanus clipmap'i, kamera takibi ve Rayleigh gökyüzüyle birlikte devreye alır ve kütüphanenin kendi demosunda kullanılan ada glTF'sini yükler. Amaç, elle yazılmış düz su gölgelendiricisi ile eksiksiz bir okyanus sistemi arasındaki farkı görmektir ve bu fark büyüktür: Bu sistem, geminin yalnızca yukarı aşağı sallanmak yerine baş-kıç ve yana yatması için gövdenin altındaki birkaç noktadan dalga yüksekliğini örnekleyen bir yüzdürme sistemine, dümen suyu üreticisine, kıyı ve yüzey köpüğüne ve dalgaların güvertenin içinden görünmesini önlemek amacıyla gemi gövdesinin içinde su işlenmesini engelleyen bir maske geçişine sahiptir.

Entegrasyon sırasında, yalnızca README dosyasını okumak yerine kütüphaneyi gerçekten kullanarak öğrenebileceğiniz türden ayrıntılar ortaya çıktı. Köpük dokularına ön ayarda dosya adlarıyla başvuruluyor ancak onları yüklemek tüketicinin görevi; bu dokular olmadan kıyı, parçalanan dalgalar yerine sert bir su çizgisi kenarı gibi görünüyor. Ada, su altındaki geometrisi okyanus tabanının altına inecek şekilde konumlandırılmıştır; böylece kütüphanenin taban mesh'i, modelin dış halkasını görünür bir düzlem kenarı bırakmadan örter. Kütüphanenin amaçladığı yaklaşım budur: Araziyi prosedürel olarak üretmeyin, bir 3B model getirin. Ayrıca kenar yumuşatma, işleme motorunda bilinçli olarak kapatılıp bunun yerine son işleme FXAA geçişi kullanılıyor. Çünkü MSAA, derinlik duyarlı atmosferik sis çalışmadan önce kenar parçalarını arka planla harmanlayarak geometrinin sisle buluştuğu her yerde ince, koyu bir saçak bırakıyor. Kenar yumuşatmayı sisten önce değil, sonra çözmek bu saçağı ortadan kaldırıyor. Bunun riski azalttığı asıl konu kararın kendisidir: Üretime hazır bir okyanus büyük ve uzmanlık gerektiren bir sistemdir. Böyle bir sisteme ihtiyaç duyduğumuz durumlarda bakımı yapılan bir kütüphaneyi benimsemek; dümen suyunu, yüzdürmeyi ve köpüğü sıfırdan yeniden oluşturmaktan daha iyidir. Spike 52'deki düzlemsel ayna gölgelendiricisi ise içerik üreticisinin kendi dünyasına yerleştirdiği daha küçük iç su kütleleri için doğru çözüm olmaya devam eder.

Bu bölümde değinilen teknolojiler

Ekran alanı yansımalı su. Yansıtılmış bir görüş ışını, perspektif düzeltmeli 1/z enterpolasyonu, parça başına maliyeti sınırlayan katı bir adım sınırı ve sınırlı ilerlemenin bıraktığı şeritlenmeyi kaldıran ikili hassaslaştırma geçişi kullanarak DDA aracılığıyla ekran alanındaki derinlik tamponunda ilerler. Derinliğe göre ölçeklenen kalınlıkla yapılan noktadan doğruya doğrulama, yanlış isabetleri eler. Yöntemin kesin sınırı, yalnızca ana kameranın daha önce örneklediği geometriyi yansıtabilmesidir; dolayısıyla ekran dışındaki ve yanlış taraftaki yüzeyler hiçbir zaman görünmez. Bkz. arazi malzemeleri.

Düzlemsel ayna yansıması. Su düzlemine göre aynalanmış yardımcı bir kamera, sahneyi su gölgelendiricisinin örneklediği ekran dışı bir hedefe işler. Böylece SSR'ın göremediği geometriler dâhil piksel düzeyinde kusursuz yansımalar sağlanır. UE5 Water ve three.js WaterMesh, dalga bozulmasını yansıtıcının UV düğümüne ofset olarak uygulayarak bu yaklaşımı kullanır. Renk büyüklüğüne göre ağırlıklandırılmış gökyüzü yedeği, koyu yansıma piksellerini hatalı biçimde yok ediyordu; yansıtıcı hedefi ilk kareden sonra güvenilir olduğundan çözüm, yedeği kaldırmaktı.

Beer-Lambert derinlik tonlu kırılma. Her iki gölgelendirici de yüzeyin arkasındaki sahneyi örnekler, arka plandaki her pikselin su çizgisinin altındaki derinliğini yeniden oluşturur ve kanal başına üstel sönümleme uygular; kırmızı metreler içinde kaybolurken mavi kalıcı olur ve sonuç bir su sisi rengine doğru birleştirilir. Uzak düzlemin sislenmemesi için de bir gökyüzü maskesi kullanılır. Schlick Fresnel, dik geliş açısındaki kırılmayı sıyırma açılarındaki yansımayla harmanlar.

Üretime hazır bir su kütüphanesini benimsemek. threejs-water-pro; okyanus clipmap'i, Rayleigh gökyüzü, geminin baş-kıç ve yana yatması için çok noktalı yüzdürme, dümen suyu, köpük ve gövde maskesi geçişi sunar. Tüketici tarafındaki ayrıntılar önemlidir: Köpük dokuları açıkça yüklenmeli, adanın su altındaki geometrisi okyanus tabanının altına inerek tabanın kenarları örtmesini sağlamalı ve geometri kenarlarında koyu bir sis saçağı oluşmasını önlemek için kenar yumuşatma MSAA yerine son işleme FXAA geçişi olarak çalıştırılmalıdır.

29 bölümün 26.'sı. Önceki: Bölüm 25 - Tek iskelet, her kıyafet Sonraki: Bölüm 27 - Gürültüden bir ada, zemine benzeyen zemin Seri rehberi: /tr/blog/2026-02-25-open-world-browser-series-guide

Cinevva CTO'su ve Kurucu Ortağı Oleg Sidorkin tarafından

Bir orman, GPU'dan render etmesini isteyebileceğiniz en zorlu şeylerden biridir. Her yaprak, alfa maskesiyle kesilmiş dokulu bir dörtgendir. Her görüş ışını boyunca bu dörtgenlerden onlarcası üst üste biner. Rasterleştiricinin hangi fragment'lerin alfa testini geçeceğini önceden bilmesinin bir yolu yoktur; dolayısıyla opak sahneleri kurtaran standart early-Z optimizasyonu büyük ölçüde devre dışı kalır. Bunun sonucunda tek bir ekran pikseli, kare tamamlanmadan önce tam yaprak shader'ını 10 veya 15 kez çalıştırabilir. Bitki örtüsü overdraw'u budur ve son on yılda yayımlanan tüm açık dünya oyunlarında bir karenin en pahalı kısmıdır.

İyi haber şu ki bu, çözülmüş bir problemdir. Birinin tek bir numarayla sorunu ortadan kaldırması anlamında değil; yedi veya sekiz tekniğin bir araya gelerek yoğun bir ormandaki efektif overdraw'u 8-15 kattan 1-2 kata düşürmesi anlamında. Her modern motor bu teknikler bütününün bir sürümünü kullanır. Şimdi bunun neler içerdiğine, her parçanın neden var olduğuna ve her biri için temel kaynaklara bakalım.

1. Bitki örtüsü overdraw'u neden bu kadar maliyetli?

Tipik bir opak sahnede GPU, erken derinlik reddi uygular: piksel shader'ı daha çalışmadan donanım mevcut derinlik tamponunu kontrol eder ve zaten başka bir şeyin arkasında kalan fragment'leri atlar. Bunun maliyeti neredeyse yoktur ve yoğun geometrinin maliyetini makul düzeyde tutan şey de budur.

Alfa testli bitki örtüsü bunu bozar. Fragment shader'ın alfa dokusunu değerlendirmek ve maskeyle dışarıda bırakılan pikseller için discard (veya clip) çağırmak üzere gerçekten çalışması gerekir. Donanım, shader çalışana kadar bir fragment'in elenip elenmeyeceğini bilemez; bu nedenle çoğu GPU'da shader'ın herhangi bir yerinde discard kullanılması, ilgili draw call için early-Z'yi tamamen devre dışı bırakır. Tile tabanlı GPU'larda (mobil, M serisi, bazı konsollar) tüm kare için Hi-Z'yi ve derinlik sıkıştırmasını devre dışı bırakabilir. Piksel shader'ı, bir pikseli kaplayan her üçgen için bir kez çalışır ve bu değerlendirmelerin çoğu discard ile sonuçlanır.

Tek bir ekran pikselinin önüne 10 yaprak dörtgeni yerleştirdiğinizde yaprak shader'ı 10 kez çalışır. Bunu 4 milyon pikselle çarpınca maliyet korkunç hâle gelir. Marco Salvi'nin Early-Z Kullanmalı mı, Kullanmamalı mı? başlıklı yazısı, bunun donanım düzeyinde neden gerçekleştiğini en anlaşılır şekilde ele alan kaynaklardan biridir ve konuyu daha önce hiç düşünmediyseniz başlamak için doğru yerdir.

2. Maskeli geometri için derinlik ön geçişi

Tek başına en büyük kazanımı sağlayan ve her modern motorun kullandığı teknik, bitki örtüsü çizimini iki geçişe ayırmaktır. İlk geçiş yalnızca derinlik yazar; alfa testini yapan, maskelenmiş pikselleri atan ve başka hiçbir şey yazmayan minimal bir shader kullanır. İkinci geçiş, derinlik testi "equal" olarak ve derinlik yazımı kapalı şekilde tam materyali render eder. Böylece her görünür piksel, arkasında kaç yaprak dörtgeni üst üste binmiş olursa olsun tam BRDF'yi tam olarak bir kez hesaplar.

Aynı üçgenlere iki kez dokunulduğu için bu, iki kat iş gibi gelebilir. Ancak ön geçiş shader'ı o kadar ucuzdur ki (bir doku örneği, bir discard, bir derinlik yazımı), ana geçişteki tasarruf ek maliyeti fazlasıyla aşar. Yoğun bir ormanda ana geçiş, tam yaprak shader'ını piksel başına 10-15 kez çalıştırmak yerine tam olarak bir kez çalıştırır.

Unreal, Frostbite, Decima ile modern Rage ve Dunia dallarının tümü bunu yapar. Bu aynı zamanda maskeli materyallerin bu motorların hepsinde hâlâ yarı saydam materyallerden daha ucuz olmasının temel nedenidir.

Derinlemesine kaynaklar:

• Pettineo, Early-Z Kullanmalı mı, Kullanmamalı mı? (discard ile Hi-Z ve early-Z arasındaki etkileşimi açıklayan temel kaynak).
• Wihlidal, Compute ile Grafik İşlem Hattını Optimize Etmek (GDC 2016, Frostbite'ın derinlik ön geçişi ve ön geçiş güdümlü ayıklama mimarisi).
• Sanders, Teknoloji ile Sanat Arasında: Horizon Zero Dawn'ın Bitki Örtüsü (GDC 2018, Decima'nın iki geçişli bitki örtüsü render sistemiyle birlikte).
• Persson, Z Hakkında Birkaç Not (depth-equal testi ve ön geçiş ekonomisini hâlâ en net açıklayan kaynaklardan biri).

3. Agresif LOD'lar ve oktahedral imposter'lar

İkinci en büyük kazanım, gerekmediğinde yaprakları hiç çizmemektir. Bitki örtüsü varlıkları birkaç LOD kademesiyle gelir. En yakındaki kademe, ayrı yaprak kartları içeren tam mesh'tir. Orta mesafede yapraklar daha yoğun birleşik kartlara dönüştürülür (30 yapraktan oluşan bir küme, aynı silüete sahip tek bir dokulu karta dönüşür). Belirli bir mesafe eşiğinin ötesinde ağacın tamamı bir imposter'a dönüşür: ağacın birçok açıdan önceden render edilmiş görüntüleriyle dokulanan küçük bir geometri parçası.

Modern imposter biçimi oktahedral imposter'dır: oktahedral eşleme kullanılarak bir küre üzerindeki noktalardan yakalanan görüntü atlasıyla dokulanmış, 8 yüzlü bir geometri parçası. Çalışma zamanında shader, kamera yönüne göre önceden render edilmiş en yakın iki veya üç görünümü seçer ve bunlar arasında geçiş yapar. Sonuç, her açıdan 3B görünen ve düzgün gölgelendirme, normal map'ler, hatta rüzgâr animasyonu sunabilen, yalnızca birkaç üçgenden oluşan bir temsildir. Başlangıçta topluluk eklentisi olan ve artık Unreal'ın bir parçası hâline gelen Ryan Brucks uygulaması, bu konudaki temel referanstır. Microsoft Flight Simulator'ın milyarlarca ağaçtan oluşan ormanları, kamera yakını dışında esasen tamamen oktahedral imposter'lardan oluşur.

Daha büyük yapısal kazanım, imposter'ların uzaktan opak veya opaklığa yakın olmasıdır. 30 yapraklı birleşik kart, 30 dörtgen yerine tek bir maskeli dörtgendir. Tüm ağacı temsil eden imposter, binlerce yüz yerine yalnızca birkaç yüzden oluşur. Uzak alan overdraw'u neredeyse sıfıra iner.

Derinlemesine kaynaklar:

• Brucks, Oktahedral Imposter'lar (matematiği ve UE uygulamasıyla birlikte temel kaynak).
• Halen, Unreal Engine'de Oktahedral Imposter'lar (entegre UE iş akışı).
• Häggström, Bitki Örtüsünün Gerçek Zamanlı Render Edilmesi (LOD zincirlerini, imposter'ları ve bunların arkasındaki matematiği ele alan anlaşılır bir tez).
• Crytek, CryEngine 3'te SpeedTree Entegrasyonu (GPU Gems 3, ağaç LOD zincirleri için hâlâ en iyi giriş kaynaklarından biri).

4. Küme ve GPU güdümlü ayıklama

Derinlik ön geçişi kullanılsa bile ön geçişin kendisi maliyetlidir: görünür veya görünür olma ihtimali bulunan her ağacın her üçgenine yine de dokunması gerekir. Modern motorlar, rasterleştiriciye ulaşmadan önce üçgen gruplarının tamamını atan GPU güdümlü küme ayıklama ile bu maliyeti azaltır.

İşlem hattı şu şekilde işler: her mesh önceden, sıkı bir sınırlayıcı kutuya ve normal konisine sahip 64 veya 128 üçgenlik kümelere ayrılır. Render sırasında bir compute shader örnek listesini dolaşır, her örneği görüş hacmi testinden geçirir, ardından görünür her örneğin tüm kümelerini görüş hacmi testinden geçirir ve son olarak hayatta kalan her kümeyi önceki karenin derinlik piramidine karşı Hi-Z örtülme testine tabi tutar. Bir tepenin veya başka bir ağacın arkasında kalan tüm ağaç dalları, herhangi bir vertex shader çalışmadan önce ayıklanır. Çıktı, doğrudan tek bir DrawIndirect çağrısına aktarılan kompakt bir "bu kümeleri çiz" argümanları listesidir.

10.000 ağaçlık bir ormanın saniyeler yerine milisaniyeler içinde render edilmesini sağlayan şey budur. Ubisoft'un Assassin's Creed Unity sunumu bu işlem hattını üretimde kullanılan biçimiyle tanıttı (üçgenlerin %20-40'ı, gölge üçgenlerinin %30-80'i ayıklanıyor ve önceki nesle göre ekranda 10 kat daha fazla örnek gösteriliyor); Wihlidal'ın Frostbite sunumuysa bunu daha ileri taşıdı. UE5 Nanite bu gelişim çizgisinin görünür son noktasıdır: piksel düzeyine kadar küme ayıklama.

Derinlemesine kaynaklar:

• Haar ve Aaltonen, GPU Güdümlü Render İşlem Hatları (SIGGRAPH 2015, temel niteliğindeki Assassin's Creed Unity sunumu).
• Wihlidal, Compute ile Grafik İşlem Hattını Optimize Etmek (GDC 2016, Frostbite'ın GPU güdümlü ön geçişi).
• Karis, Stubbe, Wihlidal, Nanite Sanallaştırılmış Geometriye Derinlemesine Bakış (SIGGRAPH 2021, meshlet ayrıntı düzeyinde küme ayıklama).
• Liktor, Activision'da Geometri Render İşlem Hattı Mimarisi (Call of Duty'nin küme ayıklama sürümü, 2021).

5. Önden arkaya örnek ve küme sıralama

Ön geçiş görevini yerine getirmeye başladığında sıralama önem kazanır. Ön geçiş derinlik yazar, ancak yalnızca alfa testini geçen fragment'ler için. Önce ormanın arkasını, en son da önünü çizerseniz öndeki her fragment arkadaki bir fragment'in üzerine yazılır ve ön geçiş shader'ı arkadakiler için yine çalışır. Önden arkaya doğru çizerseniz birbirini izleyen her çizim, derinlik tamponunun daha büyük bir bölümünü daha küçük değerlerle doldurur; böylece Hi-Z, arkadaki fragment'lerin giderek daha fazlasını shader çalışmadan önce reddeder.

Bu nedenle neredeyse tüm modern motorlar ön geçişi başlatmadan önce bitki örtüsü örneklerini kameraya olan mesafelerine göre sıralar. Sıralama ucuzdur (GPU'da radix sort ile birkaç yüz bin örnek) ve ön geçişin kendisini, kendi yükünü azaltan bir işleme dönüştürür. Küme düzeyindeki ayıklama da aynı nedenle meshlet ayrıntı düzeyinde sıralama yapar. Derinlik ön geçişi ile önden arkaya sıralama, tek başlarına iyi ama birlikte harika olan teknik çiftlerindendir.

Derinlemesine kaynaklar:

• Persson, Derinliğin Derinliklerine (derinlik tamponu sıralaması, ön geçiş ekonomisi ve Hi-Z davranışı üzerine mimari notlar).
• Giesen, Grafik İşlem Hattında Bir Yolculuk (Hi-Z reddetme oranının çizim sırasına nasıl bağlı olduğunu ayrıntılı biçimde açıklayan teknik kaynak).
• Wihlidal, Compute ile Grafik İşlem Hattını Optimize Etmek (GDC 2016, Frostbite'ın GPU tarafındaki örnek sıralamasını içerir).

6. Dither uygulanmış LOD geçişleri ve hash'lenmiş alfa

Diğer büyük tuzak ise soldurmadır. İki LOD arasında geçiş yapmanın veya kamera yaklaşırken bir örneği görünür ya da görünmez hâle getirmenin basit yolu alfa harmanlamadır. Ancak harmanlanmış geometri derinlik tamponuna yazamaz; bu da soldurulan her ağacı yavaş yarı saydamlık yoluna sokar ve ön geçişi bozar. Çözüm, geometriyi maskeli yolda tutmak ve soldurmayı alfa testinin içinde gerçekleştirmektir.

İki ana teknik vardır:

• Dither uygulanmış LOD geçişleri, 4x4 veya 8x8 Bayer deseni (ya da ekran uzayında bir blue-noise dokusu) örnekler ve bunu piksel başına kesme eşiği değiştiricisi olarak kullanır. %50 geçişteki bir ağacın dama tahtası desenindeki pikselleri hayatta kalır; eksik pikseller bir sonraki LOD'un tamamlayıcı dama tahtası deseniyle doldurulur. TAA, dama tahtası desenini iki veya üç kare içinde yumuşak bir geçişe dönüştürür. Ucuz ve kararlıdır; motordaki diğer her şeyle uyumlu biçimde harmanlanır.
• Hash'lenmiş alfa testi (Wyman & McGuire, I3D 2017), sabit 0,5 alfa eşiğini [0,1) aralığında piksel başına hash'lenmiş bir eşikle değiştirir. Normalde tamamen kaybolacak uzak alfa geometrisi (mipmap uygulanmış alfa 0,5'in altına düştüğü için), hayatta kalan piksellerden oluşan kararlı bir dağılımı korur. Temizleme işini yine TAA yapar.

Her iki teknik de bitki örtüsünü, derinlik ön geçişinin çalıştığı opak/maskeli yolda tutar; böylece yalnızca bir şeyi soldurmak için yarı saydam render işleminin tüm maliyetini ödemezsiniz. Alpha to coverage, aynı fikrin MSAA döneminden kalma akrabasıdır: alfayı alt piksel kapsam maskesine dönüştürür ve maskeli yoldan çıkmadan kısmi saydamlık sağlar. Ancak A2C yalnızca MSAA ile gerçek anlamda parlar ve çoğu modern deferred renderer artık MSAA kullanmaz.

Derinlemesine kaynaklar:

• Wyman ve McGuire, Hash'lenmiş Alfa Testi (I3D 2017, hash'lenmiş alfa üzerine temel makale).
• Castaño, Alfa Mipmap'lerini Hesaplamak (The Witness blogu, uzaktaki ağaçların kaybolmaması için alfa testli dokulara mipmap uygulamanın doğru yolu).
• Yuksel, Alfa Testi için Alfa Dağılımı (alfa mipmap'leri üzerine daha yeni bir iyileştirme).
• NVIDIA, Kenar Yumuşatmalı Alfa Testi (A2C, hash'lenmiş alfa ve dither uygulanmış alternatiflere genel bakış).

7. Maskeli piksellerde gölgelendirme maliyetini azaltmak

Kusursuz bir ön geçiş ve kusursuz ayıklama kullansanız bile görünür her bitki örtüsü pikselini yine de bir kez gölgelendirmeniz gerekir. Motorlar bu maliyeti de azaltır:

• Daha ucuz BRDF. Bitki örtüsü mattır ve tam bir Cook-Torrance speküler yoluna pek ihtiyaç duymaz. Sarılmış Lambert dağılımlı difüz aydınlatma ile tek satırlık bir speküler yaklaşım fazlasıyla yeterlidir.
• Daha düşük frekanslı normal haritaları. Yapraklar zaten görsel açıdan karmaşıktır. 256x256 bir normal haritası, tipik izleme mesafelerinde 1024x1024 olanla aynı görünür ve bant genişliğinden tasarruf sağlar.
• Paralaks, anizotropi ve vernik katmanı yok. PBR özellikleri yapraklar için devre dışı bırakılır.
• Tam yüzey altı saçılımı yerine iki taraflı ince geçirgenlik. Yapraklar arkadan gelen ışığı geçirir, ancak bunu arkadan aydınlatmaya yönelik tek bir nokta çarpımıyla taklit edebilirsiniz.
• Bazı motorlarda yarı çözünürlüklü gölgelendirme. Bitki örtüsü 1/4 veya 1/2 piksel hızında gölgelendirilip üst ölçeklenir. TAA'nın stokastik gürültüsü yeniden örneklemeyi gizler.
• Maskeli malzemelerde ayrıntı dokularını ve çıkartmaları varsayılan olarak atlama.

Bunların her biri tek başına küçük bir kazanımdır. Birlikte kullanıldıklarında maskeli bitki örtüsü gölgelendiricileri, eşdeğer opak malzemeden 2-3 kat daha hızlı çalışabilir.

Ayrıntılı kaynaklar:

• Lagarde ve de Rousiers, Frostbite'ı Fizik Tabanlı İşlemeye Taşımak 3.0, bitki örtüsü ve yarı saydamlık bölümleri (SIGGRAPH 2014, iki taraflı ince malzemelere yönelik standart PBR ayarlamaları).
• Jimenez, Yeni Nesil Karakter İşleme (başlangıçta cilt için geliştirilen, ancak yapraklara yaygın biçimde uyarlanan sarılmış Lambert dağılımı ve arkadan yarı saydamlık matematiği).
• Sanders, Teknoloji ile Sanat Arasında: Horizon Zero Dawn'ın Bitki Örtüsü (GDC 2018, Decima'nın bitki örtüsü gölgelendiricisi sadeleştirmeleriyle birlikte).

8. Maskeli malzemeler için görünürlük tamponları ve Nanite

Aşırı çizime verilebilecek en temiz yanıt, gölgelendirmeyi rasterleştirmeden tamamen ayırmaktır. Görünürlük tamponu, geometriyi ince bir tampona rasterleştirir (piksel başına yalnızca üçgen kimliği ve örnek kimliği), ardından görünürlük tamponunu okuyup her pikseli tam olarak bir kez gölgelendiren ertelenmiş bir geçişte tam malzemeyi çalıştırır. Tasarım gereği gölgelendirme aşamasında aşırı çizim yoktur. Burns ve Hunt'ın 2013 tarihli makalesi bu yaklaşımı tanıttı; UE 5.5 itibarıyla maskeli bitki örtüsünü de destekleyen UE5 Nanite ise bunun üretim kalitesindeki uygulamasıdır.

Nanite'ın farkı, bunu küme düzeyinde sanallaştırılmış geometriyle yapmasıdır; böylece rasterleştiricinin kendisi alt piksel boyutundaki üçgenler için bir yazılım yolu üzerinde çalışır ve aşırı çizimi sınırlı tutar. Nanite'taki maskeli malzemeler "programlanabilir rasterleştirme" özelliğine ihtiyaç duyar: alfa testi görünürlük tamponu geçişi sırasında çalışır, ancak malzeme gölgelendirmesi ertelenmiş çözümleme aşamasında görünür piksel başına yine yalnızca bir kez yapılır. Sonuç olarak, bir zamanlar maskeli malzemelerde yavaşlığıyla bilinen çok yoğun Nanite bitki örtüsü artık opak malzemelerle rekabet edebilir, hatta onlardan daha ucuz olabilir; çünkü gölgelendirme sırasındaki aşırı çizim sıfırdır. Bunun bir ödünleşimi vardır: Maskeli yol programlanabilir rasterleştirme maliyeti eklediğinden, düşük poligonlu maskeli kartlardan oluşan ağaçları korumak yerine yüksek poligonlu opak ağaç geometrisini Nanite üzerinden geçirmek çoğu zaman daha iyidir.

Ayrıntılı kaynaklar:

• Burns ve Hunt, Görünürlük Tamponu: Ertelenmiş Gölgelendirmeye Önbellek Dostu Bir Yaklaşım (JCGT 2013, özgün makale).
• Karis, Stubbe, Wihlidal, Nanite Sanallaştırılmış Geometrisine Derinlemesine Bakış (SIGGRAPH 2021, üretim mimarisi).
• Epic, Nanite GPU Güdümlü Malzemeler (GDC 2024, maskeli malzeme ve programlanabilir rasterleştirme işlem hattıyla birlikte).
• "Nanite GPU Güdümlü Malzemeler"den Notlar (aynı sunumun üçüncü tarafça hazırlanmış anlaşılır bir incelemesi).

9. Bitki örtüsü için ayrı gölge temsilleri

Alfa testi uygulanan bitki örtüsüne yönelik gölge haritaları, geniş basamaklardan sonra herhangi bir açık dünya karesindeki en pahalı ikinci gölge problemidir. Her basamak kendi derinlik ön geçişine ihtiyaç duyar, her ön geçiş alfa testini çalıştırır ve maliyet 4 basamak ile düzinelerce ışık frustumu boyunca hızla birikir. Bu nedenle çoğu motor, bitki örtüsü gölgelerini bitki örtüsü rengini işlediği şekilde işlemez.

Yaygın alternatifler:

• Örgü mesafe alanı gölgeleri (UE Lumen, özel motorlar). Her örgü, önceden hesaplanmış bir işaretli mesafe alanına sahiptir. SDF içinden yapılan kısa bir koni izleme, alfa testi uygulanan örgüye hiç dokunmadan yumuşak bir gölge üretir. Bu yöntem özellikle ağaçlar için uygundur; çünkü SDF, taç silüetini tek bir katı kütle olarak yakalar ve yaprak başına ayrıntıları yok sayar.
• Bitki örtüsü için daha düşük çözünürlüklü basamaklar. Bitki örtüsü gölgeleri yarı çözünürlüklü bir dilime yazılır ve kenar duyarlı filtrelemeyle üst örneklenir. Gölgeler zaten yumuşak olduğundan göz çözünürlük düşüşünü fark etmez.
• MSAA ile alfadan kapsama gölge haritaları. Gölge yolunda hâlâ MSAA bulunan motorlarda A2C, tam alfa testi maliyeti olmadan yumuşak kenarlı bitki örtüsü gölgeleri sağlar.
• Gövde ve büyük dallar için kapsül gölgeleri, taç için mesafe alanı ve yalnızca en yakın basamakta tam alfa testi. Farklı mesafeler için farklı temsiller kullanılır ve bunlar aydınlatma geçişinde harmanlanır.
• WPO devre dışı bırakma mesafesi. Rüzgâr güdümlü World Position Offset, önbelleğe alınmış gölge verilerinin kareler boyunca geçerli kalması için belirli bir eşiğin ötesinde kapatılır. UE'nin Virtual Shadow Maps sistemi buna yoğun biçimde dayanır.

Ayrıntılı kaynaklar:

• Epic, Unreal Engine'de Mesafe Alanlı Yumuşak Gölgeler (örgü mesafe alanı gölgeleri için standart UE kaynağı).
• Wright, Lumen: Unreal Engine 5'te Gerçek Zamanlı Global Aydınlatma (SIGGRAPH 2022, Lumen'ın bitki örtüsüne yönelik örgü SDF entegrasyonuyla birlikte).
• Epic, Sanal Gölge Haritaları (bitki örtüsüne özgü WPO devre dışı bırakma ve önbelleğe alma kurallarıyla modern UE5 gölge mimarisi).
• Persson, Pratik Basamaklı Gölge Haritaları (alfa testi uygulanan gölge oluşturucularla ilgili notlar içeren, hâlâ standart kabul edilen CSM kaynağı).

10. Rüzgâr, animasyon ve gölge önbelleğe alma

Bununla ilişkili incelikli bir problem daha vardır: Bitki örtüsünün çoğu hareket eder. Rüzgâr güdümlü tepe noktası animasyonu (UE'de World Position Offset, Frostbite ve Decima'daki eşdeğerleri), bitki örtüsü geometrisinin kareden kareye sabit kalmaması anlamına gelir; bu da gölge önbelleğe alma ve yeniden projeksiyonu bozar. Modern motorlar bununla iki şekilde mücadele eder:

• WPO'yu mesafeye göre sınırlandırma. Belirli bir eşiğin ötesinde rüzgâr animasyonunun genliği yumuşak biçimde sıfıra iner. Göz zaten bu kadar uzaktaki sallanmayı göremez ve gölge önbellekleri geçerliliğini korur.
• Rüzgârı küme sınırlarına dahil etme. Küme sınırlayıcı kutuları, maksimum WPO ofseti kadar genişletilir; böylece her karede yeniden yükleme yapmadan ayıklama tutucu kalır.
• Örnek başına faz ofsetleri. Birbirinin aynısı ağaçlar, rüzgâr fazını kaydırmak için örnek başına rastgele bir tohum kullanır. Böylece orman, ağaç başına benzersiz animasyon maliyeti olmadan hep birlikte aynı ritimde sallanmaz.

Bu, teknik listelerinde görünmeyen ancak uygulamada 3 ms'lik bir orman ile 9 ms'lik bir orman arasındaki farkı yaratan türden bir ayrıntıdır.

Ayrıntılı kaynaklar:

• Sanders, Teknoloji ile Sanat Arasında: Horizon Zero Dawn'ın Bitki Örtüsü (GDC 2018, Decima rüzgâr animasyonu işlem hattı ve gölge önbelleğe almayla birlikte).
• McAuley, Far Cry 4 Dünyasının İşlenmesi (GDC 2015, bitki örtüsüne yönelik rüzgâr ızgarası örneklemesini içerir).
• Epic, Bitki Örtüsü ve Sanal Gölge Haritaları (WPO devre dışı bırakma mesafesi ve VSM önbelleğe alma konusunda UE5 topluluk rehberi).

11. Birleşik matematik

Bu tekniklerin hiçbiri tek başına kusursuz bir çözüm değildir. İlginç olan, bunları üst üste kullandığınızda ne olduğudur:

• Yoğun bir orman sahnesindeki basit bir maskeli bitki örtüsü geçişi, 8-15 kat etkin aşırı çizim ölçer. Görünür her piksel, yaprak gölgelendiricisini 8 ila 15 kez çalıştırır.
• Bir derinlik ön geçişi eklendiğinde ana geçiş yaklaşık 1 kat aşırı çizime iner, ancak ön geçişin kendisi hâlâ her şeye dokunur.
• Önden arkaya sıralama eklendiğinde ön geçiş kendi içeriğini ayıklamaya başlar.
• Küme düzeyinde GPU ayıklama eklendiğinde ön geçiş yalnızca görünür olma ihtimali bulunan öğelere dokunur.
• LOD zincirleri ve sahte görünümler eklendiğinde, 30 metrenin ötesindeki görünür dörtgen sayısı bir büyüklük mertebesi azalır.
• Görünürlük tamponu / Nanite yolu eklendiğinde gölgelendirme aşaması, yoğun örtüşmede bile gerçekten piksel başına bir kez çalışır.
• Mesafe alanı gölgeleri eklendiğinde gölge maliyeti artık alfa testiyle birlikte ölçeklenmez.

Yukarıda bağlantısı verilen sunumlarda tekrarlanan temel sonuç şudur: Etkin aşırı çizim 8-15 kattan 1-2 kata iner ve yoğun bir orman sahnesindeki toplam bitki örtüsü kare maliyeti 4-6 kat azalır. Modern açık dünya oyunlarının tüketici donanımlarında ormanları 60+ fps hızında işleyebilmesinin tüm nedeni budur.

12. Bunun tarayıcı için anlamı

Bu yığının büyük bölümü WebGPU'ya kolayca uyarlanabilir. Açık dünya tarayıcı motorunda GPU güdümlü ayıklama, dolaylı yürütme, Hi-Z örtülme ve önden arkaya sıralanmış ön geçişleri zaten kullanıma sunduk. Maskeli geometriye yönelik derinlik ön geçişi oldukça basittir: WebGPU, erken Z ile ilgili aynı sınırlamalarla birlikte derinlik eşitliği testini ve parça gölgelendiricilerinde discard kullanımını destekler. Oktahedral sahte görünümler doğrudan uyarlanabilir; gereken matematik yalnızca küreden oktahedrona açılım ve atlas indekslemesidir.

Daha zor olanlar modern tekniklerdir. WebGPU'da bir görünürlük tamponu, bir işleme hedefine 32 bitlik üçgen kimliği yazmayı ve malzemeleri tam ekran bir hesaplama geçişinde çözümlemeyi gerektirir; yapı taşları mevcuttur, ancak bunların düzenlenmesi zahmetlidir. Örgü mesafe alanı gölgeleri varlık başına bir 3B doku ve kısa bir koni izleme ister; bunların ikisi de WebGPU'nun kapasitesi dahilindedir. Karma tabanlı alfa ve titreşimli LOD'ların her biri yalnızca bir gölgelendirici işlevi gerektirir.

Tarayıcı tabanlı bitki örtüsü için izlenecek yol, bu yığındaki diğer her şeyle aynıdır: Önce ucuz ve sağlam parçaları (ön geçiş, sıralanmış örnekler, LOD'lar, sahte görünümler, karma tabanlı alfa) kullanıma sunup ağır mekanizmaları (görünürlük tamponu, örgü SDF gölgeleri) bunların üzerine eklemek. Tarayıcı donanımlarının alt sınırı nihayet yeterince yükseldi; dolayısıyla bir WebGPU ormanının konsoldaki gibi görünmemesi ve çalışmaması için mimari bir neden yok. Yalnızca mühendislik kaynaklı nedenler var ve biz de en çok bu tür nedenleri seviyoruz.

Yığının tamamı için ek okumalar

Tüm bunları bir araya getiren tek bir kaynak istiyorsanız SIGGRAPH'ın "Oyunlarda Gerçek Zamanlı İşlemedeki Gelişmeler" arşivinde (advances.realtimerendering.com), 2014'e kadar uzanan standart bitki örtüsü ve GPU güdümlü işleme sunumları bulunur. Adrian Courrèges'in GPU profil çıkarma makaleleri, burada ele alınan her geçişi üretimdeki sırasıyla gösteren GTA V ve Horizon Zero Dawn karelerinin tek tek incelemelerini içerir. Özellikle alfa testi matematiği için Chris Wyman'ın araştırma sayfasında referans gölgelendiricilerle birlikte karma tabanlı alfa ve stokastik şeffaflık makaleleri yer alır. Ayrıca Real-Time Rendering, 4. baskı kitabının şeffaflık, örnekleme ve derinlik işleme hakkındaki bölümleri hâlâ temel başlangıç noktasıdır.

Cinevva CTO'su ve Kurucu Ortağı Oleg Sidorkin tarafından

Burada yeni misiniz? Seri rehberine göz atın. Rehber, spike'ın ne olduğunu açıklıyor ve tüm bölümlere bağlantı veriyor.

24. Bölüm, dünyayı kalıcı hâle getirdi ve bitki örtüsüne rüzgâr ekledi. Bu bölüm yine dünyadaki insanlarla, ancak bu kez gardırop açısından ilgili: Bir içerik üreticisi temel bir vücut seçip kıyafetleri değiştirebilir, bir saç modeli belirleyebilir ve tamamen ücretsiz bir varlık paketiyle, rigleme ya da animasyon hazırlama gerektirmeden herhangi bir animasyonu oynatabilir mi? Riski azaltmak için özel bir rig oluşturmak doğru hedef değil. Yanıtlanması gereken asıl soru, bir CC0 paketinin tüm yükü taşıyıp taşıyamayacağı.

Birlikte uyumlu çalışmak üzere hazırlanmış bir paket

Spike 50'yi yeni bir sekmede aç ↗ · Kaynak kodunu görüntüle

Quaternius, neredeyse kuşku uyandıracak kadar iyi örtüşen dört varlık sunuyor: erkek ve kadın vücutlarının yanı sıra sekiz saç modeli ve iki kaş seti içeren Universal Base Characters; omuz zırhları ve kapüşon gibi aksesuarlarla birlikte gövde, kol, bacak ve ayak parçalarına ayrılan Modular Character Outfits; ayrıca hareket, dövüş, tırmanma, çiftçilik, balıkçılık, bekleme ve sosyal hareketleri kapsayan toplam 262 kliplik Universal Animation Library birinci ve ikinci paketleri. glTF dosyalarını incelemek, bunların neden birbiriyle uyumlu olduğunu ortaya çıkardı: Dört paketteki her bir mesh, bilinçli olarak aynı 65 eklemli UE5 tarzı iskelete riglenmiş; eklem adları ve bind pozları aynı, yapı kökten pelvise ve omurga üzerinden başa uzanıyor, her iki tarafta on beşer parmak eklemi bulunan aynalanmış kollar ve aynalanmış bacaklar yer alıyor. Yeniden hedefleme gerekmiyor. Bu, 213 kemikli bir yüz riginin 65 kemikli bir Mixamo rigiyle iletişim kurmak zorunda olduğu Spike 35'teki üç iskeletli yeniden hedefleme probleminin tam tersi. Burada dört paketin tamamı bilinçli olarak animasyon kütüphanesinin iskeleti üzerinde hazırlanmış ve eşleşme kusursuz.

Bu durum spike'ı bir animasyon iş akışı çalışması olmaktan çıkarıp bağlama çalışmasına dönüştürdü. Temel katman bir vücut glTF'si yüklüyor, kemik değişikliklerinin yükleyicinin önbelleğe alınmış sahnesine geri aktarılmasını önlemek ve her karaktere yeni bir iskelet örneği vermek için sahneyi SkeletonUtils.clone ile klonluyor, ardından bu 65 kemikli iskeleti ve animasyonun kökünü oluşturan armature nesnesini standart olarak önbelleğe alıyor.

Bir ceketi vücuda yeniden bağlamak

Tüm sistemi çalıştıran püf noktası, bir kıyafetin mesh'ini doğrudan sahnede başka bir üst nesneye bağlayamamanızdır; çünkü mesh hâlâ farklı bir alt ağaçta bulunan kendi glTF'sindeki kemiklere referans verir. Köylü gövdesi ya da korucu bacakları gibi her modüler parça, aynı armature'ün kendi klonuna sahip ayrı bir SkinnedMesh olarak gelir. Bağlama işlemi, kaynak iskeletin kemiklerini özgün sıralarında dolaşır, her birini standart iskelette adına göre bulur ve kaynağın ters bind matrislerini yeniden kullanarak bu yeniden bağlanmış kemiklerden yeni bir Skeleton oluşturur; ardından kaynağın birim bind matrisiyle SkinnedMesh.bind çağrısı yapar. Mesh, bağlandıktan sonra kaynak sahnesinden ayrılır ve doğrudan karakter kökünün altına yerleştirilir. Bind matrisi, bağlama anındaki dünya dönüşümünü yakaladığı ve kök birim dönüşümde bulunduğu için mesh'in kendi dünya dönüşümü çıktıyı hiçbir zaman etkilemez; skinning işlemi artık tamamen paylaşılan kemikler üzerinden gerçekleşir.

Saç ve kaşlar da birer yuvadır ve yanlış bir varsayımı düzeltmemizi sağladılar. Klasör yapısında "baş kemiğine riglenmiş" ifadesi yer alıyordu; bu da saçın, önceden belirlenmiş bir ofsetle başa bağlanan statik bir mesh olacağını düşündürüyordu. Öyle değil. Her saç dosyası, 65 eklemin tamamına ağırlıklandırılmış bir SkinnedMesh'tir; uzun saçın ağırlıkları üst omurgaya ve boyna kadar yayıldığı için karakter aşağı baktığında saç doğal biçimde sarkar. Bu nedenle saç da herhangi bir kıyafet parçasıyla aynı ada göre yeniden bağlama yolunu izler. Tek özel durum, kıyafetin gövde yuvasıdır: Bu parça eklendiğinde kıyafetin temel vücudun içinden geçmesini önlemek için temel vücut mesh'i gizlenir. Kollar, bacaklar, ayaklar ve aksesuarlar ise doğrudan üst üste eklenir; çünkü paket, giysilerin cildi açıkta bıraktığı yerlerde temel vücut görünecek şekilde bu parçaların birlikte kullanılmasına uygun hazırlanmıştır.

Ücretsiz 262 animasyon

İskelet paylaşıldıktan sonra animasyon kısmı neredeyse heyecansız kalıyor. İki kütüphane glb'si yükleniyor, klipleri tek bir adlandırılmış listede birleştiriliyor ve bu kliplerdeki track adları tam eklem adlarına bone.position, bone.quaternion ve bone.scale aracılığıyla referans veriyor. Karakterin armature'ünü kök alan bir AnimationMixer, bu kemikleri adlarına göre bulup doğrudan hareket ettiriyor ve animasyonlar arasında geçiş yaparken crossfade uyguluyor. Görüntüleyicinin sağ panelinde 262 klibin tamamını içeren, filtrelenebilir ve kaynak etiketleri gösteren bir liste bulunuyor; böylece "fish" araması her iki kütüphanedeki tüm balıkçılık animasyonlarını ortaya çıkarıyor. Yumuşak gölgeli standart üç noktalı aydınlatma, ayakların altındaki kutupsal ızgara ve ACES ton eşleme, koyu renkli vücut giysisinin gölgelerini ezmeden stilize temel dokuların okunaklı kalmasını sağlıyor.

Bunun ürün açısından azalttığı risk oldukça büyük. Avatar özelleştirme özelliği, sıfır rigleme çalışması ve sıfır animasyon üretimiyle bir CC0 paketi üzerinden kullanıma sunulabilir: Dört paketi ekleyip bir gardırop arayüzü bağladığınızda, kullanıma hazır olarak yaklaşık altı kıyafet × sekiz saç modeli × iki cinsiyet × 262 animasyonluk çeşitlilik elde edersiniz. 65 eklemli iskelet, GPU skinning maliyetini ihmal edilebilir düzeyde tutacak kadar küçük ve Spike 45'teki toplu skinning çalışması bu boyuttaki bir rig üzerinde 200'den fazla avatarı zaten destekliyor. CC0 herhangi bir kullanım kısıtlaması getirmediği için ücretli bir içerik üretme platformunda ticari kullanımda sorun yok. Geriye kalan açık soru, kullanıcıların yüklediği özel kıyafetler. Bu, yükleme sırasında kıyafetleri bu standart iskelete yeniden hedefleyerek çözülecek bir 3. Aşama problemi; yani Spike 35'teki çalışma zamanı yeniden hedeflemesinin tersi. Varlıkların diskte kapladığı alan, ham 2K PNG'ler ve sıkıştırılmamış animasyon glb'leriyle yaklaşık 147 MB. Üretimde KTX2 doku sıkıştırması ve bir gltf-transform geçişiyle bu boyut yaklaşık 30 MB'a indirilebilir.

Bu bölümde kullanılan teknolojiler

Paket genelinde tek bir standart iskelet. Dört Quaternius paketinin tamamı (temel vücutlar, modüler kıyafetler ve iki animasyon kütüphanesi), aynı eklem adlarına ve bind pozlarına sahip, birbirinin aynısı 65 eklemli UE5 tarzı bir iskelete riglenmiştir; dolayısıyla bunları birleştirmek için yeniden hedefleme gerekmez. Temel modeli SkeletonUtils.clone ile klonlamak, yükleyicinin önbelleğe alınmış sahnesini değiştirmek yerine her karaktere yeni bir iskelet örneği verir.

Ada göre iskelet yeniden bağlama. Her modüler parça, kendi armature'üne referans veren ayrı bir SkinnedMesh ile gelir. Yeniden bağlama işlemi kaynak kemikleri sırasıyla dolaşır, her birini adına göre standart iskeletteki karşılığıyla eşler, kaynağın ters bind matrislerini yeniden kullanarak yeni bir Skeleton oluşturur ve birim bind matrisiyle SkinnedMesh.bind çağrısı yapar. Ardından mesh, paylaşılan karakter kökünün altına yerleştirilir; böylece skinning tamamen paylaşılan kemikler üzerinden çalışır. Kıyafet gövdesi yuvası, kesişmeyi önlemek için temel vücudu gizler; diğer yuvalar ise üst üste eklenir.

Skinning uygulanmış bir yuva olarak saç. Saç, baş kemiğine bağlanan statik bir nesne değil, 65 eklemin tamamına ağırlıklandırılmış bir SkinnedMesh'tir. Uzun saçın ağırlıkları üst omurga ve boyna kadar uzandığı için karakter aşağı baktığında saç sarkar. Kıyafet parçalarıyla aynı yeniden bağlama yolunu izler.

Ek işlem gerektirmeyen, ada dayalı animasyon yeniden hedefleme. Animation Library klipleri eklemlere tam adlarıyla referans verdiğinden, paylaşılan armature'ü kök alan bir AnimationMixer, 262 klibin tamamını klip başına yeniden hedefleme gerektirmeden ve crossfade ile doğrudan çalıştırır. CC0 lisansı ticari kullanımı kapsar; düşük eklem sayısı da GPU skinning maliyetini Spike 45'teki toplu skinning yolunu yeniden kullanmaya yetecek kadar düşük tutar. Bkz. GPU destekli LOD.

29 bölümden 25'incisi. Önceki: 24. Bölüm - Bir dünyayı kaydetmek ve görebildiğiniz rüzgâr Sonraki: 26. Bölüm - Her ölçekte etkileyici görünen su Seri rehberi: /blog/2026-02-25-open-world-browser-series-guide

Cinevva CTO'su ve Kurucu Ortağı Oleg Sidorkin tarafından

Burada yeni misiniz? Seri rehberini kullanın. Rehber, spike'ın ne olduğunu açıklıyor ve tüm bölümlere bağlantı veriyor.

Bölüm 23, insanları dünyaya yerleştirdi ve onlara ses verdi. Bu bölüm, dünyanın insanların yaptığı değişiklikleri hatırlamasını ve kimse dokunmadığında bile canlı hissettirmesini ele alıyor. Spike 47 kalıcılıkla ilgili: Bir içerik üreticisi araziyi şekillendirip nesneler yerleştiriyor; bu düzenlemeler sayfa yeniden yüklendiğinde korunuyor, diğer tüm eşlerle eşitleniyor ve iki kişi aynı anda düzenleme yaptığında çakışmalar düzgün biçimde çözümleniyor. Spike 49 ise rüzgârla ilgili: Stilize bir doğa paketindeki bitki örtüsü gölgelendiricilerini, ağaçların, çalıların ve çimenlerin sanatçının amaçladığı şekilde hareket etmesi için taşımak. Bu süreç, matematikten çok gölgelendirici derleyicisiyle mücadeleye dönüştü.

Hatırlayan bir dünya

Spike 47'yi yeni sekmede açın ↗ · Kaynak kodunu görüntüleyin

Kurulum, paylaşılan bir içerik üretme oturumundan oluşuyor. Oyuncular dünyada dolaşıyor, tıklayarak nesneler yerleştiriyor, sağ tıklayarak bunları kaldırıyor ve bir fırçayı sürükleyerek zemini şekillendiriyor. Bunu yaparken yükseklik haritasını yükseltip alçaltabiliyor veya bir parçayı marching cubes yöntemine geçiren SDF arazisinde hacimsel mağaralar oyabiliyorlar. Yaptıkları her şey, kendi SQLite depolamasıyla desteklenen, sunucu otoriteli bir Durable Object olan Cloudflare WorldChunkDO içinde kalıcılaştırılıyor. İstemciler durumu doğrudan yazmıyor. Niyetlerini gönderiyorlar; DO kararı verip sonucu yayınlıyor. DO, tek doğruluk kaynağı olduğundan yeni katılan biri bir anlık görüntü alıyor ve diğer herkesin gördüğüyle birebir aynı dünyaya geliyor.

İki kalıcılık ayrıntısı özellikle değerini kanıtladı. Arazi, katılım sırasında yeniden oynatılacak bir olay günlüğü olarak saklanmıyor; doğruluk kaynağı olan parça başına ikili blob'lar hâlinde tutuluyor ve fırça darbesi sona erdiğinde yükleniyor. Böylece yeni katılan biri binlerce fırça örneğini yeniden çalıştırmak yerine doğrudan kaydedilmiş baytları yüklüyor. Ayrıca bu blob'lar tek bir büyük satırda değil, parça başına bir depolama anahtarında tutuluyor; çünkü tek bir SDF parçası 168 KB ve DO'nun satır başına 2 MB sınırı var. Hangi anahtarların mevcut olduğunu izleyen bir parça dizini, DO'nun uyandığında tüm haritayı yeniden yüklemesini sağlıyor. Kimlik, istemcide iki depolama alanıyla yönetiliyor: Oyuncu kimliği sessionStorage içinde tutuluyor; böylece iki sekme, DO'nun oyuncu haritasında kendisinin üzerine yazan tek bir eş yerine iki ayrı eş oluyor. Görünen ad ise localStorage içinde tutuluyor; böylece bir sekmede yapılan ad değişikliği diğer tüm sekmelere aktarılıyor.

Eşzamanlı düzenlemelerin aynı sonuca ulaşmasını sağlamak

Çok oyunculu içerik üretiminin gerçekten zor kısmı, iki kişinin aynı anda örtüşen zemin bölgelerini düzenlediğinde ne olduğudur. Spike, düzenlemeleri cebirsel özelliklerine göre ayırıyor. Toplamsal işlemler — yükseklik haritasında yükseltme ve alçaltma ile SDF üzerinde ekleme ve çıkarma — değişmelidir: Hangi sırayla uygulanırlarsa uygulansınlar aynı sonucu verirler. Bu nedenle, her istemcinin işlemi yerel olarak uygulayıp damgayı gönderdiği iyimser damga yolunu kullanırlar; DO da hiçbir koordinasyon gerektirmeden bunu herkese yayınlar. Sıralama gerçekten önemsiz olduğundan koordine edilecek bir şey de yoktur.

Sıraya bağlı işlemler olan yumuşatma ve düzleştirme ise ilginç vakaydı. İlk tasarım bunlara bölge kilidi veriyordu: İstemci, işaretçiye basıldığında kilit istiyor; DO isteği kabul veya reddediyor; istemci basılı tutma süresince örnekleri tamponluyor ve işaretçi bırakıldığında DO tüm fırça darbesini atomik olarak uyguluyordu. Bu yöntem çalışıyor, ancak kendi kilit TTL'si ve kabul/ret gidiş dönüşü olan ayrı bir protokol gerektiriyordu. Bunun yerini alan daha temiz çözüm, önceden hesaplanmış delta oldu: İşlemi başlatan istemci yumuşatma veya düzleştirme fırçasını yerel olarak çalıştırıyor, ardından hücre başına elde edilen delta listesini gönderiyor. Diğer tüm eşler de hiçbir şeyi yeniden türetmeden bu deltaları kendi hücrelerine ekliyor. Böylece sıraya bağlı bir işlem, sonucu kaynağında sabitlenerek değişmeli hâle geliyor; tüm düzenleme sistemi aynı yakınsamayı sağlayan tek ve tutarlı bir değişmeli protokol üzerinde, hiçbir kilit olmadan çalışıyor. Nesne kilitleri farklı bir nedenle varlığını sürdürüyor: Kayıt başına kilitleme, yalnızca sahibin silebildiği modelin yerini aldı. Böylece kilitli olmadığı sürece herhangi bir eş herhangi bir nesneyi silebiliyor ve kilidi yalnızca kilitleyen kişi kaldırabiliyor. Geri alma ve yineleme, istemcinin bir nesneyi yerleştirmeden önce kimliğini belirleyebilmesiyle çalışıyor. Böylece istemci, sunucunun yanıtı gelmeden kimliği biliyor ve kendi eylemlerini deterministik biçimde geri alabiliyor. Hazırda bekleyen WebSocket'ler, boşta duran bir odayı tüm süre boyunca ücretsiz tutuyor; önceki bölümde avatar aktarımını ucuz kılan da aynı özellikti.

Rüzgârı aslına sadık biçimde taşıdık, ardından onunla mücadele ettik

Spike 49'u yeni sekmede açın ↗ · Kaynak kodunu görüntüleyin

Spike 49, Quaternius'un Stylized Nature MegaKit paketini alıp rüzgâr sistemini kullandığımız teknoloji yığınına taşıyor. Paket, dört özgün Godot gölgelendiricisiyle birlikte geliyor ve doğru yaklaşım bunları yeniden icat etmek yerine aslına sadık biçimde çevirmekti. Kabuk gölgelendiricisinin verteks işlevi boş; dolayısıyla gövdeler sabit kalıyor. Daha önce denenmiş prosedürel maske, gövdelerin de sallanmasına neden oluyordu ve çözüm, rüzgârı kabuğa hiç uygulamamaktı. Yapraklar, üçgensel darbe hash'inden verteks başına kaotik bir sallanma alıyor. Bu hareket yüksekliğe göre maskelendiğinden ağaç tepeleri hareket ederken dip kısım yerinde kalıyor. Temel bitki örtüsü, dünya uzayında gürültüyle modüle edilen sin/cos sallanması alıyor. Çimen, temel bitki örtüsü hareketine ek olarak rüzgâr çizgisi salınımına sahip. Kayan bir gürültü dokusu kuvvet eğrisi üzerinden örnekleniyor; böylece yalnızca dokunun parlak bantları katkıda bulunuyor ve çayır boyunca ilerleyen görünür dalgalar oluşuyor. Yönlendirme, paketin kendi malzeme adlandırma kuralını izliyor. Bu nedenle Leaves_Birch adlı bir malzeme yaprak yoluna, Grass_Common ise çimen yoluna yönlendiriliyor; tahmin yürütmek gerekmiyor.

Taşıma sırasında karşılaştığımız sürprizlerden biri, yaprak renginin dokuda bulunmamasıydı. Quaternius, yaprak görünümünü tamamen dikey bir gradyan ve Fresnel kenar ışığıyla oluşturuyor: Albedo, yüksekliğe bağlı olarak ağaç tepesinin altındaki ek renkten üstteki yaprak rengine doğru karıştırılıyor. Buna, $(1-\mathbf{N}\cdot \mathbf{V}{)}^3$ Fresnel terimiyle ölçeklenen emisyon biçiminde bir yüzey altı saçılım tonu ekleniyor. Bu nedenle yalnızca doku kullanan sade bir geçiş düz görünüyordu. Renkler boyanmış haritadan değil, gradyandan ve kenar ışığından geliyor. Taşıma, ham yerel Y yerine önceden hesaplanmış bir heightFactor verteks özniteliğini okuyor. Bu öznitelik yükleme sırasında her yaprak grubu için dünya uzayındaki Y değerinden normalize ediliyor; böylece FBX içe aktarma işlemi her ağın yerel eksenlerini nasıl döndürmüş olursa olsun hem gradyan hem de rüzgâr maskesi doğru davranıyor. Godot renk sabitleri sRGB olarak etiketleniyor ve gölgelendiriciye ulaşmadan önce doğrusal uzaya dönüştürülüyor. Dolayısıyla taşıma da parlak sRGB sayılarını doğrusal değerler olarak verip bitki örtüsünü soluklaştırmak yerine aynı dönüşümü uyguluyor.

Kare hızını yiyip bitiren yeniden derleme

Bunun önce bir FBX temel sürümü olarak yayımlanmasının ve eksiksiz rüzgâr malzemesi setinin bir .bak dosyasında kenara alınmasının nedeni, sahneyi yaklaşık 1 fps'ye düşüren kare başına yeniden derleme hatasıydı. FBX ile yüklenmiş malzemelerin üzerine özel TSL eklemek, needsUpdate fiilen takılı kalmış gibi Three.js'in gölgelendirici programlarını her karede yeniden oluşturmasını tetikliyordu. Tanılama yaklaşımı, her bitki örtüsü malzemesini özel düğümler içermeyen sade, dokulu bir geçişe indirgemek ve yeniden derleme döngüsünün sürüp sürmediğini gözlemlemekti. Döngü durursa sorun özel grafikteydi; devam ederse neden FBX malzeme kurulumunun üst katmanlarında veya Three.js'in kendisindeydi. Gerçek gölgelendiricilerin geri gelmesini sağlayan çözüm, malzeme başına değişen her değeri — yaprak rengi, SSS rengi, kuvvet ve karışım — uniform olarak bağlamaktı. Böylece derleyicinin her benzersiz renk kombinasyonu için yeni bir gölgelendirici üretip derleme kuyruğunu altüst etmesi yerine tüm yaprak varlıkları tek bir derlenmiş programı paylaşıyor.

İki ayrıntı daha korunmaya değer. Çimen, kaynak dosya başına bir InstancedMesh olarak işleniyor ve sinüs fazları dünya konumuna bağlı olduğundan rüzgârı dünya uzayında hesaplanıyor. Ancak örnek matrisi uygulanmadan önce yer değiştirme yerel uzayda uygulanmalı ve WGSL'de çağrılabilecek bir inverse() bulunmuyor. Öteleme, Y dönüşü ve tekdüze ölçekten oluşan bir örnek matrisi için üst 3×3 bölümün tersi, basitçe transpozunun ölçeğin karesine bölünmesidir. Bu nedenle gölgelendirici, dünya uzayındaki yer değiştirmeyi transpoze model matrisiyle çarpıyor ve matrisin ilk sütununun karesi alınmış uzunluğuna bölüyor; böylece karekök kullanmadan ölçeği elde ediyor. Verteks dönüşümü matrisi yeniden uyguladıktan sonra hareket, her çimen öbeğinin dönüşünden veya ölçeğinden bağımsız olarak tam tasarlandığı biçimde dünya uzayına yerleşiyor. Ayrıca her öbek, verteks başına GPU görüş hacmi elemesi çalıştırıyor: Örnek merkezi klip uzayına yansıtılıyor ve pay bırakılmış görüş hacminin dışına düşerse her verteks yerel orijine daraltılıyor. Böylece her üçgenin üç verteksi de çakışıyor, rasterleştirici dejenere üçgeni atıyor ve ekran dışındaki çimenler için parça, alfa testi veya gölge işlemi yapılmıyor. Bu işlem, Three.js'in zaten yaptığı parça başına kaba sınırlayıcı küre elemesinin üzerine ekleniyor ve konum karışımıyla doğrudan çarpılabilmesi için boolean değerler yerine kayan noktalı step kullanılarak oluşturuluyor.

Bu bölümde değinilen teknolojiler

Sunucu otoriteli dünya kalıcılığı. Bir WorldChunkDO Durable Object, nesne yerleştirme ve arazi düzenlemeleri hakkında karar veriyor; parça başına ikili blob'ları doğruluk kaynağı olarak kalıcılaştırıyor. Böylece katılanlar olay günlüğünü yeniden oynatmak yerine kaydedilmiş baytları yüklüyor. Ayrıca DO'nun satır başına 2 MB sınırının altında kalmak için her parça ayrı bir depolama anahtarında saklanıyor. Oyuncu kimliği sessionStorage içinde tutulduğundan sekmeler ayrı eşler oluyor; görünen ad ise localStorage içinde tutulduğundan ad değişiklikleri sekmeler arasında aktarılıyor.

Değişmeli düzenlemelerin yakınsaması. Toplamsal arazi işlemleri (yükseltme/alçaltma, SDF ekleme/çıkarma) değişmeli olduğundan koordinasyon gerektirmeyen iyimser damga yolunu kullanıyor. Sıraya bağlı işlemler (yumuşatma, düzleştirme), bölge kilidi almak yerine önceden hesaplanmış hücre başına deltalar gönderilerek değişmeli hâle getiriliyor. Böylece tüm sistem, hiçbir kilit olmadan tek ve tutarlı bir protokol altında aynı sonuca ulaşıyor. Kayıt başına nesne kilitleri yalnızca sahibin silebildiği modelin yerini alıyor; istemci tarafından adlandırılan nesne kimlikleri ise sunucunun yanıtı gelmeden deterministik geri alma/yineleme sağlıyor. Bkz. GPU güdümlü LOD.

Godot'tan TSL'ye aslına sadık gölgelendirici taşıma. Quaternius'un dört özgün rüzgâr gölgelendiricisi satır satır çevriliyor: sabit kabuk, yüksekliğe göre maskelenmiş yaprak sallanması, dünya uzayında bitki örtüsü sallanması ve kayan rüzgâr çizgisi salınımına sahip çimen. Yollar, paketin malzeme adlandırma kuralına göre seçiliyor. Yaprak rengi dokudan değil, yükseklik gradyanı ile Fresnel güdümlü SSS kenar ışığından geliyor. Görünümün referans render'larla eşleşmesi için sRGB üretim sabitleri doğrusal uzaya dönüştürülüyor.

Kare başına gölgelendirici yeniden derlemelerini önleme. FBX malzemelerinin üzerine özel TSL eklemek, needsUpdate değerini takılı bırakıp programların her karede yeniden oluşturulmasına yol açarak performansı yaklaşık 1 fps'ye düşürebilir. Malzeme başına değişen her değeri uniform olarak bağlamak, her benzersiz parametre kümesi için yeni gölgelendirici üretmek yerine tüm varyantların tek bir derlenmiş programı paylaşmasını sağlar. Sade, dokulu bir tanılama geçişi de sorunun özel grafikten mi yoksa üst katmandaki kurulumdan mı kaynaklandığını ayırır.

Örneklenmiş bitki örtüsünde dünya uzayı rüzgârı. Çimen rüzgârı dünya uzayında hesaplanıyor ve WGSL'de inverse() bulunmadığı için elle türetilmiş bir ters matrisle (transpoz bölü ölçeğin karesi) yerel uzaya geri dönüştürülüyor. Verteks başına GPU görüş hacmi elemesi, ekran dışındaki öbekleri dejenere üçgenlere daraltıyor; böylece parça veya gölge işlemi yapılmıyor. Bu işlem, Three.js'in parça başına sınırlayıcı küre elemesinin üzerine ekleniyor.

29 bölümün 24. bölümü. Önceki: Bölüm 23 - Elli avatar ve odada bir ses Sonraki: Bölüm 25 - Tek iskelet, her kıyafet Seri rehberi: /blog/2026-02-25-open-world-browser-series-guide

Yazan: Oleg Sidorkin, Cinevva CTO'su ve Kurucu Ortağı

Burada yeni misiniz? Seri rehberine göz atın. Rehber, spike'ın ne olduğunu açıklıyor ve tüm bölümlere bağlantı veriyor.

22. bölüm dünyanın üzerine bir gökyüzü yerleştirdi. Bu bölümse dünyaya insanları yerleştiriyor. Üçüncü şahıs bakış açılı bir açık dünyada her an 50'den fazla karakterin görünür olması ve yanınızda duran kişileri duyabilmeniz gerekir. Spike 45 işin render tarafı: ana iş parçacığını eritmeden bu kadar çok animasyonlu avatarı GPU'ya aktarmak. Spike 46 ise ses tarafı: konuma göre sağa-sola dağılan ve zayıflayan eşler arası sesli iletişimi, bir teknoloji demosundan çok normal bir görüntülü görüşme gibi duyulacak şekilde ayarlamak.

Elli dansçı için tek çizim çağrısı

Spike 45'i yeni sekmede aç ↗ · Kaynak kodu görüntüle

Varsayılan Three.js yaklaşımı her karaktere kendi SkinnedMesh'ini, kendi AnimationMixer'ını, kendi kemik matrisi yüklemesini ve kendi çizim çağrısını verir. Yerel Mac'te 50 avatar, GPU daha tek bir işlem bile yapmadan önce kare başına yaklaşık 13 ms saf JavaScript yükü oluşturuyordu. Çok oyunculu sistemin tamamı için risk azaltma sorusu, tek bir toplu iskelet animasyonu mimarisinin bunu kontrol altına alıp karakter sayısıyla doğrusal biçimde ölçeklenip ölçeklenemeyeceğiydi.

Çözüm, animasyonun hesaplandığı yer ile çizildiği yeri ayırmak. Üç karakter sınıfı aynı FBX şablonunu paylaşıyor. Yerel oyuncu normal bir Avatar: kendi mixer'ına sahip tam bir iskelet klonu ve standart Three.js yaklaşımı; çünkü bundan her zaman yalnızca bir tane bulunuyor. Her uzak eş ise bir VirtualSkeleton: aynı klipleri çalıştıran kendi mixer'ına sahip tam bir klon, ancak yalnızca kemiklerin kalması için her SkinnedMesh düğümü klonlamanın hemen ardından kaldırılıyor. Bu nesne sahneye hiç girmiyor. Her karede, mixer güncellendikten ve matrisler son hâlini aldıktan sonra, 100 kemiğin tamamı için (bone.matrixWorld × boneInverse) değerlerini paylaşılan bir Float32Array içindeki bir yuvaya paketliyor. Ardından BatchSkinnedRenderer, geometri parçası başına bir InstancedMesh barındırıyor; bunların tümü maxInstances × numBones × mat4, yani 60 × 100 × 64 = 384 KB boyutundaki tek bir kemik matrisi StorageBufferAttribute'ından veri okuyor. Özel positionNode ve normalNode içeren bir MeshStandardNodeMaterial, tepe noktası başına dört kemik etkisini doğrudan bu depolama tamponundan okuyor. Sonuç, kalabalıkta kaç kişi olursa olsun geometri parçası başına tek bir depolama yüklemesi ve tek bir çizim çağrısı. İskelet animasyonu tepe noktası gölgelendiricisinde çalışıyor ve avatar başına JavaScript maliyeti bir mixer çalıştırıp 100 matrisi kopyalamaya düşüyor.

Bunu ölçen HUD'ın da yeniden yapılması gerekti. Eski sürüm, tüm karenin GPU süresi 3 ms'yi aştığında "bütçe aşıldı" uyarısı veriyordu; ancak kare her zaman gölge haritasını, zemini ve yerel oyuncunun tam iskelet animasyonlu mesh'ini içeriyor ve bunlar, kaç sentetik eş bulunursa bulunsun gerçek donanımda toplam 3 ila 5 ms sürüyor. Çözüm, kendini kalibre eden bir bütçe oldu: toplu avatar bulunmadığı sırada hızlı bir EMA üzerinden canlı GPU süresini taban değer olarak yakalıyor, ardından bu taban değeri donduruyor ve sentetik avatarlar belirdiğinde eklenen avatar başına bütçeyi doğrusal biçimde 0,06 ms artırıyor. Her makinede boşta PASS gösteriyor ve kalabalık büyüdükçe bütçeyi orantılı olarak sıkılaştırıyor.

Hata, göremediğiniz bir yüzdü

Chrome'daki ilk çalıştırmalarda yerde gümüş renkli gölgeler görünürken avatarlar hiç görünmedi ve şu WGSL ayrıştırma hatası çıktı: cannot index type 'f32'. Hata, uniform skaler olarak tanımlanmışken object.nodeUniform2[i] ifadesini indekslemeye çalışan bir satırdaydı. Bu hikâyenin dürüst kısmı şu: ilk düzeltme yanlıştı ama yine de işe yaradı. Tahmin, hatalı kodu InstancedMesh'in örnek matrisi yolunun ürettiğiydi ve bunu bir StorageInstancedBufferAttribute ile değiştirmek hatayı Chrome'da ortadan kaldırdı. Ancak hata, yeni yol farklı gölgelendirici kodu ürettiği için kaybolmuştu; neden ele alındığı için değil. Bu da en tehlikeli düzeltme türüdür.

Asıl suçlu morph target'lardı. 3MIKE.fbx, blend shape tabanlı yüz ifadeleriyle geliyor; klonlanan geometri morphAttributes değerlerini devralıyor ve Three.js'in MorphNode.setup() metodu morphTargetInfluences değerini skaler bir float olarak tanımladıktan sonra oluşturulmuş bir döngü içinde buna .element(i) uygulamaya çalışıyor. Derleyicinin reddettiği skaler indeksleme tam olarak buydu. Düzeltme tek satır: morph kullanmayan geometrilerde geometry.morphAttributes = {} değerini ayarlamak. Böylece Three.js, MorphNode'u hiçbir zaman eklemiyor. Kazara bulunan Chrome düzeltmesi bir süre kaldıktan sonra geri tepti: Safari'de depolama tabanlı örnekleme yolu 256 kez Vertex buffer is not big enough hatası üretti, çünkü Safari'nin WebGPU arka ucu bunu düzgün biçimde çeviremiyor. Geri almak doğru karardı ve oluşturulmuş bir örnekleme yolu yerine temel WebGPU'nun parçası olan sade kemik matrisi depolama tamponu her yerde sorunsuz çalışıyor. Buradan çıkarılması gereken ders şu: bir düzeltme tek bir tarayıcıda çalışıyor ve mekanizmasını açıklayamıyorsanız yalnızca bir belirtiyi yamamışsınızdır; bu nedenle gerçekten üretilen WGSL'yi okuyun. Spike'a daha sonra eklenen bir getCompilationInfo() shim'i, Three.js'in genel "module is not valid" mesajını gerçek Tint hatasına dönüştürdü ve harcanan emeğin karşılığını defalarca verdi.

Bunun yanında, framework'ün otomatik davranışından kaçınmak için ilgili bir yöntem daha bulunuyor. Three.js, standart skinIndex ve skinWeight öznitelik adlarını algılıyor ve özel positionNode zaten iskelet animasyonunu yapıyor olsa bile bir InstancedMesh içine kendi SkinningNode'unu eklemeye çalışıyor. Bu öznitelikleri boneIndex ve boneWeight olarak yeniden adlandırmak onları framework'ten gizliyor; özel TSL de bunları yeni adlarıyla okuyor.

Kelimeler arasında sizi unutan bir aktarıcı

İlk sürüm, gerçek kablo biçimini ve gönderim sıklığını kullanan aynı tarayıcı içi bir yer tutucu olan BroadcastChannel üzerinden eşleri senkronize ediyordu ve protokol yorumunda gerçek aktarıma geçişin tek satırlık bir değişiklik olacağı vaat ediliyordu. Bu vaadi yerine getirmek, 36 baytlık ikili kareyi çözümlemeyen 74 satırlık bir Cloudflare Durable Object olan AvatarRoomDO anlamına geldi. Gönderenin kimliği karenin içine gömülü olduğu ve her alıcı istemci tarafında kendi yankısını filtrelediği için her mesajı olduğu gibi odadaki diğer tüm eşlere iletiyor. Aktarıcı, kimlik konusunda hiçbir farkındalığa sahip değil. Hazırda bekleyen WebSocket'ler, boşta duran bir odayı ücretsiz hâle getiriyor: DO, mesajlar arasında bellekten çıkıyor ve çalışma ortamı bir sonraki pakette etiketlenmiş soketleri geri yüklüyor. Eş başına saniyede 10 olayla bu, eş-saat başına 36.000 DO isteği, yani yaklaşık yarım sent ediyor; Cloudflare'da çıkış trafiği ücretsiz ve eşdeğer AWS WebSocket yapısından yaklaşık 6 ila 10 kat daha ucuz.

Geçiş, saklamaya değer bir durum makinesi hatasını ortaya çıkardı. Uzak bir oyuncu durduktan sonra yürümeye devam ediyordu. Animasyon isteği son kuyruğa alınan adı değil, o anda oynatılan klip olan this._state değerini kontrol ediyordu. Bu nedenle aynı tick içinde önce walk, ardından idle olmak üzere iki ağ mesajı geldiğinde idle, henüz ilerlememiş bir durumla karşılaştırılıyor ve sessizce bırakılıyordu. Gelecekteki idle paketleri değişmediği için üst katmanda yinelenen veri olarak ayıklandığından eş sonsuza dek yürümeye devam ediyordu. Düzeltme, bekleyen adın üzerine her zaman yazmak ve geçiş yardımcısının gerçek aynı durum isteklerini kısa devre etmesine izin vermekti; zaten yaptığı şey de buydu. Bu hata sınıfı geneldir: yanlış referans değerine göre yapılan yinelenen veri kontrolü, önemli girdiyi sessizce yutar.

Safari için iki ek koruma gerekti. WebSocket'i Chrome'dan daha hızlı açtığı için ilk gelen eş mesajı, toplu render sistemi oluşturulmadan önce ulaşabiliyor ve null referansına erişebiliyordu; eşler her 100 ms'de bir yeniden yayın yaptığı için render sistemi yokken mesajları bırakmak güvenli. Ayrıca 'gpu' in navigator true döndürürken requestAdapter() null döndürüyordu. Bu da Three.js'in sessizce WebGL2'ye dönmesine neden oluyordu; depolama tamponlu iskelet animasyonu zincirinin burada geçerli bir çevirisi olmadığından sistem hata yağdırıyordu. Gerçek bir adaptörün varlığını kontrol etmek ve arka ucun gerçekten WebGPU olduğunu doğrulamak, bozuk bir render yerine yükleme ekranında açık bir mesaj gösterilmesini sağlıyor. Bir WGSL lehçe farkı bile vardı: Three.js, WebKit'in derleyicisinin henüz desteklemediği modern iki bağımsız değişkenli @interpolate(flat, either) ifadesini üretiyor. Bu, gölgelendirici kaynağını createShaderModule'a giderken yeniden yazıp ikinci bağımsız değişkeni kaldırarak yamalandı; düz enterpolasyon, hangi tepe noktası kullanılırsa kullanılsın aynı değeri taşıdığı için bunun hiçbir maliyeti yok.

Odaya göre sağa-sola dağılan ses

Spike 46'yı yeni sekmede aç ↗ · Kaynak kodu görüntüle

Spike 46, yakınlık tabanlı sesli iletişimdir: sessiz veya orta düzeyde gürültülü bir odada Google Meet ve Microsoft Teams kalitesini yakalamak üzere açıkça kapsamlandırılmış, HRTF uzamsal ses kullanan eşler arası WebRTC. Bir VoiceRoomDO, JSON aktarıcısı olarak sinyalleşmeyi yönetiyor: her yeni eşe katılımcı listesini gönderiyor, katılım ve ayrılmaları duyuruyor, SDP ve ICE verilerini soket etiketine göre belirli bir eşe yönlendiriyor ve uzamsal konumlandırıcıları yöneten konum güncellemelerini yayınlıyor. Eşlerin birbirlerinin kimliğine bürünememesi için her mesaja gönderen kimliğini ekliyor; sesin kendisiyse DO'ya hiç uğramıyor. Her uzak eş için bir RTCPeerConnection kullanılıyor ve sözlük sıralamasında daha küçük eş kimliği her zaman teklifi yapıyor. Böylece iki taraf, eksiksiz bir perfect negotiation uygulamasına gerek kalmadan kimin başlatacağı konusunda anlaşabiliyor.

Alıcı tarafında her eşin sesi, ters mesafe azalmasıyla HRTF'ye ayarlanmış bir PannerNode üzerinden geçiyor. AudioListener, yerel oyuncunun konumu ve baktığı yön üzerinden her karede forwardX = sin(facing), forwardZ = cos(facing) kullanılarak güncelleniyor; bu da sahnenin atan2(wx, wz) yön kuralıyla eşleşiyor. Chrome'a özgü bir tuhaflık bir saate mal oldu: yalnızca Web Audio tarafından tüketilen bir MediaStream bazen paketleri çekmiyor. Bu nedenle her akış, kod çözücüyü zamanlamaya zorlamak için gizli ve sessize alınmış bir <audio> öğesine de bağlanıyor. Kalite tarafında tarayıcılar varsayılan olarak yaklaşık 32 kbps mono Opus kullanıyor. Bu yüzden spike, bant içi FEC'yi etkinleştirip DTX'i devre dışı bırakarak bit hızını 128 kbps'ye çıkarmak için her teklif ve yanıttaki fmtp satırını değiştiriyor; ardından kodlayıcının SDP'de belirtilen değeri gerçekten kullanmasını garanti etmek için yüksek bir maksimum bit hızıyla setParameters çağrısı yapıyor. FEC, bit hızı artışından sonraki en büyük ikinci işitsel iyileştirmedir ve yeniden anlaşma gerektirmeden paket kaybının telafi edilmesini sağlar.

Sadeleştirerek temiz sese ulaşmak

Yayınlanan ses zinciri, başladığım zincirden çok daha küçük ve asıl ders de onu küçültmekti. İlk sürümde bir yüksek geçiren filtre, klavye seslerini yakalamak üzere ayarlanmış bir tıklama sınırlayıcı, bir kompresör, bir gürültü kapısı ve bir wet-dry çapraz geçişi vardı; bunların önünde de on ikiden fazla kaydırıcı içeren yüzen bir panel bulunuyordu. Kullanıcı klavye tıklamalarını duyduğunu bildirdiğinde ilk içgüdü, peş peşe yamalar ekleyerek tıklama sınırlayıcıyı daha sert ayarlamak ve dry karışımını düşürmekti. Yapısal yanıt şuydu: zincirde bir makine öğrenimi gürültü gidericisi bulunduğunda tıklama sınırlayıcı, gürültü kapısı ve yüksek geçiren filtrenin büyük kısmı gereksizdir; çünkü RNNoise tam olarak klavye, fare ve yazma sesleri üzerinde eğitilmiştir ve genlik kırpma aynı işin kesinlikle daha kötü bir sürümüdür. Üretim istemcileri makine öğrenimi tabanlı gürültü giderme, yankı engelleme, otomatik kazanç ve seviye kontrolü için yumuşak bir kompresör sunar; başka hiçbir şey kullanmaz. Böylece dört aşama, kaydırıcı paneli ve "gürültü azaltma yöntemini seç" anahtarları çıkarıldı; geriye tek ve sabit bir işleme hattı kaldı.

Kalan her aşamanın bir işlevi var. RNNoise yankıyı gidermediği ve onsuz hoparlörden mikrofona geri besleme sınırsız olduğu için tarayıcı yankı engellemesi açık kalıyor. RNNoise ile üst üste kullanıldığında sürtünmeli ünsüzlerde bozulma ürettiği için tarayıcının gürültü bastırması kapatılıyor; tek bir gürültü giderici seçmek gerekiyor. Tarayıcının otomatik kazancı açık kalıyor; çünkü kapatıldığında sinyal kompresörün çalışamayacağı kadar sessiz hâle geliyor ve Web Audio'nun DynamicsCompressorNode öğesinde bunu telafi edecek bir makeup-gain parametresi bulunmuyor. Tarayıcının geniş zaman ölçekli seviye ayarı ile spike'ın hızlı kompresörü farklı zaman ölçeklerinde çalışıyor ve bir arada kullanılabiliyor. RNNoise, yüzde 92 wet ile yüzde 8 dry karışımında çalışıyor; çünkü ses olasılığı düşen s, ş ve f gibi ötümsüz ünsüzleri aşırı bastırabiliyor. Küçük dry yolu ise biraz tuş sesi sızıntısı pahasına bu sesleri koruyor. İki özellik sistemi tamamlıyor. Bas-konuş, track.enabled değerini değiştirmiyor; çünkü bu, işlem hattı tamponlarında kalan her şeyi atarak tuş bırakıldığında son heceyi kesiyor. Bunun yerine, zincirin sonuna yakın bir GainNode, setTargetAtTime ile kademeli olarak değişiyor: ilk hecenin korunması için hızlı bir atak, son ünsüzün tamamlanması içinse yavaş bir bırakma uygulanıyor ve parça sürekli etkin kalıyor. Radyo tarzı bir özellik olarak istenen beş saniyelik yayın gecikmesi ise bir baypas kolunu ve bir DelayNode kolunu çapraz geçişle birlikte çalıştırıyor. Kesme düğmesine basıldığında gecikmeli çıkış anında sessize alınıyor ve ses yeniden başlamadan önce HUD üzerinde geri sayım gösteriliyor. Gürültü gidericiyi paketlemek başlı başına küçük bir maceraydı: yayımlanan RNNoise worklet'i, hiçbir CDN'nin çözümleyemediği yalın belirteçli içe aktarımlar kullanıyor. Çözüm, WASM'ın base64 olarak içine gömüldüğü, kendi kendine yeten 1,9 MB'lık tek bir dosya üreten yerel bir esbuild paketi hazırlamak, bunu depoya eklemek ve geliştirme sunucusunda, VitePress derlemesinde ve özel alan adında aynı şekilde çözümlenmesi için modüle göreli bir URL ile referans vermek oldu. Worklet herhangi bir zamanda yüklenemezse zincir, sade bir yüksek geçiren filtre ve kompresör üzerinden yine de ses üretmeye devam ediyor; HUD ise hatayı kırmızı renkte gösteriyor.

Bu bölümde kullanılan teknolojiler

Kalabalıklar için toplu GPU iskelet animasyonu. Uzak avatarlar, her kemiğin bone.matrixWorld × boneInverse değerini paylaşılan bir StorageBufferAttribute içine paketleyen başsız bir VirtualSkeleton (iskelet kaplamalı mesh'leri çıkarılmış, kemikleri korunmuş ve kendi mikserine sahip eksiksiz bir klon) çalıştırıyor. Geometri parçası başına bir InstancedMesh, bu matrisleri özel bir TSL positionNode/normalNode içinde okuyor. Böylece avatar başına CPU işi bir mikser güncellemesi ve matris kopyasıyla sınırlı kalırken tüm kalabalığın maliyeti tek bir depolama yüklemesi ve parça başına tek bir çizim çağrısı oluyor. Bkz. GPU güdümlü LOD.

Belirtiyi değil, oluşturulan WGSL'yi okumak. cannot index type 'f32' derleme hatasının, Three.js MorphNode bileşeninin morphTargetInfluences değerini skaler olarak tanımlayıp alt indisle erişmesinden kaynaklandığı belirlendi. Sorun, biçim değiştirme kullanmayan geometrilerde morphAttributes temizlenerek giderildi. Yalnızca hangi gölgelendirici yolunun oluşturulduğunu değiştiren ilk düzeltme, asıl nedeni maskeledi ve daha sonra Safari'yi bozdu. skinIndex/skinWeight değerlerini boneIndex/boneWeight olarak yeniden adlandırmak, öznitelikleri Three.js'nin otomatik SkinningNode eklemesinden gizliyor; böylece matematiğin denetimi özel iskelet animasyonu malzemesinde kalıyor.

Hazırda bekleyen Durable Object aktarıcıları. Yalnızca ikili veri kullanan bir AvatarRoomDO, 36 baytlık kareleri çözmeden diğer tüm eşlere iletiyor; gönderenin kimliği karenin içine gömülüyor ve istemci kendi yankısını filtreliyor. Hazırda bekleyen WebSocket'ler sayesinde boşta duran bir odanın maliyeti olmuyor ve bu yapı 10 Hz'de eş-saat başına yaklaşık yarım sente mal oluyor; bu da eşdeğer yönetilen WebSocket fiyatlandırmasının çok altında. Oynatılan animasyon durumunu son kuyruğa alınan durum yerine karşılaştıran bir yinelenen ileti engelleme denetimi, durdurma mesajlarını sessizce düşürüyor ve uzaktaki oyuncuları yürüme döngüsünde takılı bırakıyordu.

HRTF ile WebRTC yakınlık sesi. Her eş için bir RTCPeerConnection kullanılıyor; teklif/yanıt rolleri eş kimliği sıralamasına göre belirleniyor. Ses, oyuncunun baktığı yöne göre her karede güncellenen bir AudioListener ile HRTF özellikli bir PannerNode üzerinden yönlendiriliyor ve Opus, dayanıklılık için bant içi FEC ile 128 kbps'e ayarlanıyor. Sessize alınmış, gizli bir <audio> öğesi Chrome'u yalnızca Web Audio kullanan akıştan paketleri çekmeye zorluyor.

Eksiltici ses mühendisliği. Meet/Teams kalitesini yakalamak, aşama eklemeyi değil kaldırmayı gerektirdi: makine öğrenimi tabanlı gürültü giderme, yankı engelleme, otomatik kazanç ve yumuşak bir kompresör kullanılırken geçit ve tıklama sınırlayıcı kullanılmadı; çünkü klavye gürültüsüyle eğitilmiş bir makine öğrenimi gürültü gidericisi, genlik kırpmayı gereksiz kılıyor. Bas-konuş, hecelerin kesilmemesi için parçayı açıp kapatmak yerine zincirin sonundaki bir GainNode değerini asimetrik bir zarfla kademeli olarak değiştiriyor. Gürültü giderici worklet'i ise yalın belirteçli içe aktarımların çözümlenmesi sorununu aşmak için kendi kendine yeten tek bir esbuild paketi olarak sunuluyor.

29 bölümün 23. bölümü. Önceki: Bölüm 22 - Aydınlatabileceğiniz bulutlar ve beslenmesi gereken ayıklama Sonraki: Bölüm 24 - Bir dünyayı kaydetmek ve görebileceğiniz rüzgâr Seri rehberi: /blog/2026-02-25-open-world-browser-series-guide

Yazan: Oleg Sidorkin, Cinevva CTO'su ve Kurucu Ortağı

Burada yeni misiniz? Seri rehberini kullanın. Bu rehber, spike'ın ne olduğunu açıklıyor ve tüm bölümlere bağlantı veriyor.

21. Bölüm, beklenen getiriyi sağlamayan bir render tekniği hakkındaydı. Bu bölümde işe yarayan bir teknik ve çalışabilmesi için dikkatli bir düzeltme gerektiren başka bir teknik var. Spike 43 gökyüzüyle ilgili: fizik tabanlı atmosfer ve hacimsel bulutlar, bir sahnenin teknoloji demosu yerine gerçek bir mekân gibi algılanmasını sağlayan temel. Spike 44 ise meshlet tarzı GPU ayıklama üzerine; buradaki ders, örtülme testinin ancak ona sunduğunuz örtücüler kadar iyi olduğuydu.

Gradyandan değil, fizikten gelen bir gökyüzü

Spike 43'ü yeni sekmede aç ↗ · Kaynak kodunu görüntüle

Neredeyse her sinematik hava efekti iki altyapı unsuruna bağlıdır: gökyüzü ve güneş renklerinin elle ayarlanmış bir gradyan yerine fiziğe göre günün saatini izlemesini sağlayan fizik tabanlı bir atmosfer ve gökyüzüne önceden hazırlanmış bir cubemap yerine üç boyutlu yapı kazandıran hacimsel bir bulut katmanı. Spike 43, mevcut WebGPU ve TSL yığını üzerinde tam olarak bu ikiliyi kuruyor, daha fazlasını değil; çünkü bu ikisi hazır olduğunda hava sisteminin geri kalanı (sis, tanrı ışınları, ıslak yüzeyler, kar) daha küçük ve bilinen devam işlerine dönüşüyor.

Atmosfer, WGSL compute shader'larında hesaplanan bir dizi arama tablosundan oluşan Hillaire 2020 modelini kullanıyor. Bir geçirgenlik tablosu, güneş ışığını Rayleigh, Mie ve ozon yoğunluk profili boyunca entegre ediyor ve yalnızca güneş hareket ettiğinde yeniden hesaplanıyor. Gökyüzü görünüm tablosu, bunu koşula bağlamak ek kod yazmaya değmeyecek kadar ucuz olduğu için her karede yeniden hazırlanıyor; bantlaşmayı önlemek amacıyla ufuk çevresinde doğrusal olmayan bir parametrelendirme kullanıyor. Çoklu saçılma şimdilik gerçek tablo yerine analitik bir yaklaşım kullanıyor ve gün batımları doğru göründüğü için bu kestirme yol kendini iyi gizliyor. Bulutlar, yatay bir katman boyunca ilerleyen Schneider Nubis tarzı bir ray-march kullanıyor. Biçimleri, 32³ Worley dokusuyla aşındırılan 128³ Perlin-Worley dokusundan geliyor; ikisi de ağdan veri çekilmeden açılışta compute ile hazırlanıyor. Işıklandırmada Beer yasası sönümlenmesi, çift loblu faz fonksiyonu ve pudra yaklaşımı kullanılıyor. Temel bağlantı, bulutun güneş renginin her adımda aynı geçirgenlik tablosundan örneklenmesi; böylece bulut aydınlatması ikinci bir ayar geçişine ihtiyaç duymadan gün batımını izliyor.

M1'de sistemin tamamı, yarım çözünürlüklü bulutlarla 1,1 ila 2,0 ms'de tamamlanıyor; yaklaşık 14 MB GPU belleği kullanarak 100 FPS'nin üzerinde çalışıyor ve 6 ms'lik bütçenin çok altında kalıyor. İki temel iddia da pratikte doğrulandı. Gün batımı, render sistemine sinematik bir his kazandıran başlıca sahne ve günün her saati için ayrı ayar yapmaya gerek kalmadan doğrudan fizikten ortaya çıkıyor. Ayrıca güzel bir tesadüf var: bulut katmanı 800 m ile 4000 m arasında parametrelendirildiğinde, alçak bir kameradan bakılan ufuktaki uzak bulutlar koyu dağ sırtları gibi görünüyor. Böylece kimsenin arka plan arazisi modellemesine gerek kalmadan dünyaya arka plan arazisi kazandırılıyor.

Saklanmaya değer bir mimari not. Doğal yaklaşım, önce gökyüzünü swap chain'e çizmek, ardından three.js'in autoClear = false ile geometrileri bunun üzerine çizmesine izin vermek. Ancak bu yöntem r184'teki WebGPU renderer ile çalışmıyor; çünkü bu bayrak, WebGL'de olduğu gibi renk yükleme işlemini denetlemiyor ve three.js her karede gökyüzünün üzerine yazıyor. Çözüm, three.js'i ekran dışı bir hedefe render etmek ve nihai kompoziti (mix(skyCloud, scene, scene.alpha), ardından ACES ve sonra sRGB) swap chain'in sahibi olan kendi geçişimizde gerçekleştirmek.

Ancak örtücüleri kadar iyi olan bir ayıklama sistemi

Spike 44'ü yeni sekmede aç ↗ · Kaynak kodunu görüntüle

Spike 44 dört render modunu birbiriyle karşılaştırıyor: düz ileri render, CPU küme ayıklaması, GPU compute ayıklaması ve Hi-Z örtülme ayıklaması kullanan bir görünürlük tamponu. İlginç olan Hi-Z yolu ve burada sessiz bir hata vardı: HUD, örtülmenin açık olduğunu söylüyordu ancak “Hi-Z tarafından elendi” sayacı sonsuza kadar tam olarak %0,0'da kalıyordu. Görüş hacmi ayıklaması çalıştığına göre ayıklama shader'ının önceki aşamaları sağlamdı. Örtülme kısmı ise tam maliyetine rağmen hiçbir şey yapmıyordu.

Hi-Z örtülme testi, bir kümenin sınırlayıcı kutusunu ekrana yansıtır, ekran dikdörtgeni yaklaşık 2×2 texel olacak şekilde bir derinlik piramidi mip seviyesi seçer, bu dikdörtgendeki en derin örtücü derinliğini örnekler ve kümenin en yakın noktası hâlâ bu örtücüden daha uzaktaysa kümeyi eler. Derinlik piramidi, mip 0'ın opak derinlik ön geçişinden başlatılıp yukarı doğru maksimum indirgeme uygulanmasıyla her karede oluşturulur. Opak ön geçiş kasıtlı olarak yalnızca katı örtücüleri, yani zemini ve her ağaç için gövde vekillerini içerir; çünkü alfa testli yapraklar, maksimum indirgemeyi yanıltan boşluklar açar.

Hata mantıksal değil, geometrikti. Gövde vekili 0,5 m × 4 m × 0,5 m boyutlarında bir kutuydu. 30 m uzaklıkta ekranda yaklaşık 17 piksele yansıyordu. Ancak tipik bir 50 m'lik çim kümesi, her texel'in 32 kaynak pikseli kapsadığı mip 5'i seçer. 17 piksellik bir gövde, tek bir mip-5 texel'ini tamamen kaplamaz; dolayısıyla gövdeye temas eden her texel çevredeki zemine de temas eder. Daha ilk 2×2 maksimum indirgeme, daha büyük derinlik değerini, yani gövdenin arkasındaki daha uzak zemini seçer ve gövdenin derinliği ilk indirgemede silinir. Mip 5'e gelindiğinde piramit neredeyse her yerde zemin derinliğini tutar, küme hiçbir zaman zeminden daha uzakta olmaz ve hiçbir şey örtülü sayılmaz.

Çözüm, vekili düştüğü texel'lere hâkim olacak kadar büyütmek ve boyutlarını ağacın odunsu kısmına değil silüetine göre belirlemektir. Yaklaşık 2 m × 6 m × 2 m boyutlarındaki bir vekil hâlâ gerçek taçtan daha küçüktür; dolayısıyla boşluklardan görünen yapraklar gereğinden fazla ayıklanmaz. Buna rağmen önemli mesafelere kadar maksimum indirgemeden sağ çıkacak kadar büyüktür ve örtülme sayacı hemen sıfırın üzerine çıkar. Buradan çıkan sonuç, üretim motoru için genel bir kurala dönüşüyor: Hi-Z örtücüsü olarak güvenilen her şey, ekrandaki silüetine göre boyutlandırılmalıdır. Çünkü açık bitki örtüsü sahnelerinde Hi-Z'nin etkinliğini derinlik testi matematiğinin zarafetinden çok, ilgili mip seviyesindeki örtücü kapsamı belirler. Bir çim yaprağı altındaki zeminle aynı derinlikte bulunduğundan çimin çimi örtmesi zaten mümkün değildir; asıl kazançlar ağaçların uzaktaki bitki örtüsünü ve diğer ağaçları örtmesinden gelir.

Bu bölümde değinilen teknolojiler

Hillaire 2020 atmosfer LUT'ları. Yalnızca güneş hareket ettiğinde yeniden hesaplanan bir geçirgenlik tablosu (güneş ışığının Rayleigh, Mie ve ozon profilinden geçişi) ile doğrusal olmayan ufuk parametrelendirmesine sahip, her karede hesaplanan bir gökyüzü görünüm tablosu; elle ayarlanmış bir gradyan olmadan günün saatini izleyen fizik tabanlı gökyüzü ve güneş renkleri sağlar. Bir artefakt gerçek tablonun hazırlanmasını zorunlu kılana kadar tam tablo yerine analitik bir çoklu saçılma yaklaşımı kullanılır. Gün batımı, günün her saati için ayrı ayar yapılmadan doğrudan fizikten ortaya çıkar.

Schneider Nubis hacimsel bulutları. Açılışta hazırlanmış ve 32³ Worley dokusuyla aşındırılmış 128³ Perlin-Worley dokusunun biçimlendirdiği yatay bir katman boyunca ray-march uygulanır; ışıklandırmada Beer yasası sönümlenmesi, çift loblu faz ve pudra terimi kullanılır. Bulutun güneş rengini her adımda aynı geçirgenlik tablosundan örneklemek, bulut aydınlatmasının gün doğumunu ve gün batımını hiçbir ek maliyet olmadan izlemesini sağlar. Standart üretim dengesi olarak yarım çözünürlüklü ray-march, tipik izleme mesafesinde görünür kalite kaybı olmadan tam çözünürlüğe göre yaklaşık 4 kat daha ucuza çalışır.

r184'te ham WebGPU'yu three.js ile birleştirme. Gökyüzünü swap chain'e çizip three.js geometrisini autoClear = false ile bunun üzerine render etmek başarısız olur; çünkü bu bayrak WebGPU arka ucunda renk yükleme işlemini denetlemez. three.js'i ekran dışı bir RGBA16F hedefine render edin ve nihai mix, ton eşleme ve sRGB işlemlerini swap chain'in sahibi olan bir geçişte gerçekleştirin.

Hi-Z örtülme ayıklaması ve örtücü boyutlandırma. Maksimum indirgemeyle oluşturulan bir derinlik piramidi, GPU ayıklama geçişinin en yakın noktası ekran dikdörtgenindeki en derin örtücünün arkasında kalan kümeleri elemesine olanak tanır. Örtücüler seçilen mip seviyesinde bir texel'e hâkim olamayacak kadar küçükse test sessizce hiçbir şey yapmaz; çünkü ilk maksimum indirgeme, örtücünün derinliğini onun arkasındaki daha uzak arka planla değiştirir. Örtücüler fiziksel çekirdeklerine göre değil, ekrandaki silüetlerine göre boyutlandırılmalıdır. Bkz. GPU güdümlü LOD.

29 bölümden 22.'si. Önceki: 21. Bölüm - Daha hızlı olmayan, daha hızlı bir renderer Sonraki: 23. Bölüm - Elli avatar ve odadaki bir ses Seri rehberi: /blog/2026-02-25-open-world-browser-series-guide

Cinevva CTO'su ve Kurucu Ortağı Oleg Sidorkin tarafından

Burada yeni misiniz? Seri rehberine göz atın. Rehber, spike'ın ne olduğunu açıklıyor ve tüm bölümlere bağlantı veriyor.

20. Bölüm, düz bir quad üzerinde yüzey derinliği yanılsaması oluşturdu. Bu bölüm bir render mimarisi kararıyla ilgili ve ders kitaplarındaki yanıtın donanımımız için yanlış çıktığı spike'ı ele alıyor. Soru şu: üçüncü şahıs kamerası altında sinematik yoğunlukta, alfa testli çimler için 200 oyunculu yoğunluğa geçmeden önce bir görünürlük tamponuna ihtiyacımız var mı? Genel kanı kesinlikle evet diyor. Biz bunu geliştirdik, ölçtük ve yanıtın hayır olduğunu gördük.

Herkesin önerdiği teknik

Spike 40'ı yeni sekmede aç ↗ · Kaynak kodunu görüntüle

Görünürlük tamponu, render işlemini iki geçişe ayırır. 1. geçiş geometriyi rasterleştirir ve hiçbir gölgelendirme yapmadan yalnızca üçgen ve örnek kimliklerini kompakt bir tamsayı hedefine, derinlikle birlikte yazar. 2. geçiş, kaplanan her pikseldeki kimlikleri okuyan, ilgili üçgenin köşelerini yeniden getiren, enterpole edilmiş öznitelikleri yeniden oluşturan ve görünür her pikseli tam olarak bir kez gölgelendiren tam ekran bir geçiştir. Vaat, aşırı çizimin kusursuz biçimde elenmesidir: derinlik testi, üzerinde hiçbir gölgelendirme işlemi yapılmamış fragmanlara uygulanır; böylece pahalı materyal yalnızca gerçekten gördüğünüz alanlarda çalışır.

Spike, tek canvas ve tek cihaz üzerinde iki yol çalıştırır; böylece tek değişken gölgelendirmenin nerede gerçekleştiğidir. İleri yönlü yol, three.js üzerinden normal bir MeshStandardNodeMaterial kullanır. Görünürlük tamponu yolu ise three.js dışında çalışan, iki geçişli ham bir WebGPU işlem hattıdır. Bu yol, three.js'in çim dokusunu doğrudan backend'den okur, 1. geçişte bir RG32Uint hedefine (instanceId, triId) yazar ve 2. geçişte aydınlatmayı çözümler. Her iki yol da aynı referans aydınlatma kurulumunu paylaşır.

Saklamaya değer iki uygulama notu var. WebGPU, fragman shader'larında hâlâ taşınabilir bir primitive_index yerleşik değerine sahip değil. Bu nedenle çözüm, indekslenmemiş geometriye köşe başına bir üçgen kimliği işleyip bunu flat enterpolasyonla okumaktır. Bu, köşe sayısını 3 katına çıkarır ancak 12 köşeli bir çim kartında maliyeti ihmal edilebilir düzeydedir. Ayrıca context'i hiçbir zaman yeniden yapılandırmadığınız veya canvas boyutlarına dokunmadığınız sürece canvas'ı three.js renderer'ıyla paylaşmak büyük ölçüde sorunsuzdur; çünkü bunların ikisi de three.js'in kontrolündedir. Zor olan kısım ileri yönlü yolu zamanlamaktı; çünkü three.js, render geçişinin içine GPU zaman damgası sorguları eklemek için herhangi bir hook sunmuyor. Geçici çözüm, ileri yönlü yolun çalışmasını önce ve sonra gönderilen, işlem yapmayan iki zaman damgası geçişiyle çevrelemekti. GPU bunları gönderim sırasına göre çalıştırır.

Rakamlar ters yönde ilerliyor

M serisi bir Mac'te, yaklaşık 1080p çözünürlükte ve 80 metrelik bir alana yayılmış çapraz kartlı çim yapraklarıyla:

50.000 örnekte görünürlük tamponu yolu %25 farkla kazandı: ileri yönlü yolun 5,51 ms'sine karşı 4,13 ms. 100.000 örnekte sonuçlar başa baştı. 200.000 örnekte ise ileri yönlü yol %44 farkla kazandı: görünürlük tamponunun 7,80 ms'sine karşı 5,44 ms. Yoğunluk arttıkça görünürlük tamponu yolu göreli olarak daha kötü hâle geliyor. Bu, tam da aşırı çizim yoğunlaştığında üstün gelmesi gerektiğini söyleyen yaygın kanının tam tersi.

İleri yönlü render neden dayanıklı kalıyor?

Apple Silicon GPU'lar karo tabanlı ertelenmiş renderer'lardır ve bu, tüm hesabı değiştirir. Bir TBDR üzerindeki ileri yönlü gölgelendirme, fragman shader'ından önce çalışan gizli yüzey kaldırma aşamasına sahiptir: rasterleştirici, bir karoya eşlenen her fragmanı toplar, derinliğe göre sıralar ve yalnızca hayatta kalanlar (alfa testinden sonra) fragman shader'ına ulaşır. Dolayısıyla ileri yönlü yol, görünürlük tamponunun “piksel başına bir kez gölgelendirme” vaadinin büyük kısmını zaten donanım içinde ücretsiz olarak karşılıyor. Yapraklar ekranı doldurdukça daha fazla fragman, herhangi bir gölgelendirme başlamadan önce HSR tarafından eleniyor ve ileri yönlü yolun piksel başına efektif maliyeti aşırı çizimle birlikte büyümek yerine kabaca sabit kalıyor.

Görünürlük tamponu yolunun 1. geçişi de aynı TBDR avantajından yararlanıyor. Sorunun tamamı 2. geçişte. 2. geçiş, her pikselin örnek matrisini bir tampondan okuyor. Bu tampon 200.000 örnekte 12,8 MB boyutunda ve herhangi bir GPU önbelleğinden çok daha büyük. Ekranda yan yana duran pikseller genellikle farklı çim örneklerine aittir; dağılım sapmalı bir ızgara olduğundan komşu yaprakların örnek kimlikleri gelişigüzeldir. Bu nedenle o tampona erişen her wave, uyumsuz erişimler nedeniyle önbelleği ıskalar. Bu tutarsız rastgele erişim, tek başına kare başına yaklaşık 4 ms harcar. İleri yönlü yol bundan tamamen kaçınır; çünkü örnek matrisi köşeyle birlikte örnek başına öznitelik yolu üzerinden gelir. Dolayısıyla fragman shader'ı çalıştığında dönüştürülmüş köşe verileri zaten karo içi yerel register'lardadır ve megabayt ölçeğinde rastgele okuma gerekmez.

Nanite'ın materyal sınıflandırma geçişi tam olarak bu maliyeti dağıtmak için vardır: pikselleri örneğe göre gruplandırır ve sıralanmış compute wave'leri gönderir; böylece her wave'in okumaları tutarlı olur. Bizde bu yok. Kabaca yapılan bir hesap, pikselleri örneğe göre sıralamanın bu 4 ms'yi yaklaşık 1,5 ila 2 ms'ye düşürebileceğini ve kesişme noktasını 400.000 ila 500.000 örneğe taşıyabileceğini gösteriyor. Ancak bu, en başta burada üstün gelmeyen bir mimarinin üzerine optimizasyonlar yığmak anlamına geliyor.

Dürüst sonuç ve bu sonucu güvenilir kılan denetim

Apple Silicon WebGPU'da alfa testli çapraz kart bitki örtüsü için three.js'in TSL işlem hattını kullanan ileri yönlü yolun maliyeti zaten görünürlük tamponuyla aynı seviyede veya daha düşük. Görünürlük tamponu altyapısı, 200.000 örneğin çok ötesine geçene kadar görünür hiçbir kazanç sağlamıyor; o noktada bile ayrıca bir sıralama veya gruplama geçişi eklemeniz gerekiyor. Üretim motoru için pratik karar, önceki spike'lardaki ileri yönlü render, LOD ve imposter yığınını korumak ve iki koşuldan biri gerçekleşene kadar görünürlük tamponu altyapısına yatırım yapmamak: baskın dağıtım hedefimiz, aşırı çizim maliyetinin daha doğrusal olduğu ayrık NVIDIA veya AMD GPU'lar hâline gelirse ya da görünürlük tamponunun zaten doğal çıktı olduğu bir meshlet mimarisine geçersek.

Bu sonuç sezgilere aykırı olduğu için karşılaştırma adil değilse çıkarımın hiçbir değeri yoktur. Bu nedenle spike kapsamlı bir denetimden geçti. Birkaç gerçek hata ortaya çıkarıldı ve düzeltildi: iki yolu sessizce birbirinden koparan bir yaprak ölçeği kaydırıcısı, anti-paralel normaller nedeniyle ileri yönlü yoldaki yaprakların yarısının zifiri karanlık render edilmesi (standart yukarı yönlü normal kullanan bitki örtüsü tekniğiyle düzeltildi) ve görünürlük tamponunun enerjiyi koruyan 1/π yerine elle seçilmiş bir Lambert katsayısı, sabit kodlanmış bir ortam terimi ve eksik ton eşleme nedeniyle yaklaşık 2 kat fazla parlak okuması. Düzeltme, three.js'in ACES filmik eğrisini eksiksiz olarak WGSL'ye kopyaladı ve her karede ışık renkleriyle yoğunluklarını gerçek sahne ışıklarından okuyor. Bilinen son eksiklik olan 2. geçişte doğrudan speküler yansımanın bulunmaması, karşılaştırmayı görünürlük tamponu lehine çarpıtıyor. Yani ileri yönlü yol piksel başına kesinlikle daha fazla iş yapıyor ve yine de yüksek yoğunlukta kazanıyor. Bu da ana sonucu iyimser değil, ihtiyatlı kılıyor. Geçerliliğini koruyan tek uyarı şu: bunların tamamı M serisine özgü ve ayrık bir ekran kartında kesişme noktası pekâlâ tersine dönebilir. Bu nedenle Apple dışı hedefler için teknoloji yığınını kesinleştirmeden önce testi yeniden çalıştırmaya değer.

Bu bölümde değinilen teknolojiler

Görünürlük tamponuyla render. 1. geçiş geometriyi rasterleştirir ve hiçbir gölgelendirme yapmadan yalnızca üçgen ve örnek kimlikleriyle derinliği yazar. 2. geçiş, kaplanan her piksel için kimlikleri okuyan, kaynak üçgeni yeniden getiren, perspektif düzeltmeli barycentrik öznitelikleri yeniden oluşturan ve her görünür pikseli bir kez gölgelendiren tam ekran bir çözümleme geçişidir. WebGPU taşınabilir bir fragman primitive_index değeri sunmadığından üçgen kimliği, indekslenmemiş geometri üzerinde flat enterpolasyonlu, köşe başına bir öznitelik olarak işlenir.

TBDR gizli yüzey kaldırma ile ertelenmiş çözümlemenin karşılaştırılması. Karo tabanlı ertelenmiş bir GPU'da (Apple Silicon), ileri yönlü gölgelendirme fragman shader'ı çalışmadan önce örtülen fragmanları zaten eler. Böylece görünürlük tamponunun tek seferlik gölgelendirme avantajının büyük kısmını ücretsiz olarak elde eder ve aşırı çizim arttıkça piksel başına maliyeti kabaca sabit kalır. Görünürlük tamponunun çözümleme geçişi ise örnek başına büyük bir tampona yapılan tutarsız rastgele erişimin maliyetini öder (200 bin örnekte 12,8 MB). Nanite'ın materyal sınıflandırmasında olduğu gibi pikseller önce örneğe göre sıralanmadığı veya gruplandırılmadığı sürece bu maliyet yüksek yoğunlukta baskın hâle gelir.

Bir canvas'ı three.js'in WebGPURenderer'ıyla paylaşmak. context.configure() işlevini yeniden çağırmadığınız veya canvas.width/height değerlerini değiştirmediğiniz sürece ham WebGPU komut tamponları, paylaşılan kuyrukta three.js gönderimleriyle doğru biçimde iç içe çalışır; çünkü bunların ikisi de renderer'ın kontrolündedir. three.js'in hook sunmadığı ileri yönlü yol GPU zamanlaması, render çağrısının çevresine gönderilen ve işlem yapmayan iki zaman damgalı render geçişiyle ölçülebilir; çünkü GPU komut tamponlarını gönderim sırasıyla çalıştırır.

Sezgilere aykırı bir benchmark'ı doğrulamak. Şaşırtıcı bir performans sonucu, ancak karşılaştırmanın adilliği kadar güvenilirdir. Her iki yolu da aynı sahne içeriği ve gölgelendirmeyle denetlemek (eşleşen ACES ton eşleme, enerjiyi koruyan Lambert, aynı nesnelerden okunan ışıklar ve aynı yaprak ölçeği), “görünürlük tamponu daha yavaş” sonucunu olası bir ölçüm hatası olmaktan çıkarıp savunulabilir bir sonuca dönüştürdü. Geriye kalan tek asimetri de sonucu ihtiyatlı yönde çarpıtıyor.

29 bölümün 21. bölümü. Önceki: 20. Bölüm - Düz bir düzlemde derinlik yanılsaması oluşturmak Sonraki: 22. Bölüm - İçinden uçabileceğiniz bulutlar ve karşılığını veren ayıklama Seri rehberi: /tr/blog/2026-02-25-open-world-browser-series-guide

Cinevva Teknoloji Direktörü ve Kurucu Ortağı Oleg Sidorkin tarafından

Burada yeni misiniz? Seri rehberine göz atın. Rehber, spike'ın ne olduğunu açıklıyor ve tüm bölümlere bağlantı veriyor.

19. Bölüm, uzaktaki bütün bir ağacı taklit etmek için düz bir dörtgen kullandı. Bu bölüm ise yakından derinlik yanılsaması yaratmak için düz bir dörtgen kullanıyor: tek bir ek tepe noktası bile harcamadan, parke taşlı bir yolu 5 cm derinliğinde derzlere sahipmiş gibi gösteren paralaks örtüşme eşleme tekniği. Amaç, bu tekniği üretim teknoloji yığınına (Three.js r184, WebGPU, TSL) taşımaktı; böylece arazi ayrıntı malzemeleri, önemli olduğu yerlerde bu derinlik yanılsamasını taşıyabilecek, diğer her yerdeyse düz doku maliyeti ödeyecekti.

Derinliği taklit etmenin üç yolu, yan yana

Spike 39'u yeni sekmede aç ↗ · Kaynak kodunu görüntüle

Spike, yan yana üç düz 5×5 m düzlem yerleştiriyor. Hepsi aynı malzeme iskeletini kullanıyor ve yalnızca örnekleyicileri besleyen UV bakımından farklılaşıyor. Düz yöntem, referans taban çizgisi olarak dokuyu doğrudan örnekliyor. Tek örnekli paralaks, UV'yi o noktadaki yüksekliğe göre görüş doğrultusunda bir kez kaydırıyor; bu yöntem ucuzdur ve düşük genlikte yeterince iyidir, ancak yatık açılarda kayar. POM ise teğet uzayında ışın yürütür: görüş ışını boyunca ilerler, ışının yükseklik alanının altına geçtiği ilk katmanı bulur ve kesişimi hassaslaştırır. Her test düzlemi eksenlerle hizalı olduğundan teğet uzayı basit kalır; böylece görüş yönü, tepe noktası başına tam bir TBN matrisi yerine birkaç işaret çevirmesiyle teğet uzayına aktarılır. Doku seti, 17. Bölüm'deki model aramasının kullandığı yolla aynı olan Polyhaven dosya API'sinden canlı olarak alınır.

WebGPU'da iki engel ve dallanmasız ışın yürütme

Klasik POM döngüsü, ilk kesişmede aramadan çıkar. r184'te bu, birbirinden ayrı iki nedenle çalışmıyor. If(...).and(...) hatasız derlendi ancak döngü gövdesinin hiç çalışmadığı bir WGSL üretti; dolayısıyla döngü sonrası hassaslaştırma çöp veri üzerinde çalıştı ve düzlem neredeyse beyaz görüntülendi. Ayrıca bağımsız bir düğüm olarak Break() henüz r184 derlemesine eklenmemişti. Bu yüzden çalışan bir If olsa bile "ilk kesişmede dur" ifadesini oluşturmanın bir yolu yoktu. Her iki sorun da three.js'in bu sürüm aralığında If ve Loop sınırları boyunca TSL kontrol akışını aşırı optimize etmesiyle ilgili bilinen sorunlara dayanıyor.

Yeniden yazılan sürüm dallanmasız. Her yineleme dokuyu koşulsuz olarak örnekliyor; böylece doku erişimi, WGSL belirtiminin istediği gibi tekdüze kontrol akışında kalıyor. Ardından yeni durum, kayan noktalı sayı olarak tutulan bir done bayrağı aracılığıyla birleştiriliyor. done değeri 1'e geçtiğinde, yineleme başına yapılan mix çağrıları "durumu değiştirmeden koru" işlemine dönüşüyor; bu da break işleminin dallanmasız karşılığı. done bayrağı, 0.5 + 0.5 × sign(x + ε) biçiminde uygulanan bir step yardımcısıyla oluşturuluyor; çünkü boolean değerlerden kayan noktalı sayılara dönüştürme r18x serisinde zaman zaman sorunlu oldu ve sign() her yerde güvenli. Bunun bedeli, gerçekte nerede kesiştiğine bakılmaksızın her parçanın 64 yinelemenin tamamını çalıştırması. Ancak parça ölçeğinde doğru tercih bu: çalışma zamanı zaten azami adım sayısını sınırlıyor ve gerçek bir GPU da "gerçek" bir break sonrasındaki işlemleri spekülatif olarak yürütebilir. Burada temiz bir geri dönüş önemli: son bir mix(baseUV, refined, done). Böylece sıfır genlikte, yani mesafe azalmasının uzak ucunda, hiçbir parça kesişmez, done 0 olarak kalır ve POM malzemesi bit düzeyinde düz yöntemle aynı olur. Mesafeye dayalı LOD numarasının amacı da tam olarak bu: etki zaten piksel altı düzeydeyken maliyeti düz doku maliyetine indirmek.

Hata matematikte değil, disiplin eksikliğindeydi

Dallanmasız sürüm çalıştı ancak bozuk görünüyordu: orta düzey genlikte çizgili yatay bozulmalar, düşük genlikteyse belli belirsiz yanlış ama net olmayan bir sonuç vardı. Düzeltme, tek satırlık bir istemden geldi: git ve standart referansı oku. Buna ilham veren LlamAcademy öğreticisi yalnızca bir Unity ShaderGraph düğümüydü; dolayısıyla gerçek uygulama Unity'nin PerPixelDisplacement.hlsl dosyasında bulunuyordu. Dosyayı satır satır okumak, farkında olmadan ortaya çıkardığım üç anlamsal farkı açığa çıkardı: ışın yüksekliği taban çizgisinde bir birimlik kayma (Unity döngüden önce ilk ilerlemeyi yapar; dolayısıyla benim referans çerçevem tam bir adım faz dışındaydı ve kesişimleri yaklaşık yarı yarıya yanlış katmana yerleştiriyordu), hassaslaştırma adımının dayandığı azami ofset işareti kuralı ve hassaslaştırma matematiğimi gereksiz yere zorlaştırıp işareti karmaşıklaştıran kümülatif ofset ile kümülatif UV kayıt yöntemi farkı.

Temel neden tek bir hata değil, iki referansı birbirine karıştırmaktı. Kılavuz olarak benzer ama farklı işaret kuralları ve farklı bir hassaslaştırma formülü kullanan LearnOpenGL POM öğreticisini almıştım. Sonuçta matematiğin üçte ikisinin bir kaynakla, üçte birinin diğer kaynakla eşleştiği melez bir durum ortaya çıktı. Yeniden yazılan sürüm, Unity'nin HLSL kodunun TSL'ye neredeyse birebir aktarımı: aynı değişken adları, aynı ilk ilerleme, aynı hassaslaştırma ve bunların üzerine eklenmiş dallanmasız done bayrağı. Çıkarılacak ders önemli: başka bir teknoloji yığınındaki çalıştığı bilinen bir gölgelendiriciyi aktarırken önce aynı adları kullanarak satır satır aktarın, ardından yerel stile göre yeniden düzenleyin. Aktarımın ortasında ikinci bir referansa bakarak formülü yeniden türetmeyin.

Yalan söyleyemeyen bir referans düzlemi

Yan yana karşılaştırmada bariz bir şey eksikti: gerçek geometrili bir düzlem. O olmadan "POM oldukça iyi görünüyor" iddiası yanlışlanamaz. Neye kıyasla oldukça iyi? Bu nedenle spike'a dördüncü bir düzlem eklendi: aynı yükseklik haritası, gerçek tepe noktası konumlarına uygulandı. WebGPU'da donanımsal mozaikleme yoktur (Metal uyumluluğu için çıkarıldığından belirtimde hiç yer almaz). Bu yüzden yerine, tepe noktası aşamasında yer değiştirme uygulanan yoğun biçimde alt bölümlere ayrılmış bir düzlem (256×256 segment, 131.072 üçgen) kullanıldı. Aynı genlik uniform'u hem POM'u hem de geometri düzlemini yönetiyor; böylece ikisi birlikte azalıyor ve her mesafede adil bir karşılaştırma yapılıyor.

Gerçek referans ekranda gösterildiğinde, nitel iddialar ölçülebilir hâle geldi. 16°'lik yukarıdan bakan bir yörünge açısında POM ile mozaiklenmiş düzlem, iç gölgelendirme konusunda uyuşuyor. Yatık açılardaysa ayrılmaları gereken yerde ayrılıyorlar: POM, geometrinin kusursuz düz dikdörtgen kenarına sıkışırken gerçek ağ, ışığı yakalayan gerçek tepe ve vadilerin oluşturduğu engebeli bir ufuk profili gösteriyor. Böylece POM'un kenar "kaymasının" doku veya aydınlatma kaynaklı bir artefakt değil, algoritmanın özünde bulunan bir özellik olduğu kanıtlanabiliyor. İki maliyet profili de açıkça görülüyor: POM parça sınırlıdır (maliyet, kaplanan piksel sayısıyla ölçeklenir), mozaiklenmiş düzlem ise tepe noktası sınırlıdır (maliyet, kapsama alanından bağımsız olarak ağ yoğunluğuyla ölçeklenir). Zaten yükseklik haritasıyla yönetilen bir düzlemin tepe noktası maliyetini ödeyen arazi parçasında, ağ altı ayrıntılar için doğru çözüm POM'dur.

Referans düzlemi ayrıca ince bir kullanıcı deneyimi hatasını da yakaladı. Kullanıcı, genlik arttıkça yüzeyin aşağı çöktüğünü fark etti. Bunun nedeni, Unity'nin geometrik düzlemi yükseklik alanının üstü olarak kabul eden kuralıydı; böylece tepeler düzlemle aynı hizada sabit kalırken diğer her şey paralaksla aşağı kayıyor ve ortalama yüzeyi (1 − mean_h) × amplitude kadar düz taban çizgisinin altına çekiyordu. Düzeltme, kuralı h = 0.5 düzleme karşılık gelecek şekilde yeniden merkezliyor; tepeler kameraya doğru yükselirken vadiler içeri çekiliyor. Algoritma tam olarak Unity'nin öngördüğü şekilde çalışıyor; spike yalnızca çıktıyı yarım ofset kadar sonradan işleyerek "genlik" kavramını kaydırıcıyı sürükleyen bir insanın bekleyeceği anlama getiriyor.

Referans düzleminin açıklığa kavuşturduğu bir konu daha vardı. "Adımlar" kaydırıcısı hiçbir şey yapmıyormuş gibi görünüyordu ve bu bir bağlantı hatası izlenimi veriyordu, ancak öyle değildi. Doğrusal aramadan sonraki üç yinelemeli sekant hassaslaştırması o kadar başarılıdır ki (Tatarchuk'un 2006 tarihli POM makalesi, 4 adımlı arama artı 3 adımlı sekant yönteminin görsel olarak 64 adımlı aramadan ayırt edilemediğini belirtir), pürüzsüz bir yükseklik haritasında 4 ile 64 arasındaki her adım sayısı aynı piksel altı UV'ye yakınsar. Çözüm, tesisatı yeniden kurmak değil bir açma-kapama düğmesi eklemekti: sekantı kapattığınızda adım kaydırıcısı kesişim hassasiyeti üzerindeki tek denetim hâline gelir; böylece 4'e düşürmek parke taşlarında gözle görülür basamaklanma yaratırken 64'e çıkarmak yüzeyi yeniden pürüzsüzleştirir. Düğme, kapalıyken her sekant durum güncellemesini mix ile işlemsiz hâle getiren bir 0/1 uniform'dur. Böylece geçiş yapmak malzemeyi hiçbir zaman yeniden oluşturmaz ve takılmaya yol açmaz.

Bu bölümde değinilen teknolojiler

TSL'de paralaks örtüşme eşleme. POM, teğet uzayında görüş yönünü bir yükseklik alanı boyunca ışın yürüterek tarar, ışının yüzeyin altına düştüğü ilk katmanı bulur ve kesişimi hassaslaştırır. Böylece ek geometri kullanmadan düz bir dörtgen üzerinde içeri gömülü harç derinliği oluşturur. Son bir mix(baseUV, refined, done), hiçbir parça kesişmediğinde malzemeyi bit düzeyinde düz yöntemle aynı hâle getirir. Mesafeye dayalı LOD genlik azaltımının uzakta maliyeti düz doku maliyetine indirebilmesini sağlayan da budur. Bkz. arazi malzemeleri.

WebGPU kontrol akışı için dallanmasız döngüler. Three.js r184'te TSL If(...).and(...), döngü gövdesi hiç çalışmayan bir WGSL çıktısına derlenebilir ve bağımsız Break() kullanılamaz. Taşınabilir kalıp, her yinelemede koşulsuz bir doku örneklemesi (WGSL belirtimine uygun olarak doku erişimini tekdüze kontrol akışında tutar) ve ayarlandıktan sonra her durum güncellemesini mix aracılığıyla işlemsiz hâle getiren, kayan noktalı sayı olarak tutulan bir done bayrağıdır. sign(x + ε) ile oluşturulan bir step yardımcısı, güvenilmez boolean-kayan noktalı sayı dönüşümünü önler. Maliyet, erken çıkış noktasından bağımsız olarak sabit azami yineleme sayısıdır; parça ölçeğinde doğru tercih budur.

Gölgelendiricileri birebir aktarma. Başka bir motordaki çalıştığı bilinen bir gölgelendirici önce özgün değişken adlarıyla satır satır aktarılmalı, yerel stile göre yeniden düzenleme daha sonra yapılmalıdır. İki referansı (Unity'nin PerPixelDisplacement.hlsl dosyası ile LearnOpenGL öğreticisini) karıştırmak; bir birim kaymış ışın taban çizgisine, ters çevrilmiş ofset işaretine ve sınırlandırması aralık dışı ağırlıkları uzamsal süreksizlikler olarak gizleyen bir hassaslaştırma formülüne sahip melez bir sonuç üretti. Yeniden türetme değil, tek bir standart gerçeklik kaynağı kullanılmalı.

Tepe noktası yer değiştirmeli gerçek referans. WebGPU'da donanımsal mozaikleme olmadığından, tepe noktası aşamasında yer değiştirme uygulanan yoğun biçimde alt bölümlere ayrılmış bir düzlem (256² segment), parça aşamasındaki taklidi doğrulamak için gerçek geometri yerine geçer. Her ikisini de aynı genlik uniform'uyla yönetmek, mesafe boyunca karşılaştırmanın adil kalmasını sağlar. POM parça sınırlıdır (kaplanan piksel sayısıyla ölçeklenir), geometri düzlemi ise tepe noktası sınırlıdır (ağ yoğunluğuyla ölçeklenir). Bu nedenle tam olarak silüet kenarlarında ayrışırlar ve POM'un kenar kaymasının bir artefakt değil, tekniğin özünde bulunan bir özellik olduğunu kanıtlarlar.

29 bölümün 20.'si. Önceki: 19. Bölüm - Bir ormanda hayatta kalması gereken imposter Sonraki: 21. Bölüm - Daha hızlı olmayan daha hızlı bir işleyici Seri rehberi: /tr/blog/2026-02-25-open-world-browser-series-guide

Oleg Sidorkin, Cinevva Teknoloji Direktörü ve Kurucu Ortağı

Burada yeni misiniz? Seri rehberine göz atın. Rehber, spike'ın ne olduğunu açıklıyor ve tüm bölümlere bağlantı veriyor.

18. Bölüm, içerik üreticilerine bir yamacı ağaçlarla dolduran bir fırça sundu. Ancak ekranda on binlerce ağaç olduğunda bunların maliyeti sorun hâline geliyor. Uzaktaki bir ağacın dört piksele katkıda bulunmak için 2.000 üçgene ihtiyacı yoktur. Bu bölüm, en uç LOD seviyesini ele alıyor: Üzerinde ağacın fotoğrafını taşıyan düz bir dörtgen olan imposter ve “doğru görünen tek bir ağaçtan” GPU üzerindeki bir milyon ağaca uzanan yol.

Bir ağaç, billboard üzerindeki iki dokudur

Spike 38'i yeni sekmede aç ↗ · Kaynak kodunu görüntüle

Bir imposter, bir nesneyi farklı bakış açılarından oluşan bir ızgara üzerinden önceden render ederek biri renk, diğeri dünya uzayı normalleri için olmak üzere iki doku atlasına dönüştürür. Ardından çalışma zamanında, mevcut görüşle eşleşen döşemeyi örnekleyen ve kameraya dönük tek bir dörtgen gösterir. Pişirme işlemi her döşeme için iki geçişten oluşur: Aydınlatmanın dokuya işlenmemesi için ışıksız bir malzemeyle diffuse geçişi ve silüetin piksel piksele eşleşmesi için kaynak alfayı aktaran, normalWorld × 0.5 + 0.5 olarak kodlanmış normal geçişi. Çalışma zamanı malzemesi tam bir MeshStandardNodeMaterial olduğundan imposter, diğer tüm yüzeyler gibi sahnenin güneş ışığını ve IBL'sini almaya devam eder. Kazanç geometridedir: Binlerce üçgen yerine tek bir dörtgen ve ayrıntıları taşıyan 1 MB'lık bir doku.

Bunu ayrı bir spike'a taşımak başlı başına bir dersti. Imposter, spike 37'nin dağıtım sistemindeki en uç LOD olarak başlamıştı ve pişirme üzerindeki her yinelemenin; pişirme doğruluğunun örnek matrislerinin taşınması ve LOD geçişleriyle iç içe geçtiği tam dağıtım hattı üzerinden test edilmesi gerekiyordu. Sistemi tek bir nesneye, tek bir dörtgene ve yanında duran orijinal modele ayırmak, yineleme süresini dakikalardan saniyelere indirdi.

Ders kitabındaki yanıt yanlış olduğunda

İlk uygulama, küre yönlerini bir kareye paketlemek için kullanılan klasik eşleme yöntemi olan oktahedral kodlamayı kullanıyordu. Sayısal gidiş-dönüş testlerini geçmesine rağmen kullanıcı, imposter'ın tam karşıdan değil de ağaca hafifçe yukarıdan bakıyormuş gibi görünen bir döşemeye geçtiğini gösteren ekran görüntüleri göndermeyi sürdürüyordu. Ardından altı düzeltme turu geldi (dörtgen başına görüş yönü uniform'u, kare pişirme en-boy oranı, hata ayıklama malzemeleri ve statik billboard yönelimi); bunların her biri gerçekten gerekliydi ama hiçbiri asıl hatayı çözmüyordu. Çözüm ancak “baştan düşün, KISS, geçici yama yok” yaklaşımıyla geldi.

Yeniden yazım, oktahedral katlamayı kaldırıp sade azimut-yükseklik yöntemini kullandı: az = atan2(dir.x, dir.z), el = asin(dir.y), uv = (az/2π, el/π + ½). Kodlamanın tamamı bundan ibaret; L1 normalizasyonu ve sıfırın işaretiyle ilgili köşe durumları yok. Burada daha iyi olmasının nedeni daha doğru olması değil (küreyi daha az düzenli örnekler), CPU'daki hücre seçicinin ve GPU shader'ının aynı temel işlemleri kullanmasıdır. Böylece oktahedral çiftin sessizce yaptığı gibi bir sınır yönünde anlaşmazlığa düşemezler. Atlas bir kontak baskı gibi okunur: Sütun nesnenin çevresindeki açıyı, satır ise yüksekliği gösterir ve overlay üzerinde bir bakışta anlaşılır.

Bundan sonra bile “hafifçe yukarıdan görünüyor” şikâyeti devam etti ve neden kodlama değil, bir niceleme tercihiydi. 4×4 ızgarada satır merkezleri ±22,5° ve ±67,5°'ye denk gelir; dolayısıyla tam 0° yükseklikte bir satır yoktur. Açık ara en yaygın durum olan yatay yönde bakan bir izleyici, her zaman eğimli olarak pişirilmiş bir satıra düşer. Çözüm tek N'dir: 5×5 ızgarada satır merkezleri 0°, ±36° ve ±72°'ye denk gelir; böylece yatay izleyici, tam yatay açıyla pişirilmiş bir döşeme alır. Aynı “yarım hücrelik kayma” hatası ailesi, sonraki bölümün paralaks çalışmasında yeniden karşımıza çıkıyor ve çözümü yine aynı soruda yatıyor: Standart girdi için ayrık örnekleme noktam gerçekten düşündüğüm yere denk geliyor mu?

İki unsur daha önemliydi. Billboard sürekli kameraya dönmek yerine parçalı-statik olmalıdır. Imposter, belirli bir pişirme yönünden çekilmiş düz bir fotoğraftır; bu nedenle çalışma zamanı dörtgeninin görüntü düzlemi, ilgili pişirme kamerasının düzlemiyle eşleşmelidir. Bu da tek bir hücrenin seçili kaldığı yay boyunca yönelimini koruyup sınırda aniden geçiş yapması anlamına gelir. Ayrıca bütçe, oyuncuların gerçekte baktığı yerlere göre dağıtılmalıdır: Daha sonraki bir geçiş, eğimli tepeden görünüm satırlarını tamamen kaldırarak bunların yerine 15° aralıklı 24 yatay halka yuvası ve doğrudan tepeden görünüm için tek bir döşeme kullandı; çünkü ağaçlara neredeyse her zaman göz hizasından bakılır.

Ani geçiş ve harmanlamanın bunu ortadan kaldırması

Spike 42'yi yeni sekmede aç ↗ · Kaynak kodunu görüntüle

Parçalı-statik billboard uzakta fark edilmez ancak yakından bakıldığında ani geçiş yapar; kamerayla çevresinde dönene kadar bu kabul edilebilir. Spike 42, titreşimi izole edip ortadan kaldırmak için dört varyantı yan yana yerleştirdi: Orijinal nesne, azimut/yükseklik 5×5 temel sürümü ve iki hemi-oktahedral ızgara. Ani geçişe iki artefakt neden olur. Hücre sıçraması, fragment shader'ın görüş yönünü 25 hücreden birine nicelemesi nedeniyle oluşur; dolayısıyla bir sınır geçildiğinde örneklenen döşeme değiştirilir ve dörtgen aynı karede yeniden yönlendirilir. Kutup tekilliği ise her azimutun tek bir noktada birleştiği tepeden görünümdür; halka ile tepe döşemesi arasındaki köprü, atlastaki en kötü geçiştir.

Hemi-oktahedral eşleme her ikisini de düzeltir. Üst yarımküreyi sürekli biçimde birim kareye eşler; böylece komşu 3B yönler komşu UV'lere denk gelir, kutup tekilliği ortadan kalkar ve tepeden görünüm için özel bir döşemeye gerek kalmaz. Titreşimin çözümü bilineer hücre harmanlamadır: En yakın döşemeye aniden geçmek yerine, kodlanmış yönü çevreleyen 2×2'lik döşeme grubu bulunur ve dördü birden harmanlanır; toplamda 8 doku örneği alınır (4 diffuse, 4 normal). Böylece komşu görünümler aniden değişmek yerine çapraz geçiş yapar. İki birim vektörün normal harmanı kendi başına birim uzunlukta olmadığından yeniden normalleştirilir; bu da komşu döşemeler arasındaki küçük açılar için slerp gibi davranır. Maliyeti kayda değerdir (12×12 atlas, azimut/yükseklik atlasının 1,6 MB'ına karşılık yaklaşık 9 MB'tır ve pişirme 288 render-target geçişiyle yaklaşık 5 kat daha uzun sürer), ancak pişirme yükleme sırasında bir kez yapılır ve harmanlama ani geçişsiz bir sonuç sağlar. Kameranın gerçekten hareket ettiği sırada imposter'ları kullanılabilir kılan da budur.

Bir milyon ağaç, kare başına tek kamera konumu kopyası

Spike 41'i yeni sekmede aç ↗ · Kaynak kodunu görüntüle

Spike 38'in çalışma zamanı, her dörtgen için her karede bir CPU lookAt işlemi gerçekleştirir. Bu, tek bir ağaç için sorun değildir ancak bir orman için ölümcüldür. Bir milyon ağaçta kare başına matris güncellemeleri ve instance tamponu yüklemeleri diğer her şeyin önüne geçerdi. Spike 41, kare başına işleme hattının tamamını GPU'ya taşır. Her instance'ın merkezi, yaw değeri ve ölçeği, oluşturma sırasında instanced attribute olarak bir kez yüklenir ve bir daha değişmez. Vertex shader, dünya uzayındaki camPos − center görüş yönünden billboard tabanını oluşturur ve paylaşılan birim dörtgeni dünya uzayına genişletir. Fragment shader, hemi-oktahedral kodlamayı ve bilineer harmanlamayı piksel başına gerçekleştirir. Tüm orman için kare başına yapılan tek CPU işi, kamera konumu uniform'unu güncelleyen bir Vector3.copy işlemidir ve bu maliyet ağaç sayısıyla birlikte artmaz.

Matematiğin hoş bir yanı, instance başına yaw değerinin normal çözümlemede birbirini götürmesidir. Pişirme, normalleri pişirme kamerasının koordinat sisteminde saklar. Dünya yukarı ekseni etrafındaki yaw dönüşü +Y'yi koruduğundan ve vektörel çarpım dönüşle uyumlu olduğundan, dünya yukarı referansıyla oluşturulan çalışma zamanı tabanı zaten döndürülmüş pişirme tabanına eşittir. Böylece shader, instance başına yaw değerine hiç dokunmadan normalleri doğrudan çalışma zamanı tabanının varying'leri üzerinden çözümler. Yerleştirme, tamamen rastgele dağıtım yerine jitter uygulanmış bir ızgara kullanır: Alan hücrelere bölünür ve her hücrenin merkezine sınırlı bir ofset eklenerek bir ağaç yerleştirilir. Bu yöntem, doğal bir orman görünümünü korurken minimum aralığı garanti eder; hiçbir ağaç diğerinin üzerine gelmez. Gözden kaçırılması kolay bir ayrıntı da sınırlayıcı küredir. Geometri şablonu yalnızca birim dörtgenden oluştuğundan three.js, kamera orijinden uzaklaştığı anda tüm ormanı görüş hacminin dışında sayardı. Tüm alanı ve bir dörtgenlik kenar payını kapsayan açık bir sınırlayıcı küre ayarlamak, köşelerdeki ağaçların eğik açılarda kesilmesini önler.

Bu bölümde kullanılan teknolojiler

Oktahedral ve azimut-yükseklik imposter atlasları. Bir imposter, bir nesneyi görüş yönlerinden oluşan bir ızgara üzerinden diffuse atlasına ve dünya uzayı normal atlasına pişirir; ardından eşleşen döşemeyi örnekleyen tek bir billboard render ederek binlerce üçgeni iki dokuyla değiştirir. Klasik oktahedral eşleme küreyi düzenli biçimde kapsar ancak katlama sınırlarında CPU/GPU ayrışmasına yatkındır. Sade bir azimut-yükseklik ızgarası küreyi daha az düzenli örnekler ancak hücre seçiciyle shader'ın yapısal olarak aynı sonucu vermesini garanti eder. Bir satırın tam 0° yüksekliğe denk gelmesi için tek N kullanın ve nesneler çoğunlukla göz hizasından görüldüğü için döşeme bütçesini yatay halkaya ayırın.

Parçalı-statik billboard yönelimi. Imposter belirli bir pişirme yönünden çekilmiş bir fotoğraf olduğundan çalışma zamanı dörtgeninin görüntü düzlemi, sürekli olarak çalışma zamanı kamerasına dönmek yerine pişirme kamerasının düzlemiyle eşleşmelidir. Dörtgen, tek bir hücrenin seçili kaldığı yay boyunca yönelimini korur ve sınırda aniden geçiş yapar. Bu, imposter mesafesinde fark edilmez ve yalnızca imposter'ların zaten kullanılmadığı yakın mesafede görünür.

Bilineer hücre harmanlamalı hemi-oktahedral atlas. Üst yarımküreyi sürekli biçimde birim kareye eşlemek, kutup tekilliğini ve özel tepeden görünüm döşemesini ortadan kaldırır. Ani geçiş; kodlanmış görüş yönünü çevreleyen 2×2'lik döşeme grubunun örneklenmesi ve dört döşemenin de bilineer olarak harmanlanmasıyla (8 örnek) yok edilir. Böylece komşu görünümler çapraz geçiş yapar. Harmanlanmış normaller yeniden normalleştirilerek döşemeler arasındaki küçük açı boyunca yaklaşık bir slerp elde edilir. Bunun karşılığında daha büyük bir atlas (12×12'de yaklaşık 9 MB) ve daha uzun süren tek seferlik bir pişirme gerekir; ancak kamera hareket ederken ani geçişsiz gölgelendirme sağlanır.

GPU güdümlü instanced imposter'lar. Instance başına merkez, yaw ve ölçek değerleri instanced attribute olarak bir kez yüklenir; vertex shader billboard tabanını oluşturup paylaşılan birim dörtgeni genişletir, fragment shader ise kodlama ve harmanlamayı piksel başına gerçekleştirir. Tüm orman için kare başına CPU maliyeti, instance sayısından bağımsız olarak tek bir kamera konumu uniform kopyasıdır. Dünya yukarı ekseni etrafındaki yaw, vektörel çarpım tabanının oluşturulması tarafından korunduğu için instance başına yaw değeri normal çözümlemede birbirini götürür. Ormanın tamamını kapsayan açık bir sınırlayıcı küre, kamera birim dörtgen şablonunun orijininden uzağa baktığında three.js'in tüm instanced mesh'i görüş hacminin dışında saymasını önler. Bkz. GPU güdümlü LOD.

29 bölümün 19. bölümü. Önceki: 18. Bölüm - Yapay zekâyla yerleştirilmiş hissi veren bir dağıtım fırçası Sonraki: 20. Bölüm - Düz bir yüzeyde derinlik yanılsaması yaratmak Seri rehberi: /tr/blog/2026-02-25-open-world-browser-series-guide

Yazan: Oleg Sidorkin, Cinevva CTO'su ve Kurucu Ortağı

Birkaç hafta önce modern AAA oyunlarda gerçekten kullanılan render teknikleri hakkında yazmıştım. Gökyüzü ve hava durumu konusunu kısa geçtim, çünkü kendi listesini hak ediyor. Bulutlar, sis, yağmur ve kar, bir arazi demosunu gerçek bir mekâna dönüştüren sistemlerdir. Ayrıca göründüğünden çok daha fazla ortak kod kullanırlar. Hacimsel bulutlar, yer sisi ve tanrısal ışınların hepsi aynı ışın yürütme tekniğine dayanır. Islak yollar, kar birikimi ve ayak izi izlerinin hepsi aynı yer değiştirme ve PBR hilesini kullanır. Rüzgâr ise sahnedeki her şeyin kullandığı tek bir yön vektörüdür.

İşte büyük stüdyoların 2026'da bu sistemleri nasıl geliştirdiğine dair, her parçanın arkasındaki makaleler ve oyun motoru sunumlarıyla birlikte kısa ve öznel bir tur.

1. Fizik tabanlı gökyüzü ve atmosfer

Atmosferik saçılma işin temelidir. Gökyüzünün rengi, ufuktaki pus, uzaktaki dağların maviye dönüşmesi ve gün batımının turuncusu; bunların tümü ışığın havada saçılmasından kaynaklanır. Modern oyun motorları bunu fizik kurallarına göre hesaplar: mavi renk için Rayleigh saçılması, güneş çevresindeki pus için Mie saçılması ve zenitteki koyu mor için ozon soğurumu.

Bruneton'ın 2008'de geliştirdiği özgün yöntem, her şeyi 4B arama tablolarına önceden işliyordu; bu da dinamik günün saati sistemlerini sınırlıyor ve güneşin alçak açılarında LUT yapaylıklarına yol açıyordu. UE5'in Sky Atmosphere bileşeninde kullanılan Sébastien Hillaire'in 2020 tarihli güncellemesi, yüksek boyutlu LUT'yi birkaç 2B doku ve kare başına güncellenen bir çoklu saçılma yaklaşımıyla değiştiriyor. Telefondan üst düzey PC'ye kadar her yerde çalışıyor.

Derinlemesine kaynaklar:

• Hillaire, Ölçeklenebilir ve Prodüksiyona Hazır Bir Gökyüzü ve Atmosfer Render Tekniği (EGSR 2020, UE5'te kullanılan modern standart).
• Bruneton ve Neyret, Önceden Hesaplanmış Atmosferik Saçılma (EGSR 2008, özgün LUT yaklaşımı).
• Bruneton, Önceden Hesaplanmış Atmosferik Saçılma: Yeni Bir Uygulama (açık kaynaklı referans; ozon ve çoklu gezegen desteği).
• Epic Games, Sky Atmosphere Bileşeni (UE5 belgeleri).

2. Perlin-Worley gürültüsüyle hacimsel bulutlar

Modern oyunlardaki temel bulut tekniği, Andrew Schneider'in 2015 tarihli Horizon Zero Dawn sunumuyla başladı. Bulutlar mesh değildir. Katmanlı gürültüyle tanımlanan bir 3B yoğunluk fonksiyonudur: düşük frekanslı bir Perlin-Worley karışımı bulutun genel şeklini oluştururken daha yüksek frekanslı Worley gürültüsü, silüeti aşındırarak ince ve tüylü kenarlara dönüştürür. Bir hava durumu haritası (dünya XZ koordinatlarıyla örneklenen 2B bir doku), her bölgenin bulut örtüsünü, bulut türünü ve yağışını kontrol eder. Yüksekliğe dayalı bir gradyan ise irtifaya göre kümülüs, stratus ve sirüs profilleri arasında geçiş yapar.

Render sistemi, kameradan bulut hacminin içine doğru bir ışın yürüterek yoğunluk ve saçılmayı biriktirir. 2017'deki "Nubis" iterasyonu, bölgesel ölçekte içerik oluşturma ve animasyon özellikleri ekledi; özgün PS4 uygulaması ise tüm gökyüzünü yaklaşık 2 ms'de işliyordu. Günümüzde hacimsel bulut kullanan çoğu stüdyonun tekniğinin kökeni hâlâ bu makaleye dayanır.

Derinlemesine kaynaklar:

• Schneider, Horizon Zero Dawn'ın Gerçek Zamanlı Hacimsel Bulut Manzaraları (SIGGRAPH 2015, temel referans).
• Schneider, Nubis: Decima Engine ile Gerçek Zamanlı Hacimsel Bulut Manzaraları Oluşturma (SIGGRAPH 2017, bölgesel ölçekli devam çalışması).
• Hillaire, Frostbite'ta Fizik Tabanlı Gökyüzü, Atmosfer ve Bulut Render'ı (SIGGRAPH 2016, Frostbite sürümü).
• Häggström, Hacimsel Bulutların Gerçek Zamanlı Render'ı (tam shader koduyla sade ve anlaşılır bir tez).

3. Voksel bulutlar ve Nubis³

Nubis'in 2023'teki evrimi, gerçek 3B vokseller lehine 2.5B şekil temsilini tamamen terk etti. Her voksel bulut yoğunluğunu doğrudan depoluyor; böylece sanatçılar bulut şekillerini araziyi yontar gibi biçimlendirip canlandırabiliyor. Daha yoğun bir temsile geçmenin maliyeti, sıkıştırılmış işaretli uzaklık alanlarıyla ışın yürütmenin hızlandırılması ve seyrek voksel verilerinin akıllıca yüksek çözünürlüğe çıkarılması sayesinde telafi ediliyor.

Sonuç olarak, temeldeki hilelerin dağıldığını görmeden içinden uçabileceğiniz türde bulut manzaraları ortaya çıkıyor. Çoğu stüdyo için gereğinden fazla olsa da üst düzey teknolojinin ilerlediği yön bu.

Derinlemesine kaynaklar:

• Schneider, Nubis³: Sarmalayıcı Gerçek Zamanlı Voksel Tabanlı Bulutları Modelleme ve Render Etme Yöntemleri (ve Çılgınlığı) (SIGGRAPH 2023, voksel bulut sunumu).
• Schneider, Nubis'in Evrimi (SIGGRAPH 2022, 2.5B ile tam 3B arasındaki köprü).
• Schneider, Gerçek Zamanlı Hacimsel Efektler ve VFX (Andrew'nun ders notları ve çözümlemeler içeren kişisel sitesi).

4. Katmanlı bulut render'ı ve 2B arka planlar

Her stüdyonun tam hacimsel bulutlara ayıracak bütçesi yoktur ve her kamera açısı da buna ihtiyaç duymaz. Birçok oyun farklı teknikleri birleştirir: yüksek irtifadaki sirüsler kayan bir 2B katman olarak, orta irtifadaki kümülüsler hacimsel ışınlarla, alçak irtifadaki stratuslar ise ince bir katılımcı ortam tabakası olarak işlenir. Ufukta genellikle, hacimsel geçişin belirli bir solma mesafesinden sonra harmanlandığı, önceden işlenmiş bir gökyüzü küp haritası kullanılır.

Bulut bütçesini makul tutan şey bu katmanlamadır. Tek bir bulut türü tam kalitede 4-6 ms tüketebilir; farklı bulut irtifalarında farklı kalite seviyelerini katmanlamak, aynı görünümü yarı maliyetle koruyabilir.

Derinlemesine kaynaklar:

• Vos, Horizon Zero Dawn'ın Gerçek Zamanlı Hacimsel Bulut Manzaraları (GDC 2016 videosu, katmanlama çözümlemesi ikinci yarıda).
• Bauer, Red Dead Redemption 2'nin Atmosferik Dünyasını Yaratmak (SIGGRAPH 2019, RDR2'nin birleşik gökyüzü/bulut/hacimsel efekt iş akışı).
• Hillaire, REDengine 4'te Hacimsel Bulutlar ve Mega Parçacıklar (GDC 2025, Cyberpunk 2077'nin bulut iş akışı).

5. Froxel ızgaralarıyla hacimsel sis

Sis, 2B bir ekran efekti değil, 3B bir alandır. Standart modern yaklaşım froxel ızgarasıdır: kameranın görüş frustum'una hizalanmış, her hücresinde ("froxel" = frustum + voxel) yoğunluk ve aydınlatılmış renk depolanan 3B bir doku. Bir compute shader, tüm ışık kaynaklarından gelen saçılmayı ızgaraya enjekte eder, görüş ışını boyunca sönümü biriktirir ve sonucu tam ekran geçişi olarak uygular.

Pencerelerden süzülen ışık huzmelerini, noktasal ışıkların çevresindeki renkli sisi ve patlamaların etrafındaki görünür hacimleri oluşturan şey budur. Aynı zamanda uzaktaki nesneleri havayla bütünleştirerek solduran "atmosferik perspektifin" altında yatan mekanizmadır. Teknik, Assassin's Creed 4 için Bart Wronski tarafından geliştirildi ve Frostbite'ta Sébastien Hillaire tarafından standartlaştırıldı.

Derinlemesine kaynaklar:

• Wronski, Hacimsel Sis: Atmosferik Saçılma için Birleşik Compute Shader Tabanlı Çözüm (SIGGRAPH 2014, özgün froxel ızgarası makalesi).
• Hillaire, Frostbite'ta Fizik Tabanlı ve Birleşik Hacimsel Render (SIGGRAPH 2015, prodüksiyon kalitesindeki uygulama).
• Kovalovs, The Last of Us Part Two'nun Hacimsel Efektleri (SIGGRAPH 2020, zamansal jitter ve derinlik uyumlu kompozitleme notlarıyla).
• Wright ve diğerleri, Lumen: Unreal Engine 5'te Gerçek Zamanlı Küresel Aydınlatma (SIGGRAPH 2022, Lumen'ın hacimsel sisle etkileşimini de içerir).

6. Tanrısal ışınlar ve alacakaranlık huzmeleri

Puslu havada görülebilen güneş ışınları ayrı bir efekt değildir. Sis yoğunluğu ve gölge haritası aynı compute shader tarafından kullanılabildiği sürece aynı sis sisteminin doğal bir sonucu olarak ortaya çıkarlar. Shader bir froxel'e ışık enjekte ettiğinde, o froxel'in dünya konumundaki gölge haritasını örnekler. Gölgedeki hücreler karanlık kalırken aydınlıktaki hücreler güneşin rengini alır. Kamera ışını sonuç boyunca yürütüldüğünde parlak hücreler kesintisiz ışık huzmeleri oluşturur.

Daha ucuz ekran uzayı çeşitleri de vardır (güneş konumundan derinlik tamponuna doğru radyal bulanıklaştırma) ve mobil ya da düşük seviye donanımlarda hâlâ doğru tercihtir. Ekran dışındaki güneş konumlarını yakalayamazlar ancak maliyetleri yok denecek kadar azdır.

Derinlemesine kaynaklar:

• Mitchell, Post-Process Olarak Hacimsel Işık Saçılması (GPU Gems 3, ekran uzayı radyal bulanıklaştırma yaklaşımı).
• Engelhardt ve Dachsbacher, Katılımcı Ortamlarda Gölgeler ve Alacakaranlık Işınları için Epipolar Örnekleme (I3D 2010, daha isabetli GPU tekniği).
• Vos, Killzone: Shadow Fall'da Hacimsel Işık Efektleri (SIGGRAPH 2014, gölge entegrasyonuna sahip prodüksiyon sürümü).

7. Şimşek ve stokastik hava olayları

Şimşek, iki parçadan oluşan tek karelik bir efekttir: yıldırım mesh'i ile sahne genelindeki ton eşleme ve aydınlatma tepkisi. Yıldırımın kendisi genellikle özyinelemeli çizgi parçası bölme algoritmasıyla oluşturulan, kaotik görünmesi için konumları saptırılmış ve yere doğru incelen prosedürel bir billboard mesh'idir. Bazı oyun motorları bunu ekran uzayında eklemeli bir parlama olarak işlerken diğerleri, dünyaya tek karelik bir noktasal ışık enjeksiyonu aracılığıyla ışık saçan, tamamen aydınlatılmış emissive geometri olarak işler.

Asıl ilginç kısım diğer her şeydir: bulutların altı aşağıdan aydınlanır, zemin iki kare boyunca parlar, otomatik pozlama ölçümü birkaç karede toparlanır ve mesafeye bağlı olarak gecikmeli bir gök gürültüsü sesi çalınır. İyi uygulandığında bu yaklaşım, 16 ms'lik bir parlamayı beş saniyelik bir sekansa dönüştürerek hava durumunun yalnızca dünyanın üzerinde değil, dünyanın içinde gerçekleşen bir olay olduğu hissini verir.

Derinlemesine kaynaklar:

• Reed ve Wyvill, Yıldırımın Görsel Simülasyonu (SIGGRAPH 1994, herkesin hâlâ kullandığı özyinelemeli yıldırım algoritması).
• Kim ve Lin, Uyarlanabilir Mesh Kullanarak Hızlı Yıldırım Animasyonu (IEEE TVCG 2007, fiziksel açıdan daha temellendirilmiş).
• Bauer, Red Dead Redemption 2'nin Atmosferik Dünyasını Yaratmak (SIGGRAPH 2019, şimşek zamanlaması dâhil RDR2'nin fırtına iş akışı).

8. Yağmur parçacıkları, yağmur mesh'leri ve ekran uzayı damlaları

Modern oyunlarda yağan yağmur nadiren yalnızca parçacıklardan oluşur. Ucuz ve ikna edici çözüm; dikey ya da ekrana hizalı dörtgenler üzerine gerilmiş, sahnedeki diğer her şeyle aynı güneş ve gökyüzü probları tarafından aydınlatılan, kayan az sayıda doku kullanmaktır. Kameraya yaklaştıkça bağımsız çizgi parçacıkları ayrıntı katar. Kamera merceğinin üzerindeyse damlacık dokuları, kayan izler ve çarpma dalgaları, "fırtınanın içindesiniz" hissini güçlendirir.

Rüzgâr, yağmurun yönünü etkiler. Aynı rüzgâr vektörü bulutların hava durumu haritasını iter, çimleri büker ve yağmur dörtgenlerini eğer. Sahne genelinde tek bir vektör, onlarca tüketici.

Derinlemesine kaynaklar:

• Tatarchuk, Şehir Ortamlarında Sanatçı Tarafından Yönlendirilebilir Gerçek Zamanlı Yağmur İşleme (EGSR 2006, katmanlı yağmur için temel referans).
• Garg ve Nayar, Yağmur İzlerinin Fotogerçekçi İşlenmesi (SIGGRAPH 2006, ışığın yağmur damlalarından geçiş fiziği).
• Wojciechowski, Cyberpunk 2077'de Yağmur (GDC 2021, modern bir prodüksiyon incelemesi).

9. Islak yüzeyler, su birikintileri ve halkalar

Zemini değiştirmeyen yağmur hemen yapay görünür. Islak yüzeyler; albedolarını koyulaştırarak (su, gelen ışığı emer), normal haritalarını düzleştirerek (su tabakası mikro yüzeyi pürüzsüzleştirir) ve pürüzlülüklerini azaltarak (su, eğik açılarda neredeyse kusursuz bir aynadır) tepki verir. Gölgelendiricideki değişiklik küçük, görsel değişiklik ise çok büyüktür.

Su birikintileri maskelerle yönlendirilir: yüksekliğe dayalı veya köşe noktalarına boyanmış bir maske, "ıslaklık" parametresi yükseldikçe suyla dolacak alçak noktaları tanımlar. Halkalar, yağmur damlalarının çarpmasıyla tetiklenen flipbook normal haritası dokularıdır. Gerçekten iyi uygulamalarda ıslaklık durumu zaman içinde birikir; böylece uzun bir yağmur fırtınası dünyayı yavaşça sırılsıklam ederken kısa bir sağanak yalnızca yüksek noktaları koyulaştırır.

Derinlemesine kaynaklar:

• Lagarde ve de Rousiers, Frostbite'ı Fizik Tabanlı İşlemeye Taşımak 3.0, bölüm 5.5 (SIGGRAPH 2014, ıslak yüzeyler için temel PBR ayarlamaları).
• Lagarde, Fizik Tabanlı Bir Gölgelendirme Modelini Benimsemek (ıslak PBR matematiğini içeren özgün blog serisi).
• Cyanilux, Yağmur Efektlerinin İncelenmesi (su birikintileri, halkalar ve damlacıklar hakkında anlaşılır bir Shader Graph rehberi).

10. Kar birikimi ve deformasyonu

Kar, yağmurun simetrik problemidir: dünya onu yalnızca almakla kalmamalı, hatırlamalıdır da. Standart yaklaşım, gökyüzünün görünür olduğu her yerde zaman içinde biriken, üstten görünüşlü bir "kar birikimi" dokusu kullanır (üstten görünüşlü bir derinlik veya gölge haritasına göre hesaplanır). Arazi gölgelendiricisi bu maskeyi örnekler ve gölgeli bölgelerde kar malzemesini, açıkta kalan alanlarda ise kar derinliğine göre yer değiştirmeyi harmanlar.

Ayak izleri ve lastik izleri, oyuncuyu merkez alan kayan bir deformasyon haritasına işlenir. Kamera hareket ettikçe eski ayak izleri kayarak görünümden çıkar ve doku döngüsel olarak sarılır. Arazi veya kar gölgelendiricisi bu deformasyon haritasını örnekler ve yazılmış noktalardaki köşe noktalarını aşağı iter. Battlefield 5'in kar sistemi bunu donanım mozaikleme ile yapar; daha düşük maliyetli yaklaşımlar yalnızca köşe noktası yer değiştirmesiyle birlikte yüksek yoğunluklu bir arazi ağı kullanır.

Derinlemesine kaynaklar:

• Barré-Brisebois, Battlefield 5 ile Uygulamalı Deneyim: Küçük Şeyler Neden Önemlidir? (Frostbite kar sisteminin prodüksiyon incelemesi).
• St-Amour, Gerçek zamanlı kar deformasyonu (GPU uygulamasının tüm ayrıntılarını içeren bir tez).
• Andersson, Prosedürel Gölgelendirici Katmanlaması Kullanarak Frostbite'ta Arazi İşleme (kar birikiminin üzerine kurulduğu katman sisteminin temeli).

11. Küresel bir sistem olarak rüzgâr

Rüzgâr bir parçacık efekti değildir. Prodüksiyon motorlarında, her dinamik sistemin köşe noktası gölgelendiricisinden okuduğu tek bir küresel vektördür (bazen düşük çözünürlüklü bir 3B alandır). Çimen yaprakları eğilir, ağaç dalları sallanır, kumaşlar dalgalanır, yapraklar sürüklenir, yağmur eğik yağar, duman taşınır ve bulutların hava durumu haritaları kayar. Kare başına güncellenen tek bir uniform değer, onlarca tüketici.

Daha gelişmiş sürüm, dünya konumuna göre örneklenen yön ve şiddeti depolayan bir "rüzgâr ızgarasıdır"; bu sayede yerel rüzgâr darbeleri, korunaklı vadiler ve binaların ardındaki iz akımları bulunan fırtınalar oluşturulabilir. Ayrıca aynı ağaçların eşzamanlı sallanmaması için bitki örtüsüne genellikle içerik üretimi sırasında köşe noktası başına bir ofset işlenir. Sonuç, aynı ritimde nefes alan bir dünyadır.

Derinlemesine kaynaklar:

• McAuley, Far Cry 4 Dünyasının İşlenmesi (GDC 2015, Far Cry 4'ün bitki örtüsü rüzgâr ızgarasını içerir).
• Habel ve Wimmer, Billboard Bulutları Kullanarak Manzaraların Gerçekçi ve Gerçek Zamanlı İşlenmesi (eski bir kaynak olsa da rüzgârın bitki örtüsü üzerindeki etkisine ilişkin matematik değişmedi).
• Frostbite, Horizon Zero Dawn'ın Bitki Örtüsü (SIGGRAPH 2017, rüzgâr sistemi mimarisiyle birlikte).

12. Kum fırtınaları, tipiler ve yoğun hava olayları

Şiddetli hava olayları başlı başına bir işleme kategorisidir. Kum fırtınası; güçlü bir yönsel eğilime ve yoğun uzaklık sisine sahip, kalın, opak ve zemine hizalı bir sistir. Tipi, buna kameraya yakın bir parçacık hücumu ve azalan görüş mesafesi ekler. Volkanik kül ve duman da farklı renklerle aynı mimariyi kullanır.

Bunları inandırıcı kılan parçacıklar değil, bağlantıdır: güneş kararır, gökyüzünün tonu değişir, son işleme renk derecelendirmesi kayar, ortam sesleri değiştirilir, ayak sesi efektleri farklılaşır ve oyuncunun sesi varsa boğuklaşır. İşleyici yalnızca habercidir; sürükleyicilik, oyundaki her sistemin aynı anda tepki vermesinden doğar.

Derinlemesine kaynaklar:

• Burley, Uncharted: The Lost Legacy'nin Gerçek Zamanlı Gökyüzü ve Atmosferi (GDC 2018, yoğun hava olaylarının bileşimine ilişkin notlarla).
• Khalifa, Forza Horizon 5'te Atmosferik Hava Efektleri (GDC 2022, modern açık dünya hava sistemi).
• Karis, Unreal Engine 5 "Lumen in the Land of Nanite" Demosunun Arkasındaki Teknoloji (SIGGRAPH 2021, mağaradaki toz sahnesinin hacimsel efekt yığını).

13. Günün saati ve dinamik gökyüzü

Gerçek zamanlı gün döngüsü, bu listedeki diğer tüm sistemleri yayınlamaya değer kılan çarpandır. Güneşin yönü ve rengi, 24 dakikalık veya 24 saatlik bir döngü boyunca güncellenir. Atmosfer LUT'si güneş açısıyla birlikte güncellenir. Bulut aydınlatması her karede yeniden hesaplanır. Gölge kademeleri yeniden yönlendirilir. Yansıma probları yenilenir. Ortam rengi değişir. Son işleme pozlaması uyum sağlar.

Bunu görünür yapaylıklar olmadan gerçekleştirmek, büyük ölçüde doku önbellekleme ve zamansal kararlılık meselesidir. Hızlı teknikler, gökyüzünü sabit güneş açılarında önceden hesaplayıp aralarında enterpolasyon yapar; daha yavaş teknikler ise her karede yeniden hesaplar. Hillaire'in 2020 atmosfer modeli yeniden hesaplama için yeterince hızlıdır; UE5'in bunu kullanmasının nedeni de budur. Bulut hava durumu haritası rüzgârla birlikte kayar; böylece kimsenin anahtar kareler hazırlamasına gerek kalmadan bulutluluk doğal biçimde değişir.

Derinlemesine kaynaklar:

• Hillaire, Ölçeklenebilir ve Prodüksiyona Hazır Bir Gökyüzü ve Atmosfer İşleme Tekniği (EGSR 2020, dinamik gün döngüsü tartışmasıyla birlikte).
• Pesce, Gerçek Zamanlı Gökyüzü İşleme: Teknikler ve Ödünleşimler (Ray Tracing Gems II bölümü, modern bir genel bakış).
• Bauer, Red Dead Redemption 2'nin Atmosferik Dünyasını Oluşturmak (SIGGRAPH 2019, 24 saatlik işlem hattıyla birlikte).

14. Hava durumu durum makinesi

Tüm bunların altında küçük bir durum makinesi vardır. Çoğu oyun; her biri bulutluluk ve bulut türü, rüzgâr hızı ve yönü, yağış türü ve yoğunluğu, ortam rengi tonları, ses profili ve son işleme renk derecesi gibi parametrelerle tanımlanan 4 ila 12 hava durumu durumuyla (açık, parçalı bulutlu, kapalı, hafif yağmur, şiddetli yağmur, gök gürültülü fırtına, sis, kar, tipi, kum fırtınası) yayınlanır.

Geçişler, 30 ila 120 saniye boyunca parametre kümeleri arasında yapılan doğrusal enterpolasyonlardır. Geçiş özel bir durum değildir; yalnızca iki durumun doğrusal olarak harmanlanmasıdır ve her işleme alt sistemi o karedeki mevcut parametre değerlerini okur. Hava durumu betiklenebilir (bir ara sahne fırtına gerektirir), seed değeriyle üretilebilir (oyun içindeki her gün ve bölge için deterministik olur, böylece aynı dünyadaki iki oyuncu aynı hava durumunu görür) veya tamamen bir bölge ızgarası üzerinde tasarlanabilir. En temiz işlem hatları, üçünü de aynı parametre arabelleğine yazan farklı zamanlayıcılar olarak ele alır.

Derinlemesine kaynaklar:

• Bauer, Red Dead Redemption 2'nin Atmosferik Dünyasını Oluşturmak (SIGGRAPH 2019, hava durumu durum işlem hattıyla birlikte).
• Khalifa, Forza Horizon 5'te Atmosferik Hava Efektleri (GDC 2022, parametre harmanlama yaklaşımıyla birlikte).
• Schneider, Horizon Zero Dawn'ın Gerçek Zamanlı Hacimsel Bulut Manzaraları (SIGGRAPH 2015, hava durumu haritasıyla yönlendirilen bulut evrimiyle birlikte).

15. Sinematik anlar

Tüm bu sistem yığını birkaç özgün an için vardır. Bir fırtına cephesi yaklaşırken bir sırtın üzerinde durmak. Güneş ışığının ağaç örtüsündeki bir açıklığı delip geçtiğini izlemek. Bir mağaradan çıkıp kara adım atmak. Bir kümülüs bulutunun içinden uçarken içerideki ışığı görmek.

Bunlar, oyuncuların ekran görüntülerini aldığı anlardır. Aynı zamanda yukarıdaki her sistemin eşzamanlı çalışması gereken anlardır: bulut hacimleri, atmosferik saçılma, gölge entegrasyonlu sis, ıslak PBR, bitki örtüsündeki rüzgâr, günün saatine bağlı renk derecelendirmesi ve hava durumları arasındaki geçiş; bunların tümü tek karede bir araya gelir. Bunlardan birini bile yanlış yaparsanız büyü bozulur.

Bunun tarayıcı için anlamı

Bu tekniklerin çoğu WebGPU'ya doğrudan uyarlanabilir. Açık dünya tarayıcı motorunda temel atmosferik sisi, eşdikdörtgensel skybox harmanlamasını ve ekran uzayında uzaklık pusunu kullanıma sunduk. Arazi işlem hattı artık kararlı olduğuna göre daha zor parçalar (tam hacimsel bulutlar, froxel ızgaralı sis, dinamik su birikintilerine sahip ıslak PBR, kar deformasyon haritaları) sıradaki bariz adımdır. Spike 24'ün skybox'tan parça başına sis rengi örneklemesi bu yapbozun bir parçasıdır. Aynı atmosfer LUT'sine veri sağlayan, compute shader tabanlı bir bulut raymarcher ise bir sonraki adımdır.

İyi haber şu ki tarayıcı donanımlarının alt sınırı artık yeterince yüksek. WebGPU compute, 3B dokular, dolaylı dispatch ve zaman damgası sorgularının tümü mevcut. Hillaire'in 2020 atmosferi birçok kez WebGL'ye taşındı. Schneider'ın Nubis sistemi, mekanik düzenlemelerle WGSL'ye çevrilebilen açık kaynaklı GLSL referans uygulamalarına sahip. Artık bir tarayıcı oyununun konsol oyunuyla aynı gökyüzüne sahip olamaması için işlemeye dayalı bir neden yok. Yalnızca mühendislik nedenleri var ve mühendislik nedenleri bizim sevdiğimiz türden.

Tüm sistem yığını hakkında ek kaynaklar

Tüm bunları bir araya getiren tek bir kaynak istiyorsanız SIGGRAPH'ın "Advances in Real-Time Rendering in Games" arşivi (advances.realtimerendering.com), 2014'e kadar uzanan temel hava durumu ve atmosfer sunumlarını içerir. Belirli oyunların gökyüzünü ve hava durumunu nasıl işlediğine dair prodüksiyon incelemeleri için Adrian Courrèges'in GPU profilleme makaleleri, GTA V, Horizon Zero Dawn ve Doom Eternal'ın ayrıntılı kare kare çözümlemelerini içerir. Özellikle gökyüzü ve atmosfer matematiği için scratchapixel.com'un hacim işleme bölümü en anlaşılır giriş kaynağıdır; Hillaire'in açık kaynaklı uygulama deposu ise prodüksiyon kalitesindeki referanstır.

Oleg Sidorkin, CTO ve Cinevva Kurucu Ortağı

2026 yapımı bir AAA oyunun render işlem hattını açıp incelerseniz bulacağınız şeylerin çoğu, farklı stüdyoların oyunlarında kullanılan küçük bir teknik kümesine dayanır. İsimler oyun motorları arasında değişse de temel fikirler aynıdır. İşte ekrandaki asıl işi yapan tekniklerin kısa bir listesi; her biri için bir görsel ve birkaç ayrıntılı teknik kaynakla birlikte.

1. Fizik tabanlı render (PBR)

Malzemeler albedo, pürüzlülük, metaliklik, normal ve ortam örtme dokularıyla tanımlanır; enerjiyi koruyan gölgelendiricilerle (Cook-Torrance yansıması, Lambert veya Disney yayınık yansıması) aydınlatılır. Bu, tüm modern AAA oyun motorlarının temel aldığı standarttır. Bir yüzey güneş ışığı, lamba ışığı ve el feneri altında tutarlı görünüyorsa bunun nedeni PBR'dır.

Ayrıntılı kaynaklar:

• Burley, Disney'de Fizik Tabanlı Gölgelendirme (orijinal "Disney BRDF" ders notları, SIGGRAPH 2012).
• Karis, Unreal Engine 4'te Gerçekçi Gölgelendirme (SIGGRAPH 2013, temel UE4 PBR sunumu).
• Lagarde ve de Rousiers, Frostbite'ı Fizik Tabanlı Render 3.0'a Taşımak (SIGGRAPH 2014, eksiksiz Frostbite işlem hattı).
• Gerçek Zamanlı Render, 4. baskı, 9. bölüm (temel ders kitabı kaynağı).

2. Ertelenmiş gölgelendirme ve görünürlük tamponu gölgelendirmesi

Geometri önce öznitelikleri (normaller, malzeme kimlikleri, derinlik) bir G-buffer'a veya görünürlük tamponuna yazar. Aydınlatma, bu tamponları okuyup her pikseli bir kez gölgelendiren tam ekran bir geçiş olarak çalışır. Görünürlük tamponları (Nanite ve benzeri sistemlerde kullanılır) yalnızca üçgen kimliklerini depolayıp malzeme parametrelerini daha sonra piksel başına çözümleyerek bunu daha da ileri taşır; böylece yoğun geometrilerde üst üste çizim maliyeti düşük kalır.

Ayrıntılı kaynaklar:

• Engel, Ertelenmiş Gölgelendirme (NVIDIA, alanın temelini atan sunum).
• Burns ve Hunt, Görünürlük Tamponu: Ertelenmiş Gölgelendirmeye Önbellek Dostu Bir Yaklaşım (JCGT 2013, orijinal görünürlük tamponu makalesi).
• Wihlidal, "Grafik İşlem Hattını Compute ile Optimize Etmek" (GDC 2016, Frostbite'ın compute tabanlı ertelenmiş render yolu).
• Karis, Stubbe, Wihlidal, Nanite Sanallaştırılmış Geometriye Derinlemesine Bakış (SIGGRAPH 2021, Nanite görünürlük tamponunu ayrıntılarıyla ele alır).

3. Sanallaştırılmış geometri (Nanite tarzı)

Mesh'ler önceden bir küme hiyerarşisi hâlinde oluşturulur. Çalışma zamanında GPU, her pikselin çözünürlüğüne uygun kümeleri seçip akışla yükler; böylece manuel LOD'lara gerek kalmadan piksel altı hassasiyetinde ayrıntı elde edilir. Unreal'ın Nanite sistemi bunun en bilinen örneğidir. Diğer oyun motorları da artık kendi türevlerini sunuyor. Pratikte bunun sonucu, LOD hazırlamaya gerek kalmadan film kalitesinde varlıkların gerçek zamanlı kullanılmasıdır.

Ayrıntılı kaynaklar:

• Karis, Stubbe, Wihlidal, Nanite Sanallaştırılmış Geometriye Derinlemesine Bakış (SIGGRAPH 2021).
• Brian Karis, Nanite GDC 2021 sunumu (kolay anlaşılır bir video anlatımı).
• Liktor, Activision'da Geometri Render İşlem Hattı Mimarisi (küme tabanlı render, 2021).
• Schied ve diğerleri, Uzamsal-Zamansal Varyans Güdümlü Filtreleme (ilgili küme ayıklama teknikleri).

4. Gölgeler, yansımalar ve AO için gerçek zamanlı ışın izleme

Donanım hızlandırmalı ışın izleme (DXR, Vulkan RT), her karede oluşturulan bir BVH üzerinde gölge ışınlarını, aynasal ve parlak yansıma ışınlarını ve ortam örtme ışınlarını izler. Özellikle ekran dışındaki yansımalar ve temas gölgeleri söz konusu olduğunda, piksel başına birkaç ışın bile ekran alanı tekniklerinin yapabildiklerini aşar. Çoğu oyun bunu her şey için değil, seçici biçimde kullanır.

Ayrıntılı kaynaklar:

• Microsoft, DirectX Raytracing (DXR) İşlevsel Spesifikasyonu (API kaynağı).
• Wyman, DirectX Raytracing'e Giriş (SIGGRAPH ders notları, oldukça anlaşılır).
• Boksansky ve Marrs, Ray Tracing Gems II, 17-19. bölümler (ücretsiz PDF, modern DXR teknikleri).
• Stachowiak, Stokastik Ekran Alanı Yansımaları (Frostbite, SSR'dan RT'ye geçiş köprüsü).

5. Yazılım tabanlı ışın izleme (Lumen tarzı)

Her oyuncuda RTX kartı bulunmadığından oyun motorları mesafe alanı veya yüzey önbelleği tabanlı yedek çözümler de sunar. Örneğin Unreal'ın Lumen sistemi, düşük maliyetli yayınık GI için işaretli mesafe alanları ve yüzey önbellekleri üzerinde izleme yapar; yalnızca gerektiğinde donanım ışınlarına geçer. AAA oyunların konsollarda "ışın izlemeli görünüm" elde etmesini sağlayan yöntem budur.

Ayrıntılı kaynaklar:

• Wright ve diğerleri, Lumen: Unreal Engine 5'te Gerçek Zamanlı Küresel Aydınlatma (SIGGRAPH 2022, Lumen makalesi).
• Epic Games, Lumen Teknik Ayrıntıları (resmî oyun motoru belgeleri).
• Wright, Gerçek Zamanlı Küresel Aydınlatma için Işınım Önbellekleme (SIGGRAPH 2021).
• Wright, Lumen GDC 2022 sunumu (video sürümü).

6. ReSTIR ve rezervuar örnekleme

Binlerce ışık kaynağıyla doğrudan ve dolaylı aydınlatma için ReSTIR (Reservoir Spatio-Temporal Importance Resampling), ışık örneklerini pikseller ve kareler arasında yeniden kullanır. Path Tracing etkinleştirilmiş Cyberpunk 2077 gibi oyunların piksel başına bir veya iki ışınla gürültüyü düşük tutabilmesini sağlayan teknik budur. Yol izleme üst düzey hedef hâline geldikçe bu tekniği daha fazla oyun motorunda görmeyi bekleyebilirsiniz.

Ayrıntılı kaynaklar:

• Bitterli ve diğerleri, Dinamik Doğrudan Aydınlatmayla Gerçek Zamanlı Işın İzleme için Uzamsal-Zamansal Rezervuar Yeniden Örneklemesi (SIGGRAPH 2020, orijinal ReSTIR makalesi).
• Ouyang ve diğerleri, ReSTIR GI: Gerçek Zamanlı Yol İzleme için Yol Yeniden Örneklemesi (HPG 2021, dolaylı aydınlatma için ReSTIR).
• Lin ve diğerleri, Genelleştirilmiş Yeniden Örneklenmiş Önem Örneklemesi (SIGGRAPH 2022, matematiksel temeller).
• NVIDIA, Cyberpunk 2077 Yol İzleme Teknolojisine Derinlemesine Bakış (mühendislik blogu).

7. Hacimsel bulutlar, sis ve atmosfer

Gökyüzü, 3B gürültü ve yoğunluk hacimleri içinde ışın yürütülerek oluşturulur. Atmosfer, güneş ile ay geçişleri için önceden hesaplanmış saçılma tablolarını (Bruneton tarzı) kullanır. Sis ise yerel aydınlatmayı yakalayan bir froxel ızgarasıdır (görüş frustum'uyla hizalanmış bir 3B doku gibi düşünebilirsiniz). Bunlar birlikte bir skybox yerine "sistem olarak hava durumu" sunar.

Ayrıntılı kaynaklar:

• Schneider, Horizon Zero Dawn'ın Gerçek Zamanlı Hacimsel Bulut Manzaraları (SIGGRAPH 2015, temel bulut kaynağı).
• Hillaire, Ölçeklenebilir ve Üretime Hazır Bir Gökyüzü ve Atmosfer Render Tekniği (EGSR 2020, UE5'te kullanılan modern Bruneton ardılı).
• Wronski, Hacimsel Sis: Atmosferik Saçılma için Birleşik Compute Shader Tabanlı Çözüm (SIGGRAPH 2014, Assassin's Creed 4'ün froxel sisi).
• Hillaire, Frostbite'ta Fizik Tabanlı ve Birleşik Hacimsel Render (SIGGRAPH 2015).

8. Kademeli gölge haritaları ve sanal gölge haritaları

Güneş gölgeleri için kademeli gölge haritaları, frustum'u aralıklara böler ve her birini uygun çözünürlükte render eder. Sanal gölge haritaları bunu daha da ileri taşır: Tek bir dev gölge haritası sayfalara bölünür ve yalnızca kameradan görülebilen sayfalar render edilir. AAA oyunların devasa bir bellek maliyetine katlanmadan oyuncunun yakınındaki gölgeleri keskin tutmasını sağlayan yöntem budur.

Ayrıntılı kaynaklar:

• Dimitrov, Kademeli Gölge Haritaları (NVIDIA teknik incelemesi, standart kaynak).
• Microsoft, Gölge Derinlik Haritalarını İyileştirmeye Yönelik Yaygın Teknikler (DirectX belgeleri).
• Wright, Fortnite Battle Royale 4. Bölüm'de Sanal Gölge Haritaları (SIGGRAPH 2023, UE5 VSM sunumu).
• Epic Games, Sanal Gölge Haritaları belgeleri.

9. Ekran alanı efektleri (SSAO, SSR, SSGI, SSSSS)

Derinlik ve normal tamponlarını düşük maliyetle okuyarak ortam örtme (SSAO), yansımalar (SSR), tek sekmeli küresel aydınlatma (SSGI) ve cilt için yüzey altı saçılma (SSSSS) elde edebilirsiniz. Bunlar ekran dışındaki ayrıntıları kaçırır; ışın izlemenin öne çıkmasının nedeni de budur. Yine de hızlı bir temel çözüm olarak hâlâ her yerde kullanılırlar.

Ayrıntılı kaynaklar:

• Mittring, Yeni Nesli Bulmak: CryENGINE 2 (SIGGRAPH 2007, orijinal SSAO makalesi).
• McGuire ve diğerleri, Ölçeklenebilir Ortam Gölgelenmesi (HPG 2012, modern SSAO).
• Stachowiak ve Uludag, Stokastik Ekran Alanı Yansımaları (Frostbite, temel SSR kaynağı).
• Jimenez, Ayrılabilir Yüzey Altı Saçılması (çoğu AAA oyun motorunda cilt için kullanılan teknik).
• Mara ve diğerleri, Derin Ekran Alanı (Activision, SSGI'ın öncüllerinden).

10. Zamansal kenar yumuşatma ve makine öğrenmesiyle çözünürlük yükseltme (DLSS, FSR, XeSS)

Kare, daha düşük bir dahili çözünürlükte render edilir ve hareket vektörleri, derinlik ve geçmiş kareler kullanılarak yeniden oluşturulur. Makine öğrenmesi tabanlı çözünürlük yükselticiler (DLSS 3/4, FSR 3, XeSS) buna ek olarak optik akıştan ara kareler üreten kare oluşturma özelliğini sunar. Günümüzde çoğu AAA oyun, bir çözünürlük yükselticinin etkin olduğu varsayımıyla yayımlanıyor; bu da karenin geri kalanı için performans bütçesinin nasıl ayrıldığını değiştiriyor.

11. GPU güdümlü işleme ve mesh shader'ları

Ayıklama, LOD seçimi ve çizim komutlarının gönderimi tamamen GPU üzerinde çalışır. Mesh shader'ları, tepe noktası/geometri/mozaikleme işlem hattının yerini meshlet'ler üreten, daha esnek ve hesaplama tarzında bir aşamayla değiştirir. Çoklu dolaylı çizimle birleştirildiğinde CPU'yu nesne başına çalışan kritik döngünün tamamen dışında tutar.

Derinlemesine okumalar:

• Haar ve Aaltonen, GPU Güdümlü İşleme Hatları (SIGGRAPH 2015, temel Assassin's Creed Unity sunumu).
• Wihlidal, Grafik İşlem Hattını Hesaplamayla Optimize Etmek (GDC 2016, Frostbite'ın GPU güdümlü ayıklama sistemi).
• Kubisch, Turing Mesh Shader'larına Giriş (NVIDIA, mesh shader'larına giriş).
• Pesce, Mesh Shader'larında Hızlı Bir Tur (ve Adrian Courrèges'in RenderDoc çözümlemelerinde derlenen benzer mühendislik blogları).

12. Saç, kumaş ve cilt işleme

Saçlar, tel tabanlı geometriyle birlikte Marschner tarzı anizotropik gölgelendirme kullanır (NVIDIA HairWorks, AMD TressFX veya oyun motoruna özgü sistemler). Kumaşlar, konum tabanlı dinamiklerle GPU üzerinde simüle edilir ve anizotropik yansımayla işlenir. Ciltler, ekran uzayı yüzey altı saçılımı ile önceden tümleştirilmiş sarmal aydınlatma kullanır. AAA ile bağımsız yapımlar arasındaki bütçe farkını genellikle en belirgin biçimde bu üç alanda görürsünüz.

Derinlemesine okumalar:

• Marschner ve diğerleri, İnsan Saçı Liflerinden Işık Saçılımı (SIGGRAPH 2003, temel saç modeli).
• Chiang ve diğerleri, Üretim Tipi Yol İzleme İçin Pratik ve Kontrol Edilebilir Bir Saç ve Kürk Modeli (Disney 2016, gerçek zamanlı yaklaşımlarda yaygın olarak kullanılır).
• Müller ve diğerleri, Konum Tabanlı Dinamikler (standart kumaş simülasyonu kaynağı).
• Jimenez ve diğerleri, Ayrılabilir Yüzey Altı Saçılımı ve Gerçek Zamanlı, Gerçekçi Cilt Yarı Saydamlığı.

13. Çıkartmalar, sanal dokulama ve malzeme katmanlama

Yüzey çeşitliliği; derinlik tamponuna yansıtılan katmanlı çıkartmalardan (mermi izleri, kir, kan, pas) ve yüksek çözünürlüklü ayrıntıları tam gerektiği anda akışla yükleyen sanal dokulardan gelir. Malzeme katmanlama, maskeler ve üç düzlemli izdüşüm kullanarak piksel başına birden fazla PBR setini harmanlar; tek bir kayanın beş farklı kaya gibi görünmesi böyle sağlanır.

Derinlemesine okumalar:

• Pranckevičius, Ertelenmiş Çıkartmalar ve devam yazıları (Aras'ın klasik blog dizisi).
• Mittring, Unreal Engine 4 Elemental Demosunun Ardındaki Teknoloji (SIGGRAPH 2012, sanal dokulama ayrıntılarını içerir).
• van Waveren, id Tech 5'in Zorlukları: Doku Sanallaştırmadan Devasa Paralelleştirmeye (SIGGRAPH 2009, MegaTexture sunumu).
• Williams, The Order: 1886'da Malzeme Katmanlama (GDC 2014, katmanlı PBR malzemeleri).

14. Sıralamadan bağımsız saydamlık

Saç, bitki örtüsü, parçacıklar ve cam düzgün biçimde sıralanamaz. AAA oyun motorları, bunları CPU'da sıralama adımı olmadan doğru şekilde işlemek için ağırlıklı harmanlanmış OIT, derinlik soyma veya piksel başına bağlı listeler gibi teknikler kullanır. Bitki örtüsünün yoğun olduğu bir sahnede, karenin en maliyetli bölümlerinden biri sessizce budur.

Derinlemesine okumalar:

• McGuire ve Bavoil, Ağırlıklı Harmanlanmış Sıralamadan Bağımsız Saydamlık (JCGT 2013, WBOIT makalesi).
• Bavoil ve Myers, Çift Derinlik Soymayla Sıralamadan Bağımsız Saydamlık (NVIDIA teknik incelemesi).
• Yang ve diğerleri, GPU Üzerinde Gerçek Zamanlı Eşzamanlı Bağlı Liste Oluşturma (piksel başına bağlı listeler için temel kaynak).
• Wyman, OIT Algoritmaları Sürekliliğini Keşfetmek ve Genişletmek (HPG 2016, karşılaştırmalı inceleme).

15. Sinirsel ışıma önbellekleme ve makine öğrenimi gürültü gidericileri

En yeni katman. NVIDIA'nın sinirsel ışıma önbelleği, sahne başına dolaylı aydınlatmayı öğrenir ve daha fazla ışın izlemek yerine bu bilgiyi sorgular. Makine öğrenimi gürültü gidericileri (OptiX, Intel Open Image Denoise, kuruma özel çözümler), seyrek ışın izlemeli sinyalleri milisaniyeler içinde temizler. Bu kategorinin önümüzdeki iki yılda hızla büyümesini bekleyebilirsiniz.

Derinlemesine okumalar:

• Müller ve diğerleri, Yol İzleme İçin Gerçek Zamanlı Sinirsel Işıma Önbellekleme (SIGGRAPH 2021, NRC makalesi).
• Schied ve diğerleri, Uzamsal-Zamansal Varyans Güdümlü Filtreleme: Yol İzlemeli Küresel Aydınlatma İçin Gerçek Zamanlı Yeniden Oluşturma (HPG 2017, SVGF).
• Chaitanya ve diğerleri, Yinelemeli Gürültü Giderici Otomatik Kodlayıcı Kullanarak Monte Carlo Görüntü Dizilerinin Etkileşimli Yeniden Oluşturulması (SIGGRAPH 2017, ilk yinelemeli makine öğrenimi gürültü gidericisi).
• Intel, Open Image Denoise belgeleri (açık kaynaklı, üretime yönelik gürültü giderici).

Bunun tarayıcı açısından anlamı

Bu tekniklerin birkaçını WebGPU'da çalışan açık dünya tarayıcı motorumuzda kullanıma sunduk. Basamaklı gölge haritaları, GPU güdümlü örnekleme, üç düzlemli PBR, ekran uzayı sisi ve clipmap tabanlı sanallaştırılmış arazi, bir tarayıcı sekmesinde 120 FPS hızında çalışıyor. Geri kalanlar (donanım hızlandırmalı ışın izleme, mesh shader'ları, makine öğrenimiyle yükseltme), WebGPU belirtimi geliştikçe web'e geliyor. Daha ayrıntılı bilgi için tarayıcıda açık dünya teknolojisi ve tarayıcıda arazi üretimi rehberlerimize bakın.

Tüm teknoloji yığını için ek okumalar

Tek bir kitap okuyacaksanız, Real-Time Rendering, 4. baskı yukarıdaki konuların çoğunu ele alan standart kaynaktır. Devam eden araştırmalar için SIGGRAPH'ın “Advances in Real-Time Rendering in Games” ders arşivi (advances.realtimerendering.com), 2006'ya kadar uzanan AAA oyun motoru derinlemesine incelemelerinin ücretsiz PDF'lerini sunar. Belirli oyunların karelerini nasıl işlediğini anlatan üretim çözümlemeleri için Adrian Courrèges'in GPU profilleme makaleleri mutlaka okunmalıdır.

Oleg Sidorkin, Cinevva CTO'su ve Kurucu Ortağı

Burada yeni misiniz? Seri rehberini kullanın. Rehber, spike'ın ne olduğunu açıklıyor ve tüm bölümlere bağlantı veriyor.

17. Bölüm, oyuncuya çatışmaya uygun bir animasyon seti ve herhangi bir CC0 modeli dünyaya aktarmanın yolunu sundu. Bu bölümde yeniden içerik üreticisinin tarafına dönüyoruz. Spike 34'ün paleti her tıklamada bir nesne yerleştiriyor; bu, öne çıkan bir nesneyi sahneye yerleştirmek için yeterli ama bir orman oluşturmak için işe yaramaz. Spike 37 ise fırçanın kendisi: arazi üzerinde sürüklediğinizde ağaçlar ait oldukları yerleri dolduruyor.

Yapay zekâ olmadan "yapay zekâ yerleştirmiş" hissi

Spike 37'yi yeni bir sekmede açın ↗ · Kaynak kodunu görüntüleyin

Bu spike'ın yanıtladığı soru, bütünüyle sezgisel kurallara dayanan bir fırçanın LLM'i atlayacak kadar akıllı hissettirip hissettirmediği. "Yapay zekâ yerleştirmiş" olmanın testi somut: ağaçlar uçurumlardan uzak duruyor, kayalar eğime doğru yatıyor, sahil çakılları su çizgisinde son buluyor ve bunların hepsi ilk darbede gerçekleşiyor. Bunu eğim ve rakım koşulları, ağırlıklı seçimler ve aile başına aralık kurallarıyla, tek bir model çağrısı bile yapmadan başardık.

Fırça, elle ayarlanmış özelliklere sahip 257×257 boyutunda bir CPU yükseklik haritası üzerinde çalışıyor; böylece her hazır ayar yerleşebileceği bir alan buluyor: karma eğim seçimleri için kuzeyde dağlar, taş döküntüsü için doğuda bir uçurum şeridi, plaj ve çayır için güneyde bir kıyı ovası, güneybatıda ise göl çanağı. Arazi, (altitude, slope) biyom sınıflandırıcısından tepe renklerini önceden hesaplıyor; böylece tek bir ağaç bile boyamadan önce hazır ayarın nerede devreye gireceğini görebiliyorsunuz. Beş hazır ayar, her biri { category, weight, slopeMin, slopeMax, altMin, altMax, minSpacing, alignToSlope } biçiminde seçim listeleri içeren düz veriler olarak sunuluyor. Uçurum ve Taş Döküntüsü, kayaların yalnızca gerçek eğimlere yerleşmesi için slopeMin: 0.3, her kayanın yukarı vektörünün yüzey normalini izlemesi için de alignToSlope: true kullanıyor.

Dağıtma motoru her darbede fırça diski içinde densityPerM2 × area adet aday nokta örnekliyor, her adayın yüksekliğini ve eğimini okuyor, hazır ayarın seçimlerini koşulları geçenlerle sınırlandırıyor, bunlardan birini ağırlıklı olarak seçiyor ve ardından yarıçap içi uzamsal karma tablosunda aralık denetimi yapıyor. Her şey deterministik: tüm seçimler tohumlanabilir Mulberry32 RNG tarafından yönetiliyor; dolayısıyla (seed, brush events) herhangi bir oturumu birebir yeniden üretiyor. Başlangıç arazisinde düz çayır üzerindeki bir Karma Orman darbesi, 158 adaydan 139'unu 5 ms'de yerleştirdi. Aynı hazır ayar bir uçurumda 226 adaydan yalnızca 106'sını yerleştirdi ve HUD, bunların 81'inin eğim nedeniyle reddedildiğini bildirdi. Bu ret dökümü kullanıcı deneyiminin özünü oluşturuyor: uçurumun neden yalnızca birkaç ağacı kabul ettiğini tahmin etmek yerine doğrudan görebiliyorsunuz.

Hazır ayarları düz veri olarak tutmanın amacı, LLM sürümü geldiğinde bunun yeniden yazım değil, yalnızca bir JSON değişimi olması. paint({ preset }), preset.picks değerinin elle ayarlanmış bir tariften mi yoksa "yosunlu kayalar içeren yaprak döken orman" ifadesini ağırlıklara dönüştüren bir worker'dan mı geldiğini önemsemiyor. Motor ayrıca hiçbir nesne kimliğini sabit kodlamıyor; dolayısıyla farklı bir katalog eklemek motor değişikliği gerektirmiyor.

300 çizim çağrısından 49'a

İlk sürüm, her yerleşimi çoklu mesh grubunun clone(true) kopyası olarak işliyordu. Bu, birkaç yüz nesne için yeterliydi ama 2.500 sınırında duvara tosluyordu; çizim çağrılarının sayısı binlere çıkıyordu. Bu noktaya gelmeden InstancedMesh kullanımına geçtik ve her (propId, partIndex) için bir bucket oluşturduk. Her bucket iki katına çıkarak büyüyor: daha büyük bir InstancedMesh ayır, canlı matrisleri kopyala, sahne üst öğesini değiştir, eski niteliği dispose et. Silme işlemi swap-remove kullanıyor; bu nedenle bucket boyutundan bağımsız olarak tek bir örneği kaldırmak O(1). Determinizm, aralık kuralları ve ret HUD'u değişmeden korunuyor çünkü bu değişiklik bütünüyle yerleşim kaydının altında gerçekleşiyor.

MegaKit paketi üzerinde yaptığımız bir tanılama, gerçek bir mimari soruyu çözüme kavuşturdu. Çok primitife sahip bir glTF mesh'i (gövde ve yapraklar), three.js'e ya dizi malzemeli ve geometry.groups içeren tek bir mesh olarak ya da her biri tek malzemeye sahip ayrı kardeş mesh'ler olarak ulaşabilir. Yükleyici bu paket için ikinci yolu izliyor: her parça, grupları boş olan tek malzemeli bir mesh. Bu, dağıtma için daha iyi bir yapı; çünkü primitif başına ayrı bucket'lar, sayıları farklılaşırsa gövde bucket'ının yaprak bucket'ından bağımsız büyümesini sağlıyor. Her iki durumda da çizim çağrısı sayısı aynı, ancak ayrık yapıda bellek düzeni daha iyi. Ölçülen kazanç kalıcı oldu: yaklaşık 300 çizim çağrısı kullanan bir orman darbesi 49'a düştü; çok darbeli tam bir oturum ise 51 çizim çağrısıyla 75 FPS'de 3.221 örneğe ulaştı. Kopyalama yolu, kare bütçesi çökmeden önce bu sınıra asla ulaşamazdı.

Mesafe LOD'u ve içinde saklanan dört hata

Örnekleme çizim çağrılarını azalttı ama her örnek hâlâ tam üçgen sayısıyla çiziliyordu; 90 metre uzaktaki ve görüntüye yalnızca iki piksellik yaprak ayrıntısı katan ağaçlar bile buna dahildi. Bu nedenle meshoptimizer ile her nesne parçası için üç LOD seviyesi (tam, %50, %15) hazırladık, bucket anahtarını (propId, partIndex, lod) olarak genişlettik ve bir yerleşimi ayırma yapmadan kardeş bucket'lar arasında taşıyan move() işlevini ekledik. Mesafe bantları 0–30 m, 30–90 m ve ötesi olarak belirlendi. Her sınırın çevresinde ±4 m histerezis var; böylece bant kenarında gezinen bir kamera, yerleşimi sürekli ileri geri taşıyıp matrisini her karede yeniden yüklemiyor. Yeniden değerlendirme 4 Hz ile sınırlandırılıyor ve yalnızca kamera gerçekten hareket ettiğinde çalışıyor; dolayısıyla sabit bir kamera kare başına yalnızca bir karesel mesafe karşılaştırmasına mal oluyor.

Öğretici hatalar işte bu LOD yolunda ortaya çıktı. İlki, kamera yörüngede dönerken yerleşimlerin kaybolması veya çoğalması şeklinde görülüyordu ve sahne doldukça kötüleşiyordu. Nedeni ortak bir geçici matristi: move(), yerleşimin dönüşümünü modül kapsamındaki _tmpMat içine okuyordu; ancak kaynak bucket'ın swap-remove işlemi de kendi iç taşıması için aynı _tmpMat değişkenini kullanıyor ve hedef yazmadan önce taşınan matrisin üzerine yazıyordu. Hata yalnızca taşınan slot bucket'ta zaten son sıradaysa ortaya çıkmıyordu; bunun olasılığı yaklaşık 1/count idi. Bu da oyun testinde görülen, "sahne büyüdükçe kötüleşen nadir titreme" durumuyla birebir örtüşüyor. Çözüm, yalnızca move() için ayrılmış özel bir _carryMat kullanmaktı. Toplam 1.274 taşıma içeren stres testinde küme piksel piksel aynı kaldı.

İkinci hata daha incelikliydi: ilk geçiş dışında her LOD geçişi akıcı görünüyordu. LOD1'e geçen ağaçların silüeti neredeyse hiç değişmemesine rağmen gölgelendirmeleri belirgin biçimde kayıyordu; buna karşılık merdivenin sonraki aşamalarındaki daha büyük üçgen azalmaları sorunsuz görünüyordu. LockBorder kullanan sadeleştirici hiçbir zaman tepe noktalarını taşımıyor veya yenilerini üretmiyor; dolayısıyla kalan tepe noktaları normallerini aynen koruyor. Buna rağmen her sadeleştirmeden sonra computeVertexNormals() çağırıyorduk. LOD0, sanatçı tarafından hazırlanmış özgün normalleri değiştirmeden döndürüyor; LOD1 ve üstü ise three.js'in genel amaçlı yüz ortalaması yeniden hesaplamasını kullanıyordu. Merdivende normal düzeninin değiştiği tek yer 0'dan 1'e geçiş sınırıydı; dolayısıyla sıçrama da orada görülüyordu. O tek savunmacı satırı kaldırmak gölgelendirmeyi düzeltti ve ek bir kazanç olarak nesne başına hazırlama süresini yaklaşık yarıya indirdi; çünkü artık parça başına dört LOD için normalleri yeniden hesaplamıyorduk.

Sadeleştiricinin ürettiklerini denetlemek üçüncü bir kazancı ortaya çıkardı. Her LOD, yeni bir indeks içeren original.clone() idi ve BufferGeometry.clone() her niteliği derinlemesine kopyaladığı için beş LOD; değerleri bit düzeyinde aynı olan konum, normal, UV ve renk tamponlarının beş bağımsız kopyasını tutuyordu. Nitelik referanslarını paylaşacak ve her LOD için yalnızca özel bir indeks tamponuna sahip olacak şekilde yeniden düzenledik. Böylece tipik bir ağaç parçasındaki farklı nitelik kimliği sayısı 20'den 9'a düştü ve her tepe noktası tamponu GPU'ya yalnızca bir kez yüklendi. Paylaşımlı depolama iki kural getiriyor: herhangi bir LOD üzerinden nitelik verilerini değiştirmeyin ve tek bir LOD geometrisine dispose() uygulamayın; çünkü ikisi de tamponu paylaşan tüm kardeşleri etkiler.

Dördüncü hatanın boyamayla hiçbir ilgisi yoktu. Herhangi bir düğmeye basılmamışken imleci yalnızca arazi üzerinde hareket ettirmek kare hızını düşürüyordu. pointermove işleyicisi, hiçbir uzamsal yapısı olmayan 131.072 üçgenlik bir düzlem olan arazi mesh'ine raycast uyguluyordu; bu nedenle three.js, saniyede 1.000 olaya varan hızlarda her olay için indeks tamponunun tamamını tarıyordu. Arazi parametrik bir yükseklik haritası olduğu için bu aramada mesh'e hiç ihtiyacımız yoktu. sampleHeight üzerinde uyarlanabilir bir ışın yürüyüşü (yüzeyden yüksekte büyük adımlar, yüzeye yaklaşınca 0,4 m alt sınır, ardından işaret değişiminde 12 ikili bölme), ışın başına 131.072 üçgen testi yerine yaklaşık 8–30 örneğe mal oluyor. Bu yaklaşık üç büyüklük mertebesi daha ucuz ve fareyle üzerine gelindiğinde kare hızı yeniden üst sınırda kalıyor.

Maliyet yalnızca yer değiştirir; tıklamadan uzaklaştığından emin olun

Spike'ı three r184 üzerindeki WebGPURenderer'a (üretim hedefi) geçirdikten sonra bir DevTools profili, ilk boyamanın 265 ms boyunca engellendiğini ve bunun %79'unun meshoptimizer WASM içinde geçtiğini gösterdi. Hazırlama gerçekten ağırdı; soğuk bir hazır ayar için yaklaşık 180 sadeleştirme çağrısı yapılıyordu. Ancak preloadProps yalnızca sahneleri getirip ayrıştırdığı ve LOD hazırlamasını hiç tetiklemediği için bu iş tıklama işleyicisinin içinde çalışıyordu. Çözüm, hazır ayar seçiminin tüm hazırlamayı arka planda yapmasını sağlamaktı: preloadProps artık parça çözümleme yolunu çağırıyor, hızlı bir tıklamanın yinelenen bir işlem başlatmak yerine mevcut işleme katılması için sürmekte olan promise'i önbelleğe alıyor ve sadeleştiricinin parça başına dört kez tekrarladığı geometri ön işlemesini memoize ediyor. İlk boyama süresi HUD'da 209 ms'den 4 ms'ye düştü. WASM süresi ortadan kalkmadı; yalnızca kullanıcının kritik yolundan çıktı ve kullanıcı araziye bakıp nereyi boyayacağına karar verirken çalışmaya başladı.

Bu spike'ın tekrarlanan dersi bu. Bu düzeltmelerin neredeyse hiçbiri fırçanın ne yaptığını değiştirmedi. Maliyetin ne zaman oluştuğunu değiştirdiler: tıklamanın dışında, üzerine gelmenin dışında, kameranın yakınında gezindiği sınırın dışında. Anında tepki veriyormuş gibi hissettiren bir dağıtma aracı daha az iş yapmaz; işi kullanıcının beklemediği anda yapar.

Bu bölümde değinilen teknolojiler

Sezgisel uygunluk dağıtımı. Bir fırça, disk içinde aday noktalar örnekler; CPU yükseklik haritasından her noktanın (height, slope) değerini okur; hazır ayarın seçimlerini eğim ve rakım koşullarına göre filtreler; birini ağırlıklı olarak seçer ve uzamsal karma tablosunda izlenen aile başına minimum aralığı ihlal ediyorsa reddeder. Eğime hizalanan seçimler, yukarı vektörlerini yüzey normaline döndürür. Bu yöntem, öğrenilmiş ağırlıklar olmadan kasıtlı görünen yerleşimler üretir (ağaçlar uçurumlardan uzak durur, kayalar eğimlere doğru yatar, çakıllar su çizgisinde son bulur) ve hazır ayarı düz veri olarak tuttuğu için LLM tarafından oluşturulan bir seçim listesi doğrudan yerine takılabilir.

Asenkron yüklemeler altında deterministik yerleşim. Tohumlanabilir Mulberry32 RNG tüm seçimleri yönetir; dolayısıyla (seed, brush events) bir oturumu birebir yeniden üretir. RNG seçimleri herhangi bir await öncesinde yapılır ve aralık rezervasyonları glTF kopyası çözülmeden önce uzamsal indekse eklenir. Böylece eşzamanlı adaylar birbirlerini dikkate alır ve asenkron varlık yükleme işlemleri diziyi değiştiremez.

O(1) düzenlemeli bucket tabanlı InstancedMesh. Her (propId, partIndex, lod) için bir InstancedMesh; kapasite gerektiğinde canlı matrislerin daha büyük bir tampona kopyalanmasıyla iki katına çıkarılır. Silme ve FIFO tahliyesi, taşınan örneğin indeksini güncelleyen bir geri referans dizisiyle swap-remove kullanır; böylece kaldırma işlemi bucket boyutundan bağımsız olarak O(1) olur. Bir tanılama, glTF parçalarının tek malzemeli mesh'ler olarak geldiğini doğruladı. Bu da primitif başına tek bucket yolunu etkinleştiriyor ve her primitife bağımsız büyüyebilen bir bucket sağlıyor.

Histerezisli ve paylaşılan nitelik tamponlu mesafe LOD'u. Parça başına meshopt ile sadeleştirilmiş üç seviye, sınır yakınındaki kameranın sürekli geçiş yapmasını önlemek için ±4 m histerezis içeren mesafe bantlarıyla seçilir; yeniden değerlendirme sınırlı bir hızda yapılır ve yalnızca gerçek kamera hareketinde çalışır. LockBorder sadeleştirmesi tepe noktalarını hiç taşımadığından tüm LOD'lar aynı konum/normal/UV/renk tamponlarını paylaşır ve yalnızca özel indeks tamponlarıyla birbirinden ayrılır; böylece farklı GPU tepe noktası tamponlarının sayısı yaklaşık yarıya iner. Savunma amacıyla kullanılan computeVertexNormals çağrısını atlamak, sanatçı normallerini LOD'lar arasında aynı tutar ve merdivendeki tek gölgelendirme süreksizliğini ortadan kaldırır. Bkz. LOD ve meshoptimizer.

Yüksek frekanslı aramalar için analitik yükseklik haritası raycast'i. pointermove hızındaki bir imleç aramasını 131 bin üçgenli bir düzlem mesh'ine uygulamak, her olayda indeks tamponunun tamamını tarar. Bunu analitik yükseklik işlevi üzerinde uyarlanabilir bir ışın yürüyüşüyle değiştirmek (yüzeyden uzakta büyük adımlar, yakınında küçük bir alt sınır, $({\text{ray}}_y-{\text{terrain}}_y)$ ifadesinin işaret değişiminde ikili bölme), on binlerce üçgen testi yerine onlarca örneğe mal olur; bu yaklaşık üç büyüklük mertebesi daha ucuzdur. Önceden ayrılmış bir çıktı vektörü de sıcak yolu ayırmasız tutar.

İşi etkileşimin kritik yolundan çıkarın. Maliyetli tek seferlik işler (meshopt LOD hazırlamaları, WGSL pipeline derlemeleri) tıklama işleyicisinin içinde değil, boşta kalınan aralıklarda çalışmalıdır. Hazır ayar seçildiğinde etkin hazır ayarın tam hazırlamasını önceden yüklemek, hızlı bir tıklamanın yeni bir işlem başlatmak yerine mevcut promise'e katılması için sürmekte olan promise'i önbelleğe almak ve geometri başına ön işlemeyi memoize etmek, toplamda daha az iş yapmadan ilk boyama gecikmesini 209 ms'den 4 ms'ye düşürdü.

29 bölümden 18. bölüm. Önceki: 17. Bölüm - Yeniden hedefleme gerektirmeyen animasyonlar ve canlı varlık araması Sonraki: 19. Bölüm - Bir ormanda hayatta kalması gereken imposter Seri rehberi: /tr/blog/2026-02-25-open-world-browser-series-guide

Cinevva CTO'su ve Kurucu Ortağı Oleg Sidorkin tarafından

Burada yeni misiniz? Seri rehberini kullanın. Rehber, spike'ın ne olduğunu açıklıyor ve tüm bölümlere bağlantı veriyor.

Bölüm 16, içine nesneler yerleştirebildiğiniz bir dünya sundu. Bu bölümse oyuncuya o dünyada yapabileceği daha iyi şeyler veriyor: savaş kalitesinde bir animasyon seti ve arama yazarak binlerce CC0 modelden herhangi birini dünyaya aktarmanın bir yolu.

262 klip, tek iskelet, üç yeniden hedefleme düzeltmesi

Spike 35'i yeni sekmede aç ↗ · Kaynak kodunu görüntüle

Oyuncu iskeleti, 80'den fazla kemikten oluşan bir yüz iskeleti ve eksiksiz parmak eklemleri dâhil toplam 213 kemiğe sahip, CC4 tarzı bir 3MIKE iskeleti. Animasyon kaynakları bununla eşleşmiyor. İlk sürümde elle seçilmiş Mixamo savaş klipleri yeniden hedeflendi, ancak kaynak havuzu yetersizdi ve hareket animasyonları Mixamo ile birkaç Kimodo BVH bekleme animasyonu arasında kullanışsız biçimde bölünmüştü. Asıl kazanım, kaynak kütüphanesini Quaternius'un iki Universal Animation Library paketine geçirdiğimizde geldi: tek ve tutarlı, UE5 tarzı 65 kemikli bir manken üzerinde toplam 262 klip; kılıç komboları, okçuluk, tırmanma, duvarda koşma, sıyrılmalar, darbe tepkileri, ifadeler ve çok daha temiz bir hareket seti.

Bu, ortak kemik adları, T-pozu yönelimleri veya uzuv oranları bulunmayan 65 kemikli bir kaynaktan 213 kemikli bir hedefe aktarım demek. Her klip üç adımda yeniden eşleniyor: bir kemik adı eşlemesi, iki iskeletin ortak bir referans yönelimini paylaşmasını sağlayan bağlama pozu hizalaması ve daha kısa kaynak iskeletin karakteri dizlerine kadar zemine gömmemesi için konum izi ölçeklendirmesi. Bunu doğru yapmak, her biri bize belirli bir şey öğreten bir dizi hatanın peşine düşmek anlamına geldi.

Karakter aşırı burulmuş görünüyordu; her omuz ve dirsek yaklaşık 30° fazla dönüyordu. Bunun nedeni bir poz uyuşmazlığıydı: UAL kaynağı gerçek bir T-pozuyla geliyor, CC4'ün bağlama pozuysa A-pozu ve yeniden hedefleyici iki iskeletin de eşleşen referans pozlarında durduğunu varsayıyordu. Bu nedenle A'dan T'ye olan fark, kare başına her deltaya ekleniyordu. Düzeltme, bağlama pozunu yakalamak için CC4'ün kol zincirini gerçek bir T-pozuna zorluyor, ardından yeniden hedefleme yapıyor; böylece deltalar küçük kalıyor.

Ardından gövde ötelemesi durdu. Geri savrulmalarda üst gövde tepki veriyor, ancak ayaklar yere sabit kalıyordu. UAL, yer değiştirmeyi pelvis yerine root kemiğine koyuyor; bu nedenle pelvis konumunu okumak sıfıra yakın hareket veriyordu. Düzeltme, root.position ile pelvis.position değerlerini topluyor, yatay kısmı ölçeklendiriyor ve tek bir kalça konumu izi yazıyor. Bunu yaparken dikey ofsetlerin yaklaşık %12 hatalı olduğunu keşfettik; çünkü pelvis yüksekliği için kalçadan zemine oran gerekirken Y ekseninde genel uzuv oranını kullanmıştık. İki oran, iki eksen: Y için $\text{verticalRatio}=|\text{targetHipY}/\text{sourceHipY}|$, yatay içinse orantı oranı. Aşırı hareket ortadan kalktı. Ayrıca RL_BoneRoot.position NaN uyarıları akışının nedeni, UAL'ın root kemiğinin ($Y=0$ konumunda) konum izi bağlama Y değerine bölünerek normalleştirilen bir hedef kemiğe eşlenmesiydi. Sıfıra bölme, NaN ve sessizce atılan bir iz. Çözüm, ötelemesi zaten kalça izinde bulunduğu için kök eşlemesini tamamen kaldırmaktı.

En küçük düzeltme, izlemesi en tatmin edici olandı. Kemik eşlemesinde parmak girdileri bulunmadığı ve yeniden hedefleyici yalnızca eşlenmiş kemikler için iz yazdığı için karakter kılıcı gevşek, bağlama pozundaki parmaklarla tutuyordu. 30 parmak kemiği eklemek (beş parmak, üç segment, iki el; UAL'ın deformasyon yapmayan dördüncü uç yardımcı kemiğini hariç tutarak) elin kabzayı kavrarken kapanmasını ve bırakırken açılmasını sağladı.

262 klibi, 262 klibi izlemeden doğrulamak

262 kliplik bir kütüphaneyi gözle doğrulayamazsınız; bu nedenle çevrimdışı bir yörünge eşlik testi geliştirdik: Her paketi yükleyen, kaynak iskeleti 60 Hz'de örnekleyen, yeniden hedefleme işlem hattını çalıştıran ve ölçeklendirmeden sonra kemik başına dünya konumlarıyla dönüşlerini kaynakla karşılaştıran başsız bir Node betiği. Pelvisin Y eksenindeki maksimum sapması 0,003 m oldu. Ellerde başlangıçta “parmaklar takip etmiyor” şeklinde yorumlanan sabit 2,5°'lik bir ofset vardı; ancak sabit ofset, düz UAL eli ile CC4'ün hafifçe çukurlaştırılmış bağlama pozu arasındaki bağlama deltasıdır ve klip boyunca değişmez. Gerçek animasyon hataları, kareden kareye değişen sapmalar olarak ortaya çıkar. Bu netleştiğinde test, tek seferlik bir regresyon kontrolüne dönüştü: Bir klibin sapması bu sabit taban çizgisini korumayı bırakırsa yakın tarihli bir değişiklik yeniden hedeflemeyi bozmuş demektir.

Yan yana gösterilen bir referans manken, hata ayıklamanın görsel tarafını belirleyici hâle getirdi. Ters eğik çizgi tuşuna basıldığında geçerli klibin sahibi olan kaynak iskelet oyuncunun yanında gösteriliyor; böylece “omuz neden burulmuş?” sorusu “burulma kaynakta mı, yoksa yeniden hedefleme mi ekledi?” sorusuna dönüşüyor. Sayısal testler regresyonları yakalıyor, görsel referans sayıların ortaya çıkarmadığı bağlama pozu hatalarını buluyor ve ikisi birlikte tahmin oyununa son veriyor.

İşlem hattı sağlamlaştıktan sonra WASD/zıplama/yüzme temelini Mixamo'dan UAL'a geçirmek yalnızca ince bir takma ad eşlemesi gerektirdi: FSM hâlâ idle ve walk gibi genel durum adlarını kullanıyor ve bunlar oynatma sırasında UAL klip adlarına çözümleniyor. Serbest stil ve su üstünde durma pozları pelvisi farklı anatomik yüksekliklere sabitlediği için yüzmede klip başına iskelet ofsetleri gerekti. Bu nedenle aktif yüzme sırasında iskeleti yarım metre, su üstünde dururken daha derine batırıyor ve aralarında yumuşak bir 5 Hz geçiş yapıyoruz.

Bir kelime yazın, bir model alın

Spike 36'yı yeni sekmede aç ↗ · Kaynak kodunu görüntüle

Spike 34, elle seçilmiş bir CC0 paketi hazırlamak için bir gün harcadı. Uzun vadeli çözüm bir arama kutusu. Polyhaven, izin verici bir JSON API'si ve deterministik bir CDN üzerinden yaklaşık 1.100 CC0 model yayımlıyor. Bu spike, sorgu, küçük resimler, yükleme ve görüntülemeden oluşan tüm yolu; derleme adımı bulunmayan statik bir sayfada, yaklaşık 300 satır sade JS ve three.js ile bağlıyor.

Başlangıçta yaklaşık 600 KB büyüklüğündeki kataloğun tamamı bir kez getiriliyor. Arama, 120 ms gecikmeli, tamamen istemci taraflı puanlama kullanıyor (ad, kimlikten; kimlik, kategoriden; kategori de etiketten üstün) ve en yüksek puanlı 60 kartı oluşturuyor. Küçük resimler bir IntersectionObserver üzerinden tembel yükleniyor; böylece yazı yazmak aynı anda 60 istek başlatmıyor. İlginç kısım yükleme. Polyhaven'ın dosya uç noktası GLB değil, çok dosyalı glTF sunuyor; dokular çözünürlükler arasında paylaşılıyor ve ayrı dosyalara bölünüyor. Ayrıca göreli yollardan mutlak CDN URL'lerine uzanan bir include eşlemesi döndürüyor. JSON'u kendimiz indirip yamamak yerine bu eşlemeyi LoadingManager.setURLModifier üzerinden geçiriyoruz. Bu, yükleyicinin ihtiyaç duyduğu her bağımlılık (.bin ve her doku) için çalışıyor ve bunları CDN üzerinden çözümlüyor. Tek tıklama, görünürde tek dosya. Hem API hem de CDN izin verici CORS başlıkları sunuyor; bu durum herhangi bir istemci kodu yazılmadan önce curl ile doğrulandı, dolayısıyla proxy gerekmiyor. PBR malzemeleri, RoomEnvironment ve varsayılan ACES ton eşleme ayarlarıyla varlık başına düzeltme gerektirmeden doğru görüntüleniyor. 1k dokular da tipik bir modeli 4k'daki 20 ila 40 MB yerine 2 ila 5 MB arasında tutuyor.

Bir meshoptimizer WASM geçişi, sistemi tahribatsız bir azaltıcıyla tamamlıyor: Her mesh, özgün geometrisinin bir kopyasını saklıyor ve oran değiştiğinde kümülatif olarak sadeleştirmek yerine bu kopyadan yeni bir indeks arabelleği oluşturuyor. Çok malzemeli geometri, grup başına sadeleştiriliyor ve malzeme yuvalarının birleşmemesi için geometry.groups yeniden oluşturuluyor. Bir koltuk, tam ayrıntıda 5.626 üçgenden yarı ayrıntıda 2.812 üçgene düşüyor.

Bu bölümde değinilen teknolojiler

Bağlama pozu hizalamasıyla iskelet yeniden hedefleme. Animasyonu farklı kemik adlarına, oranlara ve referans pozlarına sahip bir iskeletten diğerine eşlemek üç düzeltme gerektirir: bir kemik adı eşlemesi, iki iskeletin ortak bir referans yönelimini paylaşmasını sağlayan bağlama pozu hizalaması (hedefin A-pozu kol zincirini kaynağın T-pozuna zorlayarak) ve konum izi ölçeklendirmesi. Poz uyuşmazlığı, A'dan T'ye dönüşü kare başına her deltaya ekleyerek eklem dönüşünü ikiye katlar. Eşlenmemiş yardımcı kemikler çıkarılmalıdır; çünkü $Y=0$ konumundaki bir kök kemik, konum izi normalleştirmesinde sessiz bir sıfıra bölme hatasını tetikler.

Tek iskelet için iki ölçek oranı. Yatay yer değiştirme genel uzuv oranını, yani iskeletin genel boyutunu kullanır; ancak dikey pelvis ofseti, iskeletlerin bacak-gövde oranları farklı olduğu için kalçadan zemine $|\text{targetHipY}/\text{sourceHipY}|$ oranını kullanır. Her iki eksende de tek oran kullanmak, tırmanışların hedefi aşmasına ve toparlanmaların zeminin altına batmasına yol açar. UAL'daki yer değiştirme pelviste değil root kemiğinde bulunduğundan, geri savrulma, tırmanma ve hareket kliplerinde hareketi korumak için ikisi de tek bir kalça konumu izinde toplanmalıdır.

Çevrimdışı yörünge eşlik testi. Başsız bir betik kaynak iskeleti 60 Hz'de örnekler, yeniden hedefleme işlem hattını çalıştırır ve kemik başına dünya dönüşümlerini kaynakla karşılaştırır. Kare başına sabit bir ofset zararsız bağlama deltasıyken, kareden kareye değişen sapma gerçek bir hatadır. Böylece test, bir değişiklik bir izi kaldırdığında veya bozduğunda tetiklenen bir regresyon kontrolüne dönüşür. Paket başına GLB yalıtımı (her seferinde yeni yükleme ve bir sonrakinden önce serbest bırakma), taramanın tamamında önbellek çekişmesini önler.

CDN glTF grafikleri için LoadingManager.setURLModifier. Bir CDN, glTF'yi beraberindeki bir include eşlemesiyle (göreli yoldan mutlak URL'ye) göreli URI grafiği olarak sunduğunda setURLModifier, JSON'u yeniden yazmadan yükleyicinin istediği her bağımlılığı CDN üzerinden çözümler. Bu, çok dosyalı ve çok çözünürlüklü bir dağıtımı tek tıklamayla yüklenebilir hâle getirir. Bir sonraki model yüklenmeden önce önceki modelin geometrisini, malzemelerini ve doku haritalarını serbest bırakmak, gezinme oturumu boyunca yüzlerce MB GPU belleğinin birikmesini önler.

Tahribatsız mesh sadeleştirme. Her mesh'in özgün geometrisinin bir kopyasını saklamak ve her sadeleştirme oranında yalnızca indeks arabelleğini yeniden oluşturmak, değişiklikleri hızlı tutar ve tekrarlanan sadeleştirmenin yol açtığı kümülatif hasarı önler. İşlemi her geometry.groups dilimi için ayrı yürütmek ve grupları yeniden oluşturmak, çoklu malzeme atamalarını korur. Bunun mesafeye dayalı LOD'a nasıl aktarıldığını görmek için LOD ve meshoptimizer bölümüne bakın.

29 bölümün 17.'si. Önceki: Bölüm 16 - Büyümeye devam eden bir dünya için yapı Sonraki: Bölüm 18 - Yapay zekâ yerleştirmiş hissi veren bir dağıtma fırçası Seri rehberi: /tr/blog/2026-02-25-open-world-browser-series-guide

Mariana Muntean, Cinevva CEO'su

Cinevva hakkında yabancılardan en sık duyduğumuz şey, onun bir yapay zekâ sarmalayıcısı olduğu. Ana sayfaya geliyor, üzerinde "Oyununu tarif et" yazan tek bir giriş kutusu görüyor ve ürünü anladıklarına karar veriyorlar. Oysa yalnızca giriş kapısını anlamış oluyorlar. Ürün, siz o cümleyi yazarken görmediğiniz her şeyin yanı sıra, bu haftadan itibaren oyuncularınızın oyununuzu bulmak için ilk adım attığı açık dünyadır.

Bu girişin arkasında eksiksiz bir oyun motoru, tür tanımlı 26 araca sahip bir orkestratör, bir üretken model filosu, on bir sağlayıcıyı kapsayan birleşik bir varlık araması, ajanın okuyup yazabildiği canlı bir oyun iframe'i ve aynı ajanın tamamlanmış oyununuzu kaydırılabilir bir oynanış videosu olarak yayımladığı bir mağaza bulunuyor. Bunların hiçbiri egzotik değil. Hepsi altyapı işi. Asıl ilginç iş, neyi neye bağlayacağımıza karar vermekti.

Bu yazıda sistemi tepeden tırnağa inceleyeceğiz. Teknik yatırımcılara ve katkıda bulunmayı düşünen geliştiricilere yaptığımız açıklama bu. İkisi de aynı yanıtı istiyor.

1. İstem sistemin kendisi değil, görünen yüzüdür

İlk tasarım kararımız, kullanıcı gerçekten işe dâhil olana kadar her şeyi gizlemekti. Ana sayfanın tek bir görevi var: bir cümleyi alıp projeye dönüştürmek. Deneyimi herkese açık taraf (istem, vitrinler ve mağaza akışı) ile üretici tarafı (IDE, varlık araçları ve yayımlama akışı) olarak ikiye ayırdık; böylece yalnızca oyun oynamak isteyenler kokpite bakmak zorunda kalmıyor.

Bu nedenle yer tutucu metin "Neon grafiklere sahip bir yılan oyunu yap" ve "Üstten görünümlü zombi nişancı oyunu" gibi örnekler arasında değişiyor. Bunlar eğitim içeriği değil. Kullanıcıya izin veren küçük bir işaret. Kullanıcı, "tuhaf arcade fikri"nin geçerli bir girdi olduğunu görüyor.

Gönder düğmesine bastığınız anda üç şey gerçekleşir. Sistem, kalıcı bir kimliğe sahip yepyeni bir oyun projesi oluşturur. Boş bir dosya ağacı (index.html, game.js, style.css, assets/, GDD.md) hazırlar. Ardından cümlenizi, bu boş dosyaları işaret eden bir proje bağlam penceresiyle birlikte orkestratöre yönlendirir. Bu noktadan sonra elleri olan bir ajanla konuşursunuz.

2. Giriş alanının arkasında eksiksiz bir tarayıcı IDE'si

Üretici çalışma alanı, tamamen tarayıcıda çalışan üç panelli bir IDE'dir. Solda dosya ağacı, ortada kod düzenleyici, sağda canlı oyun iframe'i ve alt kısım boyunca uzanan bir sohbet alanı bulunur. Bu düzeni bilinçli olarak seçtik. Hâlihazırda kod yazan kişiler onu anında tanıyor. Kod yazmayanlar ise orta paneli görmezden gelip yalnızca sohbet üzerinden ilerleyebiliyor.

Dosya ağacı bir metafor değil. Her proje gerçekten de bir Cloudflare Worker aracılığıyla doğrudan R2'den sunulan HTML, JS, CSS, üretilmiş görseller, GLB modelleri ve ses dosyalarından oluşan küçük bir statik sitedir. Derleme adımı yoktur. Bunun önemli bir nedeni var. Ajanın gerçekten yayımlayacağınız dosyaları okuyup yazabilmesi anlamına gelir. Ayrıca aynı yapının iframe içinde, Capacitor ile paketlenmiş bir telefonda, Tauri ile paketlenmiş Steam sürümünde ve Embedded Activity olarak Discord içinde çalışmasını sağlar. Tek bir dosya sistemi, altı dağıtım hedefi.

Ürettiğimiz her oyunun window üzerinde iki işlev sunması zorunludur. getGameState(), çalışan oyunu tanımlayan sade bir nesne döndürür (oyuncu konumu, skor, canlar, düşmanlar, zamanlayıcılar). setGameState(patch) ise kısmi bir güncellemeyi canlı oyuna uygular. Bu küçük API, ajanın çalışan bir oyunu yeniden yüklemeden inceleyip değiştirmesini sağlayan sözleşmedir. Bunun neden önemli olduğuna 6. bölümde geri döneceğiz.

3. Asıl motorun bulunduğu orkestratör

Buna "bir yapay zekâ sarmalayıcısı" diyenlerin gözden kaçırdığı nokta, yapay zekânın kod yazmaktan ziyade küçük bir orkestrayı yönetmesidir. Orkestratör, öncü bir model üzerinde çalışan, araç çağırmaya dayalı bir döngüdür. Yaklaşık bin satırlık bir sistem istemine ve tür tanımlı 26 işlevden oluşan bir araç yüzeyine sahiptir. Motor, araç tanımlarıdır. Model ise orkestra şefidir.

26 araç beş aileye ayrılır. Dosya sistemi araçları (list_game_files, read_files, search_game_file, edit_files, write_files, delete_files, rename_files), ajanın oyununuzu herhangi bir kod tabanı gibi ele almasını sağlar. Proje araçları (create_new_game, list_games, open_game, ask_user, game_ready), bir projenin yaşam döngüsünü ve kontrolün insana geri verilmesini yönetir. Üretken araçlar (generate_image, generate_skybox, generate_music, generate_sfx, rig_model, apply_animation, list_animations, list_skybox_styles), birazdan ele alacağımız uzmanlaşmış modelleri çağırır. Bilgi araçları (search_fonts, list_library_docs, search_library_docs, list_generations), ajana uydurma API'ler yerine güvenilir, dizine eklenmiş doğruluk kaynakları sunar. Çalışma zamanı araçları (read_console_logs, execute_js) ise ajanın canlı oyunu görmesini ve ona müdahale etmesini sağlar.

Tipik bir ilk konuşma sırası kabaca şöyle görünür. Kullanıcı "Neon bir uzay nişancı oyunu yap" yazar. Model önce tasarımı açıklayan GDD.md dosyası için bir write_files çağrısı, ardından index.html, game.js ve style.css için bir write_files çağrısı daha üretir. prompt="synthwave space shooter, 120 BPM, driving bassline" ile generate_music çağrısı yapar; bu, ElevenLabs Music üzerinde bir iş başlatır ve R2 içindeki bir MP3 URL'si döndürür. Yıldız alanı için Blockade Labs model 3 stilini kullanarak generate_skybox çağrısı yapar. iframe'i yeni yapıya geçirmek için game_ready(title, message), ardından oyunun hatasız başlatıldığını doğrulamak için read_console_logs çağrısı yapar. Bir yığın izleme kaydı görürse kullanıcı herhangi bir sorun bildirmeden önce edit_files adımına geri döner ve hatayı düzeltir.

Bu tasarımın ilginç özelliği, ürüne özgü olan tek şeyin sistem istemi ile araç şemaları olmasıdır. Modeli değiştirseniz bile her şey çalışmaya devam eder. Geçen yıl içinde yüzeyi değiştirmeden üç öncü model arasında geçiş yaptık, çünkü yüzey bize ait.

4. Varlık tarafı: modellere dağıtılan bir yapı

Ajan görsel, müzik, ses veya 3D içerik üretmez. Uzmanları çağırır. Cinevva'nın varlık tarafı, sınıfının en iyi modellerine dağılan ve birinin çıktısı diğerinin geçerli girdisi olacak şekilde birbirine bağlanan bir yapıdır.

Görseller ve sprite'lar için generate_image, her zaman 32'nin katı olan bir genişlik ve yükseklik kullanarak Flux Pro 1.1'i çağırır; istem şeffaflık talep ettiğinde çıktı biçimi PNG'ye geçer. Tam uzunlukta şarkılar için ajan, stilistik bir istem ve saniye cinsinden süreyle ElevenLabs Music'i çağırır. Tek seferlik efektlerde ElevenLabs SFX, "laser gun firing, sci-fi blaster" gibi bir metinden beş ila on beş saniye içinde bir klip üretir. 360 derecelik ortamlar için generate_skybox, yaklaşık doksan stilden biriyle Blockade Labs'i çağırır ve varsayılan olarak model 3 Digital Painting'i kullanır. 3D karakterler için rig_model, bir GLB dosyasını iki ayaklı, dört ayaklı, altı ayaklı, sekiz ayaklı, yılansı veya suda yaşayan bir canlı olarak kaplamak ve iskeletlendirmek üzere Tripo'ya gönderir. Ardından apply_animation, on beş hazır animasyondan herhangi birini oynatır (boşta durma, yürüme, koşma, zıplama, tırmanma, dalma, kesme, ateş etme, hasar alma, düşme, dönme ve iki ayaklı olmayanlara özel yürüyüşler).

Bunların her biri eşzamanlı bir çağrı değil, bir iştir. Saniyelerden dakikalara kadar sürebilirler. Orkestratör bunları başlatır, hemen bir jobId ile geri döner ve ayrı bir kanal, varlık hazır olduğunda sonucu konuşmaya aktarır. Bu, deneyimin hissini tamamen değiştirir. Ajan, arka planda bir 3D modelin iskeletlendirilmesi tamamlanırken oyun mantığını geliştirmeye devam edebilir. Kullanıcı hiçbir zaman tek bir kritik yolu beklemek zorunda kalmaz.

Tüm çıktılar aynı yere gider. cdn.cinevva.com arkasındaki R2'ye; sade URL'lerle erişilebilir biçimde. Böylece ajanın bir sonraki write_files çağrısı yalnızca <audio src="https://cdn.cinevva.com/audio/abc.mp3"> etiketini ekleyebilir ve oyun doğrudan çalışır. SDK yok, varlık paketleyici yok, manifest yok.

5. On bir sağlayıcıda varlık araması

Belirli bir şeye ihtiyaç duyduğunuzda üretim harikadır. Bir şey zaten mevcutsa arama daha hızlıdır. Varlık Kitaplığı, on bir ücretsiz ve lisanslı sağlayıcıda birleşik arama yaparak sonuçları tek bir sıralanmış akışta sunar.

Sağlayıcı kayıt sistemi worker içinde yer alır ve her sorguyu PolyHaven, Sketchfab, Freesound, Kenney, AmbientCG, Quaternius, OpenGameArt, Smithsonian 3D koleksiyonu, TurboSquid, Synty ve Jamendo üzerinde paralel olarak çalıştırır. Her sağlayıcı ortak bir arayüz uygular (search, getMetadata, isBrowsable, getSupportedTypes), dolayısıyla yeni bir sağlayıcı eklemek için tek bir TypeScript dosyası yeterlidir. Birleştirme katmanı, sayfalandırmayı farklı şekillerde yapan sağlayıcılar arasında imleç tabanlı sayfalandırmayı yönetir, yinelenen lisansları kaldırır, varlık türlerini ortak bir sınıflandırmada (model, doku, ses, hdri, sprite) normalleştirir ve ajanın yeniden dağıtamayacağı bir şeyi seçmemesi için her varlığı lisansıyla etiketler.

ChatGPT geçen çeyrekte bu aracı oyun geliştiricileri için en iyi ücretsiz varlık buluculardan biri olarak önerdiğinde gidip tavsiyeyi okuduk. Önemli olan kısımda haklıydı. Mesele tek bir kitaplığın üzerinde arama çubuğumuzun olması değil. Mesele, "taş duvar dokusu" arayan bağımsız bir geliştiricinin tek sorguyla ve tutarlı lisans meta verileriyle PolyHaven ile AmbientCG sonuçlarını, Kenney'nin stilize sürümünü ve Smithsonian'ın fotogrametri seçeneğini yan yana görebilmesi. Ajan da aynı uç noktayı kullanabilir ve varlıkları bir insanla aynı şekilde seçebilir.

Motorun çoğu zaman yeterince önemsenmeyen kısmı budur. Çoğu oyun yapay zekâsı demosu her şeyi sıfırdan üretir ve sonuçta tek tip, parlak, hafif tekinsiz bir görünüm ortaya çıkar. Cinevva'daki ilginç oyunlar, üretilmiş varlıkları Smithsonian'dan gerçek CC0 fotogrametri içerikleri ve Quaternius'tan el yapımı düşük poligonlu bir ağaçla birleştiriyor. Orkestratör bunu tek bir konuşma sırasında yapabilir.

6. Ajan oyunu oynar

Mühendislerin çoğunu gösterdiğimizde şaşırtan kısım bu. Ajan yalnızca dosyalara kod yazmaz. Oyunu korumalı bir iframe içinde çalıştırır, konsolunu okur, kullanıcı arayüzü ile 3D sahne için ayrı katmanlar hâlinde ekran görüntüleri alır ve durumu incelemek veya değiştirmek için canlı çalışma zamanı içinde JavaScript çalıştırır. read_console_logs, iframe’deki son elli console.log, console.warn, console.error satırını ve yakalanmamış istisnaları döndürür. Her game_ready çağrısından sonra ajan, sistem istemi gereği read_console_logs çağırmalı ve oyunu kullanıcıya teslim etmeden önce tüm hataları düzeltmelidir. Bu tek kural, diğer araçlarda görülen “Yapay zekâ tamamlandığını söyledi ama ekran simsiyah” sorunlarının çoğunu ortadan kaldırır.

execute_js ise daha güçlü olanıdır. Oyunun global kapsamında rastgele JavaScript çalıştırır. Her oyunun getGameState ve setGameState işlevlerini uygulaması gerektiğinden ajan, çalışan oyunun tüm durumunu okumak için JSON.stringify(getGameState()) çalıştırabilir; ardından oyuncuyu ışınlamak için setGameState({player: {x: 500, y: 100}}), yenilmezlik vermek için setGameState({lives: 99}) veya ileri atlamak için setGameState({level: 3}) çağrısını kullanabilir. Ayrıca Three.js sahne grafiğini incelemek için scene.children.map(c => c.type) ya da oluşturucunun bağlandığını doğrulamak için document.querySelectorAll('canvas').length gibi komutlarla daha alt seviyelere de erişebilir.

Bunun neden önemli olduğunu görebilirsiniz. Bir kullanıcı “Oyuncu ikinci bölümde duvara takılıyor” dediğinde ajanın tahmin yürütmesi gerekmez. İkinci bölümü açar, getGameState() çalıştırır, çarpışma verilerini inceler, düzeltmeyi test etmek için bir execute_js yaması çalıştırır ve ancak bundan sonra düzeltmeyi diske yazar. Sizin hata ayıkladığınız gibi hata ayıklar. Iframe’i bir hedef değil, eş düzey bir bileşen olarak ele alıyoruz.

7. Kütüphane belgeleri, sıkıcı gerçeklik kaynağı

Oyunların gerçekten kullandığı kütüphanelerin (Three.js, Tone.js, Cannon ve giderek daha fazlasının) resmî belgelerini yapılandırılmış, aranabilir bir JSON deposunda dizinliyoruz. Ajan, açık web’e yönelmeden önce search_library_docs("threejs", "Mesh") komutuna başvurur. Bu daha hızlıdır, sürümlendirilmiştir ve iki alt sürüm önce yeniden adlandırılmış bir yöntemi asla uydurmaz.

Bu gösterişli bir şey değil. Ancak çalışan kod üreten bir yapay zekâ ile kırkıncı satırda çöken, ikna edici görünen kod üreten bir yapay zekâ arasındaki farkı yaratıyor. Cinevva ile geliştirilen oyunların görünür kalitesinin büyük bölümü bu tek karardan kaynaklanıyor.

8. Oynanabilirlikten keşfedilebilirliğe: kısa videolar ve mağaza vitrini

Kimsenin oynamadığı bir oyun, kişisel bir hobiden ibarettir. Bağımsız oyun geliştirmedeki çözülmemiş en zor sorun artık oyun yapmak değil, dağıtımdır. Bu yüzden motor “oynanabilir” noktada durmaz. “Oyuncuların önünde” olduğu noktada durur.

Cinevva’daki her proje, oyunun en son sürümünü beğeni ve paylaşım seçenekleri içeren küçük bir katmanla birlikte tam sayfa iframe’de açan play.cinevva.com/{game-id} gibi kalıcı bir paylaşım URL’sine sahiptir. Ajan game_ready çağrısı yaptığında yalnızca IDE içi önizlemeyi etkinleştirmez. Ayrıca 15 saniyelik bir oynanış videosunu Cinevva mağaza vitrininde yayımlamayı önerir. Kısa video, oynanan oyunun doğrudan iframe’den yakalanmış gerçek bir kaydıdır (ajanın oyun çalışma zamanına enjekte ettiği küçük bir kayıt betiği sunuyoruz); dolayısıyla izleyicinin kaydırırken gördüğü şey bir pazarlama kurgusu değil, gerçek oynanıştır.

Bu, bir geliştiricinin içinde yaşadığı döngüyü değiştirir. Eski döngü; kodlama, derleme, paketleme, yükleme, bir Steam sayfası yazma, algoritmayla mücadele etme ve istek listesi sayacını izleme şeklindeydi. Yeni döngü ise bir cümle yazmak, ajanın geliştirmesini izlemek, yayımla düğmesine basmak ve oyununuzun diğer her şeyin yanında aynı kaydırmalı akışta belirmesini izlemektir. Keşif, üretimin gerçekleştiği ürünün içinde, aynı URL’de ve aynı oturumla gerçekleşir.

Geliştirici topluluğundaki okurlarımızın incelemesi gereken kısım burası. Dağıtım, oyun motorlarının hiçbir zaman birlikte sunmadığı rekabet hendeği olmuştur. Unity bir editör sunar, oyunu Steam’de siz yayımlarsınız. Unreal bir editör sunar, oyunu Epic Store’da siz yayımlarsınız. Cinevva her iki yarıyı da sunar. Motor ve mağaza vitrini, oyunu geliştiren aynı orkestratör üzerinden birbiriyle iletişim kurar.

9. En İyi Performans Gösterenler: keşif çarkı

Kısa video akışı, çarkın bir yarısıdır. En İyi Performans Gösterenler tablosu ise diğer yarısıdır. Oyunları trend, en yeni ve tüm zamanların en iyileri olarak sıralar; ham tıklamalar yerine tamamlama oranını (oyuncu bir oturumu tamamladı mı?) ağırlıklandırır. Tamamlama oranını manipüle etmek, yükleme sayılarını manipüle etmekten daha zordur. Dikkati altmış saniye boyunca koruyan bir oyun, açılıp hemen kapatılan bir oyunu geride bırakır.

Her sinyal, orkestratörün bir sonraki turuna geri beslenir. Ajan “Bir güçlendirme ekleyelim” dediğinde sabit bir kalıp kütüphanesinden yararlanmıyor. Bu ay Cinevva’da hangi mekaniklerin oyuncuları gerçekten elde tuttuğunu gözlemlemiş bir modelden yararlanıyor. Çark, sayfanın altındaki bir tablodan ibaret değil. Tüm motorun eğitim sinyalidir.

Yatırımcılar için veri hendeğimiz budur. Yalnızca üretilmiş oyunlara sahip değiliz. Bu oyunları oluşturan istemlerle, ajanın yaptığı varlık seçimleriyle ve onları beğenen oyuncularla ilişkilendirilmiş, gerçek oturum düzeyinde etkileşim metriklerine sahip üretilmiş oyunlarımız var. Her döngü bir sonrakini daha da güçlendiriyor.

10. Motor bir oyuna dönüşüyor

Aylardır sosyal medyada ima ettiğim kısım burada. 1’den 9’a kadar olan bölümlerdeki her şey, oyun geliştiren bir sistemi anlatıyor. Siz görene kadar anlatılması daha zor olan şey ise sistemin kendisi bir mekâna dönüştüğünde yaşananlar.

Sunduğumuz tüm özelliklere rağmen oyun geliştirmek zor iştir. Daha önce hiç oyun yapmadıysanız bir anda hikâyeden, karakterlerden, dünyadan, mekaniklerden, kimin neyi ne zaman yaptığından, ışığın nasıl davrandığından, özel efektlerin nasıl katmanlandığından, müzikten, ses efektlerinden ve kamera hareketlerinden sorumlu hâle gelirsiniz. Bu çok fazla şeydir. Üstelik tüm bunların yanında sonucun, başka birinin aracının çıkardığı bir şablon gibi değil, size aitmiş gibi hissettirmesini istersiniz. İstem ve orkestratör, mekanik işlerin çoğunu sizin için yapar. Tek başlarına yapamayacakları şey, tamamlanmış eseriniz için diğer insanların izlediği bir sahne sunmaktır.

Biz de sahneyi kurduk. Bu yılın büyük bölümünde Oleg ve motor ekibi, açık bir dünyayı tarayıcıya taşımayı anlatan 14 bölümlük bir seride çalışmalarını yayımladı. Gerçek zamanlı şekillendirebildiğiniz yontulmuş araziler. Eğim ve rakıma göre kendini kaya ya da çim olarak boyayan biyomlar. Hesaplamayla üretilmiş arazinin üzerinde rüzgârda eğilen 80.000 çim sapı. Aynı adımda hem yükseklik haritası hem de hacimsel arazi üzerinde yürüyen, koşan, zıplayan ve süzülen bir karakter. Bunların hiçbiri sırf teknoloji demosu olsun diye yapılmadı. Hepsi bunun altyapısını oluşturuyordu.

Bugün açık dünya erken sürümüyle yayında. Bir avatar seçip içeri giriyorsunuz. Yayımlanmış oyunlarınız, tıpkı mağaza vitrini kısa videolarının ve En İyi Performans Gösterenler tablosunun onları şimdi gösterdiği gibi, etrafınızda ziyaret edilebilir alanlar olarak beliriyor; ancak bu kez kaydırarak değil, yürüyerek ulaşıyorsunuz. Dünyadan ayrılmadan, o dünya üzerinden bir yabancının oyununa girebilirsiniz. Az önce oynadığınız şeyi yapan kişinin yanında durup ona sırada ne ekleyeceğinizi söyleyebilirsiniz. Yeni tanıştığınız biriyle bir arazi parçasını şekillendirip onu yeni bir projenin tohumuna dönüştürebilirsiniz. Keşif artık bir akış olmaktan çıkar. Bir yürüyüşe dönüşür.

Motorumuz teknik anlamda her zaman bir oyun motoruydu. Bugün gerçek anlamda da bir oyuna dönüşüyor. Oyununuzu geliştiren şey artık başlı başına bir oyun ve 3. bölümdeki aynı orkestratör, 4. bölümdeki aynı varlık rayları, 6. bölümdeki aynı getGameState sözleşmesi, 8. bölümdeki aynı kısa videolar ve 9. bölümdeki aynı tablo, oyuncularınızın içinde dolaştığı tek bir yerde birleşiyor. Üretmek ile oynamak arasındaki sınır her zaman yapaydı. Artık ortadan kalktı.

Neleri doğru yaptığımızı düşünüyoruz

Doğru yaptığımız ilk şey, istemi bir ürün yerine bir kullanıcı arayüzü olanağı olarak ele almaktı. Ürün; orkestratör, araç yüzeyi, varlık rayları ve mağaza vitrinidir. İstem ise kullanıcıyı sisteme dâhil etmenin mümkün olan en düşük maliyetli yoludur.

İkincisi, derleme adımı olmayan düz, tarayıcıya özgü bir dosya sisteminde ısrar etmekti. Bir Cinevva oyununun tek bir doğruluk kaynağından mobil cihazlara, masaüstüne, Steam’e ve Discord’a sunulabilmesinin nedeni budur. Ajanın yazdıklarını okuyabilmesinin nedeni de budur.

Üçüncüsü, üretilen her oyunun getGameState ve setGameState işlevlerini uygulamasını gerektiren sözleşmeydi. Sistem istemindeki bu tek satır, ajanın bir kod üreticisi yerine bir iş arkadaşı gibi hissettirmesini sağlar. Ajan oynayabilir ve oynayabilen bir sistem hata ayıklayabilir.

Dördüncüsü, mağaza vitrinini motorla aynı döngüye bağlamaktı. Salt model kalitesiyle kazanmayacağız. Açık ağırlıklı bir üreticiden iki ay ileride olmanın savunulabilir bir avantajı yok. Oyununuzu geliştiren aynı ajan onu yayımladığında, ölçtüğünde ve yabancıların onu nasıl oynadığından öğrendiğinde kazanırız.

Tüm makineyi çalışırken görmek istiyorsanız ana sayfadaki istem hâlâ giriş kapısıdır. Bir cümle yazın. Arkasında neler olduğunu izleyin. Sonra buraya dönüp motorun hangi parçasını sıradaki yazıda ele almamız gerektiğini bize söyleyin.

Yazan: Oleg Sidorkin, Cinevva CTO'su ve Kurucu Ortağı

Burada yeni misiniz? Seri rehberine göz atın. Rehber, spike'ın ne olduğunu açıklıyor ve tüm bölümlere bağlantı veriyor.

Bölüm 13'ten bu yana her spike aynı tarifi izliyordu: önceki monoliti kopyala, bir özellik ekle. Spike 32'nin sonunda bu monolit, tek bir <script type="module"> içindeki 6.285 satırlık bir index.html dosyasına dönüşmüştü. Kod aramaları gereksiz sonuçlarla doluydu, bir özelliği nereye ekleyeceğimizi bulmak onu yazmaktan daha uzun sürüyordu ve herhangi bir mimari değişiklik, farklarını zihinde takip edemeyeceğiniz kadar büyük bir dosyaya dokunuyordu. Yeni bir özellik daha eklemeden önce yapısal borcu kapattık.

Davranışı hiç değiştirmeden monoliti parçalamak

Spike 33'ü yeni sekmede aç ↗ · Kaynak kodu görüntüle

Kısıt katıydı: her ayırma işlemi yeniden tasarım değil, yalnızca davranışı değiştirmeyen bir yeniden düzenleme olmalıydı. Monolit, 19 .mjs dosyasına ve 151 satırlık bir ana kabuğa dönüştü. Sahne, su, çim, karakter, fizik, çok oyunculu sistem ve kullanıcı arayüzü için üst düzey modüller; GPU tarafındaki tüm doğruların tek kaynağı olarak her WGSL kaynak dizesini barındıran bir wgsl.mjs; ayrıca yükseklik haritası, SDF, parçalar, GPU tampon sarmalayıcıları, fırça, LOD ve kalıcılık için bir terrain/ alt ağacı oluşturduk. Toplam kod 6.555 satır oldu; yani temelde monolite içe aktarma için gereken standart kodların eklenmiş hâliydi. Hacim neredeyse hiç değişmedi, ancak kod içinde gezinmek çok daha kolaylaştı.

Ardından sayfa siyah ekranla açıldı. İki hata mesajı ve birbiriyle ilgisiz iki temel neden vardı. İlki, sıfır baytlık bir tampon bağlamasıyla ilgili WebGPU şikâyetiydi. Monolitte SDF fırça tamponu, ilk marching cubes parçası göründüğünde tembel biçimde ayrılıyordu; bağlama grubu fabrikası ise tesadüfen daha sonra, tampon oluşturulduktan sonra çalışıyordu. terrain/gpu.mjs dosyasını terrain/brush.mjs dosyasından ayırmak modül değerlendirme sırasını değiştirdi. Böylece fabrika artık önce çalışıyor ve bir null yer tutucuyu bağlamaya çalışıyordu. Çözüm, bağlama grubu oluşturmayı ilk dispatch işlemine kadar erteleyen bir getOrCreateBindGroup(chunk) yardımcısı kullanmaktı. "Her şeyi baştan oluştur" kalıbı, monolitin tek başlatma yolundan kalma bir kalıntıydı.

İkinci mesaj, korkutucu görünen bir FBX iskelet uyarısıydı ama bunun yanlış iz olduğu ortaya çıktı. Spike 25'ten beri yazdırılıyordu ve zararsızdı. Karakterin kayıp olmasının tek nedeni ilk hatanın zincirleme etkisiydi: her compute dispatch hata veriyor, yükseklik haritasına hiçbir zaman yazılmıyor, yükseklik örnekleri 0 döndürüyor ve karakter başlangıç noktasında doğup dünyanın içinden aşağı düşüyordu. Tamponu düzeltince karakter, uyarıya rağmen sorunsuz biçimde canlandı.

Yeniden düzenlemenin asıl dersi buydu. Monolit, tüm "Y oluşturulmadan önce X mevcut olmalı" ilişkilerini betiğin yukarıdan aşağıya çalışma sırasının içine gizliyordu. Modülerleştirme bu sırayı değiştirdi ve bekleyen üç sıralama hatasını daha açığa çıkardı: yükseklik haritası yüklenmeden önce çimlerin dağıtılması, ortam haritasının kod çözme işlemi bitmeden önce su düzleminin eklenmesi ve kalıcılık yüklemesinin ilk kareden sonra tamamlanması. Üçünün de çözümü tek satırdı ve ayırma işlemi olmasaydı hiçbiri yakalanmayacaktı.

Hiçbir şeyi büyütmeden yüz nesne eklemek

Spike 34'ü yeni sekmede aç ↗ · Kaynak kodu görüntüle

Spike 34, bu yapının işe yarayıp yaramadığını sınayan testti. Amaç, kontrollerden ayrılmadan bir CC0 model paketindeki ağaçları, kayaları, çalıları, mantarları ve yolları yerleştirmek için birinci şahıs bir palet oluşturmaktı. Buna araziye duyarlı hizalama, kalıcılık, çok oyunculu eşitleme ve fizik çarpıştırıcıları da dâhildi. Yeni kodun her satırı src/props/ altındaki beş yeni dosyaya yerleşti ve mevcut modüllerin hiçbiri on satırdan fazla bağlantı koduyla büyümedi.

Varlık süreci, kayda değer bir sapma yaşadı; çünkü bu, bir günü kolayca tüketebilecek türden bir meseleydi. İşe, gömülü dokular içermeyen bir FBX kütüphanesi olan Quaternius Ultimate Nature paketiyle başladık. FBX malzemeleri, haritasız MeshPhong olarak geliyordu. Bu nedenle malzeme adlarını PNG'lerle eşleştiren manuel bir tablo kurduk, Phong'u Standard'a dönüştürdük ve renk uzaylarını elle ayarladık. Malzemelerin yaklaşık %30'unun eşleşen PNG'si yoktu ve benzer ağaçlar arasında bazı adlar belirsizdi. İkinci bir FBX paketinde de aynı eksik vardı. Çözüm daha fazla eşleme tablosu değil, daha iyi hazırlanmış bir paketti: Quaternius Stylized Nature MegaKit, gömülü PBR malzemeleri ve fırınlanmış normalleri olan 116 eksiksiz glTF ile geliyor. FBXLoader yerine GLTFLoader kullanmak; santimetreden metreye ölçeklemeyi, doku tablosunu ve Phong dönüşümünü ortadan kaldırdı, ayrıca library.mjs dosyasını yaklaşık 80 satır küçülttü. Çıkarım şu: glTF sunan CC0 paketler için PBR destekli glTF doğru işlem hattıdır; manuel doku eşlemeli FBX ise yarı kalite için iki kat kod gerektiriyordu.

glTF yolu da birkaç keskin köşeyle geldi. Palet 116 küçük resim oluşturuyor ve WebGPU'nun canvas.toDataURL() işlevi, GPUCanvasContext yüzeyi için boş sonuç döndürüyor. Bu nedenle küçük resimler bir RenderTarget içine işleniyor, readRenderTargetPixelsAsync ile geri okunuyor ve WebGPU'nun 256 baytlık satır hizalaması dikkate alınarak 2B bir tuvale kopyalanıyor. Hayalet önizlemeler, her malzemeyi yeşile boyamak için klonluyor; ancak material değeri bir dizi olan mesh'lerde bu bozuluyordu. Sorunu bir Array.isArray dalıyla çözdük. Ayrıca yaklaşık 200 MB boyutunda gelen 16 bit normal haritaları, tek seferlik bir mogrify -depth 8 işlemiyle yaklaşık 32 MB'a indirildi. Tarayıcılar yükleme sırasında zaten alt örnekleme yaptığı için görsel sonuç tamamen aynıydı.

İşlenen geometri yalnızca GPU'da mevcut olduğunda

En öğretici hata, imleç hareket ederken hayalet önizlemenin 1 ila 2 metrelik adımlarla sıçramasıydı. Arazi mesh'leri, compute işlem hattı konumları doğrudan GPU'ya yazdığı için köşe konumlarını bir StorageBufferAttribute içinde saklıyor. Bu nedenle three.js'in CPU tarafındaki Raycaster bileşeni bunları göremiyor ve hiçbir sonuç döndürmüyor. Yedek yöntem, analitik yükseklik haritasına karşı 1,5 metrelik kaba bir ışın yürüyüşüydü ve kullanıcının gördüğü ızgarayı bu sabit adım oluşturuyordu. Bunu uyarlanabilir bir yürüyüşle değiştirdik: yüzeyin çok üzerindeyken 2,5 m adım, yüzeye 5 m kala 0,4 m adım ve $({\text{ray}}_y-{\text{terrain}}_y)$ işareti değiştiğinde 14 kez ikiye bölme. Bu yöntem, ışın başına yaklaşık 30 geniş adım ve 14 ikiye bölme ile milimetrenin altında hassasiyet sağlıyor. İşlenen geometri yalnızca GPU'da yaşıyorsa raycaster ile mücadele etmeyin; analitik kaynağa karşı yürüyün.

Düzenlemeler boyunca doğruluğunu koruyan çarpıştırıcılar

Dışbükey gövdeler veya mesh çarpıştırıcıları yerine ilkel şekil vekillerini seçtik. Quaternius nesneleri belirgin içbükeylikleri olmayan, yuvarlak hatlı ve düşük poligonlu modeller. Bu nedenle gövdeler aynı oynanış için yaklaşık 50 kat fazla kod ve çalışma zamanında 10 kat fazla maliyet getirirdi. Her nesne, sınırlayıcı kutusundan türetilen tek bir şekle indirgeniyor: ağaçlar ve kaktüsler dikey kapsüle, kayalar küreye, kütükler uzun eksen boyunca yatay kapsüle dönüşüyor; dekoratif çalılar ve çiçekler ise hiçbir çarpıştırıcı almıyor. Kayaların ve kütüklerin üzerinde yürünebiliyor; üzerlerinde durabilmeniz için yalnızca dikey itme uygulanıyor. Ağaçlar ve kaktüsler ise engelleyici; gövdeye tırmanamamanız için tam 3B itme uygulanıyor. 8 metrelik bir uzamsal karma, kare başına testi oyuncunun 3×3'lük komşuluğuyla sınırlıyor; burada genellikle sıfır ila altı nesne bulunuyor.

İki tasarım kararı sistemin tutarlı kalmasını sağladı. Arazi hizalaması, kod içine sabitlenmiş bir kategori enum'u değil, manifest içindeki bir bayraktır. Böylece hayalet önizleme ile kesinleştirilmiş yerleşim aynı placement.alignToTerrain değerini okur ve birbiriyle çelişemez. Ayrıca yerleştirilen nesneler, arazi düzenlemelerine tek bir yardımcı üzerinden tepki verir: bir fırça darbesinden sonra —ister yerel olsun ister eşten yeniden oynatılsın— refreshPlacementsInRadius, etkilenen disk içindeki her nesnenin altındaki zemini yeniden örnekler, hizalamayı yeniden uygular ve çarpıştırıcı uç noktalarını yeniden türetir. Bir ağacın altında tepe şekillendirdiğinizde ağaç da onunla birlikte yükselir. Kalıcılık ve çok oyunculu sistem, spike 31'in kalıbını aynen yeniden kullanıyor; düz bir {uid, propId, x, y, z, rotY, scale} listesi saklıyor ve yerleştirme, kaldırma ve küçük hareket olaylarını BroadcastChannel üzerinden yansıtıyor.

Bu bölümde değinilen teknolojiler

WebGPU altında ES modülü ayrıştırması. Monolitik bir <script type="module"> yapısını yalın yollu .mjs içe aktarmalarına bölmek, modüller statik varlıklar olarak sunulduğunda paketleyici gerektirmez; ayrıca three.js TSL modül sınırları arasında sorunsuz çalışır. Gizli maliyet, başlatma sırasıdır: monolit, "Y'den önce X'i oluştur" kuralını betiğin yukarıdan aşağıya sırasına kodlar. Modüller ise içe aktarma sırasına göre değerlendirilir ve bu, tamponu henüz mevcut değilken bir GPU bağlama grubu fabrikasını çalıştırabilir. Çözüm kalıbı, tembel başlatma (ilk kullanımda getOrCreate...) ve bildirim sırasına güvenmek yerine doğru promise'i beklemektir.

Gömülü PBR destekli glTF ile manuel eşlemeli FBX karşılaştırması. glTF metre cinsinden gelir, kendi dokularına başvurur ve doğrudan MeshStandardMaterial sağlar. Böylece glTF olarak hazırlanmış bir CC0 paketi doğrudan PBR işlem hattına girer. Doku bağlama meta verileri olmayan FBX paketleri, her paket güncellemesinde güncelliğini yitiren ve elle sürdürülen bir malzeme-adı-PNG tablosunun yanı sıra Phong'dan Standard'a dönüşüm ve manuel renk uzayı etiketleme gerektirir. Bitki örtüsü için kullanılan bir güvenlik ağı, alphaTest içermeyen transparent malzemeleri alphaTest: 0.5 kesme kartlarına yükseltir; böylece opak geometrinin arkasında doğru sıralanırlar.

WebGPU ekran dışı küçük resimleri. canvas.toDataURL(), GPUCanvasContext destekli bir tuval için boş sonuç döndürür; çünkü sunum yüzeyinden 2B bağlama geri dönen bir yol yoktur. WebGPU'nun 256 bayta hizalanmış geri okuma adımlarına uyulduğu sürece bir RenderTarget içine işlemek, pikselleri readRenderTargetPixelsAsync ile okumak ve 2B tuvale kopyalamak işe yarar. Sonuçlar, paket değişikliklerinin eski işlemeleri geçersiz kılabilmesi için sürümü artırılmış bir anahtar altında localStorage içinde önbelleğe alınır.

Analitik yükseklik haritasına karşı uyarlanabilir ışın yürüyüşü. Arazi köşeleri GPU'daki bir StorageBufferAttribute içinde yaşadığında CPU ışın izleyicisi bunları göremez. Analitik yükseklik işlevinde yüzeyden uzaktayken büyük, yüzeye yakınken küçük adımlarla yürümek ve $({\text{ray}}_y-{\text{terrain}}_y)$ işaret değiştirdiğinde ikili aramayla inceltme yapmak, sınırlı sayıda örnekle milimetrenin altında imleç hassasiyeti sağlar. Aynı ilkel yöntem hem fırça imlecini hem de nesne hayaletini çalıştırır.

Uzamsal karma kullanan ilkel kapsül çarpıştırıcıları. Her nesne, sınırlayıcı kutusundan kategoriye göre türetilen bir kapsüle veya küreye indirgenir, {kind, walkable, radius, p1, p2} olarak kaydedilir ve kesiştiği her 8 metrelik karma bölmesine eklenir. Oyuncu, kare başına yalnızca 3×3'lük bölme komşuluğundaki nesneleri test eder ve her biri için tek bir kapsüle karşı kapsül çözümlemesi uygulanır. Üzerinde yürünebilen vekiller (kayalar, kütükler) yalnızca dikey itme, engelleyici vekiller (ağaçlar) ise tam 3B itme alır. Bunun temel aldığı kapsül matematiği için SDF arazi çarpışmalarına bakın.

29 bölümün 16.'sı. Önceki: Bölüm 15 - Temeli değiştir, ardından eşitle Sonraki: Bölüm 17 - Yeniden hedefleme gerektirmeyen animasyonlar ve canlı varlık araması Seri rehberi: /tr/blog/2026-02-25-open-world-browser-series-guide

Mariana Muntean, Cinevva CEO'su

Mayıs 2022'de Ted Harrington'ın Tech Done Different podcast'i için bir röportaj verdim. Röportajın orijinal yazısı hâlâ Medium'da yayında. O sırada Cinevva'yı yaklaşık iki yıldır yönetiyordum. Beş kişilik bir ekibimiz, topladığımız 200 bin dolar, duvarda asılı bir Mozilla Builders ödülü ve oyun geliştirmenin nereye gittiğine dair pek çok fikrimiz vardı.

Bu fikirlerin çoğu 2022'de pek revaçta değildi. Web3 çok ses getiriyor, gündemi AAA stüdyolar belirliyor, GPT-3 bir araştırma oyuncağı olarak görülüyor, WebGL ise hobi amaçlı game jam oyunları yapmak için kullanılıyordu. “Her yaratıcı kişi bir oyun geliştiricisi olacak” dediğinizde nazikçe başlarını sallıyor ama tek kuruşluk çek yazmıyorlardı.

Geçen hafta o röportaja dönüp yeniden baktım. Söylediklerimin bazıları hüsnükuruntu gibi geliyor. Bazılarıysa sanki bir zaman makinem varmış gibi. İşte zamana en iyi direnen dört iddia ve her birinin yanında 2026'daki gerçek durum.

1. iddia: Oyun motorlarının yeri tarayıcıdır

2022'de şöyle demiştim:

WebGL teknolojisi, yalnızca PC'lerle sınırlı olabilen diğer API'lerin aksine mobil cihazlar da dâhil olmak üzere birden fazla platformda kullanılabilir. Böylece ister evinizin konforunda ister hareket hâlinde olun, üretmeye ve yayımlamaya devam edebilirsiniz. WebGL oyunları, geleneksel bir PC oyununun ihtiyaç duyduğu CPU ve GPU gücünün yalnızca küçük bir bölümünü kullanır.

Bu, 2022'de genel kabule ters düşen bir iddiaydı. Büyük oyun motorlarının tümü indirme, kurulum ve yama döngülerini temel alıyordu. Tarayıcı oyunları dendiğinde akla Flash nostaljisi ve Friv geliyordu.

2026'da açık dünya motorumuz bir tarayıcı sekmesinde 120 FPS ile çalışıyor. Arazi, ağaçlar, fizik ve çok oyunculu senkronizasyonun tamamı tek bir URL'de. İndirme yok, uygulama mağazası yok, kurulum yok.

Üç gelişme aynı anda gerçekleştiği için tarayıcı aradaki farkı kapattı. WebGPU tüm büyük tarayıcılarda kullanıma sunuldu. SharedArrayBuffer ve kaynaklar arası yalıtım güvenilir hâle geldi. WebAssembly, Rust'tan derlenen gerçek fizik motorlarını çalıştırabilecek kadar hızlandı. Ekibimiz, bu adımların her birinin gerçekte nelere mal olduğunu anlatan 12 bölümlük bir saha günlüğü yayımladı. Özetle tarayıcı artık gerçek oyunun demosunu koyduğunuz bir yer değil, başlı başına gerçek bir oyun çalışma ortamı.

Bu iddianın içinde gözden kaçırdığım nokta şuydu: İşin ne kadar büyük bir bölümünün mühendislik kültürü tarafında yapılması gerekeceğini hafife aldım. Tarayıcı tabanlı oyun motorlarını artık tarayıcılar sınırlamıyor. Onları sınırlayan şey, gerçek bir oyunun başlatıcıya sahip olması gerektiği varsayımı.

2. iddia: Yapay zekâ bir yan özellik değil, üretim sürecinin parçasıdır

2022'de şöyle demiştim:

Platformumuzun kusursuz çalışması için açık kaynaklı oyun araçlarından yararlanıyor, ayrıca Doğal Dil İşleme, Bilgisayarlı Görü ve diyaloglar için GPT3, metinden görsel üretimi için DALL:E gibi Open AI çözümlerini kullanarak kendi teknolojimizi geliştiriyoruz.

Mayıs 2022'de GPT-3, çoğu insanın hiç kullanmadığı ücretli bir API'ydi. DALL·E henüz bir yaşını biraz geçmişti ve bekleme listesiyle erişilebiliyordu. Bunları üretimde kullanılan oyun geliştirme araçları hâline getireceğimizi söylemek, en iyi ihtimalle iddialı bir rol yapma gösterisiydi.

2026'da bizimki de dâhil olmak üzere her ciddi yaratıcı üretim sürecinde dil modelleri ve görsel üretimi yer alıyor. Bugün Cinevva'nın içinde müzikler için ElevenLabs Music, efektler için ElevenLabs SFX, varlıklar için Hunyuan3D ve SAM3D, görseller için Flux, uyarlanabilir sesler için Mubert, enstrümantasyon için AceStep kullanılıyor. İstemler giriliyor, kullanılabilir varlıklar çıkıyor ve tüm bunlar editörün içinde gerçekleşiyor.

Bunun kanıtları GDC 2026 State of the Game Industry raporunda yer alıyor. Oyun şirketlerinin %52'si üretimde üretken yapay zekâ kullanıldığını söylüyor. Geliştiricilerin yine %52'si yapay zekâ kullanımının sektörü olumsuz etkilediğini belirtiyor. Her iki oran da doğru. Asıl mesele, temel teknolojinin kimsenin itiraf etmek istemediği kadar hızlı biçimde vazgeçilmez hâle gelmesi.

Yanıldığım nokta: Direncin, kalite konusunda endişelenen mühendislerden geleceğini düşünmüştüm. Direncin büyük bölümü, işlerini kaybetmekten endişe duyan sanatçılardan geldi. Bu tartışma beklediğimden çok daha karmaşık ve bunu tartışmasız bir zafer gibi görenler olup bitene dikkat etmiyor.

3. iddia: Oyun geliştirme, Google Dokümanlar tarzı iş birliğine ihtiyaç duyuyor

2022'de şöyle demiştim:

Kaynak kontrolü ve uygulama sürümleriyle çalışma çoğu zaman uzaktan iş birliğiyle bağlantılıdır. Bugün bunu yapabilmek için nereye gideceğinizi, uygulamanın hangi sürümünü indirmeniz gerektiğini bilmeniz ve herkesle senkronize olmanız gerekiyor; Allah korusun, ekip üyelerinden biri uygulamanın yanlış sürümünü kullanıyorsa bu bir soruna dönüşüyor. Google dokümanlarına benzer, gerçek zamana yakın bir deneyim hedefliyoruz: basit, zahmetsiz ama eğlenceli.

Kodlama araçlarında gerçek zamanlı iş birliği 2022'de marjinal bir fikirdi. Replit'te vardı. VS Code Live Share mevcuttu. Profesyonel motorların çoğuysa Perforce, VPN ve dalınıza göz kulak olacak kıdemli bir mühendis gerektiriyordu.

2026'da ciddiye alınmak isteyen her yaratıcı araç için gerçek zamanlı iş birliği varsayılan hâle geldi. Figma bunu tasarımda normalleştirdi. Cursor ve Bolt kodlamada normalleştirdi. Lovable, uygulama prototiplemede normalleştirdi. Oyun motorları lider değil, geride kalan taraftı.

Artık kendi motorumuzda da parça aktarımı, katılımcı görünürlüğü ve tarayıcıda paylaşılan durumla birlikte, birinci sınıf bir deneysel özellik olarak çalışan çok oyunculu senkronizasyon var. Deneyim, “Perforce'u kur, Slack'ten doğru sürümü sor, başlatıcıyı yükle”den ziyade “bağlantıyı aç, oyuna katıl” yaklaşımına yakın.

Hafife aldığım nokta şuydu: Oyunlarda gerçek zamanlı iş birliğinin en zor kısmı ağ iletişimi değil. Yaratıcı niyetler arasındaki uyuşmazlıkları çözmek. İki kişinin aynı anda aynı bölümü düzenlemesi, senkronizasyon sorunundan önce bir kullanıcı deneyimi sorunu ve çoğu araç bunu hâlâ çözebilmiş değil.

4. iddia: Gelecek bağımsız geliştiricilerin

2022'de şöyle demiştim:

Daha önce oyun içeriği oluşturamayan yaratıcı kişiler artık bunu yapabilecek. İnsanların yaratıcılığı algılama ve ifade etme biçimlerinin sayısız yeni yolunu keşfedeceğiz. Bu kez süreç yalnızca şirketlerin veya büyük AAA stüdyoların kontrolünde olmayacak. Gelecek bağımsız geliştiricilerin.

Bu, röportajdaki en romantik ve 2022'de göz ardı edilmesi en kolay cümleydi. AAA bütçeleri hiç bu kadar yüksek olmamıştı. Bağımsız projeler görünürlük kazanmakta hiç bu kadar zorlanmamıştı. Rakamlar gidişatın tam ters yönde olduğunu gösteriyordu.

2026'da hesap değişti. A Breaker Belt'i iki kişiyle, üç günde, tek bir kod tabanından web, mobil ve PC için geliştirdik. Eskiden bu iş küçük bir ekibin üç ayını alırdı. Tek başına çalışan geliştiriciler yalnızca akışa kapılmıyor, oyunlarını yayımlıyor ve Steam Next Fest 2026'ya tek kişilik ekiplerden rekor sayıda başvuru geldi.

Sıra dışı bir fikrin işe yarayıp yaramadığını öğrenmenin maliyeti dibe vurdu. Asıl değişim bu; üretim sürecindeki yapay zekâ, çalışma ortamı olarak tarayıcı ve gerçek zamanlı iş birliği dâhil diğer her şey buna hizmet ediyor. Doğru araçlara sahip solo bir geliştirici artık 2018'de 20 kişilik bir stüdyonun sahip olduğu üretim kapasitesine sahip.

2022'de yeterince net öngöremediğim nokta şuydu: Darboğaz üretimden keşfedilmeye kayıyor. Herkes oyun yayımlayabildiğinde bulunmak zorlaşıyor. Sıradaki iddialarımız bununla ilgili ve şu anda onları hayata geçiriyoruz.

Bilerek yanıldığım noktalar

2022'deki iddialardan birkaçı hâlâ sonuçlanmadı veya yeniden ele alınması gerekiyor.

Web3 konusu o röportajda olması gerekenden daha çok öne çıkıyordu. Şifreleme ve sıfır bilgi ispatı kısmı, içerik hakları için temel bir yapı taşı olarak hâlâ geçerliliğini koruyor. Token ve pazar yeri çerçevesiyse zamana yenik düştü. 2022'de buna ayırdığım enerjinin büyük bölümü, asıl potansiyelin bulunduğu yapay zekâ araçlarına harcansa daha iyi olurdu.

Ayrıca “herkes oyun yapabilir” fikrinin araçlardan çok keşfedilme ve dağıtım sorunu olduğunu hafife aldım. Geliştirmek artık kolay. Bulunmak ve para kazanmak hâlâ zor; bugün çalışmalarımızın çoğu da bu alanlara odaklanıyor.

Şu anda ortaya koyduğumuz iddia bu. cinevva.com/play adresinde TikTok tarzı bir reels akışını kısa süre önce kullanıma sunduk. Her biri on beş saniyelik gerçek oynanış kliplerini dikey olarak kaydırıyorsunuz; fragman veya pazarlama görüntüsü yok. Bir şey dikkatinizi çekerse tek dokunuşla tarayıcınızda oynamaya başlıyorsunuz. İndirme yok, kurulum yok, oyunla aranızda duran bir öğretici yok.

Bunun bağımsız geliştiriciler için önemli olmasının nedeni acımasız bir hesap. Steam Next Fest 2026'ya rekor sayıda başvuru yapıldı. Oyuna düşen ilgi payını hesaplayana kadar bu kulağa harika geliyor. Demoların çoğu binin altında gösterim aldı. Yapay zekâ durumu daha da kötüleştirmeden önce bile mağaza sayfası hunisi bozuktu. Oynanışın reklamın kendisi olduğu kaydırmalı bir keşif yüzeyi, keşif döngüsünü tek bir harekete indiriyor. TikTok'un tanınmayan müzisyenleri dinleyicilerin karşısına çıkarması gibi solo geliştiricileri oyuncularla buluşturuyor. “Herkes oyun yayımlayabilir” ile “herkes başarılı olabilir” arasındaki eksik parça bu.

Orijinal röportajın tamamını okumak isterseniz burada. Geri dönüp okumak faydalı oldu. 2022'de yüksek sesle dile getirdiklerimizin çoğu, düşündüğümüzden daha hızlı ilerleyen, uygulanabilir bir yol haritasına dönüştü.

Cinevva CTO'su ve Kurucu Ortağı Oleg Sidorkin tarafından

Burada yeni misiniz? Seri rehberine göz atın. Bu rehber, spike'ın ne olduğunu açıklıyor ve tüm bölümlere bağlantı veriyor.

On iki bölüm boyunca bakabileceğiniz bir arazi motoru geliştirdik. Üzerinde uçabiliyor, dikişlerin çatlamamasını hayranlıkla izleyebiliyordunuz. Bu kez ona dokunmak istedik.

Hedef kulağa basit geliyordu: oyuncunun araziyi bir fırçayla gerçek zamanlı olarak şekillendirmesini sağlamak ve bunu, 24 spike boyunca geliştirdiğimiz hiçbir sistemi bozmadan yapmak. Üç deneme, render hatası gibi görünen ama aslında veri modeli hatası olan iki bug ve arazi verilerinin nasıl çalışması gerektiğine dair köklü bir yeniden değerlendirme gerekti.

Üç başarısız başlangıç

Spike 25'in kolay olması gerekiyordu. Üretim kod tabanında arazi mesh'lerine isabet eden bir raycaster zaten vardı. Yerleştirme aracı, nesneleri bırakmak için bunu kullanıyordu. Fırça aracı da aynı yapıyı izler; yalnızca bir prefab oluşturmak yerine heightmap değerlerini değiştirir. Basit.

Birinci deneme: Aracı doğrudan üretimdeki world/client/ TypeScript kodunun içine geliştirdim. Yeni bir terrain-brush.ts, chunk.ts üzerinde değişiklikler, protokol değişiklikleri, Vue bileşeni güncellemeleri. Bir saat içinde kısmen çalışan bir fırçam vardı ama chunk sınırlarında görünür normal süreksizlikleri oluşuyordu. Hatanın fırça kodumdan mı, mevcut chunk birleştirmesinden mi, yoksa tam render döngüsüyle bir etkileşimden mi kaynaklandığını anlayamıyordum. Spike metodolojisi tam da bu durumu önlemek için var. Kuralı atlamıştım ve bedelini hemen ödedim. Her şeyi geri aldım.

İkinci deneme: Bağımsız bir spike hazırladım ama Three.js 0.170.0 ve WebGL'e yöneldim. Üretim kodu WebGL kullandığı için doğal bir seçim gibi gelmişti. Ancak Spike 13-24'ün tamamı WebGPU'ya geçmişti. WebGL tabanlı bir fırça spike'ı geliştirmek, bunun geçiş yapmayı planladığımız renderer'da değil, eski renderer'da çalıştığını kanıtlayacaktı. Yanlış yön. Baştan başladım.

Üçüncü deneme: WebGPU, WebGPURenderer, vertex üretimi için compute shader ve Spike 22 ile eşleşen teknoloji yığını. Bu kez mimari doğruydu. Beş fırça işlemi çalışıyordu: yükseltme, alçaltma, yumuşatma, düzleştirme ve gürültü. M1'de fırça döngüsü P95 değeri 4 ms'nin altındaydı.

Ama dikiş hatası hâlâ oradaydı.

Spike 25'i yeni sekmede aç ↗ · Kaynak kodu görüntüle

Bir türlü çözülemeyen dikiş hatası

Chunk'lar arası normal hesaplamasında standart çözüm sınır örtüşmesidir: her chunk, komşularından gelen fazladan bir veri halkası saklar; böylece sınırdaki normal hesabı her iki taraftan da örnek alabilir. Bunu uyguladım. Komşu kenar verilerini genişletilmiş bir buffer'a kopyaladım. Dikişler yine de çatlıyordu.

Matematiği incelemeye başladım. Chunk A (cx=-1) ile chunk B (cx=0) arasındaki sınırda iki chunk'ın da ortak vertex için aynı normal'i hesaplaması gerekir. Chunk A'nın shader'ı mix(own_col31, own_col32, 0.85) örneğini alıyordu. Chunk B ise mix(neighbor_edge, own_col0, 0.85) örneğini alıyordu. Bunlar, farklı veriler üzerinde ilerleyen farklı bilineer interpolasyon yollarıydı. Sınır verileri doğru olsa bile iki chunk aynı nokta için farklı normal'ler hesaplıyordu.

İşte o anda asıl hatanın sınır kopyalama olmadığını fark ettim. Asıl hata veri modeliydi.

1'den 24'e kadar her spike, height_at() adlı prosedürel bir matematik fonksiyonu kullanıyordu. Dünya koordinatlarını verin, yüksekliği alın. Temiz, global ve durumsuz. Fırça bir matematik fonksiyonunu değiştiremediği için üstüne bir displacement buffer'ı eklemiştim. Arazi artık height_at(x,z) + displacement[i] olmuştu. GPU shader'ı, temel arazi için 30 satırlık gürültü fonksiyonlarının yanı sıra displacement katmanı için bilineer interpolasyon kodunu da içeriyordu. Düzleştirme fırçası, hedef yüksekliği üretecek displacement değerini bulabilmek için height_at() değerini çıkarmak zorundaydı. Birbiri üzerine bindirilmiş, farklı örnekleme stratejileriyle farklı şeyler hesaplayan iki sistem.

Gerçek bir oyun bunların hiçbirini böyle yapmaz. Üretimde, tasarlanmış arazi buffer'larda saklanan örneklenmiş verilerden oluşur. Prosedürel fonksiyon, ilk spike'lardan kalma kullanışlı bir geçici çözümdü. Amacına hizmet etmişti. Artık etkin biçimde hatalara neden oluyordu.

Onu kaldırdım.

Artık her chunk, gerçek yükseklik değerlerini içeren bir heightmap Float32Array'e sahip. Chunk oluşturulurken bu dizi prosedürel gürültüyle dolduruluyor. Bundan sonra gürültü fonksiyonu bir daha hiç çağrılmıyor. Fırça, saklanan yükseklikleri doğrudan değiştiriyor. GPU shader'ı tek bir fonksiyon kullanarak tek bir buffer'dan okuyor: hm_at(i,j). Normal'ler, aynı veri üzerinde grid hizalı merkezi farklarla hesaplanıyor. Bilineer interpolasyon belirsizliği yok. İki sistem arasında uyumsuzluk yok. Shader 90 satırdan 40 satıra indi.

Dikişler kendiliğinden düzeldi. Ortak bir kenardaki iki chunk da artık kendi buffer'larından aynı ayrık yükseklik değerlerini okuyordu; sınır örtüşmesinde komşunun doğru iç noktaları bulunuyordu. Aynı veri girince aynı normal'ler çıkıyordu.

Bu, fırçayla ilgili bir ders değildi. Fırçanın açığa çıkardığı bir veri mimarisi dersiydi.

Patlayan mesh

Spike 26 bunun hacimsel karşılığıydı. 64 küplük bir SDF hacmini fırçayla değiştirip ardından marching cubes ile yeniden mesh üretmek. Spike 25 ile aynı soru, ancak bu kez 3B.

İlk çalıştırdığımda mesh patladı. Her yöne doğru uzanan uzun sivri uçlar vardı; kötü bir gün geçiren denizkestanesi gibiydi.

Spike 26'yı yeni sekmede aç ↗ · Kaynak kodu görüntüle

Ürettiğim MC durum tablosunda 4096 yerine 3840 girdi vardı. Tam tablo $256\text{durum}\times 16\text{yuva}=4096$ olmalıydı ama benim tablom $256\times 15=3840$ boyutundaydı; 112. durumdan başlayan on altı satır eksikti. Bu indeksten sonraki her arama kaymıştı, dolayısıyla durum numarası artık üçgenleme verileriyle eşleşmiyordu. Marching cubes yanlış girdiyi okuduğunda iki uç noktası da yüzeyin aynı tarafında bulunan kenarlar oluşturur. Gerçek bir kesişim kenarında interpolasyon parametresi

$[0,1]$ aralığında kalır çünkü $v_a$ ve $v_b$ zıt işaretlere sahiptir. Sahte bir kenarda ise aynı işarete sahiptirler; bu yüzden $v_b-v_a$ sıfıra yaklaşır veya işaret değiştirir ve $t$, $[0,1]$ aralığının dışına fırlar. Böylece vertex, hacmin çok uzağına yerleştirilir. Bunu birkaç yüz hatalı hücreyle çarptığınızda ortaya bir kirpi çıkar.

Çözüm son derece basitti: Kanıtlanmış tabloyu Spike 12'den bayt bayt kopyalamak. Dersimi aldım. Kanıtlanmış bir kopya mevcutken lookup table'ı asla yeniden üretmeyin.

İkinci hata daha incelikliydi. Yumuşatma fırçasının arazi özelliklerini yumuşatması gerekiyordu. Bunun yerine keskin kırışıklıklar oluşturuyordu. Sorun şuydu: Her SDF değerini sıfıra, yani izoyüzeye doğru çekiyordum. Bunun yüzeyi yumuşatması gerektiği düşünülebilir ama aslında distance field'ı çökertir. Yüzeyin hem üstündeki hem de altındaki voxel'ler sıfıra doğru hızla ilerleyerek fırça yarıçapındaki her şeyi düzleştirir. Sınırda, yumuşatılmış voxel'ler yumuşatılmamış olanlarla sert bir basamak oluşturarak buluşur. “Yumuşatma” fırçası aslında bir kırışıklık üretecine dönüşmüştü.

Çözüm, doğru Laplasyen yumuşatmaydı. Her değeri sıfıra doğru çekmek yerine, onu 6 doğrudan komşusunun ortalamasına doğru çekmek gerekiyordu:

Parantez içindeki terim ayrık bir Laplasyen, $\lambda \in (0,1]$ ise yumuşatma kuvvetidir. Bu yöntem yakındaki geometriyi ortalamaya tabi tutar; distance field gradyanını çökertmek yerine koruyarak yüzey şeklini yumuşatır.

Her şey aynı anda

Spike 27 entegrasyon kapısıydı. Spike 24'ün tam pipeline'ını (heightmap patch'leri, MC chunk'ları, Transvoxel dikişleri, geomorph LOD) alıp Spike 25'in örneklenmiş veri modeli ve iki fırça türüyle birleştirdik.

Spike 27'yi yeni sekmede aç ↗ · Kaynak kodu görüntüle

İlk yaptığım şey, height_at() fonksiyonunu her shader'dan söküp atmaktı. Üç compute shader'ın tamamı (SDF doldurma, heightmap patch'i ve Transvoxel dikişi) artık aynı 129x129 heightmap GPU buffer'ını bağlıyor ve paylaşılan bir WGSL preamble üzerinden aynı hm_sample() bilineer interpolasyon fonksiyonunu kullanıyor. Tek veri kaynağı, birden fazla tüketici. Spike 1'den beri her shader'ın içinde yaşayan prosedürel gürültü fonksiyonları artık yoktu.

Ardından ilginç sorunlar başladı.

Bir SDF fırçası chunk'ı MC moduna kilitlediğinde, o chunk ile heightmap komşusu arasındaki Transvoxel dikişinin heightmap'ten değil, SDF hacminden örnek alması gerekir. Dikiş shader'ını ek storage buffer binding'leri ve chunk başına MC bayraklarıyla genişlettim. Ele alınması gereken dört sınır kombinasyonu vardı: HM-HM, HM-MC, MC-HM, MC-MC.

LOD başka bir bilmeceydi. Önceki spike'larda bir MC chunk'ını daha düşük bir LOD seviyesine geçirmek, SDF'yi daha kaba bir çözünürlükte yeniden doldurmak anlamına geliyordu. Bunun yerine stride tabanlı örnekleme kullandım: SDF verisi tam çözünürlükte, yani 65 grid noktası olarak kalıyor. MC shader'ı, grid boyutunun hücre sayısına oranından bir stride hesaplıyor. LOD0'da stride 1. LOD1'de stride 2 ve her iki voxel'den biri örnekleniyor. Chunk'lar SDF verilerine dokunmadan serbestçe LOD değiştirebiliyor.

En tatmin edici çözüm, dinamik dikey chunk oluşturmaydı. Bir chunk'ın üst sınırını aşacak şekilde yukarı doğru şekillendirdiğinizde, üstünde yeni ve yalnızca MC kullanan bir chunk beliriyor; SDF'si, alttaki chunk'ın sınır yüzünden başlatılıyor. Aşağı doğru şekillendirdiğinizde de aynısı gerçekleşiyor. Dünya, düzenlemelere uyacak şekilde büyüyor.

Son tuzak, heightmap fırçasının MC'ye kilitli chunk'larda hiçbir şey yapmamasıydı. HM fırçası heightmapCPU verisini değiştirip yeniden yüklüyor. MC chunk'ları artık heightmap'ten okuma yapmıyor; çünkü SDF'leri önce heightmap'ten doldurulmuş, ardından ondan ayrışmış durumda. syncHeightmapToSdf() fonksiyonunu ekledim: Heightmap değiştikten sonra, fırça yarıçapındaki tüm MC chunk'larının SDF sütunları yeniden türetiliyor ve yeni değerler yükleniyor. Artık her iki fırça türü de her iki chunk türünde çalışıyor.

Aslında ne öğrendik?

Fırça spike'larının bir performans sorusuna yanıt vermesi gerekiyordu: Şekillendirme, kare süresi bütçesi içinde çalışabilir mi? Evet, çalışabilir. Kolay kısım buydu.

Zor kısım, arazi gerçeği olarak 24 spike boyunca height_at() kullanmanın görünmez bir bağımlılık yarattığını ve herhangi bir şeyi düzenlemeye çalıştığımız anda bu bağımlılığın sistemi bozduğunu keşfetmekti. Prosedürel fonksiyon temiz, global ve durumsuzdu; ta ki artık arazinin kendisi olmayana kadar.

Yazdığımız ve unutmayacağımız kurallar:

1. Arazi yüksekliği örneklenmiş veriden gelir. Chunk'lar kendi buffer'larına sahip olur.
2. Prosedürel üretim ilk veriyi doldurur. Çalışma zamanındaki gerçek değildir.
3. Fırça, chunk verilerini doğrudan değiştirir. Displacement katmanları kullanılmaz.
4. Normal'ler, aynı veriden grid hizalı merkezi farklarla elde edilir.
5. Sınır örtüşmesi (komşunun iç kısmından 1 hücre) chunk'lar arası normal'leri yönetir.
6. Kanıtlanmış bir kopya mevcutken lookup table'ı asla yeniden üretmeyin.

Bölüm 14'te debug geometrisini şekillendirmeyi bırakıp dünyayı gerçek bir yer gibi göstermeye ve hissettirmeye başlıyoruz.

Bu bölümde değinilen teknolojiler

Örneklenmiş heightmap mimarisi. Arazinin çalışma zamanında prosedürel bir fonksiyonla hesaplanması yerine, her chunk'a ait veriler olarak saklanması. Her chunk, gerçek yükseklik değerlerini içeren bir Float32Array barındırır. Oluşturma sırasında prosedürel gürültü ilk veriyi doldurur ve ardından fonksiyon bir daha hiç çağrılmaz. Bu yaklaşım, matematik tabanlı arazi ile düzenleme katmanları arasındaki çift sistemli uyumsuzluğu ortadan kaldırır, fırça işlemlerini basitleştirir (saklanan değerler doğrudan düzenlenir) ve GPU shader'ını son derece basit hâle getirir (buffer'dan oku, normal'leri grid hizalı merkezi farklarla hesapla). Streaming kullanan açık dünyalarda, komşulardan alınan 1 hücrelik sınır örtüşmesiyle chunk başına veri sahipliği standart yaklaşımdır. Arazi oluşturma rehberimize bakın.

SDF fırça işlemleri. Araziyi şekillendirmek için signed distance field'ın değiştirilmesi. Ekleme (şişirme), bir kürenin çevresinde smooth-step falloff kullanır. Çıkarma (oyma), aynı şeklin ters işaretlisini kullanır. Yumuşatma ise Laplasyen ortalama kullanır: 6 doğrudan komşuyu oku, ortalamalarını hesapla ve değeri bu ortalamaya doğru çek. Değerleri sıfıra çekmeye dayalı naif yaklaşım distance field'ı çökertir ve keskin kenarlar oluşturur. Laplasyen yumuşatma, özellikleri yumuşatırken alan gradyanını korur. SDF arazi gösterimine bakın.

Karışık veri kaynaklarıyla Transvoxel. Bir MC chunk'ı ile heightmap chunk'ı arasındaki sınırda bulunan geçiş hücrelerinin, her iki tarafta farklı verilerden örnek alması gerekir. Dikiş shader'ı, dört kombinasyonun tamamını (HM-HM, HM-MC, MC-HM, MC-MC) yönetmek için chunk başına bayraklar ve buffer binding'leri taşır. Taraflardan biri MC'ye kilitliyse shader, heightmap'ten örnek almak yerine SDF buffer'ını trilineer olarak interpole eder. Marching cubes için adım aralığı tabanlı LOD. SDF verileri, parçanın mevcut LOD seviyesinden bağımsız olarak tam çözünürlükte saklanır. MC shader’ı, SDF ızgara noktalarının MC hücrelerine oranından bir örnekleme adım aralığı hesaplar. Tam çözünürlükte adım aralığı 1, yarı çözünürlükte ise 2’dir. Bu yaklaşım SDF verilerini LOD değişikliklerinden bağımsız hâle getirir; böylece parçalar SDF yeniden oluşturulmadan LOD seviyeleri arasında serbestçe geçiş yapabilir.

14 bölümün 13. bölümü. Önceki: Bölüm 12 - Halkalar, gökyüzü sisi ve yeniden yapacaklarımız Sonraki: Bölüm 14 - Dünya canlanıyor Seri rehberi: /blog/2026-02-25-open-world-browser-series-guide

Oleg Sidorkin, Cinevva CTO'su ve Kurucu Ortağı

Burada yeni misiniz? Seri rehberine göz atın. Rehber, spike'ın ne olduğunu açıklıyor ve tüm bölümlere bağlantı veriyor.

13. bölümden sonra arazi şekillendirme özelliğimiz vardı. Araziyi yükseltebiliyor, mağaralar oyabiliyor, uçurumları yumuşatabiliyorduk; üstelik bunların hepsi gerçek zamanlı gerçekleşiyor ve dikişler bozulmadan kalıyordu. Ancak dünya bir teknoloji demosu gibi görünüyordu. Hata ayıklama renkleriyle düz gölgelendirme, tel kafes katmanları, parçaları birbirinden ayırmak için LOD renkleri taşıyan gri geometri. Dünyayı düzenleyebiliyordunuz. Ama onu hissedemiyordunuz.

Bunu üç spike değiştirdi. Mimaride hiçbir değişiklik olmadı. 13. bölümdeki işlem hattı, tamponlar ve dikiş birleştirme sistemi aynen kaldı. Yalnızca araziyi gerçek bir mekân gibi hissettiren katmanları ekledik: şekle tepki veren yüzeyler, bu yüzeylerde büyüyen yaşam ve üzerlerinde yürüyen bir beden.

“Teknik olarak çalışıyor” ile “burada kalmak istiyorum” arasındaki farkın şaşırtıcı derecede küçük olduğu ortaya çıktı.

Bir uçurum şekillendirin ve kayaya dönüşmesini izleyin

Spike 28 dar kapsamlı bir soru sordu: triplanar eşlemeye sahip 4 katmanlı bir malzeme, kare süresi bütçesini tüketmeden hesaplama yoluyla üretilmiş arazide çalışabilir mi? Yanıt evetti, ancak asıl ilginç olan bundan sonra yaşananlardı.

Spike 28'i yeni bir sekmede aç ↗ · Kaynak kodunu görüntüle

Dört prosedürel doku (çim, kaya, kum ve kar), başlangıçta FBM gürültüsünden üretiliyor. Harici dosya yok, varlık işlem hattı yok; yalnızca matematik ve bir DataTexture var. Malzeme ağırlıkları yüzeyin kendisinden geliyor: eğim ve rakım. Ağaç sınırının altındaki düz alanlar çimle kaplanıyor. Dik yüzeyler kayaya dönüşüyor. Alçak zeminlere kum, yüksek zirvelere kar geliyor. Her ham ağırlık, eğim ve rakım üzerinde bir smoothstep işleminden elde ediliyor; ardından parça başına normalize edilerek $\sum _i{w}_i=1$ olması sağlanıyor ve nihai renk yalnızca ağırlıklı karışım $\sum _i{w}_i{c}_i$ oluyor. Normalizasyon, biyomların örtüştüğü yerlerde yüzeyin kararmasını veya aşırı parlaklaşmasını engelliyor. Triplanar eşleme ise üçgenlerin anlamlı UV koordinatlarına sahip olmadığı MC parçalarındaki UV izdüşümünü hallediyor.

Bizi ikna eden an şuydu: fırçayla araziyi yükseltip dik bir uçurum oluşturduğunuzda, yeni yüzeyde aynı kare içinde kaya dokusu beliriyor. Tekrar düzleştirdiğinizde yüzeyi yeniden çim kaplıyor. Malzemenin fırçadan haberi yok. Yalnızca dünya konumunu ve yüzey normalini, yani geometrinin oluşturulduğu verilerin aynısını okuyor. Şekillendirme ile görsel geri bildirim arasındaki döngü anlık ve önceden betiklenmemiş.

Spike 8, bir buçuk ay önce WebGL üzerinde statik bir mesh kullanarak arazi malzemesinin maliyetini test etmişti. Spike 28 ise bunun, altında tam şekillendirme işlem hattı çalışan dinamik ve hesaplama yoluyla üretilmiş arazide de işe yaradığını kanıtlıyor. Bunun için bütçe ayırmıştık ama her şey çalışırken 60 fps'yi koruduğunu görmek yine de rahatlatıcıydı.

80.000 çim kümesi ve bir mağara tavanı

Spike 29'da oyun geliştirme içgüdülerimiz devreye girdi.

Spike 29'u yeni bir sekmede aç ↗ · Kaynak kodunu görüntüle

Breath of the Wild'daki gibi çimler istiyorduk. Poligon sayısını değil, hissini. Doğru yerleri kaplayan, rüzgârda hareket eden ve içinden koşma isteği uyandıran çimler.

Her çim kümesi, 60 derecelik açılarla kesişen üç dörtgenden ve bükülme için dört dikey segmentten oluşuyor. Billboard hileleri kullanmadan her açıdan hacimli görünen bir haç şekli. Parça başına bir InstancedMesh, dünya genelinde 80.000 çim kümesi ve toplamda yaklaşık 2,4 milyon çim köşesi.

Asıl önemli kısım yerleştirme. CPU, her parça boyunca titreşimli bir ızgarada ilerliyor ve GPU malzeme shader'ının kullandığı eğim/rakım mantığının aynısını değerlendiriyor. Malzeme sisteminin “çim” dediği yerde çim büyüyor. Kaya veya kumun baskın olduğu yerlerde yoğunluk sıfıra düşüyor. Geçiş yumuşak, çünkü temeldeki smoothstep ağırlıkları biyom kenarlarında sürekli gradyanlar oluşturuyor. Bir sınır fark etmiyorsunuz, çünkü ortada bir sınır yok.

Ardından işe yarayıp yaramayacağından emin olmadığım bir şey yaptık: SDF yüzeylerinde çim. Dağıtma fonksiyonu, SDF hacminin her sütununda ilerliyor ve komşu vokseller arasındaki sıfır geçişlerini buluyor. SDF'nin negatiften pozitife geçtiği yerde bir yüzey vardır. Yüzey normali, alanın normalize edilmiş gradyanıdır: $\hat{n}=\frac{\mathrm{\nabla }\varphi }{\Vert \mathrm{\nabla }\varphi \Vert }$. Bu değer voksel farklarından hesaplanır; eğim ise dikeyden ölçülen açı olan $\arccos (\hat{n}\cdot \hat{y})$ değeridir. Yeterince yatıksa oraya çim yerleştirilir.

Spike 27'de SDF fırçasıyla bir mağara oyun. Spike 29'a geri döndüğünüzde mağara tavanının üzerinde çimler büyüdüğünü görürsünüz. Dağıtma kodu mağaranın ne olduğunu bilmiyor. Yalnızca doğru rakımda, uygun eğime sahip bir yüzey görüyor. Açık dünya sistemleri geliştirmeyi tatmin edici kılan türden bir beliren davranış bu.

Rüzgâr, TSL vertex shader'ındaki bir sinüs dalgası. Bu dalga, çimin V koordinatıyla modüle edildiği için uçlar sallanırken kökler sabit kalıyor. Hafif, güçlü ve kapalı seçenekleri arasında geçiş yapmak için V tuşuna basın. Rüzgâr tamamen vertex shader'ında çalıştığından, 80 bin kümenin tamamını sıfır CPU maliyetiyle aynı anda etkiliyor.

Spike 7'de 50 bin çim örneğini test etmiş ve sınıra ulaşmaktan endişelenmiştik. Spike 29; hesaplamalı arazi, dikiş birleştirme, çok malzemeli dokulama ve fırçaların üzerine 80 bin örnek çalıştırıyor. Daha az sayıda InstancedMesh çiziminde gruplamak, çim başına köşe sayısını azaltmaktan hâlâ daha önemli. Spike 7'den çıkardığımız ders geçerliliğini korudu.

Ertelediğimiz bir şey var: altındaki araziyi şekillendirdiğinizde çimler güncellenmiyor. Örnek matrisleri dağıtma anında ayarlanıyor. Bir tepeyi vadiye dönüştürürseniz, yeniden dağıtmak için G tuşuna basana kadar çimler havada asılı kalıyor. Bir spike için yeterince iyi. Üretim sürümünde kirli parçaların yeniden dağıtılması gerekecek.

İlk ayak sesi

Spike 30, dönüp dönüp baktığım çalışma oldu.

Spike 30'u yeni bir sekmede aç ↗ · Kaynak kodunu görüntüle

Fizik kütüphanesi yok. 120 Hz sabit zaman adımında çalışan özel bir kapsül var. Üretim kod tabanı, bir web worker içinde Rapier kullanıyor (Spike 2 gecikmenin sorun olmadığını kanıtladı), ancak bu spike'ın çarpışma sorgularını doğrulaması gerekiyordu. Bir karakter yükseklik haritası arazisinde yürüyebilir, şekillendirilmiş SDF arazisine adım atabilir ve içinden düşmeden kalabilir mi?

Sistemin merkezinde terrainQuery(x, y, z) adlı bir fonksiyon bulunuyor. Bu fonksiyon, konumun MC'ye kilitlenmiş bir parçanın içinde olup olmadığını kontrol ediyor. İçindeyse CPU'daki SDF kopyasında trilineer enterpolasyon yapıyor ve yüzey normali olarak gradyanı döndürüyor. Değilse merkezi fark normaliyle yükseklik haritası sorgusu yapıyor. Karakter hangi arazi sisteminin üzerinde durduğunu bilmiyor. Yalnızca zemini soruyor ve bir yanıt alıyor.

SDF çarpışmasının zor olmasını bekliyordum. Kapsülün çevresinde yedi sonda noktası var: alt, orta, üst ve dört ana yöndeki ofset. $\mathbf{x}$ konumundaki bir sonda, $\varphi (\mathbf{x})<r$ olduğunda yüzeye nüfuz ediyor. Nüfuz derinliği $p=r-\varphi (\mathbf{x})$, dışarı itme yönü ise alan gradyanı $\hat{n}=\frac{\mathrm{\nabla }\varphi }{\Vert \mathrm{\nabla }\varphi \Vert }$. Kapsülün yüzeye yeniden girmesini önlemek için hız, içeri doğru bileşenini sıfırlayacak biçimde izdüşürülüyor:

Böylece yalnızca yüzey boyunca kayan bileşen kalıyor. Bu bir fizik motoru değil. Geometri sorguları ve basit tepkilerden ibaret. Ancak mağaraları, çıkıntıları ve şekillendirilmiş tünelleri, şekil başına tek bir özel durum kodu olmadan işliyor. On saniye önce oyduğunuz bir mağaraya girdiğinizde kapsül tavanın hatlarını tam olarak takip ediyor.

Hareket modeli pratik bir yaklaşımla başladı, sonra eğlenceli hâle geldi. Yürüme, koşma, depar, zıplama ve 45 derecenin üzerindeki eğimlerde kayma. Ardından BotW tarzı bir planör ekledim ve spike kapatmak istemediğim bir şeye dönüştü.

Havadayken Space tuşuna basın. Yerçekimi -30'dan -4'e düşer. Düşüş hızı -3 ile sınırlandırılır. Kapsülden, ölçek enterpolasyonuyla bir delta kanat mesh'i açılır. Sola yatış yaptığınızda kanat eğilir. Kapsülün baktığı yön, hız vektörüne otomatik olarak hizalanır; böylece her zaman gittiğiniz yöne bakarsınız. Düşmek için Space tuşunu bırakın. Yere indiğinizde yeniden koşmaya başlarsınız.

Kamera geri çekilerek üçüncü şahıs görünümüne geçiyor (P ile değiştirin). Yaw yumuşatmasıyla oyuncuyu arkadan takip ediyor. Oyuncudan kameraya doğru yapılan bir ışın yürüyüşü, araziyi 20 adımda test ediyor. Bir mağaraya uçtuğunuzda kamera kolu kayaların içinden geçmek yerine yumuşakça kısalıyor. Diğer taraftan çıktığınızda yeniden uzuyor.

Spike'ı yapmaya değer kılan an şuydu: yükseklik haritası fırçasıyla yüksek bir uçurum şekillendirin. Üçüncü şahıs kamerasına geçin. Kenara doğru koşun. Zıplayın. Planörü açın. Aşağınızda Spike 29'da yetiştirdiğiniz çimler dalgalanırken, uçurum yüzeyinde Spike 28'in kaya dokusu görünürken ve Transvoxel dikişleri her parça sınırında sağlam kalırken az önce şekillendirdiğiniz arazinin üzerinde sola yatış yapın. Karşı tarafa inin. Her şey tek bir tarayıcı sekmesinde birlikte çalışıyor.

Kendi ayaklarınızın altını şekillendirmek

Emin olmadığım bir şey vardı: karakterin üzerinde durduğu araziyi şekillendirdiğinizde ne olur? Yükseklik haritasındaki değişiklikler, CPU tamponunu doğrudan okuduğu için terrainQuery() fonksiyonuna anında yansıyor. SDF değişiklikleri de CPU'daki SDF kopyasına aktarılıyor. Kapsül, nüfuzu bir sonraki fizik tikinde çözüyor; 120 Hz'de bu, $\frac{1}{120}\approx 8.3$ ms içinde gerçekleşiyor.

Öylece çalışıyor. Oyuncunun altındaki zemini yükselttiğinizde oyuncu da onunla birlikte yükseliyor. Zemini oyduğunuzda düşüyor. Özel bir işleme gerek yok. Fizik sistemi yeterince hızlı çalıştığı için tek karelik arazi değişiklikleri hiçbir zaman büyük nüfuzlara yol açmıyor. Bu, zaman adımı için 120 Hz seçmemizin mutlu bir tesadüfüydü. Bu değeri akıcı hareket için seçmiştik; arazi düzenlemeyi de hiçbir ek maliyet olmadan güvenli hâle getirdi.

30 spike sonra

Bu seriye düz bir yükseklik haritası ve 500 küple başladık. Şimdi hacimsel mağaralara, Transvoxel dikiş birleştirmesine, yüzey şekline tepki veren çok malzemeli dokulamaya, rüzgârda salınan 80.000 çim kümesine ve tüm bunların üzerinde yürüyen, depar atan, zıplayan ve süzülen bir karaktere sahip şekillendirilmiş bir arazimiz var.

Bunların hiçbiri henüz üretim sürümünde değil. world/client/ kod tabanı hâlâ basit yükseklik haritası parçalarıyla WebGL üzerinde çalışıyor. Bu 30 spike'taki her şey bağımsız HTML sayfalarında yaşıyor. Sırada entegrasyon işi var: WebGPURenderer sistemine geçmek, hibrit HM/MC politikasını parça yöneticisine bağlamak ve fırça ile malzeme sistemlerini çok oyunculu yapıya entegre etmek.

Ancak render sistemi artık riskli kısım değil. Açık sorular veri akışıyla ilgili: düzenlemelerin kalıcı hâle getirilmesi, fırça darbelerinin ağ üzerinden senkronizasyonu ve iş birliğine dayalı şekillendirme. Yani üçgenler arasında değil, oyuncular arasında gerçekleşen şeyler.

Bu seriyi 1. bölümden beri takip ediyorsanız, dağınık kısımlarda da bizimle kaldığınız için teşekkürler. Seriyi yeni keşfettiyseniz 1. bölüme dönün. Dersler yanlış dönüşlerde saklıdır.

Bu bölümde değinilen teknolojiler

TSL (Three Shading Language). Three.js'in WebGPU renderer için geliştirilmiş, düğüm tabanlı shader sistemi. Malzemeler, JavaScript'te fonksiyon bileşimi kullanılarak düğümlerden (positionWorld, normalWorld, smoothstep, triplanarTexture) oluşturulur. Shader grafiği çalışma zamanında WGSL'ye derlenir. TSL, WebGPU hedeflerinde ham GLSL ShaderMaterial kullanımının yerini alır ve standart Three.js malzeme özellikleriyle (ışıklar, gölgeler, sis) özel parça başına mantık arasında birlikte çalışabilirlik sağlar.

Triplanar eşleme. Bir dokuyu üç kez (XY, XZ ve YZ düzlemlerinde) örnekleyen ve örnekleri yüzey normalinin yönüne göre harmanlayan bir doku izdüşüm tekniği. Bu teknik, rastgele mesh geometrilerindeki UV gerilmesini ortadan kaldırır. Üçgenlerin anlamlı UV koordinatlarına sahip olmadığı marching cubes çıktıları için bu kritik öneme sahiptir. TSL, yerleşik bir düğüm olarak triplanarTexture() sağlar.

Çapraz dörtgen çimlerle örneklenmiş bitki örtüsü. Her çim kümesi, 60 derecelik açılarla kesişen 3 dörtgenden oluşur ve her bakış yönünden hacimli görünür. Dörtgen başına 4 dikey segment, rüzgâr animasyonu için yumuşak bükülmeye olanak tanır. Tüm alan, parça başına tek bir InstancedMesh olarak render edilir. Kapasite %25 fazla ayrılır; böylece arazi düzenlendiğinde yeni örnekler GPU tamponunu yeniden ayırmadan rezerve edilmiş yuvalara yerleştirilebilir. Bitki örtüsüyle ilgili peyzaj oluşturma rehberimize bakın. Kapsül ve SDF çarpışması. Fizik motoru olmadan hacimsel araziyle karakter çarpışması. Kapsül, birden fazla noktada SDF'e karşı test edilir. Alan değerinin kapsül yarıçapından küçük olduğu yerlerde gradyan dışa dönük normali, aradaki fark ise iç içe geçme derinliğini verir. Bu yaklaşım mağaraları, çıkıntıları ve tünelleri şekle özgü kod gerektirmeden işler. Bkz. SDF arazi çarpışmaları.

Sabit zaman adımlı karakter kontrolcüsü. Fizik, kare hızından bağımsız olarak 120 Hz'de ilerler; gerçek zamanı biriktirir ve sabit boyutlu adımlarla işler. Maksimum alt adım sayısı, yavaş karelerde ölüm sarmalını önler. Zemine yapışma, eğimlerde ilerlerken kapsülün yüzeyle temasını korur. Sabit zaman adımı, gelecekteki çok oyunculu tekrar oynatımı için deterministik davranış sağlar.

29 bölümün 14. bölümü. Önceki: 13. Bölüm - Arazi şekillendirme ve matematik fonksiyonunun sonu Sonraki: 15. Bölüm - Temel sürümü değiştir, ardından eşitle Seri rehberi: /tr/blog/2026-02-25-open-world-browser-series-guide

Yazan: Oleg Sidorkin, Cinevva CTO'su ve Kurucu Ortağı

Burada yeni misiniz? Seri rehberine göz atın. Rehber, denemenin ne olduğunu açıklıyor ve tüm bölümlere bağlantı veriyor.

İlk on dört bölüm, 1'den 30'a kadar olan denemeleri ele aldı. Bu süreç, gerçek zamanlı şekillendirilebilen bir arazi sistemi ile üzerinde yürüyebilen, süzülebilen ve düşebilen bir karakterle sona erdi. Bu bölüm, seriye 31. denemeden devam ediyor ve vermemiz gereken ilk karar teknik değildi. Tüm bu deneme koduyla ne yapacağımıza karar vermemiz gerekiyordu.

"Geri taşımak yerine değiştir" kararı

Her biri ayrı bir kavramı doğrulayan 30 bağımsız HTML dosyamız vardı ama bunlar arasında hiçbir entegrasyon yoktu. Üretimdeki world/client/ hâlâ eski teknoloji yığınını kullanıyordu: WebGL, basit bir yükseklik haritası, 75 satırlık bir karakter denetleyicisi ve dokuz mesaj türüne sahip bir MessagePack protokolü. Düzenleme, WebGPU, materyal veya bitki örtüsü yoktu.

Bariz plan, deneme sonuçlarını üretim kod tabanına tek tek geri taşımaktı. Bu planı çöpe attık. 30. deneme; arazi, fizik, materyaller, bitki örtüsü ve kamera açısından world/client/ sisteminin ulaştığı her şeyden zaten daha iyiydi. Bunları eski WebGL koduna geri taşımak, bütün süreç boyunca o kodla mücadele etmek anlamına gelecekti. Bu nedenle dünya uygulamasını en başarılı denemeyle değiştirmeye ve buradan ilerlemeye karar verdik. 30. deneme yeni temel oldu ve world/client/ artık kullanılmayan koda dönüştü.

Bu karar, kalan çalışmayı yeniden çerçeveledi. "Harika bir tek oyunculu teknoloji demosundan" "ürüne" geçmek için çok oyunculu desteğe, kalıcılığa, sonsuz dünya akışına ve nesne yerleştirmeye ihtiyacımız vardı. İlk sıraya çok oyunculu arazi senkronizasyonunu koyduk çünkü mimariyi şekillendiren konu buydu. Yanıtladığı soruyu sormak kolay, yanlış yanıtlamanın bedeliyse yüksekti: Oyuncu A araziyi şekillendirdiğinde ağ üzerinden gerçekte ne gönderilecek?

Piksel senkronizasyonu değil, fırça parametrelerini yeniden oynatma

31. denemeyi yeni sekmede açın ↗ · Kaynak kodunu görüntüleyin

Tek bir satır ağ kodu yazmadan önce, bir fırça darbesinin tam olarak ne yaptığını izledik. Yükseklik haritası fırçası, CPU üzerindeki bir Float32Array içinde imlecin çevresindeki yarıçapı dolaşıyor, yumuşak geçişli bir düşüş uyguluyor ve ardından yükseltiyor, alçaltıyor, yumuşatıyor ya da düzleştiriyor. SDF fırçası da aynı işlemi 3B ortamda küresel bir voksel alanı üzerinde yapıyor. Her iki yol da saf CPU dizi matematiğinden oluşuyor. Döngüde GPU hesaplaması, rastlantısallık veya deterministik olmayan kayan nokta işlemi yok. Aynı girdi dizisi ve aynı parametreler, her makinede aynı çıktıyı üretiyor.

İşin püf noktası bu. Düzenlenmiş araziyi göndermiyoruz. Her fırça darbesi adımında 56 baytlık fırça parametrelerini gönderiyoruz ve her istemci aynı deterministik fonksiyonu yeniden çalıştırıyor. Senkronizasyon protokolünde dört mesaj türü var: eş keşfi, {op, wx, wy, wz, radius, strength, flattenTarget} biçimindeki fırça mesajı ve 20Hz frekansındaki oyuncu konumu mesajı.

Denemede sunucuyu tamamen atlayıp tarayıcının aynı kaynaktan açılan sekmeler arasında mesajlaşmayı sağlayan BroadcastChannel API'sini kullandık. İki sekme açtığınızda sıfır altyapıyla birbirleriyle iletişim kuruyorlar. Böylece senkronizasyon sorununu gecikme, kimlik doğrulama ve Durable Object bağlantılarından ayırdık. Parametreleri yeniden oynatma sekmeler arasında yakınsıyorsa WebSocket üzerinden de yakınsar.

Yeniden oynatmanın ayrışabileceği tek yer, sıraya bağlı işlemlerdir. Yükseltme ve alçaltma değişmeli işlemlerdir; dolayısıyla val + strength * falloff, önce kimin uyguladığından bağımsız olarak aynı sonuca ulaşır. Yumuşatma ve düzleştirme komşu değerleri okur. Bu yüzden iki istemci aynı anda tam olarak aynı noktayı yumuşatırsa her adımda milimetrenin küçük kesirleri kadar sapma oluşabilir. Pratikte bu durum hiç yaşanmıyor ve üretimdeki çözüm de şimdiden belli: Düzenlemeleri DO üzerinden yönlendirmek, monotonik bir sıra numarası atamasını sağlamak, istemcide iyimser biçimde uygulamak ve yetkili sıra farklıysa sıralamayı düzeltmek. Bu, klasik iyimser eşzamanlılıktır ve DO zaten doğal bir serileştirme noktasıdır.

Sürekli kaybolan eş kapsülü

Düzenlemeler ilk denemede senkronize oldu. Uzak oyuncunun kapsülü ise olmadı. Diğer sekmede görünüp kayboluyordu ve kalıcı hâle gelmesi için üç ayrı hatayı düzeltmemiz gerekti.

Kapsül dünya orijininde oluşturuluyordu; burası arazinin altında kalıyordu çünkü join mesajı herhangi bir konum verisinden önce ulaşıyordu. Çözüm: Başlangıçta gizlemek ve ilk konum güncellemesinde göstermek. Konum yayını render döngüsünün içindeydi ve Chrome, odakta olmayan sekmelerde requestAnimationFrame çağrılarını yavaşlatıyordu. Bu nedenle diğer sekmenin güncellik kontrolü eşi kaldırıyor, sonraki mesaj da onu yeniden oluşturuyordu. Çözüm: Yayını, görünür sekmelerde yavaşlatılmayan bir setInterval içine taşımak. Ayrıca güncellik zaman aşımı fazla agresif bir değer olan 5 saniyeydi ve herhangi bir GC duraklamasında tetikleniyordu. Çözüm: Süreyi 30 saniyeye çıkarmak ve normal kapanışlarda temiz leave mesajına güvenmek.

Kalıcılık ve sonradan katılım, aynı format

Kalıcılığı yeni bir denemeye ayırmak yerine aynı denemeye dâhil ettik çünkü hedef ister IndexedDB ister başka bir sekme olsun, serileştirme formatı aynıydı. Bir anlık görüntü; tam yükseklik haritasından (129×129 boyutunda bir Float32Array, yaklaşık 66 KB), yalnızca düzenlenmiş SDF parçalarından (her biri ${65}^3$, yaklaşık 1,1 MB) ve marching-cubes moduna kilitlenmiş parça kimliklerinin listesinden oluşuyor. Gecikmeli kaydetme işlemi, son düzenlemeden iki saniye sonra IndexedDB'ye yazıyor. Yükleme sırasında prosedürel arazi eşzamanlı olarak oluşturuluyor, ardından kaydedilmiş durum ilk anlamlı kareden önce onun üzerine yazılıyor. Sonradan katılım da tamamen aynı baytları yeniden kullanıyor: Yeni bir sekme katıldığında, düzenlemelere sahip mevcut bir sekme durumunu serileştirip yeni gelene özel olarak gönderiyor ve beş dakika önce şekillendirdiğiniz dağ onun ekranında beliriyor.

İlk kalıcılık testi güzel bir sıralama hatasını ortaya çıkardı. Çimler başlangıçta prosedürel yükseklikler kullanılarak eşzamanlı biçimde dağıtılıyor ancak IndexedDB'den geri yükleme eşzamansız gerçekleşip daha sonra yükseklik haritasının üzerine yazıyor. Sonuç olarak her çim yaprağı havada kalıyor ya da zemine gömülüyordu. Çözüm, her örneğin altındaki yüksekliği yeniden örnekleyen ve artık uygun olmayan bir eğimde ya da rakımda bulunan yaprakları gizleyen bir refreshAllGrass() geçişidir. Aynı fonksiyon hem yüklemeye hem de sonradan katılıma hizmet ediyor.

Eğim macerası

Şekillendirilmiş arazi, pürüzsüz prosedürel temelden daha engebeliydi ve eski arazinin asla ortaya çıkaramadığı üç fizik hatasını açığa çıkardı. Doğrudan yokuş yukarı yürümek kapsülün yana kaymasına neden oluyordu. Bunun nedeni, hareketi zemine teğet tutmayı amaçlayan ancak normalin yalnızca yatay bileşenleri kullanılarak yazılmış bir hız izdüşümüydü. Normali $(-0.3,0.9,-0.3)$ olan çapraz bir eğimde kuzeye yürümek, yoktan yere yanal hız oluşturuyordu. Zemine oturtma zaten oyuncuyu yüzeyde tuttuğu için izdüşüm işlemini tamamen sildik.

Kayma, ikinci bir kaynaktan dolayı devam etti. SDF çarpışma sondaları, gövdeyi nüfuz derinliği kadar gradyan boyunca dışarı iter. Herhangi bir eğimde gradyanın yatay bileşenleri vardır. Dolayısıyla 15°'lik bir eğimde 0,1 m'lik nüfuz, her adımda yaklaşık 0,026 m'lik yanal itiş oluşturur; 120Hz'de bu, yaklaşık 3 m/s'lik görünmez bir kaymaya karşılık gelir. Çözüm: Tepkiyi eğime göre bölmek. Yürünebilir zeminde (${\text{grad}}_y$ değeri yürüme eşiğinin üzerindeyken) itiş yalnızca dikeydir. Duvarlarda ve uçurumlarda tam 3B itiş korunur çünkü yönünüzün saptırılmasını istediğiniz yerler tam olarak buralardır. Ayrıca fırçayla oluşturulan tepelerin Breath of the Wild'daki gibi tırmanılabilir hissettirmesi için yürünebilir sınırı $\cos 45°$ değerinden $\cos 60°$ değerine çıkardık.

Üçüncü hata, kapsülün parça sınırlarında donmasına neden oluyordu çünkü çarpışma sondaları tek bir parçanın SDF'sini örnekliyor ve bir sonda komşu parçaya geçtiğinde "havanın derinlerinde" gözcü değerini alıyordu. Çözüm, herhangi bir dünya konumu için doğru parçayı bulan ve SDF'nin bulunmadığı yerlerde yükseklik haritası mesafe tahminine geri dönen sdfSampleWorld(wx, wy, wz) ile sdfGradientWorld(...) fonksiyonlarıydı. SDF'den yükseklik haritası çarpışmasına geçiş artık kesintisiz.

Su dünyayı tamamlıyor

32. denemeyi yeni sekmede açın ↗ · Kaynak kodunu görüntüleyin

Buraya kadarki her deneme "suyun üzerindeki kara" üzerineydi. 32. deneme bir okyanus ve onunla birlikte yeni bir hareket biçimi ekledi. Yaklaşık 8 ile 58 arasında değişen arazide su seviyesini 22 olarak belirledik. Böylece alçak vadiler suyla doldu, kıyı çizgisinde plajlar oluştu ve oyun için bol miktarda kuru alan kaldı.

Yüzey, araziyle aynı düğüm yaklaşımını kullanan ve TSL ile oluşturulmuş bir MeshStandardNodeMaterial materyalidir. Farklı frekanslardaki üç örtüşen sinüs dalgası köşeleri yerinden oynatıyor ve yüzey normali, örgü normallerinden değil bu dalgaların analitik kosinüs türevlerinden elde ediliyor. Renk, $[0,1]$ aralığına sıkıştırılmış $(\text{level}-y+\text{wave})\times 0.12$ derinlik tahminini kullanarak turkuaz sığlıklardan koyu deniz mavisi derinliklere geçiyor. Bu tahmin kıyı çizgisinde sıfıra yaklaşırken köpük yükseliyor ve alfa derinliği takip ediyor; böylece sığ su şeffaf, derin su ise neredeyse opak görünüyor.

Yüzme, kaldırma kuvveti sağlayan bir yaydır. Ayaklar su seviyesinin altına düştüğünde ve gövdenin merkezi yüzeye kapsül yarı yüksekliği kadar yakın olduğunda oyuncu yüzme moduna giriyor. Bir yay, gövdeyi yüzeyin hemen altındaki hedefe doğru çekiyor. Su sönümlemesi 4'e karşı kaldırma sabiti 12 olduğunda oyuncu, salınım yapmadan ve başı suyun dışında kalacak biçimde dengeli şekilde yüzüyor. Yüzme hızı yürümekten daha düşük; ivmelenme ve sürüklenme daha akışkan. Yüzeye yakınken zıplamak oyuncuyu normal zıplama hızının %60'ıyla sudan dışarı fırlatıyor, suya girişteyse aşağı yönlü hız -5 m/s ile sınırlandırılarak oyuncunun dibe çakılması önleniyor. Arazi çarpışması su altında da çalışmaya devam ediyor; bu nedenle göl yatağının yüzme hedefinin üzerine çıktığı yerlerde yürüyebilirsiniz. Yüzme bayrağı konum yayınına da ekleniyor, böylece diğer oyuncular yüzdüğünüzü görebiliyor. Kamera yüzeyin altına indiğinde bir HTML gradyan katmanı görüntüyü renklendiriyor.

Bu bölümde kullanılan teknolojiler

Deterministik fırça parametresi yeniden oynatması. Her istemci, düzenlenmiş araziyi aktarmak yerine yalnızca fırça parametrelerini gönderiyor ve aynı CPU fonksiyonunu yeniden çalıştırıyor. Bu mümkün çünkü hem yükseklik haritası hem de SDF fırçaları, rastlantısallık ya da GPU kaynaklı deterministik olmayan davranış içermeyen saf Float32Array matematiğine dayanıyor. Böylece aynı girdiler her yerde bit düzeyinde aynı çıktıları üretiyor. Yük, her fırça darbesi adımında 56 bayt. Değişmeli işlemler (yükseltme, alçaltma) sıradan bağımsız olarak yakınsarken komşuları okuyan işlemlerin (yumuşatma, düzleştirme) yakınsamayı garanti etmek için bir serileştirme noktasına ihtiyacı vardır. Üretimdeki Durable Object bunu monotonik sıra numaralarıyla sağlar.

WebSocket yerine BroadcastChannel. Sıfır sunucuyla, aynı kaynaktan açılmış sekmeler arasında mesajlaşmayı sağlayan bir tarayıcı API'si. Burada senkronizasyon protokolünü ağ gecikmesi ve kimlik doğrulamadan bağımsız olarak test etmek için kullanıldı. Serileştirme formatı (ham Float32Array yükseklik haritası, düzenlenmiş SDF parçaları ve MC kilitli parça kimlikleri), IndexedDB kalıcılığı ve sonradan katılım durum aktarımında kullanılan baytlarla aynıdır. Böylece tek format üç işi birden kapsar.

Eğime göre bölünmüş SDF çarpışma tepkisi. Bir kapsül sondası hacimsel araziye nüfuz ettiğinde en basit çözüm, gövdeyi nüfuz derinliği kadar SDF gradyanı boyunca dışarı itmektir. Eğimlerde bu gradyanın yatay bileşenleri bulunur ve bu da yanal kayma oluşturur. Tepkiyi, yürünebilir yüzeylerin (${\text{grad}}_y$ eşik değerinin üzerindeyken) yalnızca dikey bir itiş alacağı, dik yüzeylerinse tam 3B itişi ve hız izdüşümünü koruyacağı şekilde bölmek; duvar çarpışmasını kaybetmeden kaymayı ortadan kaldırır. Bkz. SDF arazi çarpışmaları.

Analitik dalga normallerine sahip TSL suyu. Okyanus, köşeleri üst üste eklenen üç sinüs dalgasıyla yerinden oynatılan bir düğüm materyalidir. Yüzey normali, yer değiştirmeden sonra örgü normallerini yeniden hesaplamak yerine dalga fonksiyonlarının kosinüs türevlerinden analitik olarak elde edilir. Bu yöntem daha ucuzdur ve kaba bir ızgarada sonlu fark normallerinin oluşturduğu bozulmaları önler. Derinliğe bağlı renk, kıyı köpüğü ve derinliğe bağlı şeffaflık aynı derinlik tahminini temel alır.

Kaldırma yaylı yüzme. Yüzme fiziği, gövdeyi yüzeyin hemen altındaki bir hedefe çeken sönümlü bir yay olarak modeller. Kaldırma sabiti 12 ve sönümleme 4 olduğunda oyuncu salınım yapmadan yüzeyde dengelenir. Farklı hareket sabitleri (daha düşük hız, akışkan ivmelenme ve güçlü sürüklenme) yüzmeye yürümekten farklı bir his kazandırır; mevcut kapsül-arazi çarpışması da su altında çalışmayı sürdürür.

29 bölümün 15.'si. Önceki: Bölüm 14 - Dünya canlanıyor Sonraki: Bölüm 16 - Büyümeye devam eden bir dünya için yapı Seri rehberi: /tr/blog/2026-02-25-open-world-browser-series-guide

Eskizden videoya ve 3D'ye uzanan üretim süreciyle Kedi Kali'yi (Cubcoats) temel alır. Lisanslama, blog veya iş ortağı sunumları için.

PDF olarak paylaşmak için: Bu sayfayı açın, ardından tarayıcınızda Dosya → Yazdır → PDF olarak kaydet seçeneğini kullanın.

Altın Ağaç — Tam tek sayfalık konsept

Slogan: Sizinle birlikte büyüyen bir dünya. Ziyaret et, sula, izle. Seviye yok. Baskı yok.

Nedir?

Gerçek dünya zamanına göre gelişen, sakin ve koleksiyon odaklı bir dünya. Herkesin paylaştığı tek bir "mevsim" (ör. Bahar Adası): çocukların içinde dolaşabildiği tek bir 3D ada (oynanabilir Kali demosu gibi). Geleneksel seviyeler veya puanlar yoktur. İlerleme; ağacının yeni bir dal çıkarması, 12 an görmüş olman veya birinin senin tohumunu sulaması demektir.

Çocuk her ziyaretinde şunlardan birini yapabilir: bir bitkiyi sulamak, bir dilek bırakmak (metin veya emoji), gizli bir Cubcoats karakterini bulmak ya da 30 saniyelik bir "an" izlemek (ör. altın ağacın altındaki Kali). Yeni anlar ve küçük hikâye parçaları her hafta yayınlanır (bölümler hâlinde). İsteğe bağlı doğal dil desteği: "Kali bugün şöyle dedi: [İngilizce ve Çince birer cümle]."

Öğrenme ve gelişim fark ettirmeden gerçekleşir: nezaket, sabır ve yeniden deneme gibi temalar derslerde değil, metinlerde ve görsel tasarımda yer alır. Deneyim okul gibi değil, bir oyuncak veya ortak bir buluşma alanı gibi hissettirir.

Temel oyun döngüsü

1. Adayı ziyaret et (tarayıcıdan veya uygulamadan).
2. Her ziyarette nazik bir eylem gerçekleştir: sula, dilek bırak, bir karakter bul veya bir an izle.
3. Günler ve haftalar içinde dünyanın değiştiğini gör (yeni çiçekler, yeni karakter pozları, yeni kısa klipler).
4. Büyümeyi sosyal bir deneyime dönüştürmek için arkadaşına bir tohum gönder veya "bir arkadaşının adasını ziyaret et."

Yazıdaki üretim sürecini ve karakterleri nasıl kullanıyor?

• Oynanabilir 3D dünya: Kali demosuyla aynı üretim süreci: T pozu → 3D Model Generator → rigleme → Cinevva Engine. Ada ve karakterler üçüncü şahıs bakış açısıyla, rahatça ve baskı olmadan keşfedilebilir.
• Altın ağaç: Doğrudan yazıdan alınmıştır (Kali'nin "korkudan umuda" geçişi ve büyülü altın ağaç). Ağaç, sezonun duygusal ve görsel odağıdır.
• Kısa "anlar": Yazıdaki dikey kısa video gibi üretilir: başlangıç karesi + bitiş karesi + hareket istemi → Video Generator (Kling 3.0 Pro), 9:16, ~15 sn. Her haftalık yayın, hikâyenin küçük bir parçasını sunar.
• Cubcoats fikrî mülkiyeti: Kali ve diğer yedi karakter, ada dünyası ve sıcak, yuvarlak hatlı görsel tarz. Dijital ve bölümler hâlinde sunulan bir ürün olarak lisanslama odaklı yeniden lansmana (2026) uygundur.

Neden viral olabilir?

• Kolay erişim: Tek bağlantı, uzun bir başlangıç süreci yok. "Arkadaşına bir tohum gönder" basit ve paylaşılabilir bir çağrıdır.
• Sakin, güzel klipler: Kısa anlar tek başlarına paylaşılabilir (sosyal medyada "şu 15 saniyeyi izle"). Olumlu anlamda meme potansiyeline sahiptir.
• Bölümler hâlinde: "Bu hafta ne var?" sorusu tekrar ziyaretleri ve konuşmaları teşvik eder.
• Fark ettirmeden öğrenme: Ebeveynler "sakin, yaratıcı, reklamsız, stressiz" bir deneyim görür; çocuklar ise açıkça ders verildiğini hissetmeden rutin, sabır ve hoş sürprizlerle karşılaşır.

Cinevva blogu için olası yaklaşım

"Kali'yi eskizden videoya, ardından içinde dolaşabileceğiniz bir karaktere dönüştürdük. Altın Ağaç bir sonraki adım: çocukların ziyaret ettiği, suladığı ve kısa anları izlediği, gerçek zamanlı büyüyen bir dünya—seviye yok, baskı yok. Aynı üretim süreci. Yeni bir format."

Kali'nin Kelime Adası — Kısa bakış

Temel fikir: Cubcoats adası karakter bölgelerine ayrılır (Kali'nin ormanı, başka bir karakterin sahili). Çocuklar, İngilizce ve Çinceyi anlamayı ve kullanmayı gerektiren kısa görevleri tamamlayarak karakterlere yardım eder. İlerleme = "Tohumlar → Fidanlar → Ağaçlar → Altın Ağaç" (bölgedeki ağaç tamamen büyüdüğünde bir sonraki bölgenin kilidi açılır). Günlük "fener" koşusu, koleksiyonluk ifade kartları, karakter "ruh hâli" göstergeleri ve isteğe bağlı ebeveyn paneli. Bir bölge tamamlandığında kısa hikâye anlarının (başlangıç/bitiş karesi tarzında) kilidi açılır. Üretim süreci: Karakterler ve duygusal anlar için aynı 3D + video üretim süreci.

Cubcoats: Ada Hikâyeleri — Kısa bakış

Temel fikir: Çocukların hikâye dallarını seçtiği bölümlü anlatılar (Kali ne söylüyor? Nereye gidiyor?). Ana etkinlik yeniden yorumlamadır: karakteri, mekânı ve 2–3 hikâye adımını seç → kısa bir "bölüm" oluştur (senaryo + basit görseller veya ileride yapay zekâyla üretilen kısa video). Öğrenme fark ettirmeden gerçekleşir (diyalog ve seçimlerdeki kelime dağarcığı ve kalıplar). Sosyal özellikler: bölümünü paylaş, başka birinin versiyonunu oyna, "nazik / komik / şaşırtıcı" olarak değerlendir. Üretim süreci: Kullanıcıların oluşturduğu "anlar" için aynı karakter görünümü + iki kareli video üretim süreci; karakter ve dünya tutarlılığı için 3D.

Bahsedilen Cinevva araçları: Image Generator, Video Generator (Kling 3.0 Pro), 3D Model Generator, otomatik rigleme, Cinevva Engine. "Eskizden videoya ve oynanabilir 3D'ye" (2026-03-04) başlıklı yazıda açıklanan üretim sürecini yansıtır.

Yazan: Mariana Muntean, Cinevva CEO'su

Cinevva ekibi, yakın dönem oyun geliştirme dünyasının en şeffaf mühendislik günlüklerinden birini kısa süre önce yayımladı: tamamen tarayıcıda çalışan çok oyunculu bir açık dünya geliştirme girişimimizi belgeleyen 12 bölümlük bir seri. İndirme yok. Uygulama mağazası yok. Yalnızca bir URL.

Proje, "spike" adını verdiğimiz 24 teknik deneyi kapsıyordu; bunlar, her biri riskli bir soruyu yanıtlamak üzere tasarlanmış kısa ve odaklı prototiplerdi. Her spike, hemen şimdi tarayıcınızda açıp çalıştırabileceğiniz canlı kaynak koduyla birlikte yayımlandı. Seri, Cinevva'nın CTO'su ve kurucu ortağı Oleg Sidorkin tarafından yazıldı ve pazarlama metninden çok, tarayıcıların 2026'da gerçekte neler yapabildiğinin ön saflarından bir saha günlüğü gibi okunuyor.

Seriyi okumaya değer kılan şey — hiçbir zaman arazi sistemleri geliştirmeyi planlamıyor olsanız bile — altında yatan yöntem. Bu, pahalı herhangi bir taahhütte bulunmadan önce iddialı bir projenin risklerini nasıl azaltabileceğinize dair bir vaka çalışması.

Önce en zor sorudan başlamak

Çoğu açık dünya projesi öngörülebilir bir sırayla başarısız olur. Önce harika bir fikir ortaya çıkar. Ardından güzel bir sahne gelir. Sonra da oynanış daha ortada yokken kare süresi bütçenizin çoktan tükendiğini keşfedersiniz.

Ekibimiz bu sırayı tersine çevirdi. İlk spike özellikle çirkin tasarlanmıştı: 512 metrelik bir arazi ağı, 500 örneklenmiş nesne, prosedürel yükseklik gürültüsü, bir su düzlemi ve sis. Gölge yoktu, görsel iyileştirme geçişi yoktu. Tek soru, kamera dünyada hareket ederken tarayıcının kararlı bir kare hızını koruyup koruyamayacağıydı.

Koruyabildi. Bu "evet" yanıtı, Oleg'in "temel sözleşme" olarak adlandırdığı şeyi oluşturdu: sonraki her özelliğin maliyetini haklı çıkarmak zorunda olduğu, minimal bir sahne için ölçülmüş referans maliyet. Yeni bir efekt harika görünüyor ancak kare bütçesini aşıyorsa yayımlanmıyordu. En azından henüz.

Bu tür bir disiplin kulağa bariz geliyor. Uygulamada ise herkesin bir sonraki görsel başarı için heyecanlandığı hızlı prototipleme ortamlarında nadir görülüyor.

Fizik kumarı

İkinci deney, tarayıcı oyunu geliştiricilerini ikiye bölen mimari bir tartışmayı ele aldı: fizik, daha basit olduğu ana iş parçacığında mı yoksa oluşturmayı engelleyemeyeceği bir Web Worker içinde mi çalışmalı?

Worker tabanlı fizik kâğıt üzerinde daha temizdir. Uygulamada ise korkulan şey gecikmedir. Her giriş olayı mesaj sınırını iki kez geçmek zorundadır: bir kez worker'a ulaşmak, bir kez de sonucu geri getirmek için. Bu gidiş dönüş çok yavaşsa bir tuşa basmanızla karakterinizin hareket ettiğini görmeniz arasındaki süre hantallık hissi yaratır.

Ekip, Rapier fizik motorunu (Rust'tan WebAssembly'ye derlenmiş hâliyle) özel bir worker'a entegre etti, mesaj hattını bağladı ve ölçüm yaptı. Ek yük ihmal edilebilir düzeydeydi. Kontroller hâlâ anında tepki veriyordu. Ancak evrensel bir kuralı değil, belirli bir senaryoyu doğruladığımızı özellikle belirtmeye dikkat ettik. GPU yükü ve veri akışı karmaşıklığı daha sonra değiştiğinde varsayımların yeniden kontrol edilmesi gerekecekti.

Projeyi kurtaran sıkıcı spike'lar

Serinin üçüncü bölümünde ekran görüntüsü yok. Bölüm, gösterişli görünmeyen ancak ürün düzeyinde sonuçları olan üç deneyi ele alıyor.

İlki, çok oyunculu altyapının temelini oluşturan Cloudflare Durable Objects'in gerçek zamanlı konum yayınlarını oyun benzeri tick hızlarında işleyip işleyemeyeceğini test etti. Bu başarısız olsaydı ağ mimarisinin tek ada sahipliği yerine daha başlangıçta parçalanması gerekecekti.

İkincisi, bir mobil kalite profilini doğruladı: adı değiştirilmiş bir masaüstü ön ayarı değil, aynı arazi temelinden oluşturulmuş ve düşük maliyet için açıkça tasarlanmış bir oluşturma yolu. Soru, oluşturucuyu baştan yazmadan dünyanın mobil GPU kısıtlamaları altında okunaklı ve duyarlı kalıp kalamayacağıydı.

Üçüncüsü, üretici iş akışları için yapay zekâ tarafından oluşturulan davranış betiklerinin üretimde kullanılacak kadar güvenilir olup olmayacağını değerlendirdi.

Bunların hiçbiri tanıtım videoları üretmedi. Ancak üçü de sonrasındaki her mimari kararı şekillendiren kesin sınırlar koydu. Oleg, bu "gösterişsiz spike'ların mimariyi görsel spike'lardan daha hızlı değiştirdiğini" yazıyor.

Veri akışı: güzel projelerin dağıldığı nokta

Tek bir sabit karede pek çok şeyi gizleyebilirsiniz. Koşarken bir parça sınırını geçtiğiniz anda oluşan 40 milisaniyelik takılmayı gizleyemezsiniz.

Ekip, sorumlulukları bilinçli olarak ayırıp gelişmiş araziyi oluşturmadan önce veri akışını test etti. Spike 6, basit içerikle komşu parçaların yüklenmesini doğruladı. Ancak bu net sonuçtan sonra Spike 11, aşamalı iyileştirmeyle sıkıştırılmış yükseklik haritası akışını devreye soktu: arazi önce 17 örnek çözünürlüğünde, sonra 33 örnekte ve son olarak 65 örnekli tam ızgarada yükleniyordu.

Sıralama beklediğimizden daha önemliydi. Doğrudan sıkıştırılmış yükseklik parçalarıyla başlasaydık her takılmanın nedeni belirsiz olacaktı. Sorun kod çözmede mi, doku yükleme tıkanmasında mı, yoksa geometri güncellemesinde miydi? Önce basit veri akışını test etmek, belirsizlik kategorilerinden birini tamamen ortadan kaldırdı.

Ortaya pratik bir ders çıktı: yükleme tıkanmalarını ortalama FPS üzerinden değil, doğrudan ölçün. Ortalamalar kare sıçramalarını gizler; oyuncuların gerçekten hissettiği şey de bu sıçramalardır.

Görsel bütçe savaşları

Üç ayrı deney, oluşturma maliyetlerini bir araya toplamak yerine birbirinden bağımsız olarak ele aldı. Bitki örtüsü yoğunluğu ve rüzgâr animasyonu. Uçurum yüzeyleri için üç düzlemli eşlemeye sahip çok katmanlı arazi malzemeleri. Gerçekçi arazi yükü altında basamaklı gölge haritaları.

Bitki örtüsü spike'ı, örnekleri daha az sayıda ağda toplu işlemenin, her bir ot sapındaki poligon sayısını azaltmaktan daha önemli olduğunu gösterdi. Malzeme spike'ı, dikey yüzeylerde üç düzlemli projeksiyonun GPU maliyetine değdiğini ancak beşinci bir doku sıçratma katmanı eklemenin değmediğini ortaya çıkardı. Gölge spike'ı ise 1024 çözünürlükte üç kademenin, GPU süresinde 2 milisaniyeyi aşmadan kabul edilebilir temas gölgeleri sunduğunu belirledi.

Ekip kesin bir kural benimsedi: bir özellik ancak maliyetini ölçülmüş kare süresi verileriyle açıklayabiliyorsa ilerler. Erken belirlenen bu kısıtlama, hacimsel arazi ve clipmap'lerle ilgili sonraki mimari kararları önemli ölçüde sadeleştirdi.

Projenin yönünü değiştiren dönüm noktası

Spike 10'dan önce zihinsel modelimiz "daha büyük dünya, daha fazla geometri demektir" şeklindeydi. Spike 10'dan sonra bu model "sabit geometri bütçesi, kamera merkezli halka güncellemeleri" hâline geldi.

Geometri clipmap'leri — kameranın etrafında merkezlenmiş ve her biri giderek daha kaba hâle gelen eş merkezli arazi halkaları — çizim mesafesi ne olursa olsun üçgen sayısının yaklaşık olarak sabit kalmasını sağladı. Uygulamadaki püf noktası, halka sınırlarındaki geometri geçişiydi: çözünürlük seviyeleri arasındaki değişimin hareket hâlindeyken görünmemesi için tepe yüksekliklerini shader içinde yumuşak biçimde harmanlamak.

Test yönteminden incelikli bir ders çıktı. Clipmap'ler ekran görüntülerinde iyi görünür. Kusurlarını yalnızca kamera halka sınırlarından sürekli olarak geçerken belli ederler. Ekip, sabit hızlı geçişler yapıp zamansal gürültüyü gözlemlemek için zaman harcadı. Oleg, "Ekran görüntüleri yalan söyledi," diye yazıyor. "Gerçeği hareket gösterdi."

Yer altına inmek

Yükseklik haritaları mağaraları temsil edemez. Izgaradaki her nokta için tek bir yükseklik değeri saklarlar. Tünellere, çıkıntılara veya oyulmuş kaya yüzeylerine ihtiyaç duyduğunuz anda hacimsel arazi gerekir.

Spike 12, WebGPU hesaplama shader'larını kullanarak marching cubes'ı GPU üzerinde uyguladı ve 3B işaretli mesafe alanından üçgen ağları çıkardı. Dört adet 64 küplük parça, animasyonlu SDF düzenlemelerinden gelen kare başına ağ güncellemeleriyle aynı anda çalıştı. Hesaplama shader'ı, CPU'ya hiçbir geri okuma yapmadan alanı değerlendirmekten hücreleri sınıflandırmaya ve tepe noktalarını üretmeye kadar her şeyi yönetti.

Zorluk bunu çalıştırmak değildi. Diğer her şeyle birlikte çalışmasını sağlamaktı. Three.js'in sahne grafiğiyle entegrasyon, tampon yaşam döngüsü yönetimi (WebGPU tamponları yeniden boyutlandırılamaz), hâlâ kullanımda olan GPU kaynaklarını yok etmekten kaçınmak için fence yönetimi... Seri, "kademeli sağlamlaştırma" adını verdiğimiz şeye iki tam bölüm ayırıyor: her seferinde tek bir yetenek ekleyip her eklemeden sonra önceki katmanın hâlâ çalıştığını doğrulamaya dayanan gösterişsiz süreç.

Birleşim yeri kâbusu

Serinin teknik açıdan en çetin bölümü, farklı çözünürlüklerdeki arazi parçaları bir araya geldiğinde neler olduğunu ele alan 9. Bölüm'den 11. Bölüm'e kadar uzanıyor.

Yüksek ayrıntılı bir parça düşük ayrıntılı bir parçanın yanına geldiğinde, bağımsız olarak oluşturulan ağları sınırda hizalanmaz. Sonuç; görünür çatlaklar, titreyen kenarlar ve ışığın sızdığı T bağlantılarıdır. Transvoxel algoritması, çözünürlük farkları arasında köprü kuran özel geçiş hücreleriyle bu sorunu çözer. Ancak algoritmayı tüm parça yapılandırmalarında tutarlı sarım sırası, doğru tampon yönetimi ve isabetli çizim aralıklarıyla doğru şekilde uygulamak altı ayrı deney gerektirdi.

Ekibin en unutulmaz hata ayıklama hikâyesi şuydu: geçiş mantığından kaynaklandığını düşündüğümüz bir birleşim yeri kusurunun peşinde geçen iki gün. Asıl suçlu eski veriydi. GPU hesaplama shader'ı bir tampona N tepe noktası yazıyordu ancak çizim çağrısı hâlâ önceki kareden kalan N+M tepe noktasını oluşturacak şekilde yapılandırılmıştı. Bu fazladan tepe noktaları, titreşen ve jilet inceliğinde üçgenler üreten bozuk veriler içeriyordu. Tek satırlık çözüm: çizim aralığını atomik sayacın etkin tepe noktası sayısıyla sınırlandırmak.

Oleg, "Oluşturma hataları genellikle ağ oluşturma hatası kılığına girer," diye belirtiyor. "Geometri başından beri doğruydu."

Kaostan yönetişime

Birleşim yeri mücadelesinin ardından ekip, plansız parça davranışını açık bir politika sistemiyle değiştirdi. Artık merkezi bir işlev her parçanın LOD seviyesine, oluşturma moduna (yükseklik haritası veya marching cubes) ve hangi yüzlerde geçiş hücreleri gerektiğine karar veriyordu. Mesafe halkaları temel LOD'u belirliyordu. Komşuluk kısıtlaması, yan yana iki parçanın çözünürlük seviyeleri arasında birden fazla kademe fark olmamasını sağlıyordu. Düzenleme bit eşlemi ise üretici değişiklikleri içeren hacimsel parçaları, mesafeden bağımsız olarak marching-cubes modunda tutuyordu.

Renk kodlu hata ayıklama katmanları — yükseklik haritası parçaları için yeşil, marching cubes parçaları için mavi, geçiş yüzleri için turuncu — "şu sırtın yakınlarında bir yerde hata gördüm" ifadesini "hata kuzeybatıya bakan (142, 12, -67) konumunda görünüyor" ifadesine dönüştürdü.

Oleg, "Politika karmaşıklığı azaltmadı," diye yazıyor. "Karmaşıklığı düzenledi."

Tüm bunların ortaya çıkardığı sonuç

Son spike; clipmap halkalarını, parça başına gökyüzü sisini (her arazi parçasının yönündeki gerçek gökyüzü kutusu rengini örnekleyen) ve Three.js modül bağlantılarını birleşik bir gösterimde bir araya getirdi. Sonuç; yakın alanda hacimsel düzenlemeyi, orta alanda yükseklik haritası parçalarını ve uzak alanda clipmap halkalarını; modu, LOD'u ve geçişleri yöneten bir politika katmanı altında birleştiren bir arazi sistemi.

Seri, Oleg'in gelecekteki her projede tekrarlayacağını söylediği derslerle sona eriyor:

• Özellik geliştirmeden önce risk spike'larıyla başlayın. İçerik işlem hatlarına yatırım yapmadan önce "bunu gerçekten yapabilir miyiz?" sorularını ortadan kaldırın.
• Büyük entegrasyon adımlarından önce çalıştığı bilinen temel sürümleri sabitleyin. Temiz bir kontrol noktası oluşturmak için harcanan bir gün, daha sonra gerilemeleri ikili aramayla bulmak için harcanacak birkaç günü kurtarır.
• Uzun optimizasyon süreçlerinden önce politika ve gözlemlenebilirliği zorunlu kılın. Tetikleme kurallarına sahip adlandırılmış koşullar, gizemli hatalara her zaman üstün gelir.
• Ekran görüntülerinde değil, hareket hâlinde test edin. Ani geçişler, titremeler ve veri akışı takılmalarının tümü sabit karelerde gizlenir.
• Ortalama FPS'yi değil, özellik başına kare süresini ölçün. Ortalamalar, kullanıcıların gerçekten hissettiği sıçramaları gizler.
• Dağınık kısımları da yayımlayın. Yanlış yolları, hayalet avlarını, yanlış sistemi suçlayarak geçen iki günü... İnsanların gerçekten ders çıkarabileceği kısımlar bunlardır.

Bunun Cinevva'nın ötesinde taşıdığı önem

Seri, tek bir şirketin arazi işlem hattının ötesine geçen üç nedenle önem taşıyor.

Birincisi, WebGPU hesaplama shader'larının, WebAssembly fiziğinin ve uçta dağıtılan Durable Objects'in bir eşiği aştığını gösteriyor. Hacimsel araziye, gerçek zamanlı düzenlemeye ve akışlı LOD'a sahip çok oyunculu bir açık dünya, 2026'da bir tarayıcı sekmesinde mimari açıdan uygulanabilir durumda. Bu, iki yıl önce mümkün değildi.

İkincisi, spike yöntemi — her biri canlı ve ölçülebilir sonuçlarla tek bir riskli soruyu yanıtlayan küçük, odaklı deneyler — çalışmayabilecek bir şeyi denemeye girişen her ekip için bir şablon sunuyor. Taahhütte bulunmadan önce ölçme, entegrasyondan önce temel ölçümler oluşturma ve optimizasyondan önce uç durumları adlandırma disiplini, arazi sistemlerinin çok ötesinde geçerlidir.

Üçüncüsü, bu radikal şeffaflık başlı başına amaçtır. Çıkmaz yollar ve iki günlük hata ayıklama sapmaları dâhil olmak üzere 24 deneyin tamamının kaynak kodunu yayımlamak, bunu teknik bir blogdan daha fazlasına dönüştürüyor. Bu, okuyucuya müşteri değil meslektaş gibi davranan, herkese açık bir mühendislik defteri. Serinin tamamına, her teknik denemenin tarayıcıda canlı olarak çalıştığı seri rehberimizden ulaşabilirsiniz.

Bu makale ilk olarak Medium'da yayımlandı.

Cinevva CTO'su Oleg Sidorkin tarafından

Bir karakteri düz bir eskizden oynanabilir bir 3D oyuna dönüştürmek eskiden bir konsept sanatçısı, 3D modelleme sanatçısı, rig uzmanı, animatör ve tüm bunları bir oyun motorunda bir araya getirecek birini gerektiriyordu. Bu iş akışının ne kadarını Cinevva'nın yaratıcı araçlarının kendi başlarına üstlenebileceğini görmek istedik. İşte bulduklarımız.

Karakter, bir milyondan fazla pelüş hayvan kapüşonlusunu Nordstrom, Amazon ve Disney Store üzerinden satan çocuk markası Cubcoats'tan Kedicik Kali. Cubcoats'un belirli kişiliklere sahip sekiz özgün karakteri, kurgusal bir ada dünyası ve 14 patenti var. Marka, 2026'da lisanslama odaklı bir platform olarak yeniden faaliyete geçiyor. Biz de bu fikrî mülkiyetin fiziksel ürünlerin ötesine taşındığında nasıl göründüğünü göstermek istedik: dikey bir kısa video ve tarayıcıda hareket ettirebileceğiniz rig'lenmiş bir 3D karakter. Aşağıdakilerin tamamı bu çalışmadan elde edilen gerçek çıktılardır.

Yörüngede döndürmek için 3D görüntüleyicileri sürükleyin. Dikey kısa videonun ilk kareden son kareye nasıl ilerlediğini görmek için film şeridini kaydırın.

Düz kitap çiziminden çevresinde döndürebileceğiniz bir karaktere

Cubcoats'un zaten güzel 2D illüstrasyonları vardı. Mimi Chao'nun sanat yönetimi, her karaktere hem kapüşonlularda hem de hikâye kitaplarında kusursuz çalışan sıcak, yuvarlak ve elle çizilmiş bir görünüm kazandırmıştı. Ancak düz çizimler 3D iş akışına uygun değildir. Video üretimi, mesh oluşturma ve rig işlemlerinde referans olarak kullanılabilecek, tüm aşamalarda aynı yüzü koruyan yüksek kaliteli bir karaktere ihtiyacımız vardı.

Özgün kitap illüstrasyonlarını Görsel Oluşturucumuza yükleyip aynı karakterin 3D render edilmiş bir sürümünü üretmesini isteyerek başladık.

Oranlar korundu, karakterin kişiliği yansıtıldı ve yumuşak 3D çizgi film görünümü sonraki tüm araçlara tutarlı bir temel sundu. Ardından kesin pozu ve kadrajı tekrar tekrar iyileştirerek sabitlenmiş ana karakter referansını elde ettik.

T-pozu önemlidir çünkü rig işlemi, kolların gövdeden uzakta olmasını gerektirir. Bu adımı atlarsanız otomatik rig aracı kolları gövdeyle birleştirir ve işlemi tamamlayamaz. T-pozunu aynı sabitlenmiş karakter görünümünden ürettik; böylece silüet ve oranlar her aşamada tutarlı kaldı.

Herhangi bir şey üretmeden önce hikâyeyi yazın

Video araçlarına geçmeden önce hikâyenin ana vuruşlarını sade bir dille yazdık. Kali'nin Cubcoats evrenindeki kişilik özelliği "Pozitif" olmasıdır. Herkesin kendini gruba dâhil hissetmesini sağlayan ve işler zorlaştığında iyimserliğini koruyan karakter odur. Bu yüzden onun etrafında on saniyelik bir hikâye akışı oluşturduk:

Kali, gece vakti elinde minik, parlayan bir fenerle karanlık ve sisli bir ormana girer. Korkar, tek başına yere oturur ve neredeyse pes eder. Sonra arkasında ışıldayan büyülü, altın bir ağaç keşfeder. Hayret, neşe ve gökten yağan altın parçacıklar. Tek nefeste korkudan umuda.

Hikâyenin tamamı bu. Karmaşık olmasına gerek yok. Başlangıç ve bitiş karelerinin gerçekten birbirine bağlanabilmesi için tek bir kesintisiz çekimde tek bir duygusal dönüşe sığması gerekir.

Tüm hikâyeyi çevreleyen iki kare

Bu hikâyeden yola çıkarak Görsel Oluşturucumuzla iki ana sabit kare ürettik. Dikey kısa videoya uyması için portre en-boy oranını kullandık. İstemler, tamamen aynı karakteri iki farklı anda betimliyor.

Başlangıç karesi istemi:

Kali'nin 3D animasyonlu Pixar tarzı render'ı; iri, yuvarlak, koyu renk gözlere, sivri pembe kulaklara, açık pembe bir karna ve neşeli, yuvarlak bir yüze sahip küçük pembe bir kedicik karakter. Gece vakti, karanlık ve sisli bir ormanın kıyısında duruyor ve iki patisiyle minik, parlayan bir fener tutuyor. Kulakları hafifçe geriye yatmış, ifadesi gergin ama kararlı. Yukarıdan gelen soğuk mavi ay ışığı ve fenerden yayılan sıcak turuncu parıltıyla sinematik aydınlatma. Arka plandaki koyu ağaç gövdelerinin arasında yoğun sis. Kamera açısı: orta çekim, hafif alçak açıdan ona doğru yukarı bakıyor. Metin yok, filigran yok.

Bitiş karesi istemi:

Kali'nin 3D animasyonlu Pixar tarzı render'ı; iri, yuvarlak, koyu renk gözlere, sivri pembe kulaklara ve açık pembe bir karna sahip küçük pembe bir kedicik karakter. Parlayan altın çiçeklerle kaplı devasa, büyülü bir ağacın önünde duruyor; kolları iki yana açılmış ve yüzünde kocaman, neşe dolu bir gülümseme var. Altın yapraklar çevresinde havada süzülüyor. Ağaç, orman açıklığının tamamını aydınlatan sıcak, altın bir ışık yayıyor. Yukarıda yıldızlı gece gökyüzü görünüyor. Kamera açısı: hafif alçak açıdan geniş çekim, görkemli açığa çıkış kompozisyonu. Metin yok, filigran yok.

Seedance bu iki uç kare arasında geçiş oluşturuyor. Modelin ikisinin de aynı kişi olduğunu anlaması için karakter açıklaması her iki istemde de aynı kalıyor. Yalnızca sahne, duygu ve kamera değişiyor.

Video beklediğimizden daha iyi çıktı

Her iki kareyi de Cinevva'nın Video Oluşturucusuna yükledik, Seedance 1.5 Pro'yu seçtik, en-boy oranını 9:16 ve süreyi 15 saniye olarak ayarladık, hikâyeyi hareket istemine yazdık ve Oluştur'a bastık.

Klip, iki uç kare arasında geçiş oluşturuyor. Yerel ses de aynı işlem sırasında üretildi. İşte zaman çizelgesinin farklı noktalarından alınan kareler.

Soldan sağa: oluşturulan dikey kısa videodaki ilerleyiş.

Kesin bir kapanış pozuna ulaşmak istediğimizde başlangıç ve bitiş karesi modu doğru seçimdi. Daha uzun duygusal akışlarda tek referans ve istem yöntemi, Video Oluşturucunun Kling 3.0 Pro hikâye panosu moduyla iyi sonuç verdi. Farklı işler için farklı ayarlar.

Aynı karakter, şimdi 3D

İşin ilginçleştiği yer burası. Video referanslarıyla aynı görsel aileden gelen T-pozu görselini, görselden 3D üretimi için 3D Model Oluşturucumuza gönderdik. Oyun mesh'ini videoyla piksel piksel eşleştirmiyorsunuz. Oyuncunun belleğindeki karakterle eşleştiriyorsunuz. Oyundaki karakter, kısa videodakiyle aynı kişiliğe sahipmiş gibi hissettirmeli. Başlangıçta tek bir görsel kimliği sabitlediğimiz için de öyle oldu.

3D Model Oluşturucu, dokulu bir GLB çıktısı verir. Oyun için hazır değildir ama Kali olduğu kolayca anlaşılır. Silüet eşleşti. Malzemeler oldukça yakındı. İlerlemek için yeterince iyiydi.

Bunları sürükleyerek döndürün

3D Model Oluşturucunun ham çıktısı. Rig yok, yalnızca dokulu bir mesh. Yanında ise otomatik rig işleminden geçirilmiş ve yürüme animasyonu gömülmüş aynı karakter var.

Rig ve animasyon

3D Model Oluşturucu size bir mesh verir. Bu mesh'in hareket edebilmesi için bir iskelete ve animasyonlara ihtiyacı vardır. Platformumuz rig işlemini otomatik olarak gerçekleştirir: GLB'yi yükleyin, eksiksiz bir animasyon kitaplığına sahip rig'lenmiş modeli geri alın. Yürüme döngüleri, boşta nefes alma, zıplamalar ve bir oyun karakterinin ihtiyaç duyduğu her şey.

Varsayılan yürüme animasyonu neredeyse doğru görünüyordu ama tam değildi. Kali'nin kolları vücuduna fazla yakındı ve başı hafifçe yanlış bir açıyla eğiliyordu. Her ikisi de genel bir insansı karakter için mantıklıydı ancak yuvarlak bir çizgi film kediciğinde tuhaf görünüyordu. Bu yüzden oyun koduna çalışma zamanı kemik düzeltmeleri ekledik: kolları dışarı iten bir omuz ofseti ve eğimi düzelten bir baş dönüşü düzeltmesi. Küçük ayarlar, büyük fark. Bunlar olmadan sert ve robotik görünüyordu. Bunlarla birlikte yeniden Kali gibi göründü.

Karakteri tarayıcıda oynamak

Rig'lenmiş modeli Cinevva Engine'e aktardık. Üçüncü şahıs kamerası, WASD ile hareket, etrafa dağılmış toplanabilir nesneler ve karakter boşta dururken yörünge kamerası. Animasyon geçişlerini doğru hâle getirmek birkaç deneme gerektirdi: boşta durma ve yürüme arasında yumuşak geçiş, yüksekliği normalleştirme, ileri eksenini düzeltme ve kemik ofsetlerini ayarlama. Karakterin arkasındaki üçüncü şahıs kamerası, eskizden hareket ettirebileceğiniz bir karaktere uzanan süreci tamamlıyor.

Kendiniz deneyin. Hareket etmek için WASD tuşlarını kullanın.

Bunu yarın yapacak birine ne söylerdim?

Herhangi bir üretim aracına dokunmadan önce tek bir karakter görünümünü sabitleyin. Bu referansı doğru hâle getirmek için harcadığınız her dakika, daha sonra tutarlılık peşinde koşacağınız bir saatten tasarruf ettirir.

Önce kısa bir hikâye yazın. Ardından başlangıç ve bitiş karelerinizi Görsel Oluşturucuyla üretin. Referans görsellerini API boyut sınırları içinde tutun. 3D Model Oluşturucuya aktarırken aynı tasarım sisteminden gelen T-pozunu kullanın.

Her iki kareyi de Video Oluşturucuya verin ve aralarındaki geçişi oluşturmasına izin verin. Oyun mesh'i için modeli platform üzerinden rig'leyin ve varsayılan animasyonlar karakterinizin oranlarına tam uymuyorsa çalışma zamanında kemik ofsetlerini ayarlayın.

İki yıl önce bu iş akışı yoktu. Bir ekibe ve bütçeye ihtiyacınız olurdu. Artık bir eskiz ve Cinevva'nın yaratıcı araçları yeterli. Bence bu, kimlerin bir karaktere hayat verebileceği konusunda anlamlı bir değişim.

Kullanılan Cinevva araçları: Görsel Oluşturucu, Video Oluşturucu, 3D Model Oluşturucu, otomatik rig ve Cinevva Engine. 2026'nın başındaki durumu yansıtır.

Cinevva CTO'su ve Kurucu Ortağı Oleg Sidorkin tarafından

Burada yeni misiniz? Seri rehberine göz atın. Rehber, spike'ın ne olduğunu açıklıyor ve tüm bölümlere bağlantı veriyor.

Tamamen tarayıcıda çalışan çok oyunculu bir açık dünya geliştiriyoruz. Kurulum yok, uygulama mağazası yok; yalnızca bir URL var. Başlangıçtaki en büyük risk açıktı: Bir tarayıcı, oynanış, fizik ve ağ iletişimi için yeterli pay bırakırken kalıcı bir 3D dünyayı oynanabilir kare hızlarında işleyebilir mi?

Çoğu açık dünya projesi öngörülebilir bir sırayla başarısız olur. Önce güzel bir konsept elde edersiniz. Ardından hoş görünen bir sahne oluşturursunuz. Sonra da henüz oynanış ortada yokken kare bütçenizin çoktan tükendiğini fark edersiniz.

Başka herhangi bir şeye yatırım yapmadan önce render bütçesi sorusunu yanıtlamak istedik. Bu yüzden Spike 1, gösterişli fragmanı es geçti ve doğrudan ölçüm yapmaya odaklandı.

Spike 1'i yeni sekmede aç ↗ · Kaynak kodunu görüntüle

Kurulum bilerek basit tutuldu. 512 metrelik bir arazi mesh'i, ada kenarlarına doğru alçalan katmanlı sinüs gürültüsüyle oluşturulan prosedürel yükseklik, bir su düzlemi, atmosferik sis ve örneklenmiş 500 nesne. Three.js ile sade WebGL, ACES ton eşleme kullandık ve gölgeleri devre dışı bıraktık.

Nasıl göründüğünü önemsemedik. Kamerayı sahnede hareket ettirirken sahnenin kararlı kalıp kalmadığını önemsedik.

Bu spike'tan tüm projeye yön veren iki sonuç çıktı.

İlk olarak, ilk geçişi disiplinli tuttuğumuz sürece masaüstünde gerçekten yeterli performans payımız olduğunu doğruladık. Bu da daha sonra daha zorlu arazi mimarisini denemek için bize güven verdi.

İkinci olarak, bir temel performans sözleşmesi oluşturduk. Sonraki her spike, maliyetini bu sahneye kıyasla açıklamak zorundaydı. Yeni bir özellik iyi görünüyor ancak maliyeti çok yüksekse bir üst aşamaya geçirilmedi.

Bu temel ölçüm disiplini; daha sonra parça birleşim artefaktları, karma LOD geçişleri ve compute tabanlı mesh üretimiyle karşılaştığımızda kritik önem kazandı. Kararlı bir referans olmadan her hata gerçekte olduğundan daha büyük görünür.

2. bölümde render'dan girdi hissine geçiyoruz. Worker fiziği, mimari belgelerinde kulağa harika gelir. Ancak bir tuşa bastığınızda karakter hâlâ anında tepki veriyorsa anlam taşır.

Bu bölümde değinilen teknolojiler

Heightmap arazisi. Her hücrenin tek bir yükseklik değeri sakladığı 2D bir ızgaradır. GPU, arazi yüzeyini oluşturmak için düz bir mesh'i vertex shader'da deforme eder. Heightmap'ler kompakttır (65x65'lik bir parça, 16 bitte yaklaşık 8 KB'dir), GPU dostudur ve hızlı işlenir. Sınırlamaları ise mağaraları, çıkıntıları veya kendi üzerine kıvrılan herhangi bir yüzeyi temsil edememeleridir. Heightmap kısıtlamaları ve bunlardan sonra gelen yaklaşımlar hakkında bilgi için arazi üretimi rehberimize bakın.

Three.js. Bu proje boyunca kullandığımız render kütüphanesidir. Three.js, WebGL 2'yi (ve daha sonra WebGPU'yu) kameralar, ışıklar, malzemeler ve geometri nesneleri içeren bir sahne grafiği hâlinde soyutlar. Aynı geometrinin çok sayıda kopyasını tek bir draw call ile işlemek için InstancedMesh, görüş hacmi ayıklama, PBR malzemeleri ve son işleme özellikleri sunar. Bkz. GitHub'da Three.js. Three.js'in tarayıcı tabanlı açık dünya teknoloji yığınındaki yeri için tarayıcıda 3D teknolojileri rehberimize bakın.

InstancedMesh. Aynı geometrinin N kopyasını, her biri farklı bir konumda/döndürmede/ölçekte olacak şekilde tek bir draw call ile işleyen bir Three.js özelliğidir. Örnek başına dönüşümler bir matris öznitelik tamponunda saklanır. Spike 1'de 500 nesneyi 500 ayrı draw call kullanmadan bu şekilde işledik. Büyük ölçekli bitki örtüsünde GPU tabanlı örnek ayıklama bu yaklaşımı daha da ileri taşır. GPU ile bitki örtüsü ayıklamayı ele alan arazi rehberimize bakın.

Kare bütçesi. 60 fps'de her karede JavaScript mantığı, fizik, render ve birleştirme dâhil her şey için $\frac{1000\text{ms}}{60}\approx 16.7$ ms vardır. Bir "bütçe kontrolü" spike'ı, temel sahnenin bu sürenin ne kadarını tükettiğini ölçer; böylece sonradan eklediğiniz her şey için kalan pay $t_{\text{features}}=16.7-t_{\text{baseline}}$ olur. Temel sahne zaten 12 ms tüketiyorsa oynanış, fizik ve ağ iletişiminin tümü için yalnızca yaklaşık 4,7 ms kalır. Bu yaklaşım, GTA V, Skyrim ve Elden Ring'in sabit kare bütçeleri içinde kalmak için yoğun LOD ve akış kullandığı AAA açık dünya geliştirme pratiğinden gelir.

12 bölümün 1.'si.
Sıradaki: Bölüm 2 - Worker fiziği ve girdi gecikmesi korkusu
Seri rehberi: /tr/blog/2026-02-25-open-world-browser-series-guide

Cinevva CTO'su ve Kurucu Ortağı Oleg Sidorkin tarafından

Burada yeni misiniz? Seri rehberine göz atın. Rehber, spike'ın ne olduğunu açıklıyor ve tüm bölümlere bağlantılar sunuyor.

Yeterince uzun süre tarayıcı tabanlı çok oyunculu oyun geliştirirseniz, eninde sonunda şu tartışmayla karşılaşırsınız.

"Fiziği bir worker'da çalıştırmak temiz bir mimaridir. Fiziği ana iş parçacığında çalıştırmak daha güvenli hissettirir."

İkisi de doğru olabilir. Önemli olan, gerçek girdiler altında kontrollerin nasıl hissettirdiği ve gecikmedir.

Spike 2, bu soruyu görüşlerle değil, ölçümlerle yanıtlamak için geliştirildi.

Spike 2'yi yeni bir sekmede açın ↗ · Kaynak kodunu görüntüleyin

Spike 1'deki araziyi yeniden kullandık ve Rapier'ı özel bir modül worker'ına entegre ettik. Girdi durumu her karede worker'a gönderildi, simülasyon orada ilerletildi ve yetkili konum verisi render sistemine geri iletildi.

Temel metriklerimiz, girdiden görünür harekete kadar geçen gecikme ile fizik adımının süresiydi. Ayrıca normal hareket, kısa süreli deparlar ve art arda zıplamalar sırasında oluşabilecek titreşimleri de izledik.

Sonuç beklediğimizden daha iyiydi. Kullandığımız mesaj yapısı ve gönderim sıklığıyla worker sınırı, gecikmenin baskın kaynağı olmadı. Kontroller hâlâ anında tepki veriyormuş gibi hissettirdi; oyuncuların önemseyeceği tek şey de buydu.

Bu aşamadaki zorluklardan biri, sonuçları yanlış yorumlama riskiydi. Başarılı bir sonucun ardından ekipler genellikle aşırı genelleme yapar ve mimari sorunun sonsuza dek çözüldüğünü varsayar. Oysa çözülmüş değildi. Yalnızca belirli bir senaryoyu ve donanım profilini doğrulamıştık. Daha sonraki spike'larda GPU ve veri akışı baskısı değiştiğinde varsayımlarımızı yeniden sınamamız gerekecekti.

Bu spike, geliştirme sürecimizi de iyileştirdi. Etkileşimli spike'larda zamanlama telemetrisini varsayılan olarak HUD üzerinde göstermeye başladık. Böylece ekip içindeki konuşmalar "bir tuhaflık var"dan "bu işlem yolu 1,2 ms ekledi"ye dönüştü.

3. bölümde, ileride pahalı sürprizlerle karşılaşmamızı önleyen daha az gösterişli deneyleri ele alıyoruz: yayın yükü, mobil kısıtlamalar ve davranış üretiminin güvenilirliği.

Bu bölümde değinilen teknolojiler

Rapier. Rust ile yazılmış ve tarayıcıda kullanılmak üzere WebAssembly'ye derlenen bir fizik motorudur. Katı cisimleri, çarpışma şekillerini, eklemleri, karakter kontrolcülerini ve ışın izlemeyi yerel performansın 2-3 katına varan hızlarda işler. Rapier, açık dünyalar için oyuncu karakter kontrolcüleri (arazide yürüme, basamak çıkma ve eğimlerde kayma), nesne çarpışmaları, etkileşimler için ışın izleme ve tetikleyici hacimler sağlar. Rapier belgelerine ve fizik hakkındaki tarayıcı 3D teknoloji rehberimize bakın.

Web Workers. JavaScript'i (veya Wasm'ı) ana iş parçacığının dışında çalıştıran tarayıcı iş parçacıklarıdır. Fizik simülasyonunu bir worker'da çalıştırmak, ağır bir world.step() çağrısının render işlemini engellememesi anlamına gelir. Ana iş parçacığı, girdi durumunu her karede postMessage aracılığıyla worker'a gönderir ve yetkili konumları geri alır. Gecikme maliyeti, iki mesaj geçişidir (masaüstünde her biri yaklaşık 0,1-0,5 ms). Avantajı ise render iş parçacığının çarpışma algılama nedeniyle hiçbir zaman duraklamamasıdır. Aktarılabilir nesneler (ArrayBuffer aktarımı), büyük konum dizilerindeki kopyalama yükünü ortadan kaldırır.

WebAssembly (Wasm). Tarayıcılarda yerel uygulamalara yakın hızda çalışan ikili bir komut biçimidir. Rapier, Havok ve Recast'in tümü Wasm'a derlenebilir. Rapier-Wasm'daki fizik adımı, birkaç yüz cisim için genellikle 0,5-2 ms sürerken eşdeğer JavaScript uygulamasında bu süre 5-15 ms'dir. Wasm modülleri, JavaScript bağlayıcı koduyla birlikte getirilen .wasm dosyaları olarak yüklenir. WebAssembly spesifikasyonuna bakın.

Girdiden görüntüye gecikme. Bir tuşa basılması ile bunun sonucunda ekranda oluşan görsel değişiklik arasındaki süredir. Hareketin "anında" gerçekleşiyormuş gibi hissedilmesi için bu sürenin yaklaşık 80 ms'nin altında kalması gerekir. Worker üzerinde çalışan bir fizik düzeninde zincirdeki süreler birbirine eklenir:

keydown olayı (ana iş parçacığı), worker'a ve ardından geri gönderilen postMessage ($2t_{\text{msg}}$), fizik adımı, render sisteminin yeni konumu uygulaması ve son olarak bir sonraki vsync. Her bir terim tek başına küçüktür (masaüstünde her mesaj geçişi yaklaşık 0,1-0,5 ms), ancak süreler üst üste eklenir. Bu nedenle mimari şemasına güvenmek yerine $L$ değerini doğrudan ölçtük.

12 bölümden 2.'si.
Önceki: Bölüm 1 - İşe onu bozmaya çalışarak başladık
Sonraki: Bölüm 3 - Bizi kurtaran gösterişsiz spike'lar
Seri rehberi: /tr/blog/2026-02-25-open-world-browser-series-guide

Yazan: Oleg Sidorkin, Cinevva CTO'su ve Kurucu Ortağı

Burada yeni misiniz? Seri rehberine göz atın. Rehber, spike'ın ne olduğunu açıklıyor ve tüm bölümlere bağlantı veriyor.

Bu bölümde parlak ekran görüntüleri daha az, mimari güvenceler daha fazla.

Spike 1 ve 2'den sonra küçük görünen ancak ürün düzeyinde etkisi olan üç risk kontrolü gerçekleştirdik.

İlki, Durable Objects ile yayın fan-out'ıydı. Oyun benzeri tick hızlarında çok istemcili konum dağıtımını test ettik; gecikme dağılımını, tick başına CPU kullanımını ve iletim bütünlüğünü izledik. Bu başarısız olsaydı her adanın tek bir nesneye ait olması yerine erkenden sharding'e geçerdik.

İkincisi, mobil kısıtların doğrulanmasıydı. Bu, adı mobil olarak değiştirilmiş bir masaüstü ön ayarı değil, aynı temel arazi üzerinden oluşturulmuş, açıkça tanımlı düşük maliyetli bir profildi.

Mobil profili yeni sekmede aç ↗ · Kaynak kodunu görüntüle

Segment yoğunluğunu, nesne sayısını, işleme çözünürlüğü üzerindeki baskıyı ve sis mesafesini azalttık. Soru basitti. Bu dünya, tüm işleyiciyi baştan yazmadan mobil sınıfı kısıtlar altında okunabilirliğini ve tepki hızını koruyabilir mi?

Üçüncüsü, içerik üreticilerinin iş akışları için davranış üretiminin güvenilirliğiydi. Geçerli JSON oranını, beklenen temel öğelere göre anlamsal doğruluğu ve yanıt gecikmesini değerlendirdik. Bu başarısız olsaydı katı, form tabanlı davranış yazımına geçerdik.

Bu bölümden çıkardığımız temel ders, bu gösterişsiz spike'ların mimariyi görsel spike'lardan daha hızlı değiştirdiğiydi. Ağ topolojisi, mobil cihazlara yönelik vaatler ve araç kullanıcı deneyimi için kesin sınırlar belirlediler.

4. bölümde görünür arazi çalışmalarına dönüyor ve yalnızca statik yükleme ekran görüntülerini değil, hareket sırasındaki akış davranışını test ediyoruz.

Bu bölümde değinilen teknolojiler

Cloudflare Durable Objects. Yerleşik kalıcılık ve WebSocket desteğine sahip, uçta dağıtılan durum bilgili sunucusuz örneklerdir. Her Durable Object, bir dünya shard'ının (veya chunk'ının) yetkili durumunu tutar. Oyuncular WebSocket üzerinden bağlanır ve aynı shard'daki diğer oyuncuların konum yayınlarını alır. Oyuncu bitişik bir chunk'a geçtiğinde o chunk'ın Durable Object'ine bağlanır. Durable Objects, durumu otomatik olarak diske kalıcı biçimde kaydeder ve eşzamanlı binlerce örneğe ölçeklenebilir. Cloudflare Durable Objects belgelerine ve çok oyunculu ağ iletişimiyle ilgili tarayıcı 3D teknoloji rehberimize bakın.

Mekânsal sharding. Dünyanın coğrafi bölgelere göre sunucu örnekleri arasında bölünmesidir. Her shard, dünya ızgarasının dikdörtgen bir alanına sahip olur. Oyuncu yoğunluğu değiştikçe shard'lar bölünebilir veya birleşebilir. Shard sınırına yakın oyuncular, shard'lar arası görünürlük sorguları aracılığıyla her iki shard'ın içeriğini de görür. EVE Online binlerce oyuncuyu tek bir evrende bu şekilde barındırır.

WebSocket yayın fan-out'ı. Gerçek zamanlı konum güncellemelerinin tek bir sunucudan bağlı çok sayıda istemciye dağıtılmasıdır. İstemci başına indirme bant genişliği, görebildiğiniz kalabalıkla doğrusal olarak ölçeklenir:

Oyun benzeri tick hızlarında (20-30 Hz) her oyuncu saniyede yaklaşık $b_{\text{player}}\approx 800$ bayt konum verisi üretir; dolayısıyla görünümdeki 200 oyuncu, istemci başına $200\times 800=160$ KB/s maliyet oluşturur. Basit tümden-tüme yaklaşımında sunucu maliyeti daha da kötüdür ve $N^2$ oranında büyür. Alaka düzeyi filtrelemesinin (mekânsal ilgi yönetimi) her bağlantıya tick bütçesi içinde veri göndermeden önce $N_{\text{visible}}$ değerini sınırlamasının nedeni tam olarak budur. Delta sıkıştırma ile güncelleme sıklığı arasındaki dengeler için ağ iletişimi rehberimize bakın.

Mobil işleme kısıtları. Mobil GPU'lar, masaüstü GPU'larının 1/5'i ile 1/10'u arasında işlem kapasitesine, yaklaşık 1 GB bellek sınırına (masaüstünde 2-4 GB) sahiptir ve sürekli yük altında termal kısıtlamaya girer. Mobil kalite profili; segment yoğunluğunu, nesne sayısını, işleme çözünürlüğünü, görüş mesafesini ve gölge kalitesini azaltır. Amaç masaüstüyle eşitlik değil, okunabilirliği ve tepki hızını korumaktır. Gerçek GPU karşılaştırmaları için tarayıcı 3D performans verilerine bakın.

12 bölümün 3. bölümü.
Önceki: Bölüm 2 - Worker fiziği ve girdi gecikmesi korkusu
Sonraki: Bölüm 4 - Gösterişli araziden önce akış
Seri rehberi: /tr/blog/2026-02-25-open-world-browser-series-guide

Cinevva CTO'su ve Kurucu Ortağı Oleg Sidorkin tarafından

Burada yeni misiniz? Seri rehberine göz atın. Rehber, spike'ın ne olduğunu açıklıyor ve tüm bölümlere bağlantı veriyor.

Akış, "iyi görünüyor" denilen projelerin genellikle dağıldığı noktadır.

Durağan bir karede pek çok şeyi gizleyebilirsiniz. Bir parça sınırını geçerken oluşan 40 ms'lik takılmayı gizleyemezsiniz.

Gelişmiş arazi temsilini oluşturmadan önce akışı özellikle test ettik. Bu, yükleme ve kaldırma davranışları hakkında net veriler elde etmemizi sağladı.

Spike 6, basit parça içerikleriyle komşuluk değişimini doğruladı.

Spike 6'yı yeni sekmede aç ↗ · Kaynak kodunu görüntüle

Ardından Spike 11'de gerçek arazi yaklaşımına geçtik: worker tarafında kod çözme ve 17'den 33'e, ardından 65 örnekli ızgaralara uzanan aşamalı iyileştirmeyle yükseklik parçalarının akışı.

Spike 11'i yeni sekmede aç ↗ · Kaynak kodunu görüntüle

Sıralama, beklediğimizden daha önemliydi. Doğrudan sıkıştırılmış yükseklik parçalarıyla başlasaydık her takılmanın nedeni belirsiz kalacaktı. Kod çözme sorunu mu, doku yükleme sorunu mu, yoksa geometri güncelleme sorunu mu? Spike 6, Spike 11 karmaşıklık eklemeden önce bir belirsizlik katmanını ortadan kaldırdı.

Bu bölümden çıkardığımız pratik bir ders, sonraki spike'lara da taşındı. Yükleme kaynaklı duraklamalar, ortalama FPS'den çıkarım yapmak yerine doğrudan ölçülmelidir. Ortalama FPS, kare süresi sıçramalarını gizler; kullanıcıların gerçekten hissettiği şey de bu sıçramalardır.

5. bölümde bitki örtüsü, arazi gölgelendiricileri ve kademeli gölgelerin aynı kare bütçesi için yarıştığı görsel maliyet konusuna geçiyoruz.

Bu bölümde değinilen teknolojiler

Parça tabanlı akış. Dünya, bağımsız parçalardan oluşan bir ızgaraya bölünür (genellikle 64x64 metre). Oyuncu hareket ettikçe arkada kalan kenardaki parçalar kaldırılırken öndeki kenardaki parçalar akışla yüklenir. Skyrim'in hücre sistemi bu şekilde çalışır: Oyuncunun etrafında 5x5'lik bir hücre ızgarası yüklenir ve oyuncu hareket ettikçe hücreler değiştirilir. Tarayıcı sürümü bu denkleme ağ gecikmesini de eklediğinden, oyuncunun hızına dayalı öngörülü önceden getirme kritik önem taşır. Akış mimarisi rehberimize bakın.

Aşamalı yükseklik haritası iyileştirmesi. Araziyi önce düşük çözünürlükte gönderin, ardından iyileştirin. Izgara boyutları keyfî değildir: Her seviye bir $(2^k+1)\times (2^k+1)$ ızgarasıdır; dolayısıyla $17=2^4+1$, $33=2^5+1$, $65=2^6+1$. $+1$, komşuların hizalanması için her sınırda ortak bir örnek bulunmasını sağlar ve her adımda örnek sayısı yaklaşık dört katına çıkar (kenar uzunluğu iki katına çıktıkça $n^2$ büyür). 17x17'lik bir ızgara (4 m aralıklı 64 m'lik bir parça için gereken minimum boyut), sıkıştırılmış hâlde yaklaşık 200 bayttır ve anında görünür bir yüzey oluşturur. Ardından 33x33 iyileştirmeyi, sonrasında da tam 65x65 çözünürlüğü akışla yükleyin. Her seviye, önceki verilerin yerini almadan yeni örnekler ekler. Bu yaklaşım, uzaktaki arazinin düşük çözünürlüklü, yakındaki arazinin ise tam çözünürlüklü veriler kullandığı geometri clipmap LOD halkalarıyla doğrudan eşleşir. Aşamalı parça yüklemeye bakın.

Delta kodlama ve sıkıştırma. Komşu hücrelerin değerleri birbirine benzediği için yükseklik haritası verileri iyi sıkıştırılır. Delta kodlama, her hücrenin tahmin edilen değeriyle (komşularının ortalamasıyla) arasındaki farkı saklayarak değerleri sıfırın yakınında kümeler. Zlib veya brotli ile birlikte kullanıldığında 65x65'lik bir parça, ham hâlde 8,4 KB'den sıkıştırılmış hâlde 1-2 KB'ye düşer. Uzaktaki parçalar için azaltılmış hassasiyette (16 bit yerine 8 bit): 0,5-1 KB. Arazi verisi sıkıştırmaya bakın.

Öngörülü önceden getirme. Parçaları oyuncu ulaşmadan önce yüklemektir. Önden yükleme mesafesi, bir parça yüklenirken oyuncunun katettiği mesafeyi karşılamalıdır: $d_{\text{prefetch}}=v\cdot t_{\text{load}}$. Bu nedenle hıza göre ölçeklenir: Yürüme hızında (5 km/sa) 2 parça önden (128 m), koşma hızında (15 km/sa) ise 4 parça önden getirilir. Yükleme halkası, hız vektörünün yönüne göre kayar. Bir öncelik kuyruğu, bekleyen istekleri aciliyetlerine göre sıralar ve oyuncunun uzaklaştığı parçalara yönelik istekleri iptal eder. Öngörülü önceden getirmeye bakın.

12 bölümden 4.'sü.
Önceki: Bölüm 3 - Bizi kurtaran gösterişsiz spike'lar
Sonraki: Bölüm 5 - Görsel güzelliklerin bütçelenmesi
Seri rehberi: /tr/blog/2026-02-25-open-world-browser-series-guide

Oleg Sidorkin, Cinevva CTO'su ve Kurucu Ortağı

Burada yeni misiniz? Seri rehberine göz atın. Bu rehber, spike'ın ne olduğunu açıklıyor ve tüm bölümlere bağlantı veriyor.

Bu bölümde görsel iddialar matematikle yüzleşti.

Bir arada elde edilen sonuçları teşhis etmek zor olduğundan, render maliyetini ayrı spike'lara böldük. Her şeyi aynı anda açarsanız yalnızca karenin yavaş olduğunu öğrenirsiniz. Bütçeyi hangi özelliğin tükettiğini öğrenemezsiniz.

Spike 7, bitki örtüsü yoğunluğunu ve animasyon maliyetini hedefliyordu. Yaklaşımımız, her arazi parçası için 32x32 yoğunluk haritalarından çalışma zamanında dağıtım yaparak büyük InstancedMesh kümelerini beslemekti. Her çimen sapına ve çalı kümesine, kayan bir gürültü dokusuyla yönlendirilen vertex shader tabanlı rüzgâr animasyonu uygulandı. İzlediğimiz temel ölçüt üçgen sayısı değil, orta seviye GPU'lardaki draw call ek yükü ve vertex işleme kapasitesiydi. Örnekleri daha az sayıda mesh içinde toplamanın, çimen sapı başına poligon sayısını azaltmaktan daha önemli olduğunu gördük.

Spike 7'yi yeni sekmede aç ↗ · Kaynağı görüntüle

Spike 8, arazi malzemelerinin karmaşıklığını artırdı. Eğim açısına ve rakıma göre ağırlıklandırılan çok katmanlı harmanlama, uçurum yüzeyleri için isteğe bağlı triplanar projeksiyon ve katman başına normal haritaları kullandık. Shader, dört doku katmanıyla eğim tabanlı splatting yapıyordu ve her katman için bir diffuse ve bir normal örneği gerekiyordu. Bu da herhangi bir aydınlatma eklenmeden önce fragment başına $4\times 2=8$ doku okuması demekti. Sayı, katmanlarla doğrusal olarak arttığından beşinci katman her piksel için 10 okuma anlamına geliyordu. Alt sınırı belirlemek için özellikle tümleşik Intel GPU'larda profil çıkardık. Sonuç olarak, dikey yüzeylerde triplanar projeksiyonun maliyetine değdiğini, ancak beşinci bir splat katmanı eklemenin değmediğini gördük.

Spike 8'i yeni sekmede aç ↗ · Kaynağı görüntüle

Spike 9, gerçekçi arazi ve nesne yükü altında kademeli gölge haritası maliyetine odaklandı. Üç kademeli CSM temel yapılandırmamızdı. Kademe baskısının en kötü olduğu durum bu olduğundan, özellikle alçak açılı güneş konumlarıyla test yaptık. En uzak kademe, görüş hacminin çok büyük bir bölümünü kapsar ve gölge ayrıntısı texel yoğunluğuyla belirlenir: $\rho \approx \frac{R^2}{A}$ ($A$ büyüklüğündeki zemin alanına yayılan, $R$ çözünürlüklü bir gölge haritası). Tüm görüş mesafesini tek bir haritayla kaplamak $A$ değerini devasa hâle getirir ve $\rho$ çöker. Kademeler, görüş hacmini bölerek bu sorunu çözer; böylece her bölüm, küçük bir $A$ alanı üzerinde kendi $R\times R$ haritasına sahip olur ve $\rho$ yakından uzağa yaklaşık olarak sabit kalır. Önce iki ve dört kademe arasındaki, ardından 1024 ve 2048 gölge haritası çözünürlüğü arasındaki GPU süresi farkını ölçtük. Sonuç olarak 1024 çözünürlükte üç kademe, hedef donanımımızda 2 ms GPU süresini aşmadan kameraya yakın bölgelerde kabul edilebilir temas gölgeleri sağladı.

Spike 9'u yeni sekmede aç ↗ · Kaynağı görüntüle

Bu aşamanın zor kısmı ürün disiplinini korumaktı. Bazı efektler mükemmel görünse de görsel etkilerine kıyasla kare bütçesinin çok büyük bölümünü tükettikleri için sınırlandırılmaları gerekiyordu.

Kuralımız basitti. Bir özellik, ancak maliyetini ölçülmüş kare süresi verileriyle açıklayabiliyorsa ilerler.

Kulağa bariz geliyor. Ancak herkesin bir sonraki görsel kazanım için heyecanlandığı hızlı prototipleme döngülerinde bu yaklaşım yaygın değil. Bu kuralı en baştan uygulamak, daha sonra clipmap'ler ve hacimsel bölgelerle ilgili mimari kararları çok daha anlaşılır hâle getirdi; çünkü aynı 16 ms için yarışan her özelliğin ayrı ayrı maliyetini zaten biliyorduk.

6. bölümde, geometry clipmap'lerle birlikte ilk büyük arazi mimarisi değişikliğine gidiyoruz.

Bu bölümde değinilen teknolojiler

InstancedMesh ve GPU bitki örtüsü. Three.js'in InstancedMesh sınıfı, aynı geometrinin N kopyasını tek bir draw call ile render eder. Bitki örtüsü için bir yoğunluk haritası (parça başına 32x32), çimen saplarının ve çalı kümelerinin çalışma zamanında dağıtılarak instance buffer'lara yerleştirilmesini sağlar. Rüzgâr animasyonu, kayan bir gürültü dokusu kullanılarak vertex shader içinde çalışır. Büyük ölçekte WebGPU'nun ComputeInstanceCulling özelliği, rasterleştirmeden önce ekran dışındaki ve uzaktaki örnekleri eler; IndirectBatchedMesh ise birden fazla bitki örtüsü türünü, multi-draw indirect ile çizilen tek bir buffer içinde toplar. GPU bitki örtüsü ayıklamayla ilgili arazi rehberimize bakın.

Triplanar eşleme. Standart UV eşlemeli dokular, UV koordinatları sıkıştığı için dik eğimlerde gerilir. Triplanar eşleme, dokuları üç eksenin (X, Y, Z) tamamı boyunca yansıtır ve yüzey normaline göre harmanlar. Uçurum yüzeyleri X veya Z projeksiyonunu alırken (gerilme olmaz), düz zemin Y projeksiyonunu alır. Harmanlama yumuşak ve otomatiktir; UV açılımı gerektirmez. PBR arazilerde aynı harmanlama ağırlıkları albedo, normal, pürüzlülük ve ortam örtme kanallarına uygulanır. Triplanar eşleme ayrıntılarına bakın.

Eğim ve rakım tabanlı malzeme splatting'i. Elle boyanmış splat haritaları yerine malzemeler, arazi özelliklerine göre fragment shader içinde prosedürel olarak atanır. Alçak rakımdaki düz zemine çimen, dik eğimlere kaya, yüksek rakımlara kar (yalnızca birikmeye yetecek kadar düz yüzeylerde), deniz seviyesine yakın bölgelere ise kum atanır. Geçişlerde yumuşak harmanlama için smoothstep kullanılır. Bizim uygulamamızda her arazi parçası, katman başına diffuse ve normal örnekleriyle dört doku katmanını değerlendiriyor; bu da aydınlatmadan önce fragment başına sekiz doku okumasıyla sonuçlanıyor. Eğim ve rakım tabanlı malzeme atamasına bakın.

Kademeli Gölge Haritaları (CSM). CSM, kameranın görüş hacmini 3-4 mesafe aralığına (kademeye) böler. Her kademe, mesafesine uygun bir çözünürlükte güneşin perspektifinden bir gölge haritası render eder. Yakın kademeler yüksek çözünürlüklü gölgeler (ağaçların ve binaların altındaki ayrıntılı temas gölgeleri), uzak kademeler ise daha düşük çözünürlüklü gölgeler (geniş dağ gölgeleri) alır. Arazi shader'ı tüm kademeleri örnekler ve her fragment için uygun olanı seçer. Performans maliyeti: 1024x1024 çözünürlükte 3-4 kademe, gölge haritası render'ına yaklaşık 0,5-1 ms, örneklemeye ise yaklaşık 0,2-0,3 ms ekler. Arazi gölgelerine bakın.

12 bölümün 5.'si.
Önceki: Bölüm 4 - Gösterişli araziden önce streaming
Sonraki: Bölüm 6 - Clipmap'ler gidişatı değiştirdi
Seri rehberi: /blog/2026-02-25-open-world-browser-series-guide

Yazan: Oleg Sidorkin, Cinevva CTO'su ve Kurucu Ortağı

Burada yeni misiniz? Seri rehberine göz atın. Bu rehber, spike'ın ne olduğunu açıklar ve tüm bölümlere bağlantı verir.

Spike 10'dan önce zihinsel modelimiz hâlâ "daha büyük dünya, daha fazla geometri demektir" şeklindeydi. Spike 10'dan sonra modelimiz "sabit geometri bütçesi, kamera merkezli halka güncellemeleri" hâline geldi. Bu değişim projenin gidişatını değiştirdi.

Geometri clipmap'lerinin ardındaki fikir basittir. Araziyi, kameranın merkezinde bulunduğu bir dizi eş merkezli halka olarak render edersiniz. En içteki halka en yüksek köşe yoğunluğuna sahiptir. Dışarı doğru her $k$ halkasında köşe aralığı iki katına çıkar, $s_k=s_0\cdot 2^k$; dolayısıyla kendisinden içerideki halkanın kapladığı zemin alanının $4\times$ katını kapsar.

İşin püf noktası tamamen bu iki katına çıkışta. Görüş mesafesi halka sayısıyla geometrik olarak artarken, $d_{\text{view}}\approx s_0\cdot 2^L$, köşe maliyeti yalnızca doğrusal olarak büyür:

Burada her biri $N\times N$ köşeden oluşan $L$ halka bulunur. Görebildiğiniz mesafeyi iki katına çıkarmanın maliyeti, dört kat fazla geometri değil, yalnızca bir halkadır. Dünya boyutu ne olursa olsun üçgen sayısı yaklaşık olarak sabit kalır; çünkü aynı çözünürlükteki aynı $L$ halkayı her zaman render edersiniz.

Spike 10'u yeni sekmede aç ↗ · Kaynak kodunu görüntüle

Pratikteki püf noktası, halka sınırlarında geomorphing uygulamaktı. Bir köşe bir LOD halkasından diğerine geçtiğinde yüksekliğinin, yüksek çözünürlüklü ve düşük çözünürlüklü örnekler arasında yumuşak biçimde harmanlanması gerekir. Aksi takdirde kamera her hareket ettiğinde ve halkalar kaydığında gözle görülür sıçramalar oluşur. Bunu, köşenin halka kenarına olan uzaklığına dayalı bir harmanlama faktörüyle ve yüksekliği vertex shader'da interpolasyon yaparak çözdük:

Burada $d$, köşenin kameraya olan uzaklığıdır. Halkanın içinde ($d\le d_{\text{near}}$) köşe tam çözünürlüklü yüksekliğini kullanır; bir sonraki halkaya ulaştığında ($d\ge d_{\text{far}}$), o halkanın kullanacağı kaba yüksekliğe zaten geçmiş olur. Dolayısıyla sıçrayacak hiçbir şey kalmaz.

Kamera hareketi testlerinden incelikli bir ders çıkardık. Clipmap'leri statik ekran görüntüleri üzerinden değerlendirip geçiş bozulmalarını gözden kaçırmak kolaydır. Halka sınırları boyunca sabit hızla ilerleyen geçişleri uzun süre çalıştırıp zamansal gürültüyü gözlemledik. Ekran görüntüleri yalan söyledi. Hareket gerçeği gösterdi.

Bu spike bize aynı zamanda net bir mimari sınır kazandırdı. Yakın alan arazisi; hacimsel düzenleme, daha yüksek malzeme karmaşıklığı ve fizik etkileşimiyle zaman içinde dinamik ve maliyetli hâle gelebilirdi. Uzak alan arazisi ise kararlı, öngörülebilir ve düşük maliyetli kalabilirdi. Bu ayrım, bu noktadan sonraki tüm mimari kararların omurgasını oluşturdu.

Kendi projeniz için clipmap'leri değerlendiriyorsanız güzel görüntüleri değil, stres döngülerini test edin. Gerçek sorunları ortaya çıkaran şeyler; uzun geçiş rotaları, değişen kamera yüksekliği ve sınırların tekrar tekrar aşılmasıdır.

7. bölümde hacimsel mesh oluşturmayı ekliyor ve "yüzey olarak arazi" yaklaşımından "düzenlenebilir hacim olarak arazi" yaklaşımına geçiyoruz. Projenin bir renderer olmaktan çıkıp dünya editörüne dönüşmeye başladığı nokta buydu.

Bu bölümde değinilen teknolojiler

Geometri clipmap'leri. Losasso ve Hoppe tarafından SIGGRAPH 2004'te tanıtılan (makale) geometri clipmap'leri, araziyi kameranın merkezinde bulunduğu eş merkezli kare halkalar olarak render eder. Her halka, bir öncekinin yarısı kadar köşe çözünürlüğüyle iki kat alan kaplar. Toplam köşe sayısı sabittir: yaklaşık $N^2\cdot L$. $N=256$ ve $L=8$ seviye için bu, dünya boyutundan bağımsız olarak ${256}^2\times 8\approx \mathrm{524,000}$ köşe demektir. Kamera hareket ettikçe CPU, her halkanın heightmap verilerini günceller. Vertex shader, yüksekliği bir dokudan okur ve düz ızgarayı yerinden oynatır. Geometri clipmap'leri hakkındaki arazi rehberimize ve GPU Gems 2, Bölüm 2'ye bakabilirsiniz.

Geomorphing. Arazi LOD'undaki en belirgin görsel bozulma sıçramadır: Bir parça LOD seviyesini değiştirdiğinde köşeler bir anda yer değiştirir. Geomorphing, bir geçiş bölgesi boyunca köşe konumlarını LOD seviyeleri arasında harmanlayarak bunu ortadan kaldırır. Her köşe hem mevcut LOD yüksekliğini hem de daha kaba LOD yüksekliğini saklar. Kamera mesafesine dayalı bir morph faktörü, ikisi arasında yumuşak bir interpolasyon yapar: morphedHeight = mix(fineLodHeight, coarseLodHeight, smoothstep(lodNear, lodFar, distance)). Geçiş bölgesi genellikle her halkanın dıştaki %20'lik kısmıdır. Normal kamera hızlarında geçiş fark edilmez. Geomorphing ayrıntılarına bakabilirsiniz.

CDLOD (Quadtree Uyarlamalı Clipmap'ler). Strugar'ın sabit halkalı clipmap'ler üzerinde yaptığı bir iyileştirmedir (2014, makale). CDLOD, tekdüze çözünürlüğe sahip eş merkezli halkalar yerine arazi karmaşıklığına uyarlanan bir quadtree kullanır. Düz alanlarda kaba düğümler kullanılırken, yüksek ayrıntıya sahip alanlar (uçurumlar, sırtlar) daha ince alt bölümlere ayrılır. Farklı chunk'ların çok farklı karmaşıklık düzeylerine sahip olduğu üretici dünyaları için bu önemlidir. Arazi rehberimizdeki CDLOD bölümüne bakabilirsiniz.

12 bölümün 6.'sı.
Önceki: Bölüm 5 - Görselliğin bütçesini belirlemek
Sonraki: Bölüm 7 - Marching cubes ve ilk gerçek mağaralar
Seri rehberi: /tr/blog/2026-02-25-open-world-browser-series-guide

Yazan: Oleg Sidorkin, Cinevva CTO'su ve Kurucu Ortağı

Burada yeni misiniz? Seri rehberine göz atın. Bu rehber, spike'ın ne olduğunu açıklar ve tüm bölümlere bağlantı verir.

Yükseklik haritaları, çıkıntılara ihtiyaç duyana kadar harikadır.

Oyulmuş tüneller, havada uzanan kaya çıkıntıları veya mağara tavanları istediğiniz anda, yalnızca yükseklik alanına dayanan bir işlem hattı sizi kısıtlamaya başlar. Bir yükseklik haritası, her XZ koordinatı için tek bir Y değeri saklar. Kendi üzerine kıvrılan herhangi bir yüzeyi temsil etmesi fiziksel olarak mümkün değildir. Hacimsel bir temsile ihtiyacımız vardı.

Spike 12, WebGPU compute shader'larını kullanarak GPU üzerinde marching cubes uyguladı. Algoritma, 3B bir ızgara üzerinde işaretli uzaklık alanını (SDF) değerlendirir ve sıfır geçişi yüzeyinde bir üçgen ağı çıkarır. Her hücrenin 8 köşesi vardır ve her köşe yüzeyin ya içinde ya da dışındadır; bu da $2^8=256$ olası işaret örüntüsü verir. Bir arama tablosu, her örüntüyü bir üçgen kümesiyle eşler. Köşe noktaları, alanın sıfırı kestiği noktada hücre kenarları üzerinde yer alır. Alan değerleri $f_a$ ve $f_b$ olan $a$ ve $b$ köşeleri arasındaki bir kenar için doğrusal enterpolasyon, köşe noktasını şu konuma yerleştirir:

Burada $t$, alanın sıfıra ulaştığı kenar üzerindeki oranı ifade eder. Kesişen bir kenarda $f_a$ ve $f_b$ zıt işaretlere sahip olduğundan, $t$ her zaman $[0,1]$ aralığında kalır. Bunu aynı anda dört etkin 64 küplük chunk üzerinde çalıştırdık ve kare başına yeniden mesh oluşturma ile animasyonlu SDF düzenlemelerini test ettik.

Spike 12'yi yeni bir sekmede açın ↗ · Kaynak kodunu görüntüleyin

İlk kazanım, compute işlem hattının kendisine duyduğumuz güvendi. Tek bir dispatch çağrısı; CPU'ya hiçbir veri geri okumadan SDF'yi değerlendirebiliyor, hücreleri sınıflandırabiliyor ve köşe noktalarını bir GPU tamponuna yazabiliyordu. İkinci kazanım ise “çalışıyor” aşamasından görsel bozulma avına ne kadar hızlı geçildiğini keşfetmekti. Eksik üçgenler nadiren marching cubes kuramıyla ilgili bir sorundan kaynaklanıyordu. Genellikle tablo indeksi uyuşmazlıkları, etkin köşe noktası sayısının ötesini okuyan hatalı çizim aralıkları veya komşu SDF örneklerinin bulunmadığı chunk sınırlarına yakın uç durum etkileşimleriydi.

Bu spike, bizi bölgeler hâlinde düşünmeye zorladı. Kameranın yakınında, oyuncuların araziyi oyabilmesi, kazabilmesi ve mağaraları görebilmesi için hacimsel özgürlük istersiniz. Kameradan uzakta ise düz bir yükseklik haritasının daha ucuz ve tamamen yeterli olduğu clipmap verimliliğini istersiniz. Bu ikilik, Spike 13'ten itibaren geliştirmeyi sürdürdüğümüz mimarinin omurgası hâline geldi.

En sevdiğim hata ayıklama anlarından biri, düzenlemeler çalışırken tel kafes görünümünü açıp kapatmaktı. Topolojinin gerçek zamanlı olarak oluşup çözülmesini izlemek, kalite ödünlerini anında görünür kılıyordu. Köşe noktası yoğunluğunun nerede yeterli olduğunu, nerede fazla seyrekleştiğini ve LOD geçişlerinde çatlakları önlemek için tam olarak nerede Transvoxel desteğine ihtiyaç duyulacağını görebiliyordunuz.

8. bölümde entegrasyon zorluğunu ele alıyoruz. Ham, compute güdümlü mesh'leri ve Three.js sahne grafiği mantığını tek ve kararlı bir render işlem hattında bir arada tutmak, bağımsız demonun düşündürdüğünden daha zordu.

Bu bölümde değinilen teknolojiler

Marching cubes. 3B bir skaler alandan üçgen ağı çıkarmaya yarayan bir algoritmadır (Lorensen ve Cline, 1987). Düzenli bir 3B ızgaradaki her hücre, alanın 8 köşesinde örneklenmesiyle sınıflandırılır. İşaret örüntüsü bir durum indeksi (0-255) üretir ve bir arama tablosu her durumu bir üçgen kümesiyle eşler. Köşe noktaları, iki köşe arasında enterpolasyon yapılarak ızgara kenarlarına yerleştirilir. Her hücre bağımsız olarak işlendiğinden algoritma son derece paraleldir ve bu da onu GPU hesaplamaları için ideal kılar. SDF'ler ve marching cubes hakkındaki arazi rehberimize göz atın.

İşaretli Uzaklık Alanları (SDF'ler). 3B uzaydaki her noktada en yakın yüzeye olan işaretli uzaklığı saklayan hacimsel bir temsildir. Pozitif değerler dışarıyı, negatif değerler içeriyi belirtir; sıfır geçişi ise yüzeyi oluşturur. SDF'ler, yükseklik haritalarının ifade edemediği mağaralar, kemerler, çıkıntılar ve havada duran geometriler gibi herhangi bir 3B şekli temsil edebilir. Düzenleme, alan üzerinde doğal küme cebiriyle yapılır. Malzeme ekleme (iki şeklin birleşimi) $d=min(d_1,d_2)$, çıkarma (kazma) işlemi oyma şeklinin işareti ters çevrilerek $d=max(d_1,-d_2)$ biçimindedir; yumuşak bir harmanlama ise aşağıdaki gibi bir yumuşak minimum kullanır:

Burada $k$, harmanlama yarıçapını kontrol eder. $k\to 0$ olduğunda bu ifade yeniden katı bir $min$ işlemine dönüşür. SDF arazi temsiline göz atın.

WebGPU compute shader'ları. Rasterleştirme işlem hattına bağlı olmadan genel amaçlı hesaplama yapan GPU programlarıdır. Bir compute shader, paralel olarak çalışan iş parçacığı çalışma gruplarını yürütür. Marching cubes için her iş parçacığı tek bir ızgara hücresini işler: SDF'yi örnekler, hücreyi sınıflandırır, üçgenleştirmeyi arama tablosundan bulur, kenar köşe noktalarını enterpole eder ve atomik sayaçlar kullanarak bunları bir mesh tamponuna ekler. Çıktı tamponu render için doğrudan köşe noktası verisi olarak kullanıldığından CPU'ya veri geri okumak gerekmez. Will Usher'ın webgpu-marching-cubes projesi, tarayıcıda gerçek zamanlı 256^3 ızgara işlemeyi gösterir. WebGPU güdümlü LOD hakkındaki arazi rehberimize göz atın.

Hibrit yükseklik haritası + SDF mimarisi. Tarayıcı tabanlı araziler için pratik yaklaşım şudur: yükseklik haritaları tüm dünyayı kaplarken (ucuz ve kompakt), SDF hacimleri yalnızca mağaralara, çıkıntılara veya içerik üreticilerinin oyduğu özelliklere ihtiyaç duyan chunk'larda (chunk'ların %5-10'u) bulunur. Kameranın yakınında hacimsel özgürlük, oyma işlemlerine ve mağaralara olanak tanır. Uzakta ise yükseklik haritaları, düz araziyi verimli biçimde sağlar. Hibrit arazi temsiline göz atın.

12 bölümün 7.'si.
Önceki: Bölüm 6 - Clipmap'ler gidişatı değiştirdi
Sonraki: Bölüm 8 - Temel çizgimizi kaybetmeden entegrasyon
Seri rehberi: /blog/2026-02-25-open-world-browser-series-guide

Yazan: Oleg Sidorkin, Cinevva CTO'su ve Kurucu Ortağı

Burada yeni misiniz? Seri rehberine göz atın. Rehber, denemenin ne olduğunu açıklıyor ve tüm bölümlere bağlantılar sunuyor.

Entegrasyon, projelerin karmaşık hâle geldiği aşamadır. Tek başına çalışan parçalarınız vardır. Bunları birbirine bağladığınızda birdenbire her hata, kaynağı her yerde olabilecekmiş gibi görünür.

13. ve 14. denemeler, bu tuzağa verdiğimiz yanıttı. 13. denemede temiz bir Three.js WebGPU temel yapısı oluşturduk. Yalnızca bir işleyici, bir sahne, bir kamera ve basit bir ağ model vardı. Arazi, hesaplama veya efekt yoktu. Three.js'in WebGPU arka ucunun doğru şekilde başlatıldığını, işleme döngüsünün kararlı olduğunu ve TSL (Three.js Shading Language) düğüm malzemelerinin beklendiği gibi çalıştığını doğruladık. Ancak bu kontrol noktasını geçtikten sonra katman eklemeye başladık.

13. denemeyi yeni sekmede aç ↗ · Kaynak kodunu görüntüle

14. deneme, aşamalı sağlamlaştırma süreciydi. Her seferinde tek bir yetenek ekledik: önce kamera kontrollerini, ardından aydınlatmayı, sonra marching cubes işlem hattında hesaplamayla üretilen ağ modeli ve son olarak GPU çıktısını doğrudan Three.js geometri niteliklerine aktaran tampon bağlantılarını. Her eklemenin ardından önceki katmanın hâlâ doğru davrandığını doğruladık.

14. denemeyi yeni sekmede aç ↗ · Kaynak kodunu görüntüle

Kulağa yavaş geliyor. Tam olarak bir gün boyunca yavaştı ve kısa süre sonra dikiş mantığı ile politika değiştirme karmaşıklaştığında bize birkaç gün kazandırdı.

Bu disiplini haklı çıkaran belirli hata kategorisi, kıl inceliğindeki bozulmalardı. Geometri bozulması gibi görünen ama aslında güncelliğini yitirmiş verilerden kaynaklanan ince parçacıklar. Hesaplama gölgelendiricisi bir tampona N köşe yazıyor, ancak çizim çağrısı hâlâ önceki kareden kalan N+M köşeyi işleyecek şekilde yapılandırılmış oluyordu. Bu fazladan köşeler, eski gönderimden kalan anlamsız veriler içeriyordu. Görsel sonuç, öngörülemez biçimde belirip kaybolan, titreşen ve jilet inceliğinde üçgenlerdi.

Bu tür bir hatayı sezgiyle yenemezsiniz. Son çalışan durum ile mevcut bozuk durum arasında tam olarak neyin değiştiğini bildiğiniz kontrollü farklarla yenebilirsiniz.

WebGPU entegrasyonu bize tampon yaşam döngüsü hakkında da çok şey öğretti. WebGPU'daki GPU tamponları, belirli bir kullanım için eşlendikten sonra değiştirilemez. Marching cubes çıktısı büyüdüğü için bir köşe tamponunu yeniden boyutlandırmanız gerekiyorsa yeni bir tampon oluşturmalı ve bağlamayı güncellemelisiniz. realloc yoktur. Bu yaşam döngüsünü doğru yönetmek ve eski tamponları yürütülmekte olan GPU işleriyle yarışa girmeden yok etmek, WebGL'de bulunmayan açık bariyer yönetimini gerektiriyordu.

9. bölümde Transvoxel dikiş çalışmalarına geçiyoruz. Bu bölüm bilinçli olarak bir iskeletle başlıyor. Bu noktaya geldiğimizde, entegrasyonu aceleye getirmenin gizemli sorunlar; kontrollü kurulumun ise hata ayıklanabilir problemler ürettiği dersini tamamen benimsemiştik.

Bu bölümde değinilen teknolojiler

WebGPU. WebGL'in halefi olan ve hesaplama gölgelendiricileri ile dolaylı işleme aracılığıyla tarayıcıda düşük seviyeli GPU erişimi sağlayan teknoloji. WebGPU'nun açık dünyalar açısından kritik iki özelliği şunlardır: hesaplama gölgelendiricileri, arazi üretiminin, bitki örtüsü yerleştirmenin ve ayıklamanın GPU tarafında yapılmasını sağlar; dolaylı işleme ise GPU'nun hesaplama çıktısına göre neyi çizeceğine karar vermesine olanak tanıyarak yoğun sahnelerdeki CPU darboğazlarını ortadan kaldırır. Masaüstünde Chrome, Edge ve Firefox'ta kullanılabilir. Bkz. Performans kilidini açan WebGPU.

Three.js Shading Language (TSL). Ham GLSL/WGSL'nin yerine birleştirilebilir JavaScript ifadeleri kullanan, Three.js'in düğüm tabanlı gölgelendirici sistemi. texture(), positionWorld, smoothstep() ve fog() gibi TSL düğümleri, çalışma zamanında uygun arka uç için (WebGL GLSL veya WebGPU WGSL) derlenen bir gölgelendirici grafiği oluşturur. TSL, malzeme mantığını bir kez yazıp her iki işleyiciyi de hedeflemeyi mümkün kılar. Düğüm grafiği her karede değerlendirilir; dolayısıyla dinamik uniform değişkenler ve koşullu dallanma doğal biçimde çalışır.

WebGPU'da GPU tamponu yaşam döngüsü. WebGPU tamponları belirli kullanım bayraklarıyla (VERTEX, STORAGE, COPY_DST vb.) oluşturulur ve oluşturulduktan sonra yeniden boyutlandırılamaz. Bir marching cubes gönderimi tamponun kapasitesinden daha fazla köşe üretirse yeni bir tampon oluşturmanız, bağlamayı güncellemeniz ve eskisini yok etmeniz gerekir. Yürütülmekte olan bir GPU komutunun hâlâ başvurduğu tamponu yok etmek hatalara neden olur. Açık bariyer yönetimi (device.queue.onSubmittedWorkDone() aracılığıyla), eski tamponun GPU tarafından kullanımı tamamlanmadan yok edilmemesini sağlar. Sürücünün belleği örtük olarak yönettiği WebGL'de böyle bir yaşam döngüsü disiplini yoktur.

Aşamalı sağlamlaştırma. Entegrasyona yönelik bir süreç disiplini: çalıştığı bilinen bir temel yapı oluşturun, her seferinde tek bir yetenek ekleyin ve her eklemeden sonra önceki katmanın hâlâ çalıştığını doğrulayın. Bu yaklaşım bir günlüğüne daha yavaştır, ancak sonraki hata ayıklama çalışmalarında günler kazandırır; çünkü her gerileme belirli ve kontrollü bir değişikliğe kadar izlenebilir. Önce temel yapı, ardından aşamalı ekleme yaklaşımı; riski yönetmek amacıyla sistemlerin belirli bir sırayla entegre edildiği AAA açık dünya geliştirme süreçlerinde yaygındır.

12 bölümün 8. bölümü.
Önceki: Bölüm 7 - Marching cubes ve ilk gerçek mağaralar
Sonraki: Bölüm 9 - Transvoxel bir iskeletle başladı
Seri rehberi: /blog/2026-02-25-open-world-browser-series-guide

Cinevva CTO'su ve Kurucu Ortağı Oleg Sidorkin tarafından

Burada yeni misiniz? Seri rehberine göz atın. Bu rehber, spike'ın ne olduğunu açıklıyor ve tüm bölümlere bağlantı veriyor.

Dikişler, güvenin ölüp gittiği yerlerdir.

İki farklı çözünürlük buluşana kadar her şey kararlı görünebilir. LOD 0 seviyesindeki bir chunk, LOD 1 seviyesindeki bir chunk'ın yanında durur. Mesh'leri birbirinden bağımsız olarak oluşturulur. Ortak sınırlarında, düşük çözünürlüklü chunk'ın grid yoğunluğu yarı yarıya olduğu için vertex konumları eşleşmez. Sonuçta görünür çatlaklar, T-bağlantıları ve titreyen kenarlar ortaya çıkar.

Transvoxel algoritması, farklı çözünürlüklerdeki iki chunk arasındaki sınır yüzü boyunca özel geçiş hücreleri oluşturarak bu sorunu çözer. Bu hücreler aynı anda hem yüksek hem de düşük çözünürlüklü grid'lerden örnek alır ve iki yüzeyi birbirine diken üçgenler üretir. Algoritma, standart marching cubes tablolarından ayrı kendi lookup tablolarını kullanır ve 512 geçiş hücresi vakası içerir.

Bu noktaya kadar yeterince entegrasyon yarası aldığımızdan, uygulamaya aceleyle girişmememiz gerektiğini biliyorduk.

Spike 15'in tek bir görevi vardı: algoritmanın tamamına dokunmadan önce güvenebileceğimiz bir dikiş test düzeneği kurmak. Bilinen SDF verilerine sahip, farklı çözünürlüklerdeki iki chunk'ın yan yana durduğu kontrollü bir ortam hazırladık. Ana mesh'i, dikiş mesh'ini, wireframe'i ve normalleri birbirinden bağımsız olarak açıp kapatmamızı sağlayan görselleştirme kontrolleri ekledik.

Spike 15'i yeni sekmede aç ↗ · Kaynak kodunu görüntüle

Test düzeneği kararlı hâle geldikten sonra Spike 16, tablo güdümlü geçiş hücresi üretimini tek bir yüz üzerinde doğruladı. Eksenlere hizalı tek bir yüzü (+X sınırı) seçtik, geçiş hücresi değerlendirmesini yalnızca bu yüz için uyguladık ve çıktıyı Transvoxel makalesindeki referans verilerle karşılaştırdık.

Spike 16'yı yeni sekmede aç ↗ · Kaynak kodunu görüntüle

Her seferinde tek bir yüzü özellikle test ettik, çünkü geçiş tablolarının bağlanmasında birbirinden bağımsız pek çok hata türü bulunur. Vaka indeksinin hesaplanması, her iki grid'den de doğru vertex'lerin örneklenmesine bağlıdır. Geçiş hücresi içindeki vertex indeksleme, standart marching cubes hücrelerinden farklı bir numaralandırma düzeni kullanır. Sarım sırası ana mesh ile tutarlı olmalıdır; aksi takdirde arka yüz ayıklama, dikiş üçgenlerinizi yok eder. Altı yüzün tamamını aynı anda test ederseniz her belirti rastgele görünür. Tek bir yüzü kapsamlı biçimde test ederseniz anlamlı ve hata ayıklanabilir sorunlar elde edersiniz.

Bu aşamada elde ettiğimiz daha incelikli bir başka kazanım da araçlara yaptığımız yatırımdı. Görünürlük anahtarlarını, yalnızca dikişi gösteren render modunu ve renk kodlu LOD göstergelerini erkenden geliştirdik. O sırada bu kontroller gereksiz yük gibi gelmişti. Daha sonra köşe vakaları çirkinleştiğinde, tam olarak hangi dikiş hücrelerinin hatalı davrandığını izole edebilmemizi sağlayarak kendilerini defalarca amorti ettiler.

Bu bölümün sonunda “dikişleri tamamlamış” değildik. Ancak dikiş hatalarından korkmak yerine onlar hakkında akıl yürütebileceğimiz bir noktaya gelmiştik.

10. bölümde asıl hız treni başlıyor. Karma LOD köşeleri, tersine dönen sarım yönleri, kısmi fazla çizim hayaletleri ve algoritmanın hatalı olduğundan emin olduğunuz hâlde hatanın aslında etkin vertex sayısının ötesini okuyan bir çizim aralığından kaynaklandığını keşfettiğiniz o anlar.

Bu bölümde değinilen teknolojiler

Transvoxel algoritması. Eric Lengyel tarafından tasarlanan (transvoxel.org) Transvoxel, hacimsel arazi LOD'undaki en zor sorunu çözer: farklı çözünürlüklerdeki chunk'lar arasındaki dikişler. Yüksek çözünürlüklü bir chunk, düşük çözünürlüklü bir chunk'ın yanında yer aldığında marching cubes mesh'leri sınırda hizalanmaz ve görünür çatlaklar oluşturur. Transvoxel, sınır yüzleri boyunca her iki tarafla da eşleşen ek üçgenlerle çözünürlük farkını kapatan özel geçiş hücreleri ekler. Algoritma, 73 eşdeğerlik sınıfına indirgenen 512 geçiş hücresi vakası için standart marching cubes tablolarından ayrı kendi lookup tablolarını kullanır. Patent kısıtlaması yoktur ve yayımlanmış oyunlarda (Space Engineers, Astroneer) kullanılmıştır. Transvoxel hakkındaki arazi rehberimize bakın.

Geçiş hücreleri. İki LOD seviyesi arasındaki yüzde oluşturulan özel hücrelerdir. Tek bir grid'den 8 köşe örnekleyen standart marching cubes hücrelerinin aksine geçiş hücreleri, yüksek ve düşük çözünürlüklü grid'lerin ikisinden de aynı anda örnek alır. Yüksek çözünürlüklü yüzde $3\times 3=9$ örnek noktası, düşük çözünürlüklü yüzde ise $2\times 2=4$ örnek noktası bulunur. Bu 9 örnek, algoritmaya $2^9=512$ ham vaka kazandırır; rotasyonlar ve yansımalar elendiğinde bunlar 73 farklı üçgenlemeye indirgenir. Hücre sınıflandırması ve üçgenleme, her iki çözünürlükteki vertex'leri birbirine bağlayan üçgenler üreten özel tablolar kullanır. Vertex numaralandırma düzeni standart MC hücrelerinden farklıdır ve bu, yaygın bir uygulama hatası kaynağıdır.

LOD geçiş dikişleri. Topoloji uyuşmazlığının görsel bozukluklara yol açtığı, iki mesh çözünürlüğü arasındaki sınırdır. Dikiş uygulanmadığında, LOD 1 seviyesindeki bir chunk'ın (2 m grid) yanındaki LOD 0 seviyesinde bir chunk (1 m grid) T-bağlantıları üretir: ince mesh'in sınır boyunca kaba mesh tarafından paylaşılmayan vertex'leri vardır ve bu da ışığın sızdığı çatlaklara neden olur. Transvoxel, geomorphing ve etek geometrisi bu dikişleri düzeltmeye yönelik üç yaklaşımdır. Geomorphing yalnızca yükseklik haritalarında çalıştığı için hacimsel arazide standart çözüm Transvoxel'dir. Hacimsel arazi için LOD bölümüne bakın.

12 bölümün 9. bölümü.
Önceki: Bölüm 8 - Temel sürümümüzü kaybetmeden entegrasyon
Sonraki: Bölüm 10 - Dikiş kaosu ve köşe bölüm sonu canavarı
Seri rehberi: /blog/2026-02-25-open-world-browser-series-guide

Cinevva CTO'su ve Kurucu Ortağı Oleg Sidorkin tarafından

Burada yeni misiniz? Seri rehberine göz atın. Rehber, Spike'ın ne olduğunu açıklıyor ve tüm bölümlere bağlantılar içeriyor.

Önceki bölümler yöntemli geldiyse bu bölüm tam anlamıyla bir mücadeleydi.

17'den 22'ye kadar olan Spike'lar, uç durumlar dönemimizdi. Aynı anda iki LOD kullanan marching cubes, yükseklik haritası ile MC sınırları arasındaki dikişler, üç veya dört LOD seviyesinin buluştuğu farklı çözünürlüklü köşe chunk'ları, GPU'da dikiş üretimi ve geri dönüş modu davranışları. Her Spike, karşılaştığımız veya karşılaşmayı beklediğimiz belirli bir hata senaryosunu ele aldı.

Spike 17, iki LOD seviyesi aynı anda etkinken çift LOD'lu marching cubes yaklaşımını test etti. Zorluk, tek bir chunk'ın farklı yüzlerindeki komşularının farklı çözünürlüklerde olabilmesiydi. Spike 16'daki geçiş hücresi mantığı tek seferde bir yüz için çalışıyordu ancak bir chunk birden fazla yüzünde geçiş hücrelerine ihtiyaç duyduğunda vertex buffer yönetimi karmaşıklaşıyordu. Her yüzün geçiş hücrelerinin, diğerlerinin üzerine yazılmadan üretilip buffer'a eklenmesi gerekiyordu.

Spike 19'u yeni sekmede aç ↗ · Kaynak kodunu görüntüle

Tekrar tekrar karşımıza çıkan ilk kötü karakter sarım sırasıydı. Birkaç kez topoloji sorunları yaşadığımızı düşündük ama aslında bunların yönlendirme sorunları olduğunu keşfettik. Sarım, ana mesh'e göre ters olduğu için arka yüz ayıklama geçerli dikiş üçgenlerini yok ediyordu. Kök neden aynıydı, ancak görsel belirti kamera açısına göre değişiyordu. Çözüm, geçiş hücresi üretim kodunda tutarlı bir sarım kuralını zorunlu kılmak ve bunu çift taraflı materyal geçişiyle doğrulamaktı.

İkinci kötü karakter, kısmi doğruluğun verdiği sahte güvendi. Bir dikiş belirli bir kamera açısından kusursuz görünebilir, ancak yüksek ve düşük çözünürlüklü chunk'lar arasındaki LOD rolleri değiştiğinde bozulabilirdi. Geçiş hücresi asimetriktir. Yüksek çözünürlüklü ve düşük çözünürlüklü taraflardan farklı biçimlerde örnek alır. Bir yapılandırmada “hangi taraf yüksek çözünürlüklü” mantığını ters kurarsanız hatayı yalnızca kamera belirli bir konuma geldiğinde görürsünüz.

Ardından en sevdiğimiz toparlanma anlarından biri geldi. Yükseklik haritası karolarındaki dikişin kesilmesi artefaktını araştırıyor ve geçiş mantığını suçluyorduk. Bunun için iki gün harcadık. Asıl suçlu, önceki çizimden kalan eski geometrilerdi. Chunk daha düşük bir LOD'a geçtiğinde önceki frame'deki yüksek çözünürlüklü geometri hâlâ buffer'ın son kısmında duruyordu. Çizim aralığı ise hâlâ eski ve daha yüksek vertex sayısına ayarlıydı. Çizim aralığını compute shader'ın atomik sayacının bildirdiği etkin vertex sayısıyla sınırlandırınca “gizemli dikiş sorunu” ortadan kayboldu.

Bu, render hatalarının çoğu zaman mesh üretim hataları gibi göründüğünü hatırlatan harika bir örnekti. Geometri başından beri doğruydu. Draw call yalnızca geçerli verilerin sonunu aşarak okuma yapıyordu.

Spike 22'ye geldiğimizde, chunk'ların belirli koşullar altında marching cubes'tan yükseklik haritası moduna geçebildiği hibrit geri dönüş yaklaşımını test ediyorduk. Örneğin chunk'ın hacimsel düzenleme içermemesi ve kameradan yeterince uzakta olması bu koşullar arasındaydı. Bu yaklaşım bize ya hep ya hiç politikasından daha uygulanabilir bir yol sundu. Yakın alandaki düzenlenmiş chunk'lar hacimsel özgürlük için MC kullanırken uzak alandaki düzenlenmemiş chunk'lar verimlilik için yükseklik haritalarını kullanıyordu.

Spike 22'yi yeni sekmede aç ↗ · Kaynak kodunu görüntüle

Bu bölüm, hız treninin dik düşüşü gibiydi. Aynı anda hem sinir bozucu hem de üretkendi. Tek tek düzeltmelerin çoğu küçüktü; bazen yalnızca bir karşılaştırma operatörünü veya offset'i değiştiren tek bir satırdan ibaretti. Ancak LOD geçişlerinin, buffer yönetiminin ve çizim aralıklarının nasıl etkileşime girdiğine dair kazandırdıkları anlayış hiç de küçük değildi.

11. bölümde kaosun ardından gelen kararlılık katmanını ele alıyoruz: politika tabanlı chunk modları ve tepkisel hata düzeltmeden açık sistem kurallarına geçiş.

Bu bölümde değinilen teknolojiler

Çift LOD'lu marching cubes. Marching cubes algoritmasının, sınırı birleştiren geçiş hücreleriyle birlikte iki çözünürlük seviyesinde eşzamanlı çalıştırılmasıdır. Buradaki zorluk, tek bir chunk'ın farklı yüzlerindeki komşularının farklı çözünürlüklerde olabilmesi ve bu nedenle her yüz için bağımsız geçiş hücresi üretimi gerekmesidir. Her yüzün geçiş hücreleri, diğerlerinin üzerine yazılmadan vertex buffer'a eklenir. Atomik sayaçlar, tüm yüzlerdeki toplam etkin vertex sayısını izler.

Sarım sırası. Her üçgendeki vertex sırası, hangi tarafın “ön” yüz olduğunu belirler. Arka yüz ayıklamanın çalışması için tutarlı bir sarım gerekir; dışarıdan bakıldığında bu genellikle saat yönünün tersidir. Geçiş hücreleri üçgen üretirken sarımın ana mesh'in kuralıyla eşleşmesi gerekir. Sarımın ters olması, arka yüz ayıklamanın geçerli dikiş üçgenlerini yok etmesine neden olur ve bu da belirli kamera açılarından eksik yüzeyler gibi görünür. Yaygın bir hata ayıklama tekniği, artefaktların sarım sorunundan mı yoksa gerçek topoloji boşluklarından mı kaynaklandığını doğrulamak için materyalde side: THREE.DoubleSide ayarını açıp kapatmaktır.

Yükseklik haritasından MC'ye geri dönüş. Uzaktaki veya düzenlenmemiş chunk'ların yükseklik haritası arazisini (ucuz, düz yüzey), yakındaki veya düzenlenmiş chunk'ların ise marching cubes yaklaşımını (hacimsel, mağaraları destekler) kullandığı hibrit bir chunk modudur. Geri dönüş kararı, kameraya olan mesafeye ve chunk'ın SDF düzenlemeleri içerip içermediğine bağlıdır. Bir yükseklik haritası chunk'ı ile MC chunk'ı arasındaki dikiş, kendine ait bir geçiş geometrisi gerektirir. Bu, Transvoxel'e benzer ancak iki LOD seviyesinden ziyade iki farklı gösterim arasında köprü kurar. Bkz. hibrit yükseklik haritası + hacimsel katmanlar.

Çizim aralığı ve atomik sayaçlar. GPU güdümlü mesh üretiminde compute shader, vertex'leri bir buffer'a yazar ve kaç vertex üretildiğini izlemek için atomik bir sayacı artırır. Draw call, vertex sayısı olarak buffer kapasitesini değil bu sayacı kullanmalıdır. Çizim aralığı etkin sayıyla sınırlandırılmazsa önceki frame'lerden kalan eski vertex'ler —hâlâ buffer'ın son kısmında duran veriler— hayalet geometri üretir: topoloji hataları gibi görünen ancak aslında geçerli verilerin sonunu aşan okumalardan kaynaklanan ince parçalar ve titreyen üçgenler.

12 bölümün 10. bölümü.
Önceki: Bölüm 9 - Transvoxel bir iskeletle başladı
Sonraki: Bölüm 11 - Sabit kodlanmış mod değil, politika modu
Seri rehberi: /blog/2026-02-25-open-world-browser-series-guide

Yazan: Oleg Sidorkin, Cinevva CTO'su ve Kurucu Ortağı

Burada yeni misiniz? Seri rehberine göz atın. Bu rehber, spike'ın ne olduğunu açıklıyor ve tüm bölümlere bağlantı veriyor.

Dikiş kaosu bölümünden sonra tepki vermeyi bırakıp sistemi yönetmeye başlamamız gerekiyordu.

Spike 23, geçici davranışların yerine açık politika kuralları getirdi. Chunk'lar artık yerel durumlarının önerdiği her şeyi yapmak yerine merkezi bir politika sisteminin verdiği kararlara uyuyordu. Bu chunk hangi LOD seviyesini alacak? Yükseklik haritası olarak mı yoksa marching cubes ile mi render edilecek? Geçiş hücrelerine ihtiyacı var mı, varsa hangi yüzlerde? Yanıtlar; kameraya olan mesafeyi, düzenleme geçmişini ve komşu çözünürlük durumlarını değerlendiren bir politika fonksiyonundan geliyordu.

Spike 23'ü yeni sekmede aç ↗ · Kaynak kodunu görüntüle

Mesafeye dayalı LOD ataması, clipmap kavramına benzer biçimde kamera etrafındaki eş merkezli halkaları kullanıyor, ancak bunu chunk ızgarasına uyguluyordu. Halka 0'daki chunk'lar tam çözünürlüklü MC alır. Halka 1, yarı çözünürlüklü MC alır. Halka 2 ve ötesi ise yükseklik haritası modunu kullanır. Komşuluk kısıtı kritik öneme sahipti: komşu herhangi iki chunk için $|L_i-L_j|\le 1$ koşulunu zorunlu tutuyoruz. Bir yüz boyunca çözünürlük oranı $2^{|L_i-L_j|}$ değerindedir ve Transvoxel geçiş tabloları yalnızca 2:1 durumu ($|L_i-L_j|=1$) için tanımlanmıştır. 2 seviyelik bir sıçrama, tabloların ifade edemeyeceği 4:1 oranında bir geçiş gerektirirdi. Bu nedenle politika, kısıt sağlanana kadar daha düşük ayrıntılı chunk'ı yükseltir.

HM/MC geçiş mantığı, her chunk'ın düzenleme bit eşlemini kontrol ediyordu. Bir chunk'ta herhangi bir hacimsel düzenleme (mağaralar, tüneller, arazi şekillendirmeleri) varsa mesafeden bağımsız olarak MC modunda kalıyordu. Düzenlenmemiş chunk'lar yeterince uzağa gittiklerinde yükseklik haritası moduna geçebiliyordu. Bu hibrit yaklaşım, önemli olduğu yerlerde hacimsel özgürlük, olmadığı yerlerde ise verimlilik sağladı.

Bu spike dışarıdan bakıldığında önceki bazı spike'lardan daha küçük görünüyordu. Pratikte ise geliştirme sürecinde yaşam kalitesini ciddi ölçüde artırdı.

Sisteminiz bir chunk'ın neden mod değiştirdiğini açıklayabildiğinde tahmin yürütmeye daha az zaman harcarsınız. Renk kodlu katmanlar ekledik: yükseklik haritası chunk'ları için yeşil, MC chunk'ları için mavi, geçişin etkin olduğu yüzler için turuncu. Dikiş görünürlüğüne özel render kontrolleri olduğunda görsel hata ayıklamadaki belirsizlik azalır. Çizim aralıkları, politika sisteminden gelen etkin vertex sayılarına açıkça bağlandığında eski geometri hayaletleri öğleden sonranızı boşa harcamayı bırakır.

Bu spike'ta kamera davranışını da baştan elden geçirdik. Önceki spike'larda ekran görüntüleri için yeterli, ancak hataları yeniden üretmek için kullanışsız olan basit yörünge kontrolleri bulunuyordu. Spike 23; yapılandırılabilir hıza, irtifa kilidi açma/kapama seçeneğine ve konum göstergesine sahip WASD uçuş kamerası ekledi. Bu küçük bir ayrıntı gibi gelebilir. Ancak “şu sırtın yakınlarında bir yerde hata gördüm” ile “hata, kuzeybatıya bakarken (142, 12, -67) konumunda ortaya çıkıyor” arasındaki farkı yarattı.

Bu bölümün temel çıkarımı, politikanın karmaşıklığı azaltmadığıdır. Politika, karmaşıklığı düzenledi. Aynı sayıda uç durum hâlâ vardı. Ancak artık her uç durumun bir adı, tetikleme koşulu ve kodda kesme noktası koyabileceğiniz bir yeri bulunuyordu. Bu farklı türde bir kazanımdır ve bir sistemin gelişmeye devam edip edemeyeceğini ya da kendi ağırlığı altında çöküp çökmeyeceğini belirleyen şeydir.

Spike 23'ün sonunda, sürekli etkileşim hatası korkusu yaşamadan uzak alan clipmap halka stratejisine bağlanabilecek kadar öngörülebilir bir yakın alan davranış katmanımız vardı.

12. bölümde; halka geçişlerinin, skybox sisinin ve Three.js sürüm düzeyindeki shader entegrasyonunun projenin bu bölümünü tamamladığı Spike 24'ü ele alıyoruz.

Bu bölümde değinilen teknolojiler

Mesafeye dayalı LOD politikası. Kameraya olan mesafeyi, düzenleme geçmişini ve komşu durumlarını temel alarak her chunk'a LOD seviyesi ve render modu atayan merkezi bir fonksiyon. Eş merkezli mesafe halkaları temel LOD'u belirler: halka 0 = tam çözünürlüklü MC, halka 1 = yarı çözünürlüklü MC, halka 2+ = yükseklik haritası modu. Politika fonksiyonu, kamera hareket ederken her karede çalışır ve chunk geçişlerini tetikler. Böylece geçici, chunk başına alınan kararların yerini öngörülebilir ve hata ayıklanabilir bir kural sistemi alır. Compute shader karşılığı için GPU destekli LOD seçimine bakın.

Komşuluk kısıtları. Transvoxel algoritması yalnızca 2:1 çözünürlük oranlarını işler. İki komşu chunk arasında birden fazla LOD seviyesi farkı varsa (örneğin LOD 0'ın yanında LOD 2), geçiş tabloları geçerli dikiş geometrisi üretemez. Politika sistemi, LOD farkı 1'i aştığında daha düşük ayrıntılı chunk'ı yükselterek bu kısıtı uygular. Bu kısıt yayılımı zincirleme ilerleyebilir: bir chunk'ın yükseltilmesi, komşularının da yükseltilmesini gerektirebilir. Uygulama, tipik ızgara yapılandırmalarında 2-3 yinelemede yakınsayan basit bir yinelemeli geçişten oluşur.

Mod seçimi için düzenleme bit eşlemi. Her chunk, hacimsel SDF düzenlemeleri (mağaralar, tüneller, şekillendirmeler) içerip içermediğini kaydeden bir bit eşlemi tutar. Herhangi bir düzenleme içeren chunk'lar, üreticinin değişikliklerini korumak için mesafeden bağımsız olarak marching cubes modunda kalır. Düzenlenmemiş chunk'lar kameradan yeterince uzaktayken yükseklik haritası moduna geçerek hesaplama ve bellek tasarrufu sağlar. Bit eşlemi, chunk başına tek bir bayraktan oluşur; ancak daha ayrıntılı mod kararları için düzenleme yoğunluğunu izleyecek şekilde genişletilebilir.

Hata ayıklama görselleştirme katmanları. Renk kodlu chunk render'ında yeşil = yükseklik haritası modu, mavi = MC modu, turuncu = geçişin etkin olduğu yüzler anlamına gelir. Chunk başına katmanlar; LOD seviyesi numaraları, mod etiketleri ve tel kafes açma/kapama seçenekleri sunar. Bunlar yayınlanan özellikler değil, geliştirme araçlarıdır; ancak LOD geçişleri ile dikiş artefaktlarında hata ayıklarken maliyetlerini defalarca çıkarırlar. Tam dünya konumunu bildiren WASD uçuş kamerasıyla birlikte “bir yerde hata gördüm” ifadesini “hata, bu LOD yapılandırmasıyla (142, 12, -67) konumunda ortaya çıkıyor” ifadesine dönüştürürler.

12 bölümün 11. bölümü.
Önceki: Bölüm 10 - Dikiş kaosu ve köşe bölüm sonu canavarı
Sonraki: Bölüm 12 - Halkalar, gökyüzü sisi ve yeniden yapacaklarımız
Seri rehberi: /tr/blog/2026-02-25-open-world-browser-series-guide

Yazan: Oleg Sidorkin, Cinevva CTO'su ve Kurucu Ortağı

Burada yeni misiniz? Seri rehberini kullanın. Rehber, spike'ın ne olduğunu açıklıyor ve tüm bölümlere bağlantı veriyor.

Spike 24'ün amacı "araziye clipmap halkaları eklemek"ti. Ancak aynı anda render sürecine, shader'lara, modül altyapısına ve görsel entegrasyona dokunan tam kapsamlı bir finale dönüştü.

Temel arazi görevi, vertex shader'da eş merkezli clipmap halkaları oluşturmaktı. Her halka, kameranın merkezinde yer alan ve vertex'leri heightmap örnekleriyle ötelenen düz bir grid mesh'tir. En içteki halka tam çözünürlük kullanır. Sonraki her halka vertex aralığını iki katına çıkarır ve daha geniş bir alanı kapsar. Zor kısım halkalar arasındaki sınırdır: yüksek çözünürlüklü bir halkanın düşük çözünürlüklü bir halkayla buluştuğu yerde, daha ince mesh'in kenar vertex'lerinin daha kaba mesh kenarının orta noktasına hizalanması gerekir. Halka kenarı boyunca grid koordinatı tek sayı olan sınır vertex'lerini tespit edip yüksekliklerini iki çift sayı koordinatlı komşularının orta noktasına, $h=\frac{1}{2}(h_{\text{left}}+h_{\text{right}})$, hizalayarak 2:1 kenar morflama uyguladık. Bu, kaba halkanın tek kenarının tam olarak yer alacağı noktadır; dolayısıyla ince ve kaba kenarlar aynı çizgiyi tanımlar. Böylece geçiş geometrisine ihtiyaç duymadan aralıksız birleşimler elde edilir.

Spike 24'ü yeni sekmede aç ↗ · Kaynak kodu görüntüle

Ardından sis ve gökyüzü entegrasyonu geldi. Uzak arazinin sabit, düz bir renge değil gerçek gökyüzü rengine karışmasını istiyorduk. Bunun için sis shader'ının, her fragment yönünde gökyüzünün hangi renkte olacağını bilmesi gerekiyordu. Eş dikdörtgensel bir HDR skybox dokusu yükledik ve fragment shader'da kameradan fragment'a uzanan görüş yönünü kullanarak bu dokudan örnek aldık; yönü TSL'nin equirectUV node'u aracılığıyla eş dikdörtgensel UV koordinatlarına dönüştürdük. Sis faktörü, kamera uzayındaki derinlik için positionView.z.negate() kullanılarak mesafeye göre hesaplandı ve yakın ile uzak mesafe arasında smoothstep ile harmanlandı.

Modülleri birbirine bağlamak, geometrinin herhangi bir bölümünden daha can sıkıcı çıktı. Derleme çıktılarını yeniden yapılandıran Three.js 0.183.1 sürümüne yükselttik. three/tsl import'unun three.tsl.js dosyasına çözümlenmesi gerekiyordu ve TSL kendi içinde three/webgpu öğesini yalın bir belirteç olarak import ediyordu. Her iki eşlemenin de HTML import map'inde açıkça tanımlanması gerekti. Bunlardan birinin bile eksik olması, hangi eşlemenin yanlış olduğuna dair hiçbir ipucu vermeyen anlaşılmaz "does not provide an export" veya "failed to resolve module specifier" hatalarına yol açıyordu. Her ikisi de import map'e eklendiğinde shader grafiği doğru şekilde yüklendi.

Ayrıca dokunun baş aşağı render edilmesine yol açan bir skybox yönü sorunumuz vardı. Çözüm, eş dikdörtgensel dokuda flipY = true ayarını kullanmaktı. Bu, yüklenen dokular için Three.js'in varsayılanıdır ancak ilk kodumuzda false olarak ayarlanmıştı.

İlk sis uygulaması gökyüzünü neredeyse sabit bir yönden örnekliyor ve doğal bir gradyan yerine ufuk renginde ince bir şerit oluşturuyordu. Çözüm, positionWorld.sub(cameraPosition).normalize() kullanarak her piksel için kameradan fragment'a uzanan gerçek dünya yönünü hesaplamak ve sis rengi aramasında bunu equirectUV içine aktarmaktı. Böylece arazi fragment'ları gerçekten arkalarında bulunan gökyüzü rengine karışmaya başladı ve her kamera açısından doğru bir görünüm elde edildi.

Tüm bu ayrı düzeltmelerin altında temel sonuç değişmedi. Artık yakın alan hacimsel düzenlemeyi (Transvoxel birleşimleri kullanan marching cubes), orta alan heightmap chunk'larını ve uzak alan clipmap halkalarını bir araya getiren bir arazi sistemimiz var. Bunların tümü mod, LOD ve geçiş davranışını belirleyen bir politika katmanı tarafından yönetiliyor.

Bir sonraki projede tekrarlayacağım kalıpları sıralamam gerekseydi şunları seçerdim:

Özellik geliştirmeye başlamadan önce risk spike'larıyla başlayın. Spike 1, içerik pipeline'larına yatırım yapmadan önce "yeterince hızlı render yapabiliyor muyuz?" sorusunu ortadan kaldırdı.

Büyük entegrasyon sıçramalarından önce düzgün çalıştığı bilinen temel sürümleri dondurun. Spike 13 ve 14, regresyonları ikiye bölerek aramakla geçireceğimiz günleri kurtardı.

Uzun optimizasyon süreçlerinden önce politika katmanını ve gözlemlenebilirliği zorunlu kılın. Spike 23, gizemli hataları tetikleme kuralları olan, adlandırılmış koşullara dönüştürdü.

Ekran görüntüleriyle değil, hareket hâlinde test edin. Clipmap sıçramaları, birleşim titremeleri ve streaming takılmaları sabit karelerde gizlenir.

Ortalama FPS'yi değil, özellik başına frame süresi maliyetini ölçün. Ortalamalar, kullanıcıların gerçekten hissettiği sıçramaları gizler.

Ve dağınık kısımları da yayımlayın. Yanlış yolları, güncelliğini yitirmiş buffer hayaletlerini aramayı, draw range yanlışken geçiş mantığını suçlayarak geçirilen iki günü... İnsanların gerçekten ders çıkarabileceği kısımlar bunlardır.

Harici gerçeklik kontrolü: Vuntra City geliştirme günlükleri

Bu seriyi tamamladıktan sonra kendi açık dünya varsayımlarımızı harici bir uygulamayla karşılaştırmak için @VuntraCity geliştirme günlüklerini inceledik. Bu, tarayıcı stack'i değil yerel bir UE5 projesi; ancak sistem kalıpları yeterince örtüştüğü için karşılaştırma faydalı.

İlk işaret, hareket hızının yalnızca oynanışın bir parçası değil, bir streaming kontrolü olarak da ele alınması gerektiği. Vuntra City'de yüksek hızlı ulaşım bilinçli olarak çoğu iç mekânın üzerinden yönlendiriliyor; ayrıntı menzili de nesne oluşturma trafiğini ve takılmaları önlemek için hareket hızına göre ölçekleniyor (ulaşım sistemi, performans teknikleri). Bu, politika katmanı yönelimimizle örtüşüyor: hareket modu; chunk yarıçapını, iç mekân etkinleştirmeyi ve kare başına izin verilen iş miktarını doğrudan etkilemeli.

İkinci işaret mimariyle ilgili. Harita ve adres sistemleri, yüklenmemiş bölgelerde de genel sorguların çalışabilmesi için dünya topolojisinin render edilen nesnelerden ayrılmasını gerektirmiş (haritalar ve adresler). Bu, render'a bağlı veri yollarını zorunlu kılmadan dünya araması, görev rotalama, moderasyon taramaları ve ilgi noktası indeksleme yapabilmek için tarayıcıda ihtiyaç duyduğumuz ayrımla aynı.

Üçüncü işaret, simülasyonun katmanlara ayrılması. Bir milyon NPC'lik tasarımlarında kaba program durumu ucuz ve genel tutuluyor, pahalı davranış bütçesi ise yalnızca oyuncunun yakınında harcanıyor (bir milyon NPC'ye genel bakış, sistemin ayrıntılı incelemesi). Bu, yakın alan doğruluğu ile uzak alan determinizminin ayrı bütçelere sahip ayrı meseleler olduğu, AOI öncelikli simülasyon modelimizi destekliyor.

Dördüncü işaret ise ham ölçek değil, tasarım kalitesi. En güçlü keşif anları; sürekli UI katmanları yerine ağırlıklı dağılımlardan, nadir aykırı örneklerden ve oyun dünyasına ait yön bulma ipuçlarından doğuyor (prosedürel ortam notları, mini haritasız oynanış döngüsü). Bizim için bu, teknik sistemlerin yalnızca maksimum verim sağlamak üzere değil, keşfedilebilir çeşitlilik üretecek şekilde ayarlanması gerektiğini hatırlatıyor.

Bu bölümde değinilen teknolojiler

Clipmap halka geometrisi. Her halka, kameranın merkezinde yer alan ve vertex'leri heightmap örnekleriyle ötelenen düz bir grid mesh'tir. En içteki halka tam çözünürlük kullanır. Sonraki her halka vertex aralığını iki katına çıkarır ve daha geniş bir alanı kapsar. Zor kısım sınırdır: yüksek çözünürlüklü bir halkanın düşük çözünürlüklü bir halkayla buluştuğu yerde, daha ince mesh'in kenar vertex'leri daha kaba mesh kenarının orta noktasına hizalanır. Teknik, Losasso ve Hoppe'nin SIGGRAPH 2004 makalesinden (PDF) kaynaklanır ve GPU Gems 2, Bölüm 2 içinde ayrıntılı olarak açıklanır. Geometri clipmap'leri hakkındaki arazi rehberimize bakın.

2:1 kenar morflama. İki clipmap halkası arasındaki sınırda, daha ince halkada daha kaba halkanın paylaşmadığı konumlarda vertex'ler bulunur. Halka kenarı boyunca grid koordinatı tek sayı olan sınır vertex'leri tespit edilir ve yükseklikleri, komşu iki çift sayı koordinatlı vertex arasında interpolasyonla hesaplanır. Böylece özel geçiş geometrisine ihtiyaç duymadan aralıksız birleşimler elde edilir. Interpolasyon, vertex shader'da sınır vertex'leri için morphedHeight = mix(heightLeft, heightRight, 0.5) şeklinde çalışır ve rehberimizde açıklanan aynı geomorfing çerçevesini kullanır.

Eş dikdörtgensel skybox eşleme. Boylam-enlem projeksiyonu kullanarak gökyüzündeki tüm yönleri bir küre üzerine eşleyen tek bir 2D görüntüdür. Yatay eksen 0-360 dereceyi, dikey eksen ise 0-180 dereceyi kapsar. Normalize edilmiş bir görüş yönü $\hat{d}=(d_x,d_y,d_z)$, boylamı ve enlemi alınarak UV koordinatlarına dönüştürülür:

Three.js'te texture.mapping = EquirectangularReflectionMapping ayarını SRGBColorSpace ile birlikte kullanmak, bunu sahne arka planı olarak etkinleştirir. TSL'de equirectUV(direction) aynı dönüşümü uygular ve 3D görüş yönünü dokudan örnek almak için kullanılan 2D UV koordinatlarına dönüştürür.

Gökyüzünden fragment başına sis rengi. Standart sis, fragment'ları tek bir sabit renge doğru harmanlar. Ayrıntılı bir skybox'a sahip sahnede bu yanlış görünür çünkü gökyüzü rengi yöne göre değişir. Çözüm, her piksel için kameradan fragment'a uzanan dünya yönünü (positionWorld.sub(cameraPosition).normalize()) hesaplamak ve sis rengi için skybox'ı bu yönde örneklemektir. Her fragment gerçekten arkasında bulunan gökyüzü rengine doğru solar ve böylece her kamera açısından doğru harmanlama elde edilir. Sis faktörü, kamera uzayındaki derinlik için positionView.z.negate() ve smoothstep(nearDist, farDist, viewDepth) kullanır.

ES modülleri için import map'ler. Yalın modül belirteçlerini (three/tsl gibi) gerçek URL'lerle eşleyen, tarayıcıya özgü bir mekanizmadır (<script type="importmap">). Three.js 0.183.1 derleme çıktılarını yeniden yapılandırdığında three/tsl öğesinin three.tsl.js dosyasına çözümlenmesi gerekti ve TSL kendi içinde three/webgpu öğesini yalın bir belirteç olarak import etti. Her iki eşlemenin de import map'te açıkça tanımlanması gerekiyordu; aksi hâlde tarayıcı "does not provide an export" veya "failed to resolve module specifier" hataları üretiyordu.

Ek okumalar

Bu seri boyunca kullanılan teknolojiler hakkında daha ayrıntılı bilgi için tamamlayıcı rehberlerimize bakın:

• Tarayıcı Açık Dünyaları İçin Dinamik LOD ve Streaming ile Arazi Üretimi; heightmap'leri, SDF'leri, marching cubes'ı, Transvoxel'i, geometri clipmap'lerini, geomorfingi, streaming mimarisini, arazi materyallerini ve bitki örtüsü render sürecini kapsar.
• Çok Oyunculu Üretici Dünyaları İçin Tarayıcıda 3D Açık Dünya Teknolojileri; render stack'lerini, WebGPU'yu, fiziği, ağ iletişimini, çok oyunculu mimariyi ve Skyrim, The Witcher 3, Breath of the Wild ile GTA V'ten çıkarılan dersleri kapsar.

On iki bölümlük bu yolculuğu takip ettiğiniz için teşekkür ederiz.

Bölüm 1: Onu bozmaya çalışarak başladık
Bölüm 2: Worker fiziği ve input gecikmesi korkusu
Bölüm 3: Bizi kurtaran gösterişsiz spike'lar
Bölüm 4: Gösterişli araziden önce streaming
Bölüm 5: Görsel güzellikler için bütçe ayırmak
Bölüm 6: Clipmap'ler gidişatı değiştirdi
Bölüm 7: Marching cubes ve ilk gerçek mağaralar
Bölüm 8: Temel sürümümüzü kaybetmeden entegrasyon
Bölüm 9: Transvoxel bir iskeletle başladı
Bölüm 10: Birleşim kaosu ve köşe bölüm sonu canavarı
Bölüm 11: Sabit kodlanmış mod değil, politika modu

14 bölümün 12.'si.
Önceki: Bölüm 11 - Sabit kodlanmış mod değil, politika modu
Sonraki: Bölüm 13 - Arazi şekillendirme ve matematik fonksiyonunun ölümü
Seri rehberi: /tr/blog/2026-02-25-open-world-browser-series-guide

Cinevva CTO'su ve Kurucu Ortağı Oleg Sidorkin tarafından

Bu sayfa, serinin tamamı için gezinme merkezidir.

Buraya serinin rastgele bir bölümünden geldiyseniz buradan başlayın.

Mart 2026 güncellemesi: 12. Bölüme Vuntra City geliştirici günlüklerinden harici bir uygulama karşılaştırması ekledik ve eşlik eden tarayıcıda açık dünya teknoloji rehberini aynı bulgularla genişlettik.

Nisan 2026 güncellemesi: 13-14. Bölümler arazi şekillendirmeyi (Spike 25-27) ve görsel/oynanış katmanını ele alıyor: çok malzemeli dokulama, örneklenmiş bitki örtüsü ve HM+SDF çarpışmasına sahip bir karakter kontrolcüsü (Spike 28-30).

Mayıs 2026 güncellemesi: seri 29 bölüme ulaştı. 15-29. Bölümler; geliştirme sürecinin uzun orta bölümünü, çok oyunculu arazi ve suyu, kod yapısı yeniden düzenlemesini, animasyonları ve yapay zekâ destekli dağıtımı, imposter'ları ve paralaksı, karşılığını vermeyen görünürlük tamponunu, bulutları ve meshlet ayıklamayı, toplu avatarları ve yakınlık tabanlı sesli iletişimi, dünya kalıcılığını ve GPU rüzgârını, evrensel karakterleri, suya yönelik üç yaklaşımı, prosedürel bir adayı, çim ve örtülmeyi ve her türlü gövdeyi yöneten takılabilir bir karakter kontrolcüsünü ele alıyor (Spike 31-60).

Haziran 2026 güncellemesi: 30. Bölüm, çarpışmaları hesaba katan bir kamera ekliyor; takılabilir bir çarpıştırıcı sözleşmesine sahip yaylı bir kamera kolu ve görüntünün yalnızca tepelere değil, çıkıntılara ve mağara tavanlarına da girmesini engelleyen işaretli mesafe sondası kullanıyor.

Bu seride "spike" ne anlama geliyor?

Spike, kısa ve odaklı bir deneydir.

Her spike, riskli bir soruyu sınar. Kapsamı dar tutar, önemli olanı ölçer ve bir sonraki adımda ne yapacağımıza karar veririz. Bunu tamamlanmış bir özellik değil, öğrenme aracı olarak düşünün.

Bu projedeki spike'lar çoğunlukla /spikes/* altında bulunan ve canlı olarak çalıştırabileceğiniz bağımsız sayfalardır.

Seriyi sırayla okuyun

1. 1. Bölüm: İşe onu bozmaya çalışarak başladık
2. 2. Bölüm: Worker fiziği ve girdi gecikmesi korkusu
3. 3. Bölüm: Bizi kurtaran gösterişsiz spike'lar
4. 4. Bölüm: Gösterişli araziden önce akış
5. 5. Bölüm: Görsel güzellikler için bütçe ayırmak
6. 6. Bölüm: Clipmap'ler hikâyenin yönünü değiştirdi
7. 7. Bölüm: Marching cubes ve ilk gerçek mağaralar
8. 8. Bölüm: Temel seviyemizi kaybetmeden entegrasyon
9. 9. Bölüm: Transvoxel bir iskeletle başladı
10. 10. Bölüm: Dikiş kaosu ve köşe bölüm sonu canavarı
11. 11. Bölüm: Sabit kodlanmış mod değil, politika modu
12. 12. Bölüm: Halkalar, gökyüzü sisi ve yeniden yapacaklarımız
13. 13. Bölüm: Arazi şekillendirme ve matematik fonksiyonunun sonu
14. 14. Bölüm: Dünya canlanıyor
15. 15. Bölüm: Temeli değiştir, ardından eşitle
16. 16. Bölüm: Büyümeye devam eden bir dünya için yapı
17. 17. Bölüm: Yeniden hedefleme gerektirmeyen animasyonlar ve canlı varlık araması
18. 18. Bölüm: Yapay zekâ yerleştirmiş gibi hissettiren bir dağıtım fırçası
19. 19. Bölüm: Bir ormanda ayakta kalması gereken imposter
20. 20. Bölüm: Düz bir yüzeyde derinlik yanılsaması yaratmak
21. 21. Bölüm: Daha hızlı olmayan, daha hızlı bir işleyici
22. 22. Bölüm: Işıklandırabileceğiniz bulutlar ve beslenmesi gereken ayıklama sistemi
23. 23. Bölüm: Elli avatar ve odadaki bir ses
24. 24. Bölüm: Bir dünyayı kaydetmek ve görebildiğiniz rüzgâr
25. 25. Bölüm: Tek iskelet, her kıyafet
26. 26. Bölüm: Su yapmanın üç yolu
27. 27. Bölüm: Gürültüden bir ada, gerçekten zemine benzeyen bir zemin
28. 28. Bölüm: Ufka kadar çim ve kendini gizleyen zemin
29. 29. Bölüm: Tek kontrolcü, her gövde
30. 30. Bölüm: Duvarlara saygı duyan bir kamera

Canlı spike haritası

Teknik zaman çizelgesinde doğrudan ilerlemek istiyorsanız bunlarla başlayın.

Spike 1 arazi ve örnekleme · kaynak
Spike 2 worker fiziği · kaynak
Spike 3 Durable Object yayın yükü testi, bağımsız bir sayfa olarak değil hizmet betiği olarak çalıştırıldı
Spike 4 mobil kalite kısıtlamaları, Spike 1 sorgu parametresi aracılığıyla test edildi
Spike 5 LLM davranış güvenilirliği, bağımsız bir sayfa olarak değil betik olarak çalıştırıldı
Spike 6 parça yükleme ve değiştirme · kaynak
Spike 7 yoğunluk haritalarından bitki örtüsü · kaynak
Spike 8 arazi malzemesi maliyeti · kaynak
Spike 9 kademeli gölge bütçesi · kaynak
Spike 10 clipmap'ler ve geomorphing · kaynak
Spike 11 yükseklik haritası parçalarını akışla yükleme · kaynak
Spike 12 WebGPU marching cubes · kaynak
Spike 13 WebGPU entegrasyon temeli · kaynak
Spike 14 kademeli sağlamlaştırma · kaynak
Spike 15 dikiş iskeleti · kaynak
Spike 16 ilk Transvoxel yüzü · kaynak
Spike 17 ikili MC LOD · kaynak
Spike 18 yükseklik haritası dikişi · kaynak
Spike 19 karma çözünürlüklü köşe · kaynak
Spike 20 GPU köşe dikişi · kaynak
Spike 21 GPU MC köşe dikişi · kaynak
Spike 22 MC'den HM'ye geri dönüş · kaynak
Spike 23 politika tabanlı parça modları · kaynak
Spike 24 clipmap halkaları ve gökyüzü sisi · kaynak
Spike 25 örneklenmiş veriler üzerinde yükseklik haritası fırçası · kaynak
Spike 26 GPU hesaplama üzerinden SDF fırçası · kaynak
Spike 27 HM + MC + fırça entegrasyonu · kaynak
Spike 28 çok malzemeli dokulama · kaynak
Spike 29 bitki örtüsü ve gölgelendirici tabanlı çim · kaynak
Spike 30 arazi fiziği ve karakter kontrolcüsü · kaynak
Spike 31 çok oyunculu arazi eşitleme · kaynak
Spike 32 su ve yüzme · kaynak
Spike 33 kod yapısını yeniden düzenleme · kaynak
Spike 34 dünya içinde içerik oluşturma · kaynak
Spike 35 savaş animasyonları ve yeniden hedefleme · kaynak
Spike 36 canlı Poly Haven varlık araması · kaynak
Spike 37 yapay zekâ destekli nesne dağıtımı · kaynak
Spike 38 oktahedral imposter'lar · kaynak
Spike 39 paralaks örtülme eşleme · kaynak
Spike 40 görünürlük tamponu işleyicisi · kaynak
Spike 41 bir ormandaki imposter'lar · kaynak
Spike 42 imposter titreşimi düzeltmesi · kaynak
Spike 43 atmosfer ve hacimsel bulutlar · kaynak
Spike 44 meshlet Hi-Z ayıklama · kaynak
Spike 45 toplu avatar iskelet deformasyonu ve ağ eşitleme · kaynak
Spike 46 yakınlık tabanlı sesli sohbet · kaynak
Spike 47 sunucu yetkili dünya kalıcılığı · kaynak
Spike 48 avatar donanımı entegrasyonu, sonraki spike'lar tarafından paylaşılan kod olarak yeniden kullanıldı (bağımsız sayfası yok)
Spike 49 nesneler ve yapraklar üzerinde GPU rüzgârı · kaynak
Spike 50 evrensel karakterler ve giyilebilir öğeler · kaynak
Spike 51 ekran uzayı yansımalı su · kaynak
Spike 52 düzlemsel aynalı su · kaynak
Spike 53 üretime hazır su kütüphanesi · kaynak Spike 54 prosedürel ada üretimi · kaynak
Spike 55 arazi gölgelendirme ve döşeme tekrarlarını giderme · kaynak
Spike 56 GPU tabanlı çapraz dörtgen çimler · kaynak
Spike 57 arazi örtülme ayıklaması · kaynak
Spike 58 takılabilir karakter kontrolcüsü · kaynak
Spike 59 gerçek avatarlı kontrolcü · kaynak
Spike 60 Synty poligon animasyonları · kaynak

Cinevva CEO'su Mariana Muntean tarafından

Yılanınızın raket olduğu ve tuğlaların karşılık verdiği bir oyun yaptık. Web, mobil ve PC için yayınlandı. İkimizin yaklaşık üç gününü aldı. Aralıklı çalıştık, yoğun mesai yapmadık. Üstelik oynaması gerçekten eğlenceli.

Dikkat etmeye değer olan da bu son kısım.

Kimsenin istemediği birleşim

Snake; büyüme ve mekânsal farkındalık üzerine kurulu. Arkanoid ise refleksler ve açı tahminiyle ilgili. Tamamen farklı tasarım felsefelerinden geliyorlar ve ikisini bir araya getirmek, kibarca reddedilecek türden bir fikir gibi görünüyor.

Ama A Breaker Belt bunu başarıyor. Sürüklenme metali omurlar ve kuyruklu yıldız ipeğinden örülmüş, yaşayan bir neon akım yayı olan kozmik bir yılansınız; kırılabilir bloklarla dolu bir asteroit kuşağında ilerliyorsunuz. Başınız raket görevi görüyor. Uzayan kuyruğunuz hem en güçlü silahınız hem de en sürekli tehdidiniz. Küreler gövdenizden sekerek tuğlaları parçalıyor, ancak tek bir yanlış dönüşle kendi kuyruğunuza çarparsanız oyun bitiyor.

Bu, genellikle kimse oynama fırsatı bulamadan rafa kaldırılan türler arası tuhaf deneylerden biri. Çünkü sıra dışı bir fikrin işe yarayıp yaramadığını anlamanın geliştirme maliyeti geleneksel olarak aylarla ölçülüyordu. Burada ise birkaç öğleden sonrayla ölçüldü.

Gerçekte neler yayınlandı?

Bunu ilginç kılan şey kapsamı. Bu, geçici dikdörtgenlerden oluşan ve sesi bile olmayan bir game jam prototipi değil.

Oyun 50 dalga boyunca devam ediyor. Üstelik bunlar aynı tuğla duvarının 50 farklı çeşidi değil. Dizilimler, oyuncuyu oyuna alıştıran yumuşak kavislerden başlayıp yanlardaki boşluklardan açılı atışlar yapmayı gerektiren kale halkalarına, ardından hassas yönlendirme isteyen tek kare genişliğindeki açıklıklara sahip katmanlı çapraz labirentlere dönüşüyor. Patlayıcı tuğlalar komşularını havaya uçuruyor. Hayalet tuğlalar yanıp sönerek var olup yok oluyor. Yenilenen tuğlalar kırıldıktan sonra kendilerini onarıyor ve sizi soldan sağa ilerlemek yerine hedeflerinizi önceliklendirmeye zorluyor. Portal tuğlaları kürelerinizi arenanın bir ucundan diğerine ışınlıyor. Kütleçekim kuyuları atışlarınızı yavaş, kıvrımlı ilahilere dönüştürüyor. Lazer yayıcılar boşlukta kırmızı çizgiler çiziyor. Taklitçi tuğlalar, aksine karar verene kadar zararsız görünüyor. 15. dalgaya geldiğinizde, bir bulmacadan çok alışkanlıklarınızı öğrenen canlı bir sistem gibi hissettiren bir ortamda yolunuzu buluyorsunuz.

Müzik basit bir döngüden ibaret değil. Oynanışınıza göre gelişen tepkisel bir müzik sistemi. Altyapı; 140 BPM'de Mi minör tonunda bas hattı, solo synthesizer, pad, kick, trampet ve hi-hat kullanıyor. Aksiyon yoğunlaştıkça ek perküsyon ve synthesizer katmanları yavaşça devreye giriyor. Dalgalar arasında ortam sakinleştiğinde ise ambiyans pad'leri öne çıkıyor. Müzik sizinle birlikte nefes alıyor. Profesyonel bir besteci bu düzeyde bir duyarlılığı ayarlamak için haftalar harcardı. Burada ise yaratıcı akışın doğal bir parçasıydı.

Ses efektleri ücretsiz bir paketten alınmış örnekler değil. Her tuğla parçalanması, güçlendirme kazanımı, küre sekmesi ve çarpışma gerçek zamanlı olarak sentezleniyor. Başa ve kuyruğa çarpıldığında farklı perdeler kullanılıyor. Uzay atmosferi için sıcak bir yankı var. Seslerin sertleşmeden tatmin edici kalması için alçak geçiren filtre uygulanıyor. Bir kombo zinciri yaptığınızda bunu ekrandan önce ses size bildiriyor.

Bir de hikâye anlatımı var. Her dalga, yapay zekâ tarafından üretilen bir sesin aktardığı anlatı bölümüyle açılıyor. Metinlerin gerçekten kendine özgü bir karakteri var. Birinci dalga: "Ona Kırıcı Kuşak diyorlar: eski yıldızın çevresinde bir uyarı gibi dönen, tasarlanmış bir enkaz şeridi." 38. dalgaya geldiğinizde: "Kuşak artık bir duvar gibi değil, bir zihin gibi hissettiriyor. Reflekslerinizi değil, alışkanlıklarınızı sınıyor. Alışkanlığınızı kırıyorsunuz. Kuşak bunu fark ediyor." Uzayda neden tuğla kıran bir yılan olduğunuzu önemsemenizi sağlayan, 50 bölümlük bir kozmik mitoloji.

Arka planlar da gelişiyor. İlk dalgalarda hafif meteor yağmurlarıyla sakin çivit mavisi yıldız alanları var. Oyunun ortalarına gelindiğinde kutup ışığı şeritleri ve bulutsu bulutları beliriyor. Oyunun sonlarında ise neredeyse siyah uzayın önünde keskin camgöbeği izleriyle tam anlamıyla bir İyon Fırtınası yaşanıyor. 15. dalga ve sonrasında Olay Ufku bölgesindesiniz: yavaşça hareket eden bulutsu lifleri ve belli belirsiz kara delik merceklenmeleriyle bölünen derin bir boşluk. Oyun, ilerlemeyi zorluk kadar atmosfer aracılığıyla da aktarıyor.

Tüm bunlar klavye, gamepad veya dokunmatik ekranla çalışıyor. Tek bir kod tabanından web, mobil ve PC için yayınlandı. Ayrı derlemeler yok. Portlama yok.

İhtiyaç duyulmayan ekip

İşte her oyun geliştiricisinin durup düşünmesini gerektirecek kısım.

Bu içerik derinliğine sahip bir oyun için normalde bir oyun tasarımcısı, birkaç programcı, bir 2D sanatçısı, bir ses tasarımcısı, bir besteci, bir seviye tasarımcısı, bir anlatı yazarı ve kalite güvence uzmanları gerekirdi. Yani sekiz veya dokuz kişi. Mütevazı bir bağımsız oyun geliştirme temposuyla üç ila altı aylık koordineli bir çalışmadan söz ediyoruz. Günlük toplantılar, Jira görevleri, varlık üretim hatları ve platforma özel hata ayıklama süreçleri.

İkimiz bunu uzun bir hafta sonunda Cinevva Engine üzerinde yaptık.

Gereken yetenek değişmedi. Değişen, yaratıcı niyet ile uygulama yükü arasındaki orandı. Zamanımızı bunu gerçekleştirmek için araçlarla boğuşmaya değil, oyunun nasıl hissettirmesi gerektiğine karar vermeye harcadık.

Bir şeyler üretiyorsanız bu neden önemli?

İlginç soru, yapay zekâ araçlarının oyunları daha hızlı yapmaya yardımcı olup olamayacağı değil. Bu zaten yanıtlandı. Asıl ilginç soru, eskiden denenemeyecek kadar riskli olan fikirlere ne olacağı.

"Bir Arkanoid arenasında raket olduğunuz bir Snake oyunu" hiçbir yapımcının yeşil ışık yakacağı türden bir fikir değil. Birkaç bağımsız geliştirici itch.io üzerinde bu birleşimin farklı çeşitlerini denedi (BreakSnake, SnakeOut, Snake Break), ancak bunların hepsi küçük game jam deneyleri. Bu tür birleşimi daha önce tepkisel müzik, yapay zekâ anlatımı, düzinelerce tuğla türü ve giderek zorlaşan 50 dalgalık seviye tasarımıyla gerçek bir üretim sürecinden geçirilmedi. Geleneksel geliştirme süreçlerinde, riskli bir konsepte bu düzeyde incelik kazandırma fikri daha kimse tek satır kod yazmadan bir toplantıda elenirdi.

Tuhaf bir şeyi denemek üç aylık bütçe yerine bir öğleden sonraya mal olduğunda, sıra dışı fikirler hayata geçiriliyor. Bazıları da gerçekten iyi çıkıyor. A Breaker Belt bunlardan biri.

Oynayın. Ya da kendinizinkini yapın.

A Breaker Belt şu anda web, mobil ve PC'de oynanabilir. Sizde de bir şeyler geliştirme isteği uyandırırsa Cinevva Engine ücretsiz. Ne istediğinizi tarif edin, ortaya çıkanı yineleyerek geliştirin ve hazır olduğunda yayınlayın. Müzik, ses efektleri, görseller ve 3D modeller için gereken her şey yerleşik olarak sunuluyor.

Tuhaf oyun fikrinizin gerçeğe dönüşmesine yalnızca üç gün kalmış olabilir.

A Breaker Belt'i oyna | Kendi oyununu geliştir | Topluluk oyunlarına göz at

İlgili içerikler:

• Vibe kodlama yeni game jam'dir — yapay zekâ araçlarının fikir ile prototip arasındaki mesafeyi nasıl ortadan kaldırdığı
• Game Jam'ler ve Hackathon'lar — sıra dışı birleşimleri mümkün kılan jam formatı
• Web Oyun Motorları Karşılaştırması — web, mobil ve PC için oyun yayınlamaya uygun motorlar

Mariana Muntean, Cinevva CEO'su

Cinevva platformunda, oyun geliştiricilerinin lisans sorunlarıyla uğraşmadan oyun müzikleri ve ses efektleri oluşturabilmesi için bir müzik üreticimiz var. Sonrasında yaşananlarıysa hiç planlamamıştık. İnsanlar müzik yapmak istedikleri için müzik üretmeye başladı. Oyunlar veya projeler için değil. Sadece müzik üretmek için.

Bella Bay iki haftada 100'den fazla parça yaptı

Abartmıyorum. İçerik üreticilerimizden Bella Bay, yaklaşık iki haftada 100'den fazla parça üretti. Bunları Cinevva Radio'da dinlediğinizde gelişimi duyabiliyorsunuz. İlk parçalar birer deney. Sonrakilerse kendi tarzını bulmuş birinin eserleri gibi geliyor. Araçlarınızla boğuşurken bu tür bir yaratıcı ivme yakalanmaz. Araçlar aradan çekildiğinde yakalanır.

Bella Bay, yaklaşım bakımından aykırı bir örnek değil; yalnızca üretim miktarıyla öne çıkıyor. Platformun dört bir yanında insanlar müzik üreticisini oyun varlıkları hazırlamaya yarayan bir araç olarak değil, yaratıcı bir enstrüman olarak görmeye başladı. Daha önce hiç denemedikleri türleri keşfeden prodüktörler. Aradıkları sesi bulana kadar tekrar tekrar deneyen insanlar. Daha önce eksiksiz bir prodüksiyon araç setine erişememiş bağımsız sanatçılar bir anda bu imkâna kavuştu ve kendilerini bütünüyle müziğe verdi.

Biz de bir radyo kurduk

Bunu yapmamız gerekiyordu.

İnsanların hesaplarında duran bunca parça vardı ama bunların bir araya geldiği ortak bir alan yoktu. Başkalarının neler ürettiğini keşfetmenin bir yolu yoktu. Gününüzün gidişatını değiştirecek bir parçaya tesadüfen rastlama imkânı yoktu.

Cinevva Radio artık yayında. Sekiz istasyon. Topluluk tarafından oluşturulan 362 parça ve bu sayı her geçen gün artıyor. Şarkıların her biri platformdaki biri tarafından yapıldı. Radyoyu açtığınız anda bir şeyler çalıyor. Arama yapmanız gerekmiyor. Karar vermeniz gerekmiyor. Yalnızca dinliyorsunuz.

Soundstage en büyük istasyonumuz. Sinematik ve destansı müziklerden oluşan 111 parça var. Açıkçası bunu beklemiyordum. İnsanlar dramatik, film tarzı müzikler yapmaya bayılıyor.

Discovery hiçbir türe tam olarak uymayan her şeyi bir araya getiriyor. 78 parça. Latin ritimlerinin yanında Afrobeats, onun yanında country, hemen ardındaysa tanımlaması imkânsız bir şey. Bu istasyon çılgınca.

Main Stage pop ve vokalli parçalara ayrıldı. Eksiksiz şarkı sözleri ve vokalleri olan 56 parça var. İnsanlar aşk şarkıları, ayrılık şarkıları, ilahiler ve baladlar yazıyor. Bazıları gerçekten akılda kalıcı.

Voltage rock ve metal istasyonumuz. 53 parça var. Gitar riffleri, punk enerjisi, grunge ve hard rock. Çalışırken bu istasyonu açık tutuyorum.

Lo-Fi Cafe tam da adından bekleyeceğiniz gibi. Ders çalışırken, iş yaparken veya yalnızca keyifli vakit geçirirken dinleyebileceğiniz 25 sakin ambient parça.

Electric Dreams 22 elektronik ve synth parça içeriyor. Synthwave, techno, EDM, drum and bass.

Ivory Tower klasik ve orkestral müzik istasyonumuz. 10 parça var. Piyano eserleri, yaylı düzenlemeleri ve senfonik çalışmalar. Küçük ama büyüyor.

The Cipher hip-hop ve rap istasyonumuz. Şimdilik 7 parça var. En yeni istasyonumuz ve hâlâ kendi sesini buluyor.

Dinlerken ne görüyorsunuz?

Cinevva Radio'yu açtığınızda canlı bir yayınla karşılaşıyorsunuz. Onu bir çalma listesi uygulamasından çok gerçek bir radyo istasyonu gibi düşünün. Parçalar kesintisiz çalıyor. Gerçek zamanlı tepki verebilir, diğer dinleyicilerle sohbet edebilir ve her parçayı kimin yaptığını görebilirsiniz.

İçerik üreticilerinin parçaları çalarken adları ekranda gösteriliyor. Adları, istemleri ve parçanın türü. Hoşunuza giden bir şey duyarsanız onu kimin yaptığını biliyorsunuz. Bu, üzerine bir keşif katmanı eklenmiş, topluluk tarafından oluşturulan içerik. Neyin dinlenmeye değer olduğuna karar veren algoritmalar yok. Aracılar yok. Bir parça yaparsınız, türüne uygun istasyona eklenir ve insanlar onu dinler.

Bu, bir özellikten daha fazlası

Müzik prodüksiyonu onlarca yıl boyunca pahalı yazılımlar, yıllarca eğitim ve çoğu insanın karşılayamayacağı ekipmanlara erişim gerektirdi. Şimdiyse farklı türde bir içerik üreticisinin ortaya çıktığını görüyoruz. Notalar ve ölçüler yerine betimlemeler ve duygularla düşünen insanlar.

"Bozuk bir piyanoyla yağmurlu gece cazı" yaratıcı bir yönlendirmedir. Bu istemi yazan kişi sanatsal bir seçim yaptı. Atmosferi, enstrümanları ve duygusal tonu yönlendirdi. Sadece piyano çalmıyor.

Bunun, ürettikleri eseri daha az geçerli kıldığını düşünmüyorum. Bence bu, "müzisyen" tanımının genişlediği anlamına geliyor. Bella Bay gibi birinin iki haftada sıfırdan yüz parçaya ulaşmasını görmek, yaratma arzusunun hep orada olduğunu gösteriyor. Eksik olan yalnızca araçlardı.

Sırada ne var?

Prodüktörlerin kataloglarını sergileyip takipçi kitlesi oluşturabileceği topluluk profilleri üzerinde çalışıyoruz. Listeler sayfası şimdiden tüm araçlarda oluşturulan topluluk eserlerini gösteriyor ve aynı enerjiyi özellikle müziğe de taşımak istiyoruz.

Ama şu anda radyo yayında. Gidin, dinleyin. Kendi parçalarınızı yapmak isterseniz müzik üreticisini ücretsiz kullanabilirsiniz. Belki sizin parçanız da yayına girer.

Cinevva Radio'yu dinleyin | Müzik yapın | Topluluk eserlerine göz atın

İlgili içerikler:

• Öncü Açık Kaynak Üretken Yapay Zekâ Modelleri — perde arkasındaki yapay zekâ müzik ve ses modelleri
• Oyunlar için Web Audio API — tarayıcıda etkileşimli ses geliştirme
• Vibe coding yeni game jam'dir — niyeti tarif etmenin nasıl başlıca yaratıcı girdiye dönüştüğü

Cinevva CEO'su Mariana Muntean tarafından

Yapay zekâ, salt mantığı ve hesaplama becerisini esasen sıradan bir metaya dönüştürdü. Eskiden yücelttiğimiz becerilerin tümünü — zihinden hesaplama, örüntü tanıma, karmaşık algoritmalar üzerinde yılmadan çalışma yeteneği — artık yapay zekâ yapıyor. Daha hızlı. Daha iyi. Yorulmadan. Bunları hâlâ bilmemiz gerekiyor mu? Kesinlikle, ancak algılar değişiyor. Artık herkesin yeni çağa, sezgisel etkileşim ve sonuçlar çağına uyum sağlaması gerekiyor.

NVIDIA CEO'su Jensen Huang'a göre artık önemli olan, veriler ortaya çıkmadan önce bir “hissi” sezebilmek ve köşenin ardını görebilmek. Teknik okuryazarlık ile derin empatinin kesişimi. Silikonun erişemeyeceği sezgisel anlayış.

Onun kadar güvenilir birinin, tüm yaşam yolculuğumu bu kadar doğrudan doğrulayan bir şey söylediğini daha önce hiç duymamıştım.

SAT ve benim için kurulmamış sistem

Birkaç yıl önce SAT'ye girdim ve başarısız oldum. Bununla gurur duymuyorum ama bir daha da denemedim. Bütün bu süreçte temelden yanlış gelen bir şey vardı ve insanlar ne kadar çok “daha sıkı çalış, tekrar gir” dese de bu duygudan kurtulamadım.

Geriye dönüp baktığımda haklı olduğumu düşünüyorum.

SAT, Amerikan eğitim sistemi için tasarlanmıştır. Kulağa bariz geliyor ama bunun sonuçları oldukça derin. Amerikan liselerinde belirli örüntüler, soru türleri ve problemleri çerçeveleme biçimleri öğretilir. Öğrenciler, ilkokuldan itibaren bu standartlaştırılmış sınav tarzının içinde büyür. SAT'ye girdikleri zamana kadar sınavın ritmini içselleştirmiş olurlar.

Uluslararası öğrenciler bu avantaja sahip değil. Farklı eğitim felsefelerine sahip sistemlerden geliyoruz. Avrupa'daki okullar genellikle kapsam yerine derinliği, çoktan seçmeli sınavlar yerine yazılı sınavları, optik formlar yerine sözlü savunmayı öne çıkarır. Asya sistemlerinin kendi standartlaştırılmış sınavları vardır ancak bunlar farklı şeyleri farklı şekillerde ölçer. Güney Amerika, Afrika ve Orta Doğu'daki eğitim geleneklerinin her biri kendi mantığını taşır.

Uluslararası bir öğrenciyi SAT'ye soktuğunuzda yalnızca bilgisini ölçmezsiniz. İçeriğe hâkim olduğunu göstermeye çalışırken yabancı bir sınav kültürüne ne kadar hızlı uyum sağlayabildiğini de ölçersiniz. Akademik becerisi kadar kültürel akıcılığını da sınarsınız.

Bütün bir yaz boyunca buna hazırlanmam ve sınavdan kusursuz bir sonuç almam bekleniyordu. Baştan sona yeni bir sınav kültürünü öğrenmek, kendi eğitimsel içgüdülerimi unutmak ve Amerikalı kabul görevlilerini etkileyecek bir düzeyde performans göstermek. Hem de yalnızca birkaç ay içinde.

Bunu yapmamayı seçtim.

Gençken farklı şekillerde zekisinizdir. Sezgisel şekillerde. O sırada nedenini tam olarak ifade edemesem de kendime bir yol açıyordum. İçimdeki bir şey bu sistemin bana ait olmadığını biliyordu.

Bunun yerine yaratıcı çizgiyi izlemek

Oyun geliştirme ve tasarımı okudum çünkü insanların oynayıp etkileşime girebileceği sanal dünyalar oluşturmak için yaratıcılığı ve görsel efektleri kullanma fikrine bayılıyordum. Sanat ile teknolojinin, hikâye anlatıcılığı ile etkileşimin kesişimini seviyordum.

Karşılaştığım şey beni şaşkına çevirdi.

Oyunlar ciddi bir teknik derinlik gerektiriyor. Fizik simülasyonları, çarpışma algılama, vektör matematiği, aydınlatma hesaplamaları, optimizasyon. Başlarken bunu biliyordum. Matematik ve mühendislik, oyun geliştirmenin önündeki engeller değil. Oyunların çalışmasını sağlayan unsurların bir parçası.

Sorun, yaratıcı vizyon ile uygulama arasındaki uçurumdu. Sektöre hâkim motorlar ve araçlar, mühendisler tarafından mühendisler için tasarlanmıştı. Her şey “eğer”ler, “o zaman”lar ve düğüm tabanlı görsel betikler üzerinden yürüyordu. Bir girdap efekti mi istiyorsunuz? Gölgelendirici programlamayı öğrenin. Belirli bir aydınlatma atmosferi mi? Malzeme grafiklerinin derinliklerine inin. Doğru hissettiren bir karakter hareketi mi? Karakter denetleyicisindeki veya fizik parametrelerindeki hataları ayıklamak için saatler harcayın.

Görsel düşünen biriyseniz, canlı renkler ve hareketli görüntülerle düşünüyorsanız, fikirler size ses, doku ve duygusal ağırlıkla tamamlanmış sahneler hâlinde geliyorsa herhangi birini geliştirmeden önce bütün bunları teknik dile çevirmek zorundaydınız. Zihninizde aydınlatmasıyla, atmosferiyle ve karakterlerin mekânda hareket edişiyle tamamlanmış bir dünya görürsünüz. Sonra bilgisayarınızın başına oturup karakterinizin neden zeminin içinden düştüğünü ayıklamak için sonraki altı saati harcarsınız.

Teknik temel önemlidir. Ancak araçlar bu karmaşıklığı soyutlamak yerine içerik üreticilerini uygulama ayrıntılarıyla yaşamaya zorluyordu. Oyun oluşturmak, insanların katılabildiği bir hikâye anlatmak veya film yönetmek gibi hissettirmeli. Bu ortamın büyüsü burada. Bunun yerine, daha başlamadan önce bir mühendislik sınavına girmek gibi hissettiriyordu.

Film yönetmenleri vizyonlarını ifade edebilmek için yıllarca fizik motorlarını öğrenmez. Bir bütçeleri ve teknik uygulamayı üstlenen ekipleri vardır. Ancak bağımsız oyun geliştirmede nadiren bütçeniz olur. Sahip olduğunuz şey zaman ve araçlara erişimdir. Teknik biriyseniz harika bir oyun geliştirebilirsiniz. Ama yalnızca öyleyseniz.

Limbo gibi, tekil bir sanatsal vizyona ve bunu hayata geçirecek teknik becerilere sahip küçük bir ekip tarafından yapılan oyunlara böyle kavuştuk. Ya da yaratıcı içgüdü ile programlama becerisinin doğru birleşimine sahip tek bir kişi tarafından büyük ölçüde geliştirilen Undertale'e. Veya Eric Barone'un piksel sanatından müzik bestelemeye ve C# programlamaya kadar her şeyi kendi kendine öğrenmek için yıllarını harcadığı Stardew Valley'e.

Bu oyunlar muazzam zorluklara rağmen başarılı oldu. Ancak her Limbo'ya karşılık, araçlar içerik üreticilerinin sahip olmadığı teknik akıcılığı talep ettiği için yok olup giden milyonlarca yaratıcı vizyon var. Bağımsız oyun geliştiricilerinin %3'ünden azı kayda değer bir başarıya ulaşabiliyor. İçerik üreticileri “eğer”ler ve “o zaman”lardan oluşan bir duvara çarpıp vazgeçtiği için kaç muhteşem oyun hiç geliştirilemedi?

Giriş engeli yaratıcılık değildi. Araçların içine yerleştirilmiş teknik kapı bekçiliğiydi.

Var olması gereken şeyi geliştirmek

Bu nedenle 5 yıl önce farklı bir şey geliştirmeye başladım.

Fikir basitti: Oyun geliştirme, yaratıcı vizyonu olan herkes için erişilebilir olmalı. Kendinizi etkileşimli medya aracılığıyla ifade etmek için bilgisayar bilimi diplomasına ihtiyacınız olmamalı. Yaratıcı insanlar araçlara uyum sağlamak zorunda kalmamalı; araçlar onların gerçekte nasıl düşündüğüne uyum sağlamalı.

Sequoia, Pear, Draper ve onlarca başka firmadaki girişim sermayedarları bunun işe yaramayacağını söyledi. Bu bir B2C işi. Böyle bir pazar yok. Bağımsız geliştiriciler hiçbir şeye para ödemez. Yeteneklerden ödün vermeden oyun geliştirmeyi basitleştiremezsiniz. Oyuncular karmaşık oyunlar ister ve karmaşık oyunlar karmaşık araçlar gerektirir. Pazar analizi kılığına bürünmüş milyonlarca bahane.

İnsanlar bana deli olduğumu söyledi. Belki de öyleydim. Ama aynı soruya dönüp duruyordum: Yaratıcı ifade için neden milyonlarca dolarlık bütçeler ön koşul olsun? Film yönetmenlerinin ve ünlü oyun yapımcılarının ekipleri ve kaynakları var. Geriye kalan herkese ise bir kod editörü ve dua etmek düşüyor. Bu uçurumu kapatacak şeyi geliştirmek istedim. Ne istediğinizi tarif ediyorsunuz ve gözlerinizin önünde gerçekleşiyor. İçimdeki her şey bunun doğru olduğunu biliyordu. Bunu bedenimin her hücresinde hissedebiliyordum.

Bugün binlerce kişi 3D oyun varlıkları, oyunlar, müzikler, seviyeler ve deneyimler için her gün Cinevva'yı kullanıyor. Şimdiye kadar oluşturulan projeler milyonlarca kez görüntülendi. Her geçen gün büyüyor. Sand Hill Road'da yapılan iki dakikalık bir sunum, “SAT'de başarısız oldum ama sezgilerime güvenin” demek için pek de uygun bir format değil.

Sezginin gerçek anlamı

Huang yalnızca felsefi bir noktaya değinmiyordu. Değerli zekânın ne olduğuna ilişkin gerçek bir değişimi tarif ediyordu.

Onlarca yıl boyunca yanlış şeyleri optimize ettik. Ezberleme ve hesaplamayı ödüllendiren eğitim sistemleri kurduk. Daha önce görülmüş problemlerle örüntü eşleştirme becerisini ölçen standartlaştırılmış sınavlar tasarladık. İnsanları, dört yıllık akademik kapı bekçiliğinden sağ çıkabildiklerini kanıtlayan diplomalara göre işe aldık. Yapay zekâ bütün bunları artık daha az özel hâle getirdi.

Yapay zekânın, en azından henüz, yapamadığı şey neyin eksik olduğunu sezmek. Bir şeylerin ters gittiğini hissetmek. İnsanların kendileri ifade edemeden önce neye ihtiyaç duyduklarını sezgisel olarak anlamak. Ortamın havasını okumak. Hiçbir veri kümesinde yer almayan bağlamı anlamak.

Cinevva'yı geliştirirken zamanımı, uluslararası yaşam deneyimimi, paramı ve sezgisel bilgilerimi ortaya koydum. Bu, üniversitede edinilmesi zor bir karışım. SAT ile ölçülmesi zor. Yapay zekâ salt bilişsel gücü bol bulunan bir kaynağa dönüştürmeden önce tasarlanmış herhangi bir yeterlilik sistemine sığdırılması zor.

On altı veya yirmi yıl önce bilgisayar bilimcileri araçların nasıl görünmesi ve çalışması gerektiğine karar verdi. Araçları kendileri ve kendileri gibi düşünen insanlar için geliştirdiler. Geri kalanımızın uyum sağlaması bekleniyordu. O dönem sona eriyor. Bundan sonrasını şekillendirecek kişiler, insanların gerçekte ne istediğini anlayanlar olacak. Bir şeyin ne zaman yanlış, ne zaman doğru olduğunu hissedebilenler. Teknik zarafet için değil, insanlar için geliştirenler.

Sistemin değersiz olduğunu söylediği içimdeki bir şeye güvendim. Ve haklıydım.

İlgili içerikler:

• İş piyasası dönüşüyor — diplomalardan becerilere
• Çevrimiçi Oyun Geliştirme Kursları — geleneksel kapı bekçiliğini aşan, beceri odaklı yollar
• Artık herkes yapay zekâ oyun motoru olmak istiyor — insanların düşünme biçimine uyum sağlayan araçlara yönelik sektörel dönüşüm

Cinevva CTO'su Oleg Sidorkin tarafından

Oyunlarda yapay zekâ, 2024'ün ortaları civarında gerçek bir mayın tarlasına dönüştü. Ortadan kalkan işler. Sıranın kendilerine geleceğine inanan insanlar. Avukatların bile içinden çıkamadığı telif hakkı meseleleri. Dönüp dolaşıp aynı yere gelen bitmek bilmez estetik tartışmaları. Steam'in kimsenin istemediği içeriklere boğulması. Ve tüm bunların altında, artık her üreticinin zihnini kurcalayan o endişe: "Burada gerçekten bir şey mi üretiyorum, yoksa sadece... prompt mu yazıyorum?"

Bir platform işletiyoruz. Bunu yaparken bir şeyi çok hızlı öğreniyorsunuz.

Kimse kandırılmış hissetmekten hoşlanmaz.

Bu rakamlar bizi şaşırttı

Yapay zekâ kullanımının artacağını tahmin ediyorduk. Ama bu kadarını değil. 2025'in sonlarına gelindiğinde tablo şöyleydi:

Kaynaklar: Tom's Hardware / Totally Human Media analizi, GDC 2025 Developer Survey, Unity 2025 Gaming Report

Oyuncuları bu kadar kuşkucu hâle getiren neydi?

Bu kuşku durduk yere ortaya çıkmadı. Gerçekten yanlış giden şeyler oldu. Ve insanlar bunları hatırlıyor.

Seslendirme sanatçıları klonlandıklarını çıkış gününde öğrendi

Tomb Raider 4-6 Remastered, orijinal seslendirmelerin yapay zekâyla oluşturulmuş sürümleriyle piyasaya çıktı. Oyuncular bunu ne zaman öğrendiyse oyuncular da aynı anda öğrendi: çıkış gününde. Yasal baskı arttıktan sonra yayıncı, sesleri sonunda bir yamayla kaldırdı. On bir ay süren SAG-AFTRA grevinin ardındaki nedenlerden biri tam olarak bu senaryoydu.

"Yapay zekâ çöplüğü" artık kullanılan bir ifadeye dönüştü

Call of Duty: Black Ops 6, Steam sayfasına sessiz sedasız bir yapay zekâ açıklaması ekledi. Üstelik oyun çıktıktan sonra. Oyuncular tuhaflıkları zaten fark etmişti: her yere dağılmış görsel hatalar vardı. Yükleme ekranındaki karakterlerden birinin altı parmağı bulunuyordu. "Yapay zekâ çöplüğü", bir şekilde... yanlış görünen her şeyin kısa adı hâline geldi. Ruhsuz. Sanki kimse kontrol edecek kadar önemsememiş gibi.

Bir ödül adaylığı ortadan kalktı

Clair Obscur: Expedition 33'ün Indie Game Awards'daki Yılın Oyunu adaylığı geri çekildi. Oysa yayımlanan oyunda yapay zekâ kullanılmamıştı. Sorun, geliştirme sırasında kullanılan yapay zekâ üretimi geçici içeriklerdi; oyunculara hiç ulaşmayan şirket içi materyaller. Nihai varlıkların tamamı insanlar tarafından yapılmıştı. Fark etmedi. Sınırın tam olarak nerede çizilmesi gerektiği haftalarca tartışıldı.

Yapay zekâya hiç dokunmamış ekipler bile bunu kanıtlamak zorunda kaldı

Chessplus ve Peak, yapay zekâ kullandıkları yönünde suçlamalarla karşılaştı. İkisi de hiç kullanmamıştı. İkisi de ödül adayıydı. Her iki geliştirme ekibi de çalışmalarının elle yapıldığını kanıtlamak için eski ekran görüntülerini ve katman dosyalarını bulup çıkarmak zorunda kaldı. Peak ekibi durumu en iyi şekilde özetledi: "Çöp olabiliriz ama insan yapımı, yerel kaynaklı, zanaatkâr işi çöpüz."

Stüdyolar tamamen zıt yönlere gitti

SNK — Fatal Fury: City of the Wolves fragmanında yapay zekâ ürünü gibi görünen görseller ortaya çıkınca Discord moderatörleri görevi bıraktı. Games Workshop — tüm Warhammer yapımlarında yapay zekâyı tamamen yasakladı. Larian Studios — Baldur's Gate 3'te yapay zekâyı yalnızca çok erken aşamadaki konsept eskizleri için kullandıklarını, nihai oyunda hiçbir yapay zekâ içeriğinin bulunmadığını söyledi. Tim Sweeney — Steam'in yapay zekâ etiketlerinin değersiz olduğunu ve kaldırılması gerektiğini ilan etti. Valve — yapay zekâ etiketlerinden şikâyet eden geliştiricilerin genellikle işlerinin "özensiz" görünmesinden endişe ettiğini söyleyerek karşılık verdi.

Oyun keşfetmek bir güven sorununa dönüştü

Artık içerikler, herhangi birinin doğru düzgün değerlendirebileceğinden daha hızlı üretiliyor. Sorular değişti:

Ben burada tam olarak neye bakıyorum? Bunu kim yaptı? Buna harcadığım zamandan pişman olacak mıyım? Bunların herhangi biri fragmanda vaat edilenlerle uyuşuyor mu?

Muhtemelen büyük bir uzlaşma gelmeyecek. Yapay zekâ ile insan yapımı içerikler konusunda kesin bir hüküm de çıkmayacak.

Daha olası olan şu: filtreler, gerçek şeffaflık ve dürüstlüğü teşvik eden yapılar.

Tüm bunların ortasında kalan küçük stüdyolar

Bağımsız geliştiriciler kendilerini tuhaf bir konumda buldu.

Avantajları gerçekten göz ardı etmek zor: Daha hızlı yineleme yapabiliyorsunuz. Dört kişi her şeyi üretirken maliyetler düşüyor. Tek başına çalışan geliştiriciler artık projelerini gerçekten tamamlayabiliyor. Yerelleştirme artık tüm bütçenizi tüketmiyor.

Dezavantajları da bir o kadar gerçek: Jenerik hissettiren çıktılar. Avukatların henüz dokunmak istemediği eğitim verileri ve fikrî mülkiyet sorunları. Tam olarak anlamadığınız sistemleri yayımlamak; bazıları buna kavrama borcu diyor. Düşük emekli oyun seliyle aynı kefeye konmak. Ankete katılan geliştiricilerin neredeyse yarısı, yapay zekânın oyunları genel olarak kötüleştirdiğini düşünüyor.

Unity'nin 2025 raporuna göre geliştiricilerin %79'u yapay zekâ araçlarına olumlu bakıyor. Bu oldukça kesin bir sonuç gibi görünüyor. Gerçek ise daha karmaşık. Bunu iyi yapan ekipler, yapay zekâyı genellikle sıkıcı kısımlar için kullanıyor: angarya işler, kaba taslaklar, kalite güvencesinin monoton görevleri. Yaratıcı yönetim mi? O, insanda kalıyor.

Cinevva'nın duruşu: yapay zekâ konusunda tarafsız, dürüstlük konusunda katı

Yapay zekâ kullandıkları için oyunları geri çevirmiyoruz. Onlara özel muamele de yapmıyoruz.

Kural basit: yapay zekâ kullanıldıysa bunu söyleyin. Oyuncular neyi önemsediklerine kendileri karar versin. Böylece filtreler gerçekten işe yarar.

• Yapay zekâ üretimi içerik politikası

Filtreler tartışmalardan daha iyi çalışır

Oyunlardaki yapay zekâ tartışması yakın zamanda bir uzlaşmaya varmayacak. Muhtemelen hiçbir zaman varmayacak. Ancak bireysel tercihler yeterince net.

Bazı oyuncular özellikle insan yönetiminde üretilmiş sanat eserleri istiyor. Bir insanın kaleminden çıkmış metinler. Görünür bir zanaatkârlık.

Bazılarıysa gerçekten umursamıyor. Eğlence eğlencedir.

Filtreler, her iki grubun da aradığını bulmasını sağlar. Kimsenin kazanması gerekmez.

Ödeme modelleri herkesin fikrinden daha önemlidir

Gelir, birim satış yerine oynama süresine bağlandığında para kazanmak için şunları yaparsınız:

Oyuncuların ilgisini hızla çekmek. Dikkatlerini korumak. Pazarlamanızda vadettiğiniz şeyi sunmak.

Kalite, izlenecek en bariz yol hâline gelir. Oyunu nasıl yaptığınızın önemi azalır.

Fragmanınızda yerine getiremeyeceğiniz vaatlerde mi bulundunuz? Oyuncular hemen gider. Oyuncu tutma oranı dibe vurur. Onlara ne alacaklarını aynen mi gösterdiniz? Oynamaya devam ederler. Oynama süresi artar. Gelir gelir. Ekonomi kendi dengesini bulur.

2026 muhtemelen neler getirecek?

Daha fazla düzenleme — AB Yapay Zekâ Yasası genişlemeye devam ediyor. Özellikle SAG-AFTRA'nın ardından ABD'de ses ve görünüş haklarına yönelik korumalar artıyor.

Uzmanlaşmış araçlar — Özellikle küçük ekipler için geliştirilmiş yapay zekâ. Kontrolün insanlarda kalması için tasarlanmış araçlar.

Daha akıllı etiketler — "Yapay zekâyla yapıldı" ifadesi fazla kaba bir ayrım. Yapay zekâ destekli iş akışları ile yapay zekâ üretimi nihai varlıklar arasında ayrımlar görmeyi bekleyin.

Kitlelerin ayrışması — Bazı oyuncular bilinçli olarak geleneksel yöntemlerle yapılmış oyunları arayacak. Bazılarıysa bunu hiç düşünmeyecek. Her iki grup da kendileri için ürün geliştirmeye yetecek kadar büyük.

Platform rekabeti — Mağazaların şeffaflık ve keşif süreçlerini nasıl yönettiği gerçek bir farklılaştırıcı hâline gelecek.

İşleri gerçekten ileriye taşıyan ne?

Tartışmak, yapay zekâ meselesini çözüme kavuşturmayacak. Şunlar kavuşturabilir:

1. Oyuncuların kendileri için gerçekten önemli olan şeylere göre seçim yapması
2. Üreticilerin nasıl çalıştıkları konusunda dürüst olması
3. Platformların iki grubun birbirini bulmasına yardımcı olacak araçlar geliştirmesi

Yapay zekâ sonrası ekonomi budur. Birbiriyle savaşan kamplar değil. Her şeyi bir arada tutan güven.

İlgili içerikler:

• Yapay zekâ üretimi içerik politikası
• Oyun üreticileri için
• SSS
• Öncü açık kaynak üretken yapay zekâ modelleri — belirli modeller ve nasıl çalıştıkları
• Açık kaynak dünyasında bir yapay zekâ kirliliği sorunu var — yapay zekâ çıktıları açık kaynak projelerini istila ettiğinde neler oluyor

Cinevva CTO'su Oleg Sidorkin tarafından

Kuzenimin 2023'te onur derecesiyle mezun oluşunu izledim. İyi bir devlet üniversitesinden bilgisayar bilimi diploması vardı. Not ortalaması da iyiydi. Bir işe girmeden önce on dört ay boyunca başvurular yaptı. Bu sırada, bağımsız oyunlar geliştirmek için ikinci sınıfta üniversiteyi bırakan bir arkadaşım iş aramaya karar verdikten sonraki bir ay içinde üç teklif aldı.

Bu artık sıra dışı bir durum değil. Genel eğilim bu.

Rakamlar sonunda bir süredir hissettiklerimizi doğruladı

2025 itibarıyla İK liderlerinin %90'ı, geleneksel dört yıllık üniversite diploması olmayan adayları da işe aldıklarını bildirdi (Fortune). ABD'deki şirketlerin dörtte biri lisans diploması şartını tamamen kaldırdı (HR Dive). Eğitim kredilerinizi daha yeni ödediyseniz canınızı sıkacak kısım ise şu: İşverenlerin %94'ü, becerileri temel alınarak işe alınanların diplomalarına göre işe alınanlardan daha iyi performans gösterdiğini söylüyor (Forbes).

Verizon artık pozisyonlarının %99'u için üniversite diploması gerekmediğini söylüyor. Sergey Brin, Google'ın lisans diploması olmayan "tonlarca" kişiyi işe aldığını kabul etti. IBM ise "New Collar" programıyla ABD'deki açık pozisyonlarının yarısında diploma şartını isteğe bağlı hâle getirdi.

Bunun nedeni şirketlerin yardımsever davranması değil. Diplomaların, birinin işinde gerçekten iyi olup olmayacağını öngörmediğini fark ettiler.

Eski sistem neden bozuldu?

Dürüst cevap mı? Diplomalar kolaycı bir eleme aracına dönüştü.

İşe alım yaparken önünüzde 400 başvuru varsa lisans diploması istemek yığını yarıya indirir. Ama size işi gerçekten kimin yapabileceğini söylemez. Yalnızca dört yıl boyunca sınıflarda oturacak parası, zamanı ve aile düzeni olanları gösterir. Bunun yetenekle ilişkisi, her zaman varsaydığımızdan daha zayıftı.

Şimdiyse aynı anda üç şey oldu:

Beceriler çok hızlı değişti. Oyun motorları, yapay zekâ araçları, web framework'leri... Bir müfredat komitesi herhangi bir konuda dersi onaylayana kadar o konu çoktan güncelliğini yitirmiş oluyor. Dört yıllık bir program size dört yıl öncesinin teorisini öğretiyor. Teknoloji dünyasında bu, tarih öncesi demek.

Portföyler görmezden gelinemeyecek hâle geldi. Birinin kod yazıp yazamadığını GitHub hesabına bakarak görebilecekken neden tahminde bulunasınız? itch.io sayfasında oyuncu yorumları bulunan beş tamamlanmış proje varken bir oyunu yayımlayıp yayımlayamayacağını neden merak edesiniz?

Şirketler çaresiz kaldı. Yetenek açığı gerçek. Diploması olmayan herkesi elemek, tam da ihtiyacınız olan kişileri dışarıda bırakmak anlamına geliyor. Bazı işe alım yöneticileri, kendi kendini yetiştirmiş geliştiricilerin diplomalı çalışanlarına fark attığını gördükten sonra bunu zor yoldan öğrendi.

Oyun sektörü bunun geleceğini gördü

Oyun sektörünün bu konuda diğerlerinden ileride olduğunu düşünüyorum ve nedenini anlamaya değer.

Stüdyolar hangi okulda okuduğunuzla hiçbir zaman gerçekten ilgilenmedi. Hangi projeleri yayımladığınızla ilgilendiler. İyi işlenmiş, 48 saatlik bir game jam oyunu, bir işe alım yöneticisine dört yıllık oyun tasarımı diplomasından çok daha fazlasını anlatır. Baskı altında işleri tamamlayabildiğinizi kanıtlar. Kapsam konusunda zor kararlar alabildiğinizi gösterir. Oyunun yalnızca teoride kalmadığını, gerçekten oynanabilir olduğunu kanıtlar.

2026'da oyun sektörüne girmeye çalışıyorsanız gerçekten önemli olanlar şunlar (Dice, CombineGR): iyi işlenmiş ve oynanabilir iki veya üç demo. Ne yaptığınızı ve neden yaptığınızı açıklayan vaka çalışmaları. Başladığınız işleri bitirdiğinize dair kanıtlar. Gerçek projelerle sergilenen, en az bir önemli oyun motoruna hâkimiyet.

İşe alım yöneticileri potansiyel aramıyor. Kanıt arıyorlar.

Kimsenin konuşmadığı rahatsız edici gerçek

Araştırmaları incelerken beni hayal kırıklığına uğratan bir şey oldu.

Harvard/Burning Glass araştırması, diploma şartını kaldıran şirketlerin çoğu zaman diplomasız adayları daha fazla işe almadığını ortaya koydu. Artış yalnızca yaklaşık 3,5 yüzde puandı (Forbes). Politika değişti. İşe alım uygulamaları ise geride kaldı.

Bu, geleneksel olmayan bir yol izliyorsanız hâlâ daha çok çalışmanız gerektiği anlamına geliyor. Kapı eskisinden daha açık, ancak henüz diğerleriyle eşit koşullarda içeri girmiyorsunuz. Portföyünüzün görmezden gelinemeyecek kadar güçlü olması gerekiyor. Projeleriniz, bir başkasının diplomasından daha yüksek sesle konuşmalı.

Bu adil değil. Ancak bunu bilmek hazırlanmanıza yardımcı olur.

Şu anda yolun başında olan birine ne söylerdim?

Okuyorsanız okulunuzu bırakmayın. Ancak diplomanın artık tek başına yeterli olmadığını anlayın. Bir yandan projeler geliştirin. Game jam'lere katılın. Bir Google Kariyer Sertifikası veya Unity sertifikası alın. Diplomanızı tek geçerli belge olarak değil, sahip olduğunuz birkaç yeterlilik belgesinden biri olarak görün.

Üniversite diploması almıyorsanız farklı bir yolunuz var ama bu yol mutlaka daha zor değil. Yoğun biçimde üretin. Projelerinizi yayımlayın. Her şeyi belgeleyin. GitHub hesabınız, itch.io sayfanız ve kişisel siteniz... Artık yeterlilik belgeniz bunlar.

Hangi yolu seçerseniz seçin, çalışmalarınızı açıklama pratiği yapın. Yalnızca ne geliştirdiğinizi değil, yaptığınız seçimleri neden yaptığınızı da anlatın. Neleri farklı yapardınız? Neler öğrendiniz? Mülakat yapanlar, düşünce süreçlerini açıkça ifade edebilen kişileri hatırlar.

Bu, işe alımdan daha büyük bir değişim

Burada yaşananlar yalnızca şirketlerin pozisyonları doldurma biçimindeki bir değişim değil. Toplum olarak nelere değer verdiğimiz de değişiyor.

Yeterlilik belgeleri onlarca yıl boyunca bir filtre işlevi gördü. Pahalı ve zaman alıcıydılar ama anlaşılması kolaydı. Birinin diploması varsa onun hakkında belirli varsayımlarda bulunabiliyordunuz. Bu, doğrudan bir ölçüm değil bir sinyaldi ama yeterince işe yarıyordu.

Şimdiyse bu sinyal zayıflıyor. Teknoloji, birinin gerçekten neler yapabildiğini görmeyi mümkün kılıyor. Uzaktan çalışma, nerede oturduğunuzdan çok ortaya koyduğunuz sonuçların önemli olduğunu kanıtladı. Yapay zekâ, teorik bilgiyi pratik uygulamadan daha az değerli hâle getiriyor.

Geçiş süreci karmaşık olsa da bunu gerçekten umut verici buluyorum. Eskiden "Nerede okudun?" diye sorulurdu. Şimdiyse "Ne geliştirebilirsin?" diye soruluyor.

Bu daha iyi bir soru.

Kaynaklar

• Fortune: İK liderlerinin %90'ı geleneksel diplomaların dışından işe alım yapıyor
• Forbes: Şirketlerin %90'ı becerilere dayalı işe alımlarda daha iyi sonuç alıyor
• Forbes: Şirketler diploma şartını kaldırıyor ancak diplomasız çalışanları çok az işe alıyor
• HR Dive: İşverenler diploma şartlarını kaldırıyor
• Computerworld: Teknoloji şirketleri üniversite şartından uzaklaşıyor
• Dice: 2025'te oyun tasarımcısı olmayı hedefleyenler
• CombineGR: 2025 Küresel Oyun Sektörü İstihdam Görünümü

İlgili içerikler:

• Game jam'lerde nasıl başarılı olunur?
• Çevrimiçi Oyun Geliştirme Kursları — her bütçeye uygun, beceri odaklı öğrenme yolları
• Ajan tabanlı yapay zekâ kodlama araçları — hangi becerilerin önemli olduğunu yeniden şekillendiren araçlar
• Sezgisel zihin — sezginin neden yeterlilik belgelerinden daha önemli olduğu