Kamera Mercekleri: Perspektif ve Projeksiyonun Mantığı

Odak: Kameranın neyi görüp neyi görmediğini belirleyen hacme Frustum denir. Bu, ucu kesik bir piramit gibidir: içine düşenler çizilir, dışarıda kalanlar elenir.

Pratik sezgi: Frustum’u “kamera merceğinin kırpma kutusu” gibi düşün. İçeride kalan her şey GPU için adaydır; dışarıda kalan her şey erken elenir. Bu yüzden doğru near/far, sadece görüntü değil performans kararır.

Near Plane (Yakın Düzlem): Kameraya çok yakın olan nesnelerin çizilmediği sınırdır.

Near’ı gereğinden fazla küçültmek, “her şeyi görürüm” hissi verir ama çoğu pipeline’da derinlik hassasiyetini kötüleştirip yüzeylerin titremesine (z-fighting) zemin hazırlayabilir.

Far Plane (Uzak Düzlem): Kameranın “görüş mesafesi”dir. Bu sınırın ötesindeki hiçbir şey GPU tarafından işlenmez. Optimizasyonun kalbi buradadır.

Far’ı sahnenin ihtiyacına göre sıkı tutmak, hem culling’i güçlendirir hem de derinlik aralığını daraltarak stabiliteyi artırır. “Sonsuz far” çoğu zaman gereksiz pahalı bir lükstür.

Field of View (FOV): Görüş açısıdır. İnsan gözü yaklaşık \(120^{\circ}-180^{\circ}\) görür; ancak 3D sahnelerde ideal olan genellikle \(45^{\circ}-75^{\circ}\) arasıdır. FOV arttıkça kenarlar bükülür (fisheye), FOV azaldıkça “tele-lens” etkisi oluşur.

Dramatik karar: FOV, kullanıcının “yakınlık” hissini değiştirir. Geniş FOV hız ve hareket hissi verir; dar FOV daha sakin ve “sıkıştırılmış” bir kadraj üretir.

Odak: PerspectiveCamera, gerçek dünyadaki görme biçimimizi taklit eder: obje kameradan uzaklaştıkça küçülür.

Kritik sonuç: Perspektif, “ölçek” ile “mesafe”yi birbirine bağlar. Bu yüzden kullanıcı hareket ettiğinde dünya yaşıyormuş gibi görünür; gerçekçilik hissi burada doğar.

Derinlik hissi: Paralel çizgiler, ufuk noktasında birleşiyormuş gibi görünür.

Kullanım alanı: FPS, mimari yürüyüşler ve gerçekçilik odaklı deneyimler.

Matematiksel arka plan: Bu kamera tipi, Projection Matrix ile Z koordinatını X ve Y üzerine bir çarpan olarak ekler; derinlik arttıkça koordinatlar merkeze doğru “büzülür”.

Pratik hata işareti: “Dolly ile yaklaşınca burun büyüyor” gibi his, perspektifin doğal sonucudur. Bu etkiyi zoom ile değil, sahne/kamera mesafesi ve FOV dengesiyle yönetmek gerekir.

Odak: OrthographicCamera dünyasında mesafe, objenin boyutunu değiştirmez. Derinlik algısı bir “büzülme” olarak çalışmaz.

Bunu günlük hayata benzetelim: Elindeki bir teknik çizime veya haritaya bakarken, “uzakta olan bina daha küçük” görünmez; her şey aynı ölçeğe göre çizilmiştir. Orthographic kamera da sahneyi bu mantıkla gösterir: uzaklık, ekrandaki ölçeği değiştirmez.

Kritik sonuç: Orthographic, perspektif “dramasını” kapatır ve ölçüleri sabitler. Bu yüzden UI/harita/şema gibi “okunabilirlik” öncelikli işlerde net bir görüntü verir.

Perspektifte kamera “göz” gibidir; yakın olan büyür, uzak olan küçülür. Orthographic’te ise kamera “ölçüm aracı” gibidir. Bu yüzden kullanıcıya “gerçekçilik” değil, bilgi vermek istediğinde çok güçlüdür.

Paralellik korunur: Obje 1 metre de uzakta olsa 1 kilometre de uzakta olsa ekranda benzer boyutta görünür.

Bu özellik, grid’ler, hizalama çizgileri, plan görünümü gibi sahnelerde çok değerlidir: çizgiler kaçış noktasına akmaz, “mimarî” bir düzen bozulmaz.

Bu aynı zamanda bir trade-off’tur: uzaklık hissi azaldığı için derinlik okuması, ışık/gölge ve parallax gibi ipuçlarına daha fazla yaslanır.

Yani orthographic’te “hangisi daha uzakta?” sorusu, perspektifteki kadar otomatik cevaplanmaz. Derinliği anlatmak için genelde gölge, occlusion, renk/kontrast katmanları, animasyon veya objelerin birbirini örtmesi gibi ipuçları daha belirgin hale gelir.

Kullanım alanı: CAD/teknik çizimler, izometrik strateji oyunları ve 3D UI elemanları.

Örneğin bir şehir kurma oyununda (izometrik) binaların “okunabilir” olması, seçilebilir alanların net görünmesi ve ızgaranın bozulmaması istenir; orthographic bunu sağlar.

Avantaj: Ölçülerin doğru kalması gereken şema/harita gibi durumlarda kafa karıştırıcı perspektifi kaldırır.

Dikkat edilmesi gereken: Orthographic’te “zoom” hissi çoğu zaman perspektifteki gibi FOV ile değil, kameranın ortho sınırlarını (left/right/top/bottom) değiştirerek elde edilir. Bu, kullanıcıya “yakınlaştım” hissini verir ama perspektif oranları değişmediği için görüntü daha stabil kalır.

İzometrik not: İzometrik görünüm çoğu zaman “orthographic + belirli açıyla döndürülmüş kamera” kombinasyonudur; yani izometrik hissin kaynağı projeksiyon kadar kamera yönelimidir.

Kısaca: projeksiyon “boyutlar sabit kalsın” der, kamera açısı ise “3D hissi tamamen kaybolmasın” diye dünyayı belli bir yönden gösterir. Bu ikisi birleşince hem okunabilir hem de derinliği sezdiren izometrik görünüm ortaya çıkar.

Odak: Kamerayı hareket ettirmek, matematiksel olarak dünyayı ters yöne hareket ettirmekle aynıdır: bu ilişki View Matrix ile kurulur.

Basit düşün: Sen bir odayı video kamerayla çekiyorsun. Kamerayı sağa kaydırırsan, ekrandaki her şey sola kayar. Kamera “ileri” giderse dünya “geri” gelmiş gibi görünür. İşte view matrix bu tersliği sistematik hale getirir: “kameranın konumu ve yönü” bilgisinden, dünyayı kameranın gözünden okuyacağımız koordinat dönüşümünü üretir.

Orbit mantığı: Orbit kontrollerinde “kamera dönüyor” gibi görünse de, kullanıcı açısından his şu şekildedir: odak noktası sabit, kamera onun etrafında gezinir. Bu, ürün inceleme ve sahne keşfi için en okunabilir etkileşim modelidir.

Orbit’in yanında iki sık hareket daha vardır: pan (kamerayı yana/yukarı kaydırma) ve dolly (hedefe yaklaşma/uzaklaşma). Kullanıcı deneyiminde “pan” sahneyi taşır, “orbit” sahneyi döndürür, “dolly” sahneye girip çıkma hissi verir.

LookAt: Kameranın her zaman belirli bir noktaya bakmasını sağlayan vektörel yönelimdir.

LookAt’ı “yön vektörü” gibi düşünebilirsin; ama aslında view matrix’in yönelim kısmını kilitleyen bir kural setidir.

Pratik karşılık: LookAt kullandığında kamera, “başım hep şu noktaya dönük” der. Bu sayede orbit senaryolarında odak kaçmaz; ancak bazı durumlarda (ör. FPS kamera) kontrolü daha çok “yaw/pitch” ile vermek isteyebilirsin.

Dolly vs. Zoom: Dolly kamerayı fiziksel olarak ileri-geri yürütmektir (perspektif değişir). Zoom ise mercek açısını (FOV) daraltmaktır (perspektif sabit kalır, görüntü büyür).

Günlük örnek: Bir sahneyi telefonda çekerken yaklaşırsan (dolly), öndeki kişi büyürken arkadaki bina daha hızlı “geride kalır”. Ama parmakla zoom yaparsan, ikisi birlikte büyür; aralarındaki perspektif ilişkisi aynı kalır.

Kısa test: Öndeki obje ile arkadaki obje arasındaki “mesafe farkı” kadrajda değişiyorsa dolly yapıyorsun; her şey birlikte büyüyüp küçülüyorsa (kompozisyon sabitse) zoom yapıyorsun.

Kısa kontrol listesi: Kullanıcı “yakınlaştım” hissini istiyorsa dolly; “daha net görmek istiyorum” diyorsa zoom daha uygundur. Ürün inceleme (orbit) senaryolarında dolly genelde daha doğal; sinematik kadrajlarda zoom kontrollü bir tercihtir.

Odak: Kameranın gördüğü görüntü, tarayıcı penceresinin boyutuna göre ölçeklenmelidir. Aspect Ratio doğru ayarlanmazsa, kareler dikdörtgen, küreler elips görünür.

Bunu çok basit bir testle anlarsın: Eğer daire çizdiğini biliyorsan ama ekranda elips görüyorsan, mesele “3D model” değil; kamera/projeksiyon ayarı ve ekran oranıdır.

Pratik kural: Canvas boyutu değiştiğinde yalnızca CSS’i değil; kameranın aspect’ini ve projeksiyon matrisini de güncellemelisin. Aksi halde kullanıcı “dünya esniyor” hissi yaşar.

CSS piksel vs gerçek piksel: Modern ekranlarda (retina) tarayıcının gördüğü CSS pixel ile ekranın gerçek pikseli aynı değildir. Bu fark devicePixelRatio ile ifade edilir. Canvas’ı sadece CSS ile büyütüp küçültmek, görüntüyü bulanık yapabilir.

Bu yüzden iyi bir resize akışı genelde iki şeyi birlikte yapar: (1) Canvas’ın render çözünürlüğünü DPR ile ayarlamak, (2) Kameranın projeksiyonunu yeni en-boy oranına göre güncellemek.

Aspect Ratio, \(\frac{Genişlik}{Yükseklik}\) oranıdır ve projeksiyon matrisinin temel girdilerindendir.

Perspektif kamerada bu oran doğrudan aspect parametresine gider. Orthographic kamerada ise çoğu zaman left/right/top/bottom sınırlarını yeni boyuta göre yeniden ölçeklersin. Yani “resize” her kamerada aynı düğmeye basmak değildir; mantık aynıdır ama parametre farklıdır.

Viewport, GPU’nun “nereye çizeceğini” söyler; aspect ise kameranın “nasıl projekte edeceğini” belirler. İkisi birlikte doğru değilse görüntü geometrik olarak bozulur.

Kısaca: Viewport “tuvalin boyutu”, aspect “merceğin oranı”dır. İkisini aynı anda doğru tutmazsan, ya görüntü esner ya da kesilir.

HoloDepth Notu: Çekirdeğimizdeki Resize mekanizması, bu oranı sürekli kontrol ederek projeksiyon matrisini günceller.

Özellikle tarayıcıda pencere sürüklerken (resize drag) saniyede çok fazla event gelebilir. Bu yüzden resize kodu “hafif” olmalı ve render loop ile uyumlu çalışmalıdır.

Küçük optimizasyon: Resize dinleyicisinde gereksiz tekrarları azaltmak için ölçüleri sadece değiştiğinde güncellemek, ana thread’i korur ve render loop’un daha stabil kalmasını sağlar.

Pratik yaklaşım: Ölçüleri her event’te hesaplamak yerine, son ölçüyü saklayıp değiştiğinde güncellemek; hatta gerekirse debounce/throttle benzeri bir stratejiyle işi seyrekleştirmek, hem CPU’yu hem de GPU’ya giden gereksiz güncellemeleri azaltır.