Bu sayfadaki yazılar
Sayfanın metni
Sayfa 108
Kısacası hardware rendered demolarda 2D efektler, aslında tüm piksel efektleri zordur. En uçuk örnekle, animasyon kullanmadan kaliteli Mandelbrot fraktalları çizebilmek oldukça takdir edilecek bir şeydir. (Bu yüzden zaten 3D fraktallar daha yaygındır.) Ayrıca piksellere erişiminiz olmadığı için, PC demolarında hem vektör grafikler kullanıp, hem de göze oldukça hitap edecek görüntüler almak zordur. 2004 yılında yayınlanan We Cell/Kewlers, ekran kartının sadece 2D resim çizmeye izin veren accumulation bufferını kullanarak 3D'den uzak durmuş ve ferah görüntüler sunmuştur. Bir başka deyişe %100 spritelardan oluşan bir demodur.
Piksel işlemleri hardware renderingte bu kadar zorsa coderlar neden hala bu yolda ısrar etmektedirler? Günümüzde yazılabilecek en optimize, en hızlı poligon basma rutininin bile, ekran kartında donanım olarak bulunan işlemleri geçmesi mümkün görünmemektedir. Ayrıca CPU'dan bağımsız çalıştığı için, ekran kartlarını kullanmamak platformdan yarım verim almak anlamına gelecektir. Ama maalesef ekran kartları da codera maksimum esnekliği sağlamamakta. Bu sorunu çözmeye yardımcı olmak için programlanabilir ekran kartları piyasaya çıkmıştır.
Back to Oldskool!
Programcının yazdığı kodlarla nasıl çalışacağını belirlediği ekran kartları ilk olarak 2001 yılında gözükmeye başladı. Fakat o yıllarda yapabildikleri şeyler çok fazla değildi. Şimdi neler yapabildiğini ve ilerde neler yapabileceğini anlamak için tekrar detayları konuşalım.
Ekran kartlarındaki vertex ve piksel işlemlerinden ve bu işlemlere coderın ne kadar hakim olduğundan bahsettik. Coderdan monitöre giden yolda ilk karşımıza çıkan vertex işlemleri idi. Bunlar, gayet basit geometrik işlemlerdi ve coderın istediği çıktıya uygun vertexleri hazırlaması kolaydı. Ama kısıtlayıcı unsur bu vertex ve poligonların basılma hızı idi.
Yeni nesil ekran kartları, normal vertex işlemlerinin yanına bir de coderdan aldığı özel bir kod parçasını yerleştirerek "çizim borusundan" ilerleyen vertexlere, müdahale etme şansı tanıdı. Örneğin bir köşenin aldığı ışık belirlendikten sonra vertexi bu ışığa göre değiştirip bir tür serap efekti elde edebilirsiniz. Ya da bir dinozorun üzerindeki ayrıntılı deri bilgisini (tırtıklar yarıklar vs.) ekran kartı belleğine attıktan sonra bunu, derisiz ve düşük poligona sahip bir dinozorun üzerine yapıştırabilirsiniz. Yüksek poligon ama statik bir deri ve düşük poligon ama hareketli bir dinozor meshi ile yüksek poligon ve hareketli bir dinozor çizmeniz mümkün hale gelebilir. Buradaki en önemli nokta bu gibi kodları coderın tamamen kendisinin yazıp, ekran kartına işlenmek üzere yollaması. Bu kodlara "vertex shader" adı veriliyor.
Klavyeyle gezinmek için ← ve → tuşları.
Sayfa 109
Sonraki aşama olan piksel işlemlerinin de yanına "pixel shader" ya da "fragment shader"larınızı koyarak piksellerin nasıl basılacağını bir dereceye kadar programlayabilirsiniz. Bu sayede örneğin ayrıntılı gözükmesi için ayrıntılı bir meshte tuttuğunuz objeyi düşük poligonlu bir meshte tutup, daha sonra piksel shader'ınız ile ayrıntılı hale getirebilirsiniz (ışıklandırma, bump mapping gibi tekniklerle).
Shader'ların 2001'de ortaya çıktığından bahsettik, fakat yukarıda bahsettiğim örnekleri yapabilmek için daha fazlasını beklemek gerekti. Artık ekran kartı programlama önümüzde yeni bir ufuk gibi duruyor. Daha önceleri "GLSL" ya da "C for Graphics" gibi dillerle yazılan shader'lara artık Assembly desteğinin de gelmesi ile grafik programlama, efektleri tamamen coder'ın yazdığı eski günlere geri dönüyor. Geometrik çevrimler, poligon basma gibi işler ekran kartına bırakılıp grafik programlamaya yeni başlayanlara kolaylık sağlanırken, daha fazla esneklik isteyenlere de kendi shader'larını yazma ve yeni rendering teknikleri keşfetme olanağı sağlanıyor.
Şimdiye dek shader'ların kullanıldığı birçok demodaki shader özellikleri, daha önceden elde bulunan gereçlerle de (poligon + doku) yapılabilir gibi duruyor. Fakat geçen sene çıkan Fair Play to the Queen/Candela demosundaki metaball'ları, shader'lar ile yazılmış bir raytracer kullanmadan yapmak mümkün değil gibi gözüküyor. Ayrıca aramızda hırslı PC demo coder'ları varsa Plastic'in motoruna yaklaşmanın da başka türlü mümkün olmadığını söylemek istiyorum. :)
Şimdiye kadar ekrana yapılan çizimler için temel yöntemlerden ve bu yöntemlerin hangi aşamalarının ne derece zor/kolay olduğundan bahsettik. Esasına bakılırsa PC'de hız optimizasyonu çok da üzerinde durulan bir konu değil. Çünkü bugün yazdığınızda 20fps çalışan bir efekti, 60 fps çalıştırabilecek konfigürasyonların 2-3 yıl içinde türeyeceğine garanti gözüyle bakabiliriz. Ekran kartı belleklerinin bile çok üzerine çıkacak sayıda poligon basmak istemediğimiz sürece, çizimde hız optimizasyonu çok fazla önemli değil. Asıl hız problemi bu çizim öncesinde gerçekleştirdiğiniz hesaplamalarda beliriyor. Örneğin bir demoda ekranda yüzlerce küp dönerken bir yavaşlama fark ediyorsanız bunun sebebi, küplerin çiziminin yavaş olmasından değil, küplerin hareketlerini belirleyen kodun yavaş olmasından kaynaklanmaktadır.
Başka bir örnek olarak, bir metaball efektinde hız faktörü çizilen poligon sayısıyla çok az ilişkilidir. Esasında metaball'ları poligonlarla oluşturuyorsak, en önemli yavaşlatıcı faktör yapılan matematiksel hesapların detayındadır. Çok detaylı bir hesap çok kaliteli bir görüntü sunacakken oldukça yavaş olabilir. Tersi şekilde hızlı bir metaball efekti de belki kaliteden ödün verdiği için bu özelliğe sahip olmuş olabilir (Nested'dakiler gibi). (Aslında blobların çözünürlüğünün kübüyle orantılı sayıda işlem gerekmektedir.) İyi bir kodu kötüsünden ayıran özelliği, hız-kalite çarpımının daha yüksek olmasıdır (tüm platformlarda olduğu gibi).