Three.js Nedir? WebGL'in Modern Tercümanı

WebGL ile çalışmak, bir duvarı tuğla tuğla örerken aynı zamanda çimentonun kimyasını da düşünmeye benzer. Shader’lar, buffer yönetimi, matris çarpımları, ışık hesapları… Hepsi senin sorumluluğundadır.

Bu “düşük seviye” güç, sınırsız kontrol verir; ama giriş bariyerini yükseltir: tek bir üçgen için bile ciddi kurulum ve debug döngüsü gerekir.

Bunun temel sebebi WebGL’in bir state machine gibi çalışmasıdır: her çizimde hangi program (shader), hangi veri (buffer) ve hangi ayarların (blend, depth, cull, viewport) aktif olduğunu tek tek yönetirsin. Yani çizmek, sadece “çiz” demek değil; sahnenin o anki tüm durumunu doğru kurmak demektir.

Pratikte bu, “bir kare çiz” yerine şu tür soruların cevabını sürekli vermek demektir: hangi shader programı aktif, hangi VAO/VBO bağlı, attribute’lar nasıl okunuyor, uniform’lar güncel mi, depth test açık mı, hangi framebuffer’a çiziyorum? Bu yüzden WebGL’de hata çoğu zaman “matematik yanlış”tan çok, yanlış state kombinasyonundan çıkar.

Three.js ise sana hazır, güvenilir bir iskelet sunar: sahne kurarsın, ışık eklersin, kamera seçersin, modeli yüklersin. Yani “piksel üretmek” yerine “dünya kurmak” üzerine düşünürsün.

Three.js’in yaptığı kritik iş şudur: bu state karmaşasını senin yerine yönetir. Doğru zamanda doğru buffer’ı bağlar, materyale göre uygun shader varyasyonlarını seçer, kamera/projection matrislerini taşır, viewport/pixel ratio gibi detayları daha “doğal” bir akışa oturtur. Böylece sen, “ne çiziyorum ve nasıl bir his istiyorum?” sorusuna daha çok odaklanırsın.

Bu soyutlama, günlük geliştirmede şu nesnelerle okunur: WebGLRenderer çizimi yönetir, Scene grafiği tutar, Camera bakışı üretir; modeller genelde BufferGeometry + Material birleşiminden oluşur. İhtiyaç olursa da ShaderMaterial ile “Three.js içinde WebGL”e geri dönersin.

Trade-off sezgisi: Three.js seni hızlandırır; ama “neden böyle render ediyor?” sorusunun cevabı bazen WebGL tarafında gizlidir. Bu yüzden ileri seviyede GPU vs CPU ve Matrix gibi konularla birlikte okumak, debug’ı çok daha az sürprizli yapar.

Kaçış kapısı: Three.js yüksek seviye olsa da “kilitli kutu” değildir. İhtiyaç olduğunda kendi shader’ına inebilir, custom materyal yazabilir veya pipeline’ı daha derin kontrol edebilirsin. Bu esneklik için Shader Nedir? sayfası iyi bir köprüdür.

Pratik bağ: WebGL pipeline sezgisini almak için Canvas vs WebGL iyi bir başlangıçtır. Render ritmini de birlikte düşünmek için Render Loop Mantığı ve requestAnimationFrame sayfaları da iyi tamamlayıcılardır.

Three.js’in en büyük başarısı, 3D dünyayı bir sinema seti gibi kurgulatmasıdır: Scene evrendir, Camera bakıştır, Renderer görüntüyü üreten motordur, Mesh ise geometri + materyalden oluşan varlıktır. Pratikte bu dörtlüyü ayırabildiğinde debug da kolaylaşır: sorun “sahnede var mı?”, “kamera gerçekten onu görüyor mu?”, “materyal/ışık beklediğim gibi mi?” gibi katmanlara ayrışır.

Tek bir karede zihninde şu sırayı canlandırabilirsin: önce sahne grafığındaki dönüşümler hesaplanır, sonra Renderer (ör. WebGLRenderer) sahneyi seçilen Camera ile dolaşır; görünür Mesh örnekleri için uygun çizim komutları üretilir. Yani “dünya durumu” ile “bakış + projeksiyon” birleşince ekrandaki görüntü ortaya çıkar.

Bu model, sahneyi “liste” değil “hiyerarşi” olarak düşünmeyi de getirir: objeler parent/child ilişkileriyle bağlanır; dönüşümler zincirlenir. Bu yüzden Three.js’te sahne kurmak, aynı zamanda bir scene graph tasarlamaktır. Grafikte yalnızca Mesh yoktur; Group gibi boş düğümler organizasyon için durur, Light gibi öğeler de sahneye eklenerek materyallerin aydınlanma hesaplarına girer.

Hiyerarşinin matematik yüzü şudur: her düğümün yerel dönüşümü vardır; ebeveynlerin zinciri ise onu dünya uzayına taşıyan matrixWorld (ve benzeri) birikimini üretir. Bu yüzden “objeyi oynattım ama beklediğim yerde değil” hissi çoğu zaman grafiğin kurulma biçiminden kaynaklanır.

HoloDepth bağı: Bu dörtlü; ByteOmi’deki Core & Script Base akışının da omurgasıdır: “core” sahneyi ve render yaşam döngüsünü taşır, “script” ise davranışı (update mantığı) katmanlar.

Pratik bağ: Uzay ve eksen sezgisi için Koordinat Sistemleri; kare kare akışı netleştirmek için Render Loop Mantığı sayfası bu bölümle doğrudan örtüşür.

Three.js sadece “kolay” olduğu için değil; devasa bir ekosistem sunduğu için endüstri standardı oldu. Hazır geometriler ve PBR materyallerle saniyeler içinde sahne kurabilir, GLTF/OBJ gibi formatlarla modelleri tek akışta içeri alabilirsin. Üstüne Loader katmanı, kamera kontrolleri, ışınlama yardımcıları ve bol örnekli dokümantasyon “ilk çalışan prototip”e giden yolu kısaltır; yani kütüphane tek başına değil, etrafındaki araçlar da üretkenliği büyütür.

“Standart” olmanın pratik karşılığı da taşınabilirliktir: glTF gibi yaygın bir aktarım formatıyla model/ materyal/ animasyon paketini tasarım aracından çıkarıp web tarafına taşımak mümkün olur. Bu, ekipler arasında ortak dil üretir: “sahne”, “kamera”, “materyal” tartışmaları hem ürün hem mühendislik tarafında aynı çerçeveye oturur.

Matematik kütüphanesi (vektör, matris, quaternion) 3D’nin zor kısımlarını optimize eder; topluluk ise karşılaştığın pek çok görsel/perf problemine hızlı çözüm bulmanı sağlar. Bu kombinasyon, üretim hızını ciddi biçimde yükseltir. Ayrıca üçüncü parti eklentiler (UI katmanları, editör entegrasyonları, oyun/etkileşim kütüphaneleri) çoğu zaman Three.js’in sahne modeline yaslanır; bu da öğrendiğin kavramların başka projelerde de “transfer edilebilir” olmasını sağlar.

Gerçekçi not: Ekosistem güçlü olsa da sınır hâlâ tarayıcı ve WebGL gerçekliğidir: bellek bütçesi, shader maliyeti, mobil GPU farkları gibi konular “sihirli çözüm” değildir. Bu yüzden performans sezgisi için GPU vs CPU perspektifini ayrı tutmak faydalıdır.

Pratik bağ: Matematik omurgasını pekiştirmek için Vector Mantığı ve Matrix sayfaları, bu bölümde geçen dönüşüm/ışık tartışmalarına doğrudan destek verir.

HoloDepth’te Three.js’i seçmemizin nedeni, “hazır araçlar” ile “derin kontrol” arasında iyi bir köprü olmasıdır. Hızlı sahne kurarsın; ama istediğinde shader seviyesine iner, matris manipülasyonları yapar ve performans zincirini daha bilinçli yönetirsin. Böylece öğretim tarafında “görsel sonuç” ile “alttaki mekanizma” arasında gidip gelebilirsin; ürün tarafında ise aynı omurga hem prototip hem ileri deneylere genişler.

Bu yüzden HoloDepth’in “boş ama güçlü” dünyası, Three.js’in esnek omurgası üzerine inşa edilir: çekirdek sade kalır, üstüne script/preset/deney katmanları eklenir. “Boş” olması, sana dayatılmış bir oyun döngüsü veya görsel tarz demek değildir; HoloDepth’in sunduğu zemin, kendi kural setini ve etkileşim dilini üst katmanda tanımlaman için bilinçli olarak minimal tutulur.

Bu ayrımın pratik faydası şudur: sahne ve render ritminin tutarlı kalması “çekirdek” sorumluluğunda kalırken; senaryo/preset/deney gibi parçalar daha izole evrilebilir. Bu mimari çizgiyi Core & Script Base sayfasında da aynı kelimelerle görürsün: çekirdek yaşam döngüsünü taşır, script davranışı katmanlar.

Kare disiplini: HoloDepth’te akıcı his, yalnızca Three.js seçimiyle değil; güncelleme ve çizim aşamalarının birbirine karışmamasıyla da korunur. Bu yüzden çekirdek tarafını düşünürken Render Loop Mantığı sayfasındaki “update / draw” ayrımını zihninde açık tutmak, ileride yaşayacağın sürprizleri azaltır.

Three.js’in parçalarını bir yapboz gibi birleştirip sonucu anında görmek ister misin? Laboratuvarda scene graph’ı keşfeder, ışık/materyal preset’leri arasında geçiş yapar ve GLTF yüklemenin neden bu kadar “sihirli” göründüğünü adım adım izlersin. Amaç “oyun motoru yazmak” değil; parçaların birbirine nasıl bağlandığını hissederek, dokümantasyonda gördüğün API isimlerinin sahne içindeki karşılığını pekiştirmektir.

Pratik bağ: Lab’da ışık/materyal oynadıkça shader sezgisi ister hale gelir; bunun için Shader Nedir? iyi bir sonraki adımdır. Transform ve eksen kafa karışıklığında ise Koordinat Sistemleri sayfası, sahne grafığıyla birlikte okununca daha az “tahmin”e bırakır.