Render Pipeline: bir kare nasıl doğar?

Bir kareyi yalnızca «şu an ne görünüyor?» diye düşünmek kolaydır; fakat donanım için her kare, komutların sırayla işlenmesiyle üretilen bir çıktıdır. Pipeline boyunca veri dönüşür: sahne grafiğindeki dünya uzayından başlayıp clip uzayına, oradan ekran koordinatlarına, en sonda da renk derinlik tamponlarına kadar ilerler. Bu yüzden küçük bir sıra hatası — örneğin yanlış temizlenmiş derinlik tamponu veya yanlış zamanda çizilmiş şeffaf yüzey — tüm görüntüyü «bir anda» bozabilir.

Zaman boyutu için çerçeveleyici bağlantı: üretim hızını belirleyen şey yalnızca GPU saati değil; CPU’nun her karede hazırladığı iş listesi (draw calls), senkronizasyon ve bellek trafiği de devrededir. Bu yüzden animasyon döngüsü ve zaman konusu ile pipeline düşüncesi birlikte okunduğunda, «neden aynı sahne bazen 60, bazen 30?» sorusunun cevabı daha netleşir — çünkü iki taraftaki iş de aynı zaman dilimine sığdırılmaya çalışılıyordur.

Donanım ve grafik API’leri detayda dallanır; fakat zihinsel model olarak çoğu gerçek zamanlı hat şu üç başlıkta toplanır: uygulama / geometri / piksel. Aşağıda her blok, bir öncekinden gelen veriyi tüketir ve bir sonrakine «paketler» — bu paketleşme, teşhis etmeyi kolaylaştırır: sorun geometride mi, rasterizasyonda mı, yoksa birleştirme (blending) kurallarında mı?

A. Uygulama aşaması (CPU tarafı)

İşlemci burada bir «yönetmen» rolündedir: henüz GPU komutları gönderilmeden sahne durumu güncellenir. Bu aşama yalnızca matematikten ibaret değildir; dosya I/O, animasyon hesapları, kullanıcı girdisi ve motor içi kurallar da aynı kare bütçesine girer.

• Sahne yönetimi: Obje dönüşümları, iskelet / örnekleme (instancing) güncellemeleri ve hiyerarşide kim-kimin çocuğu gibi ilişkiler burada netleşir; GPU tarafına «hangi dünya matrisi» gideceği burada belli olur.
• Frustum culling: Kameranın görüş kesisi dışında kalanların çizim için gönderilmesi çoğu zaman israftır; bu yüzden görünürlük testleri ile aday kümesi küçültülür. Bu bir «optimizasyon sırlaması»dır — yanlış yapılırsa nesne ani kaybolmalarına gider; doğru yapılırsa draw call yükü gözle görülür şekilde azalır.
• Draw call: CPU’nun GPU’ya gönderdiği «şu geometriyi, şu shader ve durumla çiz» paketidir. Çağrı sayısı arttıkça genelde CPU tarafında maliyet hissiyatı artar; birleştirme (batching), örnekleme ve materyal paylaşımı bu yüzden üretim pratiğinde sürekli gündemdedir.

B. Geometri işleme (Vertex Shader)

Üçgen köşeleri (vertices) artık dünya uzayında serbest dolaşmaz; vertex gölgelendirici aşamasında model–görüntü zinciri işletilir ve sonuç clip uzayına yakın bir temsilde toplanır. Bu aşama, «hangi pikselin boyanacağı» değil, «üçgenin ekranda hangi projeksiyonla konumlanacağı» sorusunun matematik laboratuvarıdır.

• Vertex processing: Her köşe için dönüşümler, kemik ağırlıkları ve bazı malzemelerde ek deformasyonlar hesaplanır; çıktılar rasterleyiciye girdi oluşturur.
• Clipping: Görüş hacminin dışına taşan primitiflerin güvenli biçimde kesilmesi aşamasıdır; «sonsuz clip uzayında kaybolmuş üçgen» gibi sahnelerin çoğu kökünde yanlış projeksiyon veya clipping öncesi bozulmuş koordinat vardır.

C. Rasterizasyon ve piksel işleme (Fragment Shader)

Rasterizasyon, matematiksel üçgenleri ekrandaki piksel adaylarına (fragments) yaymayı sağlar; fragment gölgelendirici ise bu adayların renk ve — gerekiyorsa — yardımcı çıktılarını üretir. Dokusal detay, ışık modelinin çoğu ve gölgelerin görünür «yüzü» genelde burada hissedilir.

• Rasterization: Üçgenin kapladığı piksel örtüşmesi hesaplanır; kenar yumuşatma (MSAA) gibi teknikler de bu bölgede devreye girerek köşe yarılmalarını yumuşatır.
• Fragment shader: Her aday piksel için renk ve çoklu hedeflere (MRT) yazılacak ek kanallar hesaplanabilir. Basit sahnelere bile eklenen normal harita / parlaklık — görünüşte «tek düğme» gibi dursa da — fiilen bu aşamada daha çok matematik demektir.

Bu noktadan sonra tipik bir gerçek zamanlı hatta derinlik testi (depth test) ve karıştırma (blending) ile görünürlük sırası netleşir; tamponların (buffers) doğru temizlenmesi ve yazma maskeleri, özellikle şeffaf malzemelerde, yanlışlıkla «birbirini yutan» yüzeyler üretmez.

İlk «ana» görüntü oluşturulduktan sonra, ekran uzayındaki düzenlemeler için ikinci bir dal devreye girer: post-processing. Burada görüntü çoğu zaman tamponlar arasında taşınır; her adım bir pass olarak düşünülür — bir geçişin çıktısı, bir sonrakinin girdisi olur. Three.js ekosisteminde bu düzenin kalıplaşmış yüzü EffectComposer ile ilişkilidir; fakat kavramsal olarak önemli olan, post’un da kendi içinde GPU zamanı ve bellek bant genişliği tüketmesidir.

• Bloom: Yüksek parlak bölgelerin çevreye nefes aldırarak yayılması; genelde parlaklığı ayır → bulanıklaştır → geri karıştır gibi birkaç küçük geçişten oluşur.
• Depth of field: Odak düzlemi dışını bulanıklaştırarak sinematik okuma sağlar; derinlik tamponuna güvenen çözümlerde yanlış ölçek veya jitter, «titreyen bulanıklık» gibi artefaktlara yol açabilir.
• Color grading: Ton eğrisi ve renk uzayı dönüşümleriyle atmosfer tayini; aynı geometride iki tamamen farklı «film hissi» üretmenin en kestirme yollarından biridir.

Post’un gücü esnekliktir; bedeli ise çoğu zaman ekstra tampon ve ekstra geçiştir. Bu yüzden mobil ve düşük güçlü cihazlarda «her efekt varsayılan açık» yaklaşımı yerine, ürün hedefine göre kürasyon yapmak gerekir.

Tüm hesaplar bittiğinde renk (ve çoğu yapıda derinlik / stencil) bilgisi bir framebuffer içinde tutulur; ekran güncellemesi bu belleğin görüntüleyiciye sunulmasıyla gerçekleşir. Çift tamponlama (double buffering) ile bir tampon yazılırken diğeri gösterilebilir — aksi halde yarım yazılmış bir karenin «çekildiğini» kullanıcı fark edebilir (tearing).

Web bağlamında çözünürlük, pixel ratio ve hedef boyutu gibi kararlar da doğrudan bu tamponların gerçek maliyetini belirler; ayrıntılar için Renderer · Piksel oranı ve boyutlandırma ile bağ kurmak faydalıdır — çünkü «aynı sahne» farklı tampon boyutlarında farklı iki ürün gibi davranabilir.

• Performans optimizasyonu: Draw call sayısı CPU’yu, ağır shader ve yüksek çözünürlüklü tamponlar GPU’yu işaret edebilir. Sorunu doğru katmanda çözmek, haftalar süren «rastgele mikro optimizasyon»dan kurtarır.
• Hata ayıklama: Z-fighting, yanlış sıralı şeffaflık veya kesik gölgeler — hepsi belirli bir aşamanın «imzasıdır». Hangi tamponun hangi geçişte temizlendiğini bilmek, teşhisi körlemesine deneme–yanılmadan çıkarır.
• Görsel kalite: Işık–gölge ve materyal tasarımını pipeline ile hizalamak, gerçekçilik yerine tutarlılık üretir: izleyici bilinçaltında «bu sahne tek bir ışık sözleşmesine uyuyor» hissini alır.

Shader kelimesinin tarihçesinden çok teknik tanımına ihtiyaç duyarsanız, Shader nedir? sayfası ile üst köprüyü kurabilirsiniz; burada ise shader’ın hattın hangi istasyonunda çalıştığı ön plandadır.