WebGL’e giriş: doğrudan GPU erişimi

WebGL, tarayıcıda çalışan bir JavaScript API’si üzerinden ekran kartının (GPU) paralel işlem gücüne erişmenizi sağlar. Buradaki kritik fikir şudur: CPU genelde az sayıda işi çok hızlı sıraya koyma konusunda iyiyken, GPU aynı türden işi çok büyük sayılarda (binlerce–milyonlarca) eşzamanlı yürütmek için tasarlanmıştır. WebGL, 2D/3D çizimi bu paralel yapıya taşıyarak daha yoğun sahneleri daha akıcı işleyebilmenin kapısını açar.

• GPU erişimi: WebGL, geometri (vertex) ve piksel (fragment) hesaplarını GPU’nun paralel hattına taşır. Bu, sahnede obje sayısı, detay seviyesi veya ekran çözünürlüğü arttıkça “tek tek hesaplama” yaklaşımına göre çok daha avantajlı bir ölçeklenme sağlar.
• Canvas vs WebGL: 2D Canvas’ta çoğu işlem CPU tarafında “pikselleri üretip boyamak” şeklinde ilerler; WebGL’de ise siz veriyi (koordinatlar, renkler, doku bilgisi) bir kez GPU’ya uygun formatta hazırlarsınız, GPU bunu bir üretim hattı gibi işler. Bu yüzden WebGL yaklaşımı, tekrar eden çizim işlerinde ve çok sayıda öğe söz konusu olduğunda daha verimlidir.

Kısaca: Canvas “tek tek çizim” hissi verir; WebGL “veriyi hat üzerinden akıtıp sonuç almak” mantığıyla çalışır.

Bu ikili arasındaki ilişkiyi doğru okumak, HoloDepth projelerinde “neden böyle çalışıyor?” sorusunu cevaplayabilmenizi sağlar: Three.js sizi hızlandırır; WebGL ise sahnenin ekrana nasıl düştüğünü ham sözleşmelerle gösterir.

• Three.js (abstraction): Sahnede düşündüğünüz kavramları “paketler”: kamera, ışık, materyal, mesh, gölge, post-process… Siz niyeti tanımlarsınız; Three.js bu niyeti WebGL’in beklediği veriye dönüştürür.
• WebGL (low-level): Kavram yerine veri + program vardır. “Işık” bir sınıf değil; shader içinde tanımlanan aydınlatma hesabıdır. “Model” bir nesne değil; GPU’ya taşınan koordinat/normal/UV dizileridir (buffer’lar).

Altın cümle: Three.js, sahne yönetimini (kamera, ışık, materyal, hiyerarşi) sizin yerinize WebGL komutlarına çeviren bir “çevirmen” gibidir. Siz üstte ne istediğinizi söylersiniz; altta WebGL tarafı nasıl çizileceğini belirler.

Bu yüzden WebGL öğrenmek, “Three.js’i bırakmak” değil; Three.js’in kararlarını daha iyi anlamak ve gerektiğinde sınırlarını aşmak demektir: özel shader’lar, beklenmedik performans darboğazları veya “neden böyle görünüyor?” gibi görüntü hataları burada çözülür.

“Ben aslında neyin üstünde çalışıyordum?” sorusunun cevabı bu akışta gizlidir: üst katmanlar niyet üretir, alt katmanlar bu niyeti veri + çizim komutuna çevirir. En sonda GPU, bu komutların sonucunu ekrana pikseller olarak yazar.

Önemli ayrım: burada “sihir” yoktur; yalnızca bir veri akışı vardır. Nesneler, dönüşümler, materyaller, ışık hesapları… hepsi eninde sonunda shader’ların tükettiği sayılara ve GPU’nun çalıştırdığı programlara dönüşür.

• Scene (HoloDepth): Sen sahne grafiğini kurarsın: hangi nesne nerede, hangisi hangisinin çocuğu, hangi materyal hangi geometriyle eşleşiyor.
• Three.js: Bu yapıyı “çizilebilir” hâle getirir: dönüşüm matrisleri, kamera/projeksiyon bilgisi, materyal parametreleri ve görünürlük gibi kararlar hesaplanır.
• WebGL: GPU’nun anlayacağı sözleşmeye iner: shader’lar derlenir/bağlanır, buffer’lar (attribute verisi) hazırlanır, uniform’lar güncellenir ve uygun draw call’lar çalıştırılır.
• GPU: Verteksleri işler, primitive’leri rasterize eder, fragment hesaplarını yürütür ve sonuç pikselleri framebuffer’a yazar.

Küçük teknik not: GPU ne kadar hızlı olursa olsun, tarayıcıdaki animasyon döngüsü genelde requestAnimationFrame ile çalışır ve pratikte ekranın yenileme hızına (refresh rate) “kilitli” bir üst sınıra yaklaşır. Yani bazı sahnelerde limit GPU değil; ekran + zamanlayıcı sözleşmesi olabilir.

Bu zinciri net görmek, hem performans darboğazlarını “hangi halka?” diye teşhis etmenizi sağlar, hem de özel efektlerde nerede müdahale edeceğinizi (shader mı, veri mi, çizim çağrısı mı?) belirginleştirir.

Three.js varken neden daha zor olan WebGL ile uğraşasınız? Çünkü bazı hedefler “üst katmanda” doğal olarak tıkanır: ya sınır performans olur, ya ihtiyaç özel görsel kurallar ister, ya da bir sorun çıktığında teşhis için “motorun dili”ne inmek gerekir.

WebGL öğrenmek burada bir “teknoloji değiştirme” kararı değil; kontrol ve açıklanabilirlik kararıdır. Üst katmanda her şey “çalışıyor” görünebilir; ama siz, hangi maliyetin nerede doğduğunu ve görüntünün hangi aşamada şekillendiğini bilirseniz, daha bilinçli tasarım yaparsınız.

• Performans için doğru kaldıraçlar: Yavaşlık her zaman “daha güçlü cihaz” ile çözülmez. WebGL bilgisi, darboğazın nerede olduğunu anlamanızı sağlar: çok mu fazla draw call, yanlış veri düzeni mi, shader mı pahalı, yoksa fill-rate mi tükendi? Doğru parçayı hedeflemek, en büyük kazançtır. Bazı optimizasyonlar “az çiz” (geometri/instancing), bazıları “az çağır” (batching), bazıları “daha ucuz hesapla” (shader maliyeti) prensibine dayanır — WebGL bunun haritasını verir.
• Custom shaders (kendi görsel kuralların): Standart materyaller yetmediğinde (su, neon, hologram, tarama çizgileri, glitch) “görüntünün yasasını” shader ile yazarsınız. Buradaki güç, “efekt eklemek”ten daha fazlasıdır: sahnenin stilini, ışık tepkisini ve hatta materyal modelini kendi estetiğinize göre tanımlarsınız.
• Teşhis ve bağımsızlık: Bir bug oluştuğunda veya “neden böyle görünüyor?” dediğinizde, cevap çoğu zaman verinin GPU’ya nasıl gittiğinde saklıdır. WebGL bilmek, problemi kütüphanenin dışına atmadan, en temel çarklarda çözebilme yeteneği kazandırır: yanlış attribute bağlama, hatalı uniform güncelleme, renk uzayı karışıklığı, precision sorunları veya karışan blend modları gibi konular burada netleşir.
• Taşınabilir temel: WebGL; buffer, shader ve pipeline kavramları üzerinden düşünmeyi öğretir. Bu zihinsel model, yalnızca bu projede değil; başka motorlar, başka API’ler ve farklı platformlarda da aynı mantıkla iş görür. Özellikle WebGPU’ya geçerken; “veriyi GPU’ya doğru formatta taşımak”, “pipeline’ı okumak” ve “shader mantığını kurmak” gibi kaslarınızı hazır bulursunuz.

Özet: WebGL öğrenmek, Three.js’in yerine geçmek değil; Three.js’in üstte verdiği kararların altta neye dönüştüğünü bilmek ve gerektiğinde kontrol alanını genişletmek demektir.

WebGL dünyasına adım attığımızda, Three.js’in o konforlu alanından çıkıp şu teknik yapılarla tanışacağız:

• Buffers: GPU belleğine yüklenen ham sayısal veri. Geometriyi (pozisyon, normal, UV), renkleri veya indeksleri burada taşırız. “Model” dediğiniz şey, eninde sonunda bu dizilere iner.
• Shaders (GLSL): GPU üzerinde çalışan küçük programlar. Vertekslerin ekrana nasıl projekte edileceğini ve piksellerin hangi renge dönüşeceğini belirler. Işıklandırma, doku okuma ve efektlerin çoğu burada yaşar.
• Matrices: Dönüşüm matematiğinin taşıyıcıları. Nesneyi sahnede taşır, döndürür, ölçekler; kameraya göre hizalar ve perspektif projeksiyonu uygular. WebGL’de “uzay” hissini kuran temel araçtır.
• Pipeline: Verinin GPU’da aşama aşama işlenip piksellere dönüşmesi. Attribute → vertex shader → rasterizasyon → fragment shader → framebuffer hattı, her adımda neyin “ucuz/pahalı” olduğunu anlatan ana haritadır.

Bu sayfalarda hedefimiz, bu yapı taşlarını tek tek somutlaştırmak: veriyi nasıl düzenleriz, shader’a nasıl bağlarız, matrisleri neden/nerede kullanırız ve pipeline’da performansı nasıl okuruz.