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).