[LinuxFocus-icon]
<--  | Ana Sayfa  | Erişimdüzeni  | İçindekiler  | Arama

Duyumlar | Belgelikler | Bağlantılar | LF Nedir
[Photo of the Author]
Antonio Castro
<acastro/at/ctv.es>

Yazar hakkında:
Bilgisayar Bilimi benim işim ve de boş zamanlarınım bir parçası. Ben de muhtemelen herkes gibi hobilerimi paylaşmaktan keyif alıyorum. İtiraf ediyorum! ben Windows sevmeyen o garip karakterlerden biriyim, en azından MSDOS yetenekleri konusunda daha az seviyede kendini beğenmişlik yapan bir oyuncağın kategorisinde ve bilgisayarınızı işe yarayıp yaramadığını veya ne işe yaradını hiçbir zaman bilemeyeceğiniz bir sürü dosya ile doldurmuyor.



Türkçe'ye çeviri:
Özgür Ulaş Kırlangıç <ozgur_kirlangic/at/be.itu.edu.tr>

İçerik:

 

POVRAY III: Yinelemeli Yapıların Tasarımı

[Illustration]

Özet:

Bu defa Porvay ile nasıl yinelemeli yapılar tasarlanabileceğini ve güzel resimler yaratılabileceğini keşfediyoruz.

_________________ _________________ _________________

 

Bilgisayar Biliminde Sanat ve Teknik.

Makale serimizde POVRAY'in teknik ve teknik olmayan yönlerine değiniyoruz. Teknoloji önemlidir, bunu birçok defa belirttik, fakat daha da önemlisi sanatsal ve yaratıcı bir ortamda teknolojinin olanaklarından faydalanmayı öğrenmektir. Bilgisayar bilimi diğer tüm disiplinlerden o kadar farklıdır ki belki de bazıları için sanatçı özelliklerini ifade edebilecekleri mükemmel bir ortam olabilir. Teknoloji üzerine öğrenme sürecinden vazgeçemeyiz çünkü bu gerekli bir adımdır, bununla birlikte benim kişisel deneyimimde teknoloji bize yeni bir iletişim formu elde etmemizde yardımcı olan bir araçtan ibarettir.

Makalelerimde soğuk teknik bilgi ile tamamiyle yaratıcı veya sanatsal konuları birleştirmeye çalışıyorum. Amacım, okuyucunun hayal gücünü tetikleyebilecek veya belki de zihninde yeni izler açabilecek fikirler, örnekler ileri sürmek. Bazen yeni bir örneğin tasarımına başlarım ve o kadar eğlenceğe dalarım ki asıl göstermek istediğim konular gizli kalır ve unutulur. Saf sistematik bir sunum ise hemen sıkıcılaşır ve bu yüzden pek öğretici değildir.

Povray klavuzu çeşitli teknik konuların sistematik bir sunumu olarak oluşturuldu. Klavuz harika bir kaynak ve ben de onu sıklıkla kullanıyorum. Fakat biz bu ardışık (sequential) ve sistematik yaklaşımın aksine daha çok aynı konulara birçok defa ve her defasında daha derinlemesine geri gelen spiral bir yaklaşımı takip edeceğiz.

Serimizde örnek olarak sunulan görüntüler, sadece eldeki teknik konuya bir gösterim sağlamak değil, aynı zamanda o tekniğin güzel sonuçlar üretmek için nasıl kullanılabileceğine dair bazı estetik örnekler vermek gayesindedir. Bu hedef yeri geldiğinde POVRAY'in seri içinde henüz tartışılmamış olan, okuyucu için yeni ve yabancı öğelerinin takdimini gerektirebilir. Henüz birşey anlamıyorsanız endişelenmeyin, adım adım tüm konuları örneklerle işleyeceğiz. Diğer taraftan kullanılan birçok teknik tabiat olarak çok görsel olduğu için nadir olarak yazılı anlatım gerektirir, çünkü sadece örneğin sonucunu "görnek" uzunlamasına bir anlatından daha değerlidir. Gerçekten Povray öğrenmeyi daha hızlı ilerletmek isteyenler herzaman kaynak klavuza başvurabilirler.

 

Basit Geometrik Objeler

Buradaki objelerin birçoğu daha önceki örnekler içinde kullanılmışlardı. Tüm bu bilgileri bir araya getirmek için şimdi onları yeniden gözden geçirelim.

Aşağıdaki basit geometrik objeler serisi baz alınarak tasarlanabilecek obje sayısı sayısızdır, böylece objeleri temel formların bileşimine indirgemek görüntünün işlenmesinde (process) kaydadeğer zaman tasarrusu sağlamaktadır. İşte listemiz:

 

Koşullu Katı Grafiği (CSG)

CGS ilkelleri daha komplike modeller oluşturmak için birleştirilebilen temel katı objelerdir. Son kombinasyon guruplandırılabilir ve ölçekleme (scaling), ilerletmeler (translations), döndürmeler (rotations) veya doku ile doldurmalar (filling in textures), vb... kullanılarak dönüştürülebilir. Bu dönüştürmelerin her birini, bileşik model içindeki herbir ve tüm temel ilkellere uygulamak şart değildir.

CGS ilkellerini birleştiren dört ayrı method ile tekil ilkellere uygulanan beşinci bir tamamayıcı metod mevcuttur:

Takip eden örneklerde katı modeller oluşturmak için bu işlemlerden birkaçını kullanacağız. Model oluştururken öncelikle toplam hacmi oluşturmak için gerekli olan tüm elemanları eklemeyi sonra da istenmeyen parçalardan kurtulmak için kesişim işlemlerini kullanmayı tavsiye ederim.


#define EatenApple = intersection {
      object { WholeApple }
      object { Bite1 inverse }
      object { Bite2 inverse }
}

Bir katı modeldeki ilkel objelerin ortak yüzeyleri varsa yüzeylerden biri üzerindeki noktaların render edilmesinde makine hassasiyetine bağlı probemler olabilir. Bu problem yüzeyin hangi objeye ait olduğunu net bir şekilde ayırd etmek için objelerden birine çok küçük bir yer değiştirme vermek suretiyle giderilebilir.

 

Povray içinde Döngüler ve Koşullamalar.

Bir görüntü içindeki elemanlar genellikle rastlantısal bir sıralama ile tanımlanırlar. Bununla beraber, yenilemeli yapılar yaratmak için örneğin, prosedür döngüleri uygulamanın çok elverişli olduğu durumlar mevcuttur. Povray içinde döngüler çeşitli metodlar kullanılarak uygulanabilirler. Bir metod dilin kendisi tarafından sağlanan döngü akış kontrol direktifidir (loop flow control directive).

Döngü akış kontrolü POVRAY programlama arayüzünün birçok direktifinden sadece biridir. Bir süre önce #declare ve #include gibi başka direktiflerden bahsetmiş ve diğer birçoğunu ikinci derecede önemli olarak karakterize etmiştik. Takip eden örnek direkt olarak POVRAY içinde düzenlendi ve itiraf etmeliyim ki bu benim döngü akış kontrol direktifini ilk kullanışım. Bunun sebebi, genellikle döngü akış kontrol ifadelerine (for döngüsü) sahip harici bir program (C veya C++) ile POVRAY kaynağı oluşturarak aynı sonucu elde etmenin mümkün olmasıdır. İleride bu teknik için bir örnek göreceğiz.

C tecrübesi olan okuyucular, Povray'in programlama arayüzünün diğer genel amaçlı programlama dillerinde (C, C++) olduğu kadar mükemmel olmadığını göreceklerdir. Bu bir sürpriz olarak gelmemeli çünkü POVRAY görüntü tanımlamak üzere taraslanmış bir dildir, ve akış kontrol direktifleri sonradan yapılmış eklenmelerdir. Benzer şekilde, POVRAY karmaşık matematiksel işlemleri gerçekleştirmek için gerekli direktifler ile her türlü döngüyü de içermektedir. Kişisel olarak POVRAY'in tüm bu işlemleri barındırıyor olmasını inanılmaz buluyorum fakat diğer yandan aslına bakılırsa ille de gerekli olduklarını düşünmüyorum, çünkü bu işlemleri daha güçlü programlama dilleri içerisinde harici olarak gördürmemiz herzaman mümkün. Bu işlemleri dışarıda veya içeride gerçekleştirmenin kompozisyonun nihai sanatsal değeri üzerinde ne tür bir farklılık yaratacağını düşünemiyorum. Benim için en önemli konu nihai resmin kalitesidir. Daha dar bir kapsamda görüntüyü tasarlayıp ve proses etmek için gereken zaman ve uğraş da bir faktör olmalı. Genel amaçlı programlama dillerine daha fazla aşina olan kullanıcılar POVRAY dosyalarını onlar üzerinden oluştururken kendilerini daha iyi hissedebilirler, programlama tecrübesi olmayan diğerleri ise belkide direkt olarak POVRAY üzerinde yazarken daha rahat edebilirler. Ayrıca basit resimler için POVRAY içinde direkt düzenleme daha kolay olurken kompleks görüntüler için POVRAY dosyalarının diğer programlarla oluşturulması daha iyi olabilir. Her iki metodu da inceleyeceğiz ve okuyucunun bu bağlamda seçim yapmasına olanak tanıyacağız.

 

Deneme Yanılma Metodu Kullanmak

Birçok görüntü basit bir fikirden yola çıkarak tasarlanabilir. İlk uygulamadan sonra daha iyi bir sonuç elde edebilmek için bazı değerleri değiştirmeye veya yaklaşık değerler kullanmaya karar verebiliriz. Yani deneme yanılma metodu POVRAY içerisinde görüntü tasarımı yapma işinin önemli bir parçadır. Bu makaleler serisinin başlangıcında okuyuculara resim oluşturulmayı kolaylaştıran basit bir script-tool (POV) önermiştik, fakat okuyucu bu küçük script'in yeterli olduğunu düşünmemeli. Çoğu zaman çizgisiz kağıt, kalem ve bir hesap makinesine ihtiyacınız olacak. Bir çok durumda tasarımlarımız 3-Boyutlu geometriler içerdiğinden, bazı efektleri elde edebilmek için başka yolu yok bir miktar özel geometri ve trigonometri bilgisi olmazsa olmaz. Genellikle birkaç formülü bilmek yeterlidir, bu nedenle bazı temel trigonometrik bağıntıları hatırlayalım:

sin(a) = A / C = (Karşı kenar / Hipotenüs)
cos(a) = B / C = (Komşu kenar / Hipotenüs)
tan(a) = A / B = (Karşı kenar / Komşu kenar)

Yani:

A = sin(a)/C
B = cos(a)/C
C = sqrt(A^2 + B^2)
2* Pi radyan = 360º olduğundan

1 Radyan = 180 / Pi = 57,29577951308232
1º = Pi / 180 = 0,174532925199432957

Sonraki hatırlatma olarak trigonometrik fonkyonların ana tanım kümelerini kuadrantın bir fonksyonu olarak tablolaştırıyoruz:


Kuadrant Sinüs Kosinüs Tanjant
0 .. 90 0 .. +1 +1 .. 0 0 .. +Sonsuz
90 .. 180 +1 .. 0 0 .. -1 -Sonsuz .. 0
180 .. 270 0 .. -1 -1 .. 0 0 .. +Sonsuz
270 .. 360 -1 .. 0 0 .. +1 -Sonsuz .. 0


a = atan(A/B)

Bu son ilişki tek (unique) olarak tanımlı değil. Alfa açısı +/- 180 dereceler için belirsiz (undetermined). Hesaplama yönünden şunu kullanmak tercih edilir:

a = atan2(A,B)

Sonuç olarak P1(x1,y1,z1)'den P2(x2,y2,z2)'ye olan mesafe

D = sqrt( (x2-x1)^2 + (y2-y1)^2 + (z2-z1)^2 )

Daha birçok kullanışlı trigonometrik bağıntı var fakat gözden geçirdiklerimiz birçok durum için yeterli olacaktır. POVRAY içerisinde kullanılan trigonometrik fonksyonlar açıların radyandan cinsinden verileceğini varsayarlar. Dönüşüm fonksyonu radians(alfa) dereceyi radyana çevirir. Ne yazık ki POVRAY tutarlı değil, örneğin dönmeler (rotations) derece cinsinden ölçülmektedir :-(

 

Deniz Kestaneleri

Bu örnekte bir miktar temel trigonometri kullanıyoruz. Deniz kestanelerinde iğneler öyle düzgün bir şekilde yerleştirilmişlerdir ki bu etkiyi şansa bağlı olarak elde etmek kolay olmasa gerek. Tasarımcı iğneleri kesin olarak yerleştirmek için bir algortma düşünmeli ve bunu nihai 3 boyutlu konfigurasyonun net tasavvuru ile uygulamalı. Bu örneğin kaynak kodu gerektiği şekilde belgelendi, bu nedenle burada daha fazla yorum yapmanın bir faydası yok. Bu örnek bir döngü algoritmasının işe yaradığı net bir durum. Kullanıcının döngüyü POVRAY içerisinde veya dışarıda bir C-programı üzerinde uygulamaya karar vermesi kişisel tercih meselesidir.

erizo

Balikların kaynakları da burda. Bunlar daha önce bahsedildiği gibi CGS ilkelleri kullanılarak modellendiler.

balistap.inc

Sırada geri kalan görüntünün kaynakları var. Buradaki en özel iş hiç şüphesiz ki kompozisyndaki başlıca karakterler olan deniz kestanelerinin (ispanyolcası erizo) tanımı:

erizo.pov

Bu örnek içerisindeki birkaç efekt tamamiyle yeni, mesela kum üzerindeki yüzey efektleri (kum üzerindeki dalgalar), atmosferik efektler (yeşil deniz renginde çok kalın ve çok nemli bir sis) ve pek tabiki karmaşık CGS objeleri. Yüzeydeki dalgalardan serpilen düzensizlik ile karakterize olmuş görüntüdeki ışık birçok noktasal kaynaktan gelmekte, deniz altı aydınlanmasını simule etmek için ortamda dağılmakta. Bu kompozisyon için tek bir ışık kaynağı uygun olmazdı çünkü bu deniz kestanesinin gölgesinin çok keskin olmasına sebep olurdu.

 

Harici Programlar ile Üretim

Bir ray-tracer yalnızca formal bir rey-tracing dili yardımı ile tanımlanmış olan görüntüyü oluşturmada kullanılan için bir araçtır. Rey-tracer'lar renk ve ışık vb... tanımlamaları algılayabilirler. Çoğu zaman tasarım işimizi desekleyecek ön çalışmalar vardır: 3-Boyutlu tarayıcılar, format dönüştürme araçları, programlar, bunlar arasında sayılabilir. Öyleyse bir ray-tracer, görüntü inşa ve tasarım araçları zincirinde halkalardan yalnızca biridir. Diğer bir söyleyişle düşüncelerimizi klavyeye dökerek tasarım yapmak sanatsal kompozizyonlar üretmek için tek mekanizma değildir, elle bir ray-tracer dilinde yazmanın çok kolay olmadığı daha karmaşık kompozisyonları üretmek için yardımcı araçlarımız mevcuttur.

Harici bir program ile oluşturulmuş karmaşık bir görüntü örneği olarak sırada bir burbujaz.c (baloncuklar) adında bir C-programı veriyoruz. Program 1000x750 piksel boyutundaki bir yüzey üzerine rastlantısal olarak baloncuklar yerleştiriyor. Baloncuklar birbirleri ile kesişemiyorlar, bu nedenle örnek kodumuz raslantısal yerleri ve raslantısal boyutları bu koşula göre belirliyor. Eğer bir baloncuk için oluşturulan yeni konum var olan diğer bir balonun yanına düşüyorsa yeni bir konum hesaplanıyor. Kürenin boyutu uygun olacak şekilde küçültülüyor. Çok sayıda iterasyon ardından hemen hemen hiç boş yer kalmamış bir yüzey elde ediliyor. Bu özel örneğin oluşturulması çok sayıda hesaplama gerektiriyor çünkü seri ilerledikçe yeni bir baloncuğu uydurmak daha da zor olmaya başlıyor.

burbujas.c

Bu programı derleyin ve çalıştırın. Standard çıktıyı baloncuklar için verilerin saklandığı 'burbujas.inc' adında bir dosyaya yönlendirin (burbujas > burbujas.inc). Çıktı dosyası aşağıdakine benzer satırlar içerecektir:


sphere{<-375, 0,   33> 55.0000000 texture{Gold_Metal}} //(0/1)
sphere{< -86, 0,   62> 55.0000000 texture{Gold_Metal}} //(1/2)
sphere{<-326, 0,  346> 55.0000000 texture{Gold_Metal}} //(2/3)
sphere{< 190, 0, -156> 55.0000000 texture{Gold_Metal}} //(3/4)
sphere{<  62, 0, -293> 55.0000000 texture{Gold_Metal}} //(4/5)
sphere{< 323, 0,  161> 55.0000000 texture{Gold_Metal}} //(5/6)
sphere{< 341, 0,  -15> 55.0000000 texture{Gold_Metal}} //(6/7)
...................

Biraz sabır öneririm çünkü çıktı dosyasının oluşturulması biraz zaman alıyor. Herhangi bir anda işlemi durdurabilir ve son çıktı satırını düzenleyerek tamamlanmış hale getirebilirsiniz. Veya eksik satırı dosyadan çıkarın. Pov için kaynak aşağıdaki gibi olacaktır:

burbujas.pov

Kaynak kodu gene "clock" simgesine atıflar içeriyor fakat bu sefer amacı çok farklı. Bu defa bir animasyon için resimler serisi üretmek yerine çok farklı görüntü noktası olan 4 resim üretiyor. Kamera pozisyonu, açısı ve açıklığı (aperture) dört resim için de farklı.

Bir önceki POVRAY makalesinde bir noktada POVRAY içerisinde kamera olanaklarını inceleyen örnekler inceleyecebileceğimizi belirtmiştik. İşte bu bir örnek. Kamera tanımlamalarına bağlı olarak render edilmiş nihai resimler üzerindeki farklar hayli belirgin. Açıklık (aperture) açısına bağlı olarak çok farklı pespektifler elde edilebilir: Küçük açı uzak perspektifleri verirken, geniş açılar yakın perspektifleri sunar. En geniş açıklık 180 derecedir, bu çok uç bir değerdir çünkü şekilleri ayırt etmek zordur.

Gösterilen resimler bir Pentium 200 MMX 48 MB Ram (398 bogomips) üzerinde preses edildiler. Önerildiği gibi önceki serilerde verilimiş olan 'pov' aracı kullanılarak çalıştırıdı:


pov burbujas 6 9 1 5 1 5
Total Time =

Geçilen parametreler şunları temsil ederler:

Herbir fotogramın oluşturulması için harcanan zaman kaydadeğer. Daha iyi bir kalite ile aşağıdaki zamanları alırdı:

pov burbujas 9 9 1 5 1 5

Total time = 4 1/2 hours .
First photogram 2 minutes
Second photogram 5 minutes.
Third photogram 10 minutes
Fourth photogram 13 minutes
Fifth photogram 4 hours !!

Şimdi sonuçları inceleyelim. Dört fotogramdan ilkinde tek değişiklik kamera kurgusunda. (poziston (position), açı (angle), yönlendirme (orientation) v.b.)

Son fotogramı göstermeden önce bu son resmin değerini arttırma ile alakalı diğer bir konu üzerinden gitmeme izin verin, CPU optimizasyonu konusu.



 

CPU Kullanımı Optimizasyonu

Son program en karmaşık olanı idi ve POVRAY onu optimize etmeyi başaramadı. Karmaşık kompozisyonlarla karşı karşıya kaldığında ray-tracer görüntüyü en basit ortak paydaya sadeleştirmeye çalışır. POVRAY'in önceki versyonlarında optimizasyonların elle yapılması zorunluydu; sanatçıların bir veya daha fazla objeyi örtecek bir ilkeli tanımlamak için "bounded_by" direktifleri vardı. Ray-tracer bu örtünme ile çarpışmayan ışınların içerideki objeler ile de çarpışmayacağını farz ediyordu. Bu bir miktar proses zamanı kazandıran bir yaklaşımdır (approximation). Hakikaten işe yaradığı durumlar ise çok nadirdir. Sonuçlarına bakılırsa son resmimiz bu durumlardan biri! Son görüntü çok fazla resim içeriyor ve çok karmaşık. Bu nedenle kompozisyonu el yordamıyla optimize etmek daha iyi olabilirdi, örneğin baloncukları bölge bölge gruplamak, baloncukları bileşik objeler halinde birleştirmek veya hatta "bounde_by" komutu ile aynı bölgeleri küre gruplarını örtüp tüm baloncukları bir obje halinde birleştirmek. Sentaks şöyle olurdu:


    union {
    sphere { <x1, y1, z1>, r1 }
    sphere { <x2, y2, z2>, r1 }
    sphere { <x3, y3, z3>, r1 }
    ..........................
    bounded_by { sphere { <xb, yb, zb>, rb } }
  }

Açıklanan türdeki el yordamı optimizasyon birleşimlerle ve kesişmelerle ve hatta herhangi bir diğer obje ile kullanılabilir. Kullanıcı başka örtme ilkellerini de seçebilir, biz bir küre seçtik, fakat en iyi sonuçlar genellikle kutular ve kürelerle elde edilmekte. Eğer seçilen ilkel birleşik objenin bir parçasını dışarıda bırakılırsa sonuç arızalı olabilir.

Bir kere daha vurgulamak isterim ki el yordamı optimizasyonlara nadiren ihtiyaç duyulur. Son örneğimiz konuyu açmak için önceden 'kötü niyetle' tasarlanmıştı. POVRAY otomatik eniyileyicisi kompozisyonu daha iyi bir hale getirmeyi beceremedi. Kompozisyon 2154 küre içeriyor. Okuyucu bu sayıyı sayarak kontrol edebilir :-).

Örneğimizde ray-tracer'ın olanakları ile nasıl oynanacağını gösterdik. Çoğu zaman aynı düşünce veya kavram farklı sonuçlar elde etmek için değişik şekillerde uygulanabilir ve burası sanatçının yaratıcılığının su yüzüne çıktığı yerdir.

 

Eksik olan...

Povray bazıları daha az veya daha çok ilginç olan birçok matematik fonksyonu sunuyor. Fakat ne yazık ki çok ilginç bir fonksyon eksik. "spline" fonksyonu. Bir kalem ile kağıta birkaç nokta işaretledikten sonra noktaların üzerinden yumuşak bir çizgi ile geçen bir fonksyon uygulaması kadar kullanışlı birşey yoktur. Povray'in spline ilkeli bir fonksyon olarak kullanılamaz, bunun yerine diğer formların inşasında baz olacak bir çizgi oluşturur, eğer spline'ı istediğimiz tüm değişkenlere uygulayabilseydik ne iyi olurdu. Bu, örneğin bir kameranın keyfi bir yörünge izlemesini olanaklı kılardı. Eğer harici fonsyonları uygulayabilseydik de çok iyi olurdu. Bir seviyeye kadar tüm bunlar include kullanarak ve harici programlama yaparak elde edilebilir. Linux altında 'spline' adı altında bir araç (utility) var. Bu, bir noktalar kümesinden istenilen eğriyi oluşturan bir komut olarak kullanılabilir. Bu komutu harici programlama ile kullanmayı deneyin, örneğin animasyonlar veya kamera hareketi oluşturmak için.

 

Egzersizler

 

Okuyucu katkıları

Okuyuculardan haber almayı ve kompozisyonlarını (belki de burada tartışılan yinelemeli veya döngü yapılarını uyguladıkları) görmeyi çok isterim. Lütfen deneylerinizi sıkıştırılmış dosyalar içinde gönderin. Okuyucu katkılarını biriktirmek ve burada LinuxFocus dergisinde bir sergi organize etmek harika olurdu. Sergi için en ilginç veya yaratıcı olan resimleri seçeceğim. Lütfen herhangi bir ticari ödeme-karşılığı lisansı (for-pay license) altındaki resimleri göndermeyin. Eğer mümkünse resimlerinizin kaynaklarını da gönderin ki diğer insanlar da sizin fikirlerinizden birşeyler öğrenebilsin.

 

Kaynakça





Görselyöre sayfalarının bakımı, LinuxFocus Editörleri tarafından yapılmaktadır
© Antonio Castro
"some rights reserved" see linuxfocus.org/license/
http://www.LinuxFocus.org
Çeviri bilgisi:
es --> -- : Antonio Castro <acastro/at/ctv.es>
es --> en: Miguel A Sepulveda <sepulveda/at/linuxfocus.org>
en --> tr: Özgür Ulaş Kırlangıç <ozgur_kirlangic/at/be.itu.edu.tr>

2004-11-23, generated by lfparser version 2.50