Gönderen Konu: pc demolari  (Okunma sayısı 19032 defa)

pc demolari

« Yanıtla #15 : 14.04.2007 14:20:57 »
Hızlı düğmeleri aç

skate

İleti: 5.245

A Sinner Scener
Çevrimdışı
  • Administrator
  • *****
  • Hero Member
    • Profili Görüntüle
    • http://www.akaydin.com/
PC'nin dezavantajlarından biri de hazır libraryler. Örneğin PC'de beni en çok etkileyen efektlerden bazıları fiziksel hesaplama içeren efektler olmuştur. Ancak adamın ODE gibi hazır bir fizik engine kullanıp kullanmadığını bilemediğim için hep kafamda "acaba kendisi mi yaptı, yoksa?" türü şeyler dönüp durmuştur. Adam 4k bile kodlamış olsa sonuçta o efekt için gerekli fonksiyonları copy&paste edebilir open source bir projeden. Benim kafamı en çok bu kurcalıyor ve süpheci yaklaşıyorum.
 
Gelelim "ulan 64de adam copy&paste yapamaz mı?" olayına. şu kadarını söyliim, yapamaz :) Eğer birilerini etkileyecek kalitede bir efektse zaten detaylı olarak incelenir ve arak olup olmadığı ortaya çıkar. Bunun haricinde sağdan soldan bulabileceği rutinler "16 bit unsinged multiply" hede hödö tarzındadır ki bunlar zaten diğer paltformlarda hazır opcodelar olarak gelmekte. Kısacası 64'de izlediğimiz bir efektin %99 programcıya ait olduğu kesindir. %1 ise en geç 1 hafta içinde CSDB'de yankılanmaya başlar.
 
Bu yüzden PC demolarında çok taktir ettiğim efektler görsem de içimde hep bir süphecilik olmuştur. Tabii efekti yapan bu grup ASD, FB, FLT, TBL, MFX v.s. bir grupsa bu kadar süphe etmiyorum olaydan. Ancak Jumalatua kalkıp 40 yılda bir adam gibi bir demo partı kodladığında kıllanıyorum mesela. Olay benim açımdan budur.

pc demolari

« Yanıtla #16 : 14.04.2007 23:01:56 »
Hızlı düğmeleri aç

nightlord

İleti: 1.085

Çevrimdışı
  • Administrator
  • *****
  • Hero Member
    • Profili Görüntüle
    • http://www.nightnetwork.org
sunu belirtmeden gecemeyecegim:

Procedurel olarak arbitrary sekillerde modeller uretip bunlari real time olarak binlerce daha kucuk parcaya bolmek ve o parcalarin fiziksel olarak yeterince inandirici sekilde hareketlerini saglamak, c64'te textured hires kub cevirmekten daha kolay degil. Tabii bu kisiden kisiye degisebilir. Bu yapilan 64K 128K falan degil 20MB demo olsaydi yine gayet zordu.

Bak valla boyle :) Inanmayanlari size limitsiz olarak bir engine yazmaya davet ediyorum. Ben size arbitrary bi .x modeli vericem. Siz de onu parcaliycaksiniz :)


anes: Diger butun soylediklerine katilmakla beraber, "yonetmen" kelimesine ben hala tepkiliyim yalniz. Demolarda sunuma, ses senkronizasyonuna, gecislere kisaca o dedigin bi sonraki partta nasil "waaaaay" dedirtiriz kaygisina ilk dikkat eden gruplar tbl, farbrausch degil. Bu olay scene'de onyillardir var ve buna "design by", "idea by" falan deniyordu. "directed by" bence mesaj kaygili bir credit. Yine senin refere ettigin "kendisi demo yapmayan ama partilerde on siradan demo seyredenlere (ozellikle bunlardan genc olanlara)", "vaay abi adamlar demolarini film gibi yonetiyolaaar " dedirtmek icin oldugunu dusunuyorum. Her demo yapan zaten bu sunum olayina kamera hareketlerine dikkat eder. Evet fr, tbl falan bunu herkesten iyi yapiyor kesinlikle. Ama yaptiklari isin adina "design" degilde "direction" demek tamamen bir pazarlama taktigi bence :)

PS: Evet Obsolete igrenc bi demodur bence de. Planet Riski yenmesi scene inner circle'inin tarihteki buyuk ayiplarindan biridir. Assembly 2004 katilimcilari bulunup tokatlanmalidir :)

pc demolari

« Yanıtla #17 : 15.04.2007 02:07:41 »
Hızlı düğmeleri aç

Hydrogen

İleti: 932

Çevrimdışı
  • 7DX Organizer
  • *****
  • Hero Member
    • Profili Görüntüle
    • http://www.glance.ws
Debris bence gayet super bir demo. Ve directed by yazisina da pek takilmadim. Zira designed ya da idea gibi olaylarin bile asla cok on plana cikmadigi bir olay demoscene ki bu olaylar, en az bir sinema filminde oldugu kadar onemli oldugu halde.
Bu tarz cool olaylari kullanmak da ilk degil zaten. Mesela c64'de Dutch Breeze'de normalde hic adet olmadigi halde, butun scenerlarin isimleri yazardi ve bu demonun cok daha karizmatik gorunmesine yol acardi.
 
Demolar da sinema tekniklerinin ve terminolojisinin kullanilmasi da beni cok rahatsiz etmedi acikcasi. Cins bir kubun ya da anlamsiz bir 3d objenin, 150 acidan cevirilip, hayvan gibi fovu abartilmis bir sahnede, bakctoundundaki texturela birlikte hizli hizli donmesi olayi cok cok daha fazla rahatsiz edici . Ve bu 150bin demoda yapildi ve hala yapilmakta. En basta elestirilmesi gereken bence bu.
 
Ha Hydrogen sen yazarmiydin Directed by. Hayir muhtemelen klasik( ve klas) olan design ve idea'yi tercih ederdim. Ama demo iyi olduktan sonra orada directed by yazmis oteki yazmis, bu yalnizca bir sov. Bu bir taktik de olsa, gayet etik. Herkes bu tarz yontemleri kullaniyor.
 
Bir diger olay da Pc demolarini anlamak uzerine. Ben de partilerdeki ilk uc demoyu izleyen scenerlardanim. Ve bir pc demosunu teknik yeterliligine gore cok algiladigim soylenemez ortada olan demo bunu bagirmadigi surece. Ancak pc'de asil dikkat ettigim, demolarin cogunun pc'nin yeteneklerini ozellikle gorsel ve isitsel olarak kullanmadaki zayifliklari. Mesela adam gibi donatilmis 3d modelleri, Tbl, Andromeda, Farbrauch'dan baska gruplarda cok gormedim. Veya kulak daglamayan muzikleri.
 
C64'de bazi demolarda oyle code,gfx,msx dengesi var ki, hangi birine dikkat edecegini sasirirsin. Grafikeri mukemmel oldugu icin izledigim c64 demolari vardir. Veya okuz gibi soundtracki olan.
Benim gozume carpan, Pc demolarinda, hala bir cok grupta olayin %95'i sadece codedan ibaret. Bu dehset guclu makineler olan pclerin sucu degil. Bu pc demoscene kulturunun bir eksikligi bence.
 
Bir de "Pc demolari genel olarak neden daha az etkiliyor" sorusuna kendimce buldugum bir yanit da su. C64'de cikan bir seyin demo olabilmesi faslinda bir cok coder vs. elenir zaten. Cunku demo sayilabilecek bir seyi c64'de yapmak cok zordur. Dogal seleksiyon cok gucludur. Pc'de ise basit demolar codelamak gercekten cok kolay ve buyuk bir demo enflasyonu var, bu da dogal olarak pc demolarinin degerini dusuruyor.
 
Ama su da bir gercek ki, Pouet'te igrenc 8 bit seylere, wow, 8 bit rules gibi geyikler yazan ancak hayvan gibi Debris demosuna ruhsuz bu gibi anlamsiz gerekcelerle thumb down veren zihniyeti ben de siddetle kiniyorum.
« Son Düzenleme: 15.04.2007 02:12:31 Gönderen: Hydrogen »

pc demolari

« Yanıtla #18 : 15.04.2007 14:35:43 »
Hızlı düğmeleri aç

tesla

İleti: 426

Çevrimdışı
  • ****
  • Sr. Member
    • Profili Görüntüle
    • http://
Ufak bir ekleme olarak; Debris'in en çok güvenlik kamerası sahnesini beğendim. Tam o sırada ses dışardan ve boğuk olarak geliyor, sanki gerçekten binanın güvenlik kamerasından izliyormuşuz gibi oluyor. Onun haricinde ilk seferinde ağır çalışmasından olsa gerek aşırı beğenmedim. Sonradan videosunu izleyince biraz daha fikrim değişti.

Son zamanda çıkan demolardan en çok onwards,  'ı beğeniyorum. Renkleri ve akışı öylesine güzel ki bana göre. Efektleri ne kadar karmaşık olmuş, ne kadar zor olmuş ben zaten kestiremiyorum. Sadece beğeniyorsam beğeniyorum :)

Sanırım ben Hydrogen'in 8 bit şeylere "wow" diye bakan kitleye yakınım biraz ...  Desert Dream c64 versiyonunu Debris'ten fazla izledim.  Onca PC demosu varken tekrar tekrar açıp Amiga demolarını izliyorum. :)  bence biraz karar tercih meselesi. Scene'in ne kadar merkezindesin? le ilgili. Scene'in merkezinde duranlar kıyılarında duranların zevklerini garipsiyor / küçümsüyor olabilirler, normaldir.

pc demolari

« Yanıtla #19 : 15.04.2007 23:42:48 »
Hızlı düğmeleri aç

ghost

İleti: 86

Çevrimdışı
  • **
  • Jr. Member
    • Profili Görüntüle
    • http://www.bronxwhq.org
Alıntı yapılan: nightlord;14111
sunu belirtmeden gecemeyecegim:

Procedurel olarak arbitrary sekillerde modeller uretip bunlari real time olarak binlerce daha kucuk parcaya bolmek ve o parcalarin fiziksel olarak yeterince inandirici sekilde hareketlerini saglamak, c64'te textured hires kub cevirmekten daha kolay degil. Tabii bu kisiden kisiye degisebilir. Bu yapilan 64K 128K falan degil 20MB demo olsaydi yine gayet zordu.

Bak valla boyle :) Inanmayanlari size limitsiz olarak bir engine yazmaya davet ediyorum. Ben size arbitrary bi .x modeli vericem. Siz de onu parcaliycaksiniz :)

...


ben tam aksini dusunuyorum. procedurel olarak uretilmis objleri parcalamak, elle yapilmis .x objesini parcalamaktan daha kolaydir. cunku prosedurel olarak urettigin modeli parcalanabilir olarak yaratabilirsin (atiyorum kup/kure bloklarin bilesimi olarak). yani obje yaratimi bittiginde zaten parcalanmaya hazir halde olacaktir. oyle demo esnasinda hesaplanmasi gerekmez, demo baslamadan once yaratilir komple o sekilde.

ha otur yaz desen, yazmam. zaten o kadar optimize bir kod cikaramam, ayrica tembelin tekiyimdir. :)
he moves like a madman as he spins his disc.

pc demolari

« Yanıtla #20 : 16.04.2007 02:30:24 »
Hızlı düğmeleri aç

skate

İleti: 5.245

A Sinner Scener
Çevrimdışı
  • Administrator
  • *****
  • Hero Member
    • Profili Görüntüle
    • http://www.akaydin.com/
Belirli özelliklerdeki objeleri parçalamak kolay. Örneğin bir cube, torus ya da cylinder objesinden türeme bir objeyi (eğilmiş, bükülmüş, yamulmuş, kıvrılmış felan) verin bana parçaliim, sorun değil. Ama random bir yöntemle modellenmiş bir .x'i verin bana, döt gibi kaliim :) Nightlord da bu ikinci ihtimalden bahsediyor olsa gerek.

pc demolari

« Yanıtla #21 : 16.04.2007 04:09:06 »
Hızlı düğmeleri aç

nightlord

İleti: 1.085

Çevrimdışı
  • Administrator
  • *****
  • Hero Member
    • Profili Görüntüle
    • http://www.nightnetwork.org
Alıntı yapılan: ghost;14136
ben tam aksini dusunuyorum. procedurel olarak uretilmis objleri parcalamak, elle yapilmis .x objesini parcalamaktan daha kolaydir. cunku prosedurel olarak urettigin modeli parcalanabilir olarak yaratabilirsin (atiyorum kup/kure bloklarin bilesimi olarak). yani obje yaratimi bittiginde zaten parcalanmaya hazir halde olacaktir. oyle demo esnasinda hesaplanmasi gerekmez, demo baslamadan once yaratilir komple o sekilde.


Ben iki problemin temelde ayni oldugunu (ya da en azindan ayni zorlukta oldugunu) dusunuyorum. yani hedefledigin sekil arbitrary bir sekilken (3D text, vs gibi), onu kuplerden olusturacak procedurel algoritmayi bulma problemi ile, elde olan arbitrary bir obje modelinin 3d olarak parcalara bolme probleminin yakin problemler oldugunu dusunuyorum.


Buna ilaveten tam olarak parcalanma ani ile ilgili olarak vertex shader'in nasil yonetildigine dair ciddi sekonder problemler var. Modellerin parcalanmadan once zaten kuplere bolunmus fakat her kupun yerinde oldugu sekilde render edildiklerini sanmiyorum. Oyle olsaydi, z buffer ordering problemlerinden dolayi kamera hareket ettikce seam'ler goruyor olurduk. Mesela opengl veya directxte sirt sirta dayali ayni buyuklukte iki kup render edip kamerayi oynatirsaniz birlesim yerinde izler gorursunuz pekcok ekran kartinda.

Ya seam'leri saklamanin cok guzel bi yolunu buldular pixel shader'da. ya da parcalari tam kopma anindan itibaren ic yuzeyleriyle beraber render ediyorlar. (kopmadan once ic yuzeyleri render etmiyorlar)
« Son Düzenleme: 16.04.2007 04:12:49 Gönderen: nightlord »

pc demolari

« Yanıtla #22 : 16.04.2007 05:24:10 »
Hızlı düğmeleri aç

ghost

İleti: 86

Çevrimdışı
  • **
  • Jr. Member
    • Profili Görüntüle
    • http://www.bronxwhq.org
Alıntı yapılan: nightlord;14139
...
... ya da parcalari tam kopma anindan itibaren ic yuzeyleriyle beraber render ediyorlar. (kopmadan once ic yuzeyleri render etmiyorlar)


benim tahminim de bu yonde oldu.

bilmiyorum, buyuk bir objeyi kucuk parcalardan uretmek, tek bir objeyi kucuk parcalara ayirmaktan daha kolaymis gibi geliyor bana.
he moves like a madman as he spins his disc.

pc demolari

« Yanıtla #23 : 16.04.2007 06:49:19 »
Hızlı düğmeleri aç

anesthetic

İleti: 403

Çevrimdışı
  • ****
  • Sr. Member
    • Profili Görüntüle
    • http://resident.tr-demoscene.info/
benim izleyeceğim yöntem şu olurdu: t0 anında explosion p0 noktasında başlasın ve yayılma hızı v olsun.

objeyi çizerken p0 merkezli ve (t-t0)*v yarıçaplı küre patlamanın tamamen gerçekleştiği hacim olacak. yani p0 merkezli ve giderek yarıçapı büyüyen bir küre.

vertex shader ile küçük poligonlara bölünmüş objede bu kürenin içinde olan her vertexi kürenin yüzeyindeki en yakın noktaya gönderirim.

bu sayede parçalanmanın yarısı, yani parçalanan büyük objenin parçalanmış kısmının görünmeme olayı halledilmiş oldu. geri kalan kısmı, yani parçalanma bölgesinde dağılan edevatlar göstermeyi de büyük objenin küçülmesinden bağımsız bir şekilde, etrafa rasgele (giderek açılan tabi) prizmalar dağıtarak hallederim.

burada tek sorun büyük objenin giderek büyümesinin önüne geçmek için p0 noktasını objenin dışında bir yerde alma gerekliliği (her primitive, noktanın aynı yamacına maplenecek).

debris'teki bütün parçalanmaların mükemmel küresel şekilde olması bana onların da öyle yaptıklarını düşündürüyor.



aslında aynı şeyi tam ters yoldan nested'ta kullanmıştım. objenin küre içinde değil de küre dışında kalan kısmını saklamak için.


pc demolari

« Yanıtla #24 : 16.04.2007 06:55:21 »
Hızlı düğmeleri aç

anesthetic

İleti: 403

Çevrimdışı
  • ****
  • Sr. Member
    • Profili Görüntüle
    • http://resident.tr-demoscene.info/
etrafa dağılan küçük parçaların, tam dağılmaya başlama anında büyük objenin yüzeyi ile align etmesi gerektiği için, nightlordun bahsettiği seamler oluşacak. ama zaten hem anlık olduğu hem de biz orayı parçalanıyor olarak gördüğümüz için göze batmayacak.

pc demolari

« Yanıtla #25 : 16.04.2007 07:08:32 »
Hızlı düğmeleri aç

ghost

İleti: 86

Çevrimdışı
  • **
  • Jr. Member
    • Profili Görüntüle
    • http://www.bronxwhq.org
Alıntı yapılan: anesthetic;14141
benim izleyeceğim yöntem şu olurdu: t0 anında explosion p0 noktasında başlasın ve yayılma hızı v olsun.

objeyi çizerken p0 merkezli ve (t-t0)*v yarıçaplı küre patlamanın tamamen gerçekleştiği hacim olacak. yani p0 merkezli ve giderek yarıçapı büyüyen bir küre.

vertex shader ile küçük poligonlara bölünmüş objede bu kürenin içinde olan her vertexi kürenin yüzeyindeki en yakın noktaya gönderirim.
...



akla daha yatkin hakaten.
he moves like a madman as he spins his disc.

pc demolari

« Yanıtla #26 : 16.04.2007 09:11:59 »
Hızlı düğmeleri aç

nightlord

İleti: 1.085

Çevrimdışı
  • Administrator
  • *****
  • Hero Member
    • Profili Görüntüle
    • http://www.nightnetwork.org
Alıntı yapılan: anesthetic;14141
vertex shader ile küçük poligonlara bölünmüş objede bu kürenin içinde olan her vertexi kürenin yüzeyindeki en yakın noktaya gönderirim.

bu sayede parçalanmanın yarısı, yani parçalanan büyük objenin parçalanmış kısmının görünmeme olayı halledilmiş oldu. geri kalan kısmı, yani parçalanma bölgesinde dağılan edevatlar göstermeyi de büyük objenin küçülmesinden bağımsız bir şekilde, etrafa rasgele (giderek açılan tabi) prizmalar dağıtarak hallederim.

Ben tam anlamadim. Eger kurenin icinde kalan vertexleri kurenin yuzeyine gonderirsen gorunmelerini engellemis olmayacaksin gibi geliyor bana sadece objenin kure icinde kalan bolumu balon gibi sisiyor olmayacak mi? Sonucta Nested'da kurenin yuzeyine gonderilen vertexler gorunmeye devam ediyor.

Dagilan edevat ile ilgili ise particle system'lere benzer bir durum oldugunu dusunuyorum ben. her edevat prizmasinin t= t0_piece aninda buyuk objeyle alligned olarak baslamasi ve sonrasinda da hafif variationlarla, ivme, hiz ve pozisyonlarinin update edilip. rotationlarin da fiziksel dayanak olmaksizin oldugunu saniyorum.

Dolayisiyla ben olsam edevat prizmalari icin buyuk bir vertex bufferda her vertex basina bazi extra fieldlarda su bilgileri saklardim:
- ait oldugu prizmanin local orijini
- ait oldugu prizmanin patlamadan once gorunen bir vertexi mi degil mi (buna originally visible vertex diyelim)
- ait oldugu prizmanin t0_piece yani patlama anini
- prizmanin x exseni etrafi rotasyon hizi (rot_spd_x)
- prizmanin y exseni etrafi rotasyon hizi (rot_spd_y)
- prizmanin z exseni etrafi rotasyon hizi (rot_spd_z)
- prizmanin ustundeki a_init, v_init vektorleri


daha sonra vertex shadera her frame sunlari gecirirdim:
- t
- buyuk objenin x y z eksenlerine yaptigi aci (yani bir nevi buyuk objenin rotasyon matrisi)
- buyuk objenin x y z pozisyonu

sonra da vertex shaderda
-t_local = t - t0_piece
--t_local negatif ise ve originally visible degil ise hide vertex (!?)
--t_local negatif ise ve originally visible ise render edicez
--t_local pozitif ise t_local, rot_spd_x, rot_spd_y, rot_spd_z, kullanip bunlari buyuk objenin rot_x, rot_y, rot_z si ile toplayarak prizmanin rotasyon matrisini hesapla
- t_local, a_init, v_init ve buyuk obje pozisyonlarini kullanarak prizma pozisyonunu bul
- pozisyon ve rotasyon bilgilerini kullanarak ModelToWorld matrisini olustur, vertexi carp ve dunyaya yerlestir

Boylece prizmalarin inital pozisyonlarinin buyuk objede alligned olmasi garantilenmis olur. butun hesaplamalar vertex shaderda oldugu icin cok hizli olur ve cpuya yuklenmez.

Fakat benim problemim bir vertexi (ve ona bagli olan poligonlari) render etmemek istedigimde bunu yapacak optimum bir yol bulamamis olmam. Aklima gelen tek sey. pixel shader'a her vertexten 1 veya 0 bir value gecirip, ps'da o value 1 mi diye bakmak (eger ucgenin koselerinden biri 0 ise poligondaki pixeller icin interpolasyon degeri 0dan kucuk olur). Ama bu cok inefektif olur.

O yuzden anes'in bunu nasil yapmayi planladigini merak ettim zaten :)

Bi de tabi o buyuk vertex bufferi hazirlamak gibi de guzel bi problem var

pc demolari

« Yanıtla #27 : 16.04.2007 10:35:05 »
Hızlı düğmeleri aç

anesthetic

İleti: 403

Çevrimdışı
  • ****
  • Sr. Member
    • Profili Görüntüle
    • http://resident.tr-demoscene.info/
Alıntı
Ben tam anlamadim. Eger kurenin icinde kalan vertexleri kurenin yuzeyine gonderirsen gorunmelerini engellemis olmayacaksin gibi geliyor bana sadece objenin kure icinde kalan bolumu balon gibi sisiyor olmayacak mi? Sonucta Nested'da kurenin yuzeyine gonderilen vertexler gorunmeye devam ediyor.


objenin küre içinde kalan kısmı içe çöküyor olmalı. kum havuzuna düşen basket topunun kumlarda yaptığı değişiklik gibi. küreyi dışarıdan büyütmemiz gerekiyor dememin sebebi buydu.

obje küçük ve obje yüzeyi değişken ise (greetlerdeki harfler gibi) bu basıklık küreye daha çok benzeyecek. görünüp görünmemesi ise önemli değil çünkü harfin hem önünden hem arkasından basılacak (ve önden baktığımızda arkayı boş göreceğiz).

obje büyük ve obje yüzeyi geniş düz parçalardan oluşuyorsa (binalar gibi) hem basıklık küreye benzemeyecek (fazla eğrisel olmayacak) hem de görünmeleri sorun teşkil edecek.

ama binanın birazcık içine karlı görüntü kaplamalı büyük bir blok koyarsak sorun kalmaz gibi geliyor bana :) bu blok basıklığın önüne geçeceği için içeri bastırdığımız kısım tamamen kayboluyor hissi verecek (kaybolmuş vertexlere sahip üçgenleri piksel shaderda çizdirmemek gibi yollar gerekmeyecek).

pc demolari

« Yanıtla #28 : 16.04.2007 17:42:12 »
Hızlı düğmeleri aç

GnoStiC


  • Ziyaretçi
debris'in yeri ayri tabi ama halen cogu pc intro/demo'su beni 199x (x=0,1,2,3) yillarinda yayinlanmis Amiga ECS demolari kadar etkilemiyor..

resident'in 7d7'de yayinlayacagi (amin) pc demosunu 4 gozle bekliyorum.. izledikten sonra mest olacagimizdan (mest'ed) eminim :)

i have had it with these motherfucking demos on my motherfucking pc!

pc demolari

« Yanıtla #29 : 16.04.2007 23:29:29 »
Hızlı düğmeleri aç

skate

İleti: 5.245

A Sinner Scener
Çevrimdışı
  • Administrator
  • *****
  • Hero Member
    • Profili Görüntüle
    • http://www.akaydin.com/
@anes: ben anladım senin kastettiğin yöntemi ancak sanırım debris'te nightlord'un düşündüğü yöntem kullanılmış.
 
bu arada seamlerle ilk tanışmam çok geç oldu benim (2004-2005 falan). PC'de aklıma gelen hoş bir efekt planı sırf bu yüzden suya düşmüştü. Deneme yanılma kadar öğretici başka birşey bilmem zaten hayatımda :)