GLSL lighting

[chenmy1]

selam biliyorum bu soruyu sordugum icin cahil diyebilirsiniz ama sormak zorundayim :)cunku bilmiyorum..
 
GLSL de standart Point light ,Directional Light , Spot Light icin isik formullerini soyliyebilecek olan var mi?
 
bildigimiz Fizikdeki isik formullerini bilmiyorum..

isik + material = ambinent + specular * shin + diffuse:) etc..

bunlarin formulleri standart saniyorsam bunlarla ilgili bir tutorial hazirliyacak olaniniz var mi?
 
Mumkunse Per Vertex olsun cunku Per Pixel acayip bi sekilde siciyor..

[oxzy]

Kullandığın shader editörde mutlaka per-pixel ve per-vertex lighting örnekleri vardır. Mesela ben RenderMonkey kullanıyorum. Examples\GL2\Illumination.rfx dosyasında basit bikaç örnek var. Akşam eve gidince bende bildiğim ışık formüllerini bi örneğe yazıp yollarım.

[chenmy1]

Evet ,tam bu soruyu sordum eve gittim ve render monkeyi inceledigimde icinde Vertex light ornegi varmis gordum :)Ama yinede bilmedigim seyler olabilir veya baskalarininda vardir buraya post etsen cok kisi faydalanabilir:)

[nightlord]

su an kafadan cikariyor olacagim hatalar olabilir.
 
asagidaki operasyonlarin anlamlari
 
. -> dot_product : (a,b,c) . (x,y,z) = ax + by + cz sonuc skalar
* -> component carpma: (a,b,c) * (x,y,z) = (ax, by, cz) sonuc vektor
+ -> vektor_toplama
 
renk = ambient_renk + diffuse_renk + specular_renk
 
ambient_renk = ambient_isik * ambient_material
 
diffuse_renk = diffuse_noktaya_varan_isik * diffuse_material (sabit renk olabilir veya texture'dan gelebilir)
 
specular_renk = specular_noktaya_vara_isik * specular_material(sabit renk olabilir veya texture'dan gelebilir)
 
diffuse_noktaya_varan_isik = isik_diffuse_renk * ( normalize_isik_vektor . normal ) * uzakliga_bagli_azalma
 
normalize_isik_vektor = norm(isik_vektor)
isik_vektor = isik_pozisyon - nokta_pozisyon
 
uzakliga bagli azalma sabit, linear veya quadratic secilebilir
sabit-> 1 / k0
linear-> 1 / k0 + k1*d
quad -> 1 / k0 + k1*d + k2*d*d
 
d = mag(isi_vektor)
 
specular_noktaya_varan_isik = isik_specular_renk * ( spec_vector . normal ) * uzakliga_bagli_azalma * specular_azalma
 
spec_vektor = ( isik_vektor + goz_vektor ) /2
 
goz_vektor = camera_pozisyon - nokta_pozisyon
 
Yani spec_vektor noktadan isiga ve goze giden vektorlerin aciortayidir. bu vektor, normale yaklastikca isik tam o noktadan bizim gozumuze yansiyor gibi oldugu icin ekstra bir "parlaklik" olusur.
 
specular_azalma = bu material'in "shininess" (matlik / cillopluk) degerine bagli bir deger. NVidia CG de bir math fonksiyonu var bunun icin
 
simdi son olarak isik kaynaginin turune gor ne degisiyor
1- noktasal isik: tam burada verdigimiz formuller birebir kullaniliyor
2- directional: uzakliga bagli azalma yok. o terimi 1 yapmak yeterli
3- spotlight: herseyden once spot konisinin icinde olunup olunmadigi kontrol edilmeli:
 
isik_yon_vektoru : spotun baktigi yon
ters_isik vektoru = nokta_pozisyon - isik_pozisyon
 
cos(aci) = norm(isik_yon_vektoru) . norm(ters_isik_vektoru)
 
aci <= spot_koni_tepe_acisi --> isik aliyoruz
aci > spot_koni_tepe_acisi --> isik almiyoruz
 
 
Per vertex vs Per pixel
 
Isiklandirma formulu her kosulda aynidir. sizin per pixel veya per vertex yaklasimlariniz formulleri degistirmez.
 
Degisen sizin hesaplamalarin ne kadarini vertex shader da yapip, ne kadarini pixel shader'a birakmanizdir
 
vertex shaderda yapacaginiz hesaplamalar pixellere interpole edilerek gecirilir ve bu yuzden biraz hata payi eklenir.
 
Texture lookuplari genelde pixel shaderda yaparsiniz
 
butun vektorleri (nokta_pozisyon, isik_vektoru, spec_vektoru, normal vs) vertex shaderda hesaplayip, pixel shader'a gecirdikten sonra iceride norm() komutunu kullanmalisiniz. Cunku interpole edilen vektorlerin boylari her zaman 1 olmayabilir.

[scg_]

Nightlord un çektiği özete bişeyler ekliyim :
Nightlord un verdiği shading eşitliğinde diffuse terim lambert in kosinüs yasası olarak
bilinir ( N.L ). Fakat farklı diffuse modelleri (Oren - Nayar vs..) de var. Aynı şey
specular terim içinde geçerli. Phong specular modeli fiziksel dayağını az olan bi model.
Sırtını BRDF lere falan dayamış olan modellerde var. (Cook - Torrence mesela)
Tabii yinede genel shading eşitliği:
 
renk = ambient_renk + diffuse_renk + specular_renk
 
formunda.
 
Performans kısmına tekrar gelirsek :
 
Seçtiğiniz modeli vertex shader da mı , yoksa pixel shader da mı gerçekleştiriyimin yanında
hesapları hangi space de yapacağınız da etkili olabilir. Yaptığınız hesapların anlamlı
olabilmesi için kullandığınız (shading için) tüm niceliklerin (normal vector , light vector
vs..) aynı space de olması gerekir. Peki farklı space ler performansı nasıl etkileyebilir?
 
Mesela directional lighting yapıyo olalım : Eğer lighting modeli ile ilgili hesapları world
space de yaparsak, shading i yapılan bi geometrideki her vertex in normali world space
e çekilmeli. Eğer object space de yapılırsa sadece direction vector object space e
çekilmeli. Normaller zaten object space de tanımlı.
 
Bu gibi şeylerin dışında eskiden hesaplaması pahalı olan bazı fonksiyonlar önceden
hesaplanıp texture içine konurdu. Mesela attenüasyon fonksiyonları falan. Bunlar pixel
shader da fetch edilirdi. Eskiden diyorum çünkü pixel shader 1.1 de komut sayısı falan
yetmiyordu. şimdiki GPU lar baya güçlü ve güncel shader modellerinde karmaşık hesaplar
yapmak mümkün. Yani artık texture look up yerine aritmetik işlemleri tercih ediniz.
 
Tabii iş implementasyona gelince bi sürü detay var.. sadece rendermonkey projelerinden ne
kadar öğrenilirir bilemicem yani.. kolay gelsin ..
 
scg / forlorn

[nightlord]

hah evet islemlerin ayni space'te yapilmasi erkliligini vurguladigin cok iyi olmus scg... ben atlamisim... saolasin.
 
ve de nerelerdesin yahu

[nightlord]

Yani artık texture look up yerine aritmetik işlemleri tercih ediniz.

Aslinda tam emin degilim fakat , texture lookup uniteleri ile aritmetik uniteleri esit miktarda utilize etmeye calismak daha fazla performans saglamali. cunku shader compilerlari bu durumda onlari gpu'da paralel isleyecek sekilde reorder edebiliyordu galiba. Yani ayni anda aritmetik unite bazi aritmetik komutlari isletirken texture unit de lookuplari yapabiliyor... diye hatirliyorum.

[scg_]

selam nightlord.
 
Akademik hayatım , hayatımın içine etti diyelim ıyice uzaklaştım bu işlerden ...
 
Artık yeni GPU larda ALU : TEX oranı büyüyecek. Ne demek bu ?
Shaderlarda texture komutlarından daha çok aritmetik komutlar kullanın demek. Matematikle halledilebilcek
herşeyi hesaplayın. Mesela ati paper larından birinde minimum 6 : 1 gibi bi oran tavsiye
ediliyordu. Compiler ın matematik komutları optimize edebileceğini ama texturelara yapacak
bişeyi olmadığı vurgulanıyordu. Yani bi de texture lar sadece 24 / 32 bit lik standart
diffuse map ler de değil artık.Genel amaçlı look up tablosu oldular. 64 bitlik (fp 16) ,
yada ne biliyim 128 bit (fp 32) bile olabiliyor. Volume texture lar falan .. GPU bus
transferleri falan .. sonra sampling için filtreleme de yapacak .. bilinear falan en az 1
clock yiyodur herhalde
 
Son çıkan nvidia DX10 demolarından birinde realtime procedural texturing vardı ...
 
düşünün artık yani..
 
scg / forlorn

[chenmy1]

Cevaplar icin sagolun bu gibi standart formullerin yaninda birde degisik isiklandirma formullerinin oldugu ATI render monkey ve Opengl nin sitesindeki linklerde gormustum ..
 
Bunun gibi diger isiklandirma sistemi tekniklerini ve formullerini anlatabilecek olanlar var mi?veya ceviri yapabilecek olanlar?introlarimizda kullanmak icin...