☰ Menu

Scene.hu

Magyar demoscene portál – grafikusok, zenészek, programozók alkotói közössége

Archive for the ‘Programozás’ Category

Hi! Megismételtem egy régi történetet, írtam egy klienst a Rocket Editor-hoz Rust-ban. Windows, Linux és Mac-en is megy (elvileg!).  (Gyors linkek, akiknek ez már ismerős terület: leírás, client és sync crate, példa kód).

Ez egy viszonylag egyszerű dolog, de kódolás közben eszembe jutott, ahogy korábban mások, csendben magukban egy nagy CRT monitor előtt, vagy egy parti közepén együtt valakivel, Rocket klienst írtak.

Hamarosan Function lesz! Demót nem tudok küldeni, de ti majd remélem, mert várom látni a beadott prod-okat.

Demók Rust nyelven

Hagyományosan a demó írás a C/C++ nyelveken történik, mert a végeredmény mindenképp egy darab futtatható bináris fájl kell legyen, és a művészi szabadsághoz (értsd: wild hacking) kell, hogy szabadon lehessen irányítani, mi történik alacsony szinten a kódban. Illetve, a 4k – 64k kategóriákhoz ennek a méretét is erősen optimalizálni kell.

A Rust nyelv hasonlóan binárisra fordul. Újnak nevezhető, de azért már 2015-ben volt az 1.0 kiadása, és azóta már két év eltelt. Növekszik az olyan elvárt library-k száma, mint a smallvec (growable array on the stack), notify (file asset figyelés) vagy a serde (serialization to- and from structs).

Rust-ban dolgozva többet segít a compiler abban, hogy segfault mentes legyen a programunk. Minden változót végigellenőriz, és nem engedi meg például azt a helyzetet, hogy olyan változó címre írjunk ami már felszabadult, vagy valami éppen máshol is módosítja azt.

Alacsony szintű hozzáférés? Művészi szabadság? Van. Egy unsafe { ... } blokkon belül a compiler elengedi a kezünket, és vagdalkozhatunk mindenféle unsafe csatabárddal mint amilyen a mem::transmute. Idézem a Rust nomicon-t:

“Újra fogjuk értelmezni ezeket a biteket ha bele is pusztulunk!”

A compiler remek hibaüzenetekkel szolgál, gyakorlatilag a compiler üzeneteiből meg lehet tanulni használni a nyelvet.

Például jellemző az, hogy változtattam valamit egy struct-ban. Most akkor emlékezzek minden helyre ahol ez releváns? Hagyjuk rá a compiler-re. Minden helyet megtalál, ahol ki kell bővítenem a kódot, és a szerkesztőben egyik helyről a következőre ugrok amíg el nem fogynak a hibák. Ha lefordul, jó is lesz.

Rust-ban dolgozik például Ferris és Phaazon. Látta valaki az Elysian (64k!) demót vagy az Outline 2017 invite-ot? Remek demók, Rust-ban. Ferris tartott egy három órás előadást arról, hogyan működik a demotool-juk.

Logicoma – Elysian (Final version)

Outline 2017 Invitation – DESiRE & The Undead Sceners

Rocket Editor

A GNU Rocket Editor az animált változó értékek ütemezését segíti. Ad egy felületet, ahol szerkeszthetjük, hogy például épp ekkor legyen a magasság 0.5, és ez menjen felfelé 1.5-ig. Közben a fényerősség változzon 2.1-től 4.0-ig. És lássuk közben, hogy az jól néz ki vagy sem. Ezt kézzel tetűkoppasztó szenvedés összebabrálni, ebben az ütemezésben segít a Rocket.

Több változata van. Az eredeti a rocket/rocket repóban él. Én magam az emoon/rocket változatot használom Linux-on.

A kliens egy futó Rocket alkalmazáshoz kapcsolódik localhost:1338 porton, és kommunikálja ezeket a változtatásokat a demónak.

Például itt, a felső ablakban fut egy kis példa projekt, ez csatlakozik az alsó ablakban a Rocket szerkesztőhöz, ott futnak az időre ütemezett változó értékek.

Link lista:

Ennyi.

A Cocoon Demo Editor rövid bemutatója

Posted by Gargaj on June - 15 - 2016

Mint ahogy azt már többször hangoztattam, a Pouëtes “Work in progress”-thread igazi aranybánya, mert nemritkán látható benne egy-egy ismertebb csapattól valami érdekesség.

Ezúttal se volt másképp: most a Cocoon grafikusa, NTSC, ragadott screengrabbert és rakott össze egy kis tízperces videót arról, hogy hogyan dob össze a Cocoon demótoolban egy viszonylag egyszerű de látványos scenet:

A videó nem sokat, de mégis rengeteget mutat: Először 3dsmax-ban dob össze egy primitív scenet, azt behúzza a toolba, majd rádob néhány effektet – ez eddig nyilván egyszerűen hangzik. A trükk a részletekben rejlik:

  • Ugyan pl. az object és a kameramozgatás 3dsmax-ban készül, utólag a toolban is tud kamerát beállítani – ezzel nagyon gyorsan tud több szögből megnézni egy jelenetet.
  • Bár ezt csak tippelem, de ha jól látom minden kiexportált adat utánszerkeszthető a toolban is.
  • Az effekteknek rengeteg paramétere ki van vezetve, így a kóder bármikor a grafikusra bízhatja, hogy mivel játszogat.
  • Ugyan aki használt már modern grafikai programot (3dsmax, After Effects, stb.) az ismeri, de mégis kiemelném mennyire fontos az a fajta numerikus input, amit használnak: minden számszerű érték klikkeléssel húzogatható fel-alá, de duplaklikk után manuálisan is beírható neki pontos érték. Ezzel nagyon könnyű mind “szemre” belőni valamit, de elkerülhető a klasszikus designeri frusztráció is ha valaminek egzakt érték kell lennie.
  • Szinte minden textúrából mappelhető: így nagyon könnyen tudja pl. a tüskés effekt formáit és színeit egyszerre úgy állítani, hogy tetszetős legyen.
  • Minden textúra helyére betölhető videó(!) is
  • Egészen elképesztő overlay- / textúra- / layer-gyűjtemény látható a vinyóján, ránézésre minden effektre azonnal ki tud próbálni 15-20 változatot. Ez a legjobban a colorgrading és a lensflare overlay állítgatásánál látszik, ahol gyakorlatilag másodpercek alatt kipróbál 5-6 variációt; mindezt azért teheti meg, mert az évek alatt összegyűjtögette tulajdonképp presetnek a rengeteg LUT-ot.
  • Érdemes összevetni a scenet a postprocessing előtt és után: az alapvetően egyszerű jelenetnek hirtelen mélysége lesz a hozzáadott (szintén egyszerű) effektektől. Rengeteget számít itt is, hogy pillanatok alatt tudja összedobálni a végleges comp-ot, és azonnal látja, hogy mit csinál. Nyilván ez nem azt jelenti, hogy minden effekt azonnal jól kezd el kinézni mihelyst belefojtjuk megfelelő mennyiségű postprocessingbe, de pl. a végén rárakott kis noise layer egyszerű, olcsó, és mégis sokat ad a végeredményhez.
  • Szintén apróságnak tűnhet, de csak a használat során derül ki az, hogy mennyire fontos az átrendezhető GUI: függően attól, hogy min dolgozik éppen, folyamatosan rendezi át a tool GUIját, hogy többet lásson abból amit épp csinál, amit meg már nem használ, azt bezárja. Ezzel rengeteg fejfájástól menti meg magát.

Egy ilyen demotool elkészítése persze nyilván évekbe telhet, folyamatos iteráció mellett, és mindenkinek gusztusa válogatja, hogy egyáltalán szüksége van rá (vagy van-e valaki aki használni is fogja), mert nyilván demót írni jobb, mint tool-t írni. Ettől függetlenül viszont nagyon fontos lecke tanulható meg pl. abból, hogy mennyire hasznos, ha az ember egy effektre azonnal rá tud dobni 3-4 textúrát is, mert sose lehet tudni, hogy melyik lesz jó, vagy melyiktől jön meg a következő ötlet.

Ez pedig nyilván így uszkve 3 hónappal Function előtt nem haszontalan.

Megjelent az Elevated forrása

Posted by Gargaj on June - 6 - 2016

Az RGBA és a TBC koprodukciójából született Elevated c. intrót biztosan nem kell senkinek bemutatni; a 2009-es Breakpoint 4k compójának győztese azon kevés intrók egyike lett ami messze túlhaladt a scene határain. Mától ez valószínűleg még tovább fog terjedni, mert tegnap publikusan is elérhető lett az intró forrása is, melynek köszönhetően végre betekintést nyerhetünk a kulisszák mögé.

Első átfutásra a következő dolgok derülnek ki a forrásból:

  • Az intró full-ASM – erről korábban ment vita is – bár érdekesmódon kétféleképp van megközelítve a dolog, a “debug” könyvtárban megtalálható az intró C verziója is, a “release” könyvtárban pedig a végleges optimalizált ASM forrás.
  • A zenét szolgáltató szintiből nincs C verzió, és egészen minimalista.
  • A kód egyik legviccesebb / legzseniálisabb része a “src\constants.h” elején található kis kódrészlet, ami segítségével ugyanaz a forrás C és ASM fordítóval is lefordítható – öröm nézni, akkora hekk.
  • Szintén gyakran hallható elmélet volt az, hogy az intró a szokásos 2D polygonra raymarcholt egy-nagy-shader. Ez nem igaz: a talaj maga egy tesszellált 3D mesh, aminek csak a poszt-processzingje történik shaderből.
  • Maga a shader természetesen olvashatatlan, ennek megértéséhez valószínűleg célszerű ha párosítjuk IQ Function 2009-es előadását is.
  • Az időzítések a GNU Rocket egy korai verziójával készültek, kivéve az égben villogó csíkokat, amik simán a zeneadatból vannak áthúzva. Ami engem elsőre meglepett, hogy sokkal több dolog van animálva, mint amire gondoltam, pl. a kontraszt, napsütés beeső szöge, de akár a domborzat mérete is.
  • Külön vicces, hogy a mostani Crinkler egy jó 30 byte helyet talál még a régihez képest.

Gömbsubdiv, röviden

Posted by reptile on April - 24 - 2016

A tavalyelőtti Astroidea 4k, a Discovery legalapvetőbb eleme a realtime sphere subdiv, vagyis egy gömb részletességének nézőponttól függő, folyamatos változtatása. Az alap algoritmust írom le most.

  1. Egy ikozaéderből indulunk ki. Ez egy olyan ojjektum, ami 20 háromszögből áll, teljesen mindegy, hogy generálod, csak a vertexek körüljárási sorrendje stimmeljen. Praktikusan a vertexek pozíciója normalizált, vagyis egy egység-gömb felületén ülnek.
    Icosahedron
  2. Húsz háromszöggel indulunk, ez majd a folyamat során változni fog, ez nem befolyásol semmit. A háromszögeken egyesével haladunk, nem teszünk köztük SEMMILYEN különbséget, vagyis az algoritmus nem függ a szomszédos háromszögektől, ami nagyon előnyös tud lenni. Cserébe sajnos indexelést sem nagyon praktikus használni vele, de ez nem egy akkora katasztrófa. Nevezzük el az aktuális háromszög vertexeit 0-1-2-nek.
    ico0
  3. Fogjuk a háromszög három élét, és generáljunk új vertexeket a felezőpontokra, nevezzük el őket 3-4-5-nek. A poziciókat normalizáljuk, vagyis pld 3=normalize(0+1)
    ico1
  4. Az érdekes rész most jön: döntsük el az új vertexekről, hogy szükség van-e rájuk, kell-e ilyen szintű osztás. Fontos, hogy csak az adott él vertexeit használjuk a döntéshez. Pld csinálhatjuk úgy, hogy megnézzük a kamera távolságát az új vertextől, megszorozzuk egy konstanssal (subdiv factor), és az így kapott értéket összehasonlítjuk az eredeti két vertex, vagyis az aktuális él hosszával. Ezzel kapunk egy igen/nem választ, ez még fontos lesz később. Tegyük fel, hogy mindhárom él IGEN-el válaszolt az “osszalak-e tovább” kérdésre, ekkor létrehozhatjuk a négy új háromszöget, amit aztán továbblökünk feldolgozásra. Az eredeti háromszöget el is felejthetjük. (Az új háromszögek: A=0,3,5 B=1,4,3 C=2-5-4 D=3-4-5)
    ico2
  5. Tegyük fel, hogy az előző pontban nem minden él adta ugyanazt a választ. Mondjuk a 0-1 él (amin a vertex 3 ül) azt mondta, őt nem kell tovább osztani. Ebben az esetben az adott él felező vertexét (esetünkben a 3-as számút) az él első vertexének (esetünkben a 0-ás számúnak) a pozíciójára állítjuk. Erre nem feltétlenül lenne szükség, hiszen – ahogy majd az ábrán látszik – az egyik háromszög gyakorlatilag eltűnik, de pld hardware megvalósításnál jól jön, hogy MINDIG fix számú háromszöget hozunk létre, maximum némelyik nulla területű. Ha az élek nem értettek egyet, akkor ugyan az eredeti háromszöget elfelejtük, de az újonnan létrehozottak mehetnek azonnal renderelődni, további feldolgozásukra nincs szükség.
    ico3
  6. … és így tovább, haladunk a háromszögeken, daraboljuk őket, ha nem kell tovább, akkor rendereljük, ha kell tovább, akkor hozzáadjuk a feldolgozási listához. Előbb-utóbb, ha nem valami végtelen kritériummal dolgozunk, elfogynak a feldolgozandó háromszögek, ezzel kész is vagyunk.

 

Az élek osztása, illetve az, hogy csak és kizárólag az élek vertexeivel számolunk biztosítja, hogy sosem lesz törés, lyuk, vagy bármi ilyesmi anomália a mesh-en, hiszen két szomszédos háromszög élei matematikailag is ugyanazt a választ fogják adni mindig, bármelyik oldalról nézzük.

Lehetséges még minden háromszögre előszűrést, pld backface vagy frustum szűrést végezni, de óvatosan – egy nagy háromszög nem tökéletes mása a gömb-darabkának, amit reprezentál, pláne, ha később mondjuk displacement is kerül rá (márpedig fog, mert ki akar sima gömböt renderelni:)).

AstroideA 4k source pack

Posted by Gargaj on January - 11 - 2016

Kellemes karácsonyi meglepetéssel szolgált Reptile, amikor elérhetővé tette az elmúlt három 4k intrójának (Discovery, Re(s)tro, TheFa Definitive 15th Anniversary Edition) forrásait.

A lefordításukhoz Visual Studio 2013 (elvileg az ingyenes Express edition is megfelel a célra) és DirectX 9/11 SDK szükséges; a szintén felhasznált Crinkler és a Ctrl-Alt-Test Shader Minifier megtalálható a ZIP-ben is, ahogy a zenét szolgáltató 4klang és egyéb alkatrészek is.

Ami első rátekintésre a legérdekesebbnek tűnik mindhárom intró kódjában, az a CPU-kód szinte teljes hiánya – az ablaknyitást és mindenféle inicializálást leszámítva az intrók szinte teljességgel shaderben vannak megvalósítva. Ez alapvetően nem is lenne meglepetés, hiszen a rengeteg Shadertoy-based 4k ugyanezt teszi, viszont ez a három intró sokkal inkább geometria-alapú, így a tényleges effektkód eloszlik a vertex-, pixel-, illetve a DX11-es intrók esetén a geometry-shaderek között. További érdekesség a Discoveryben a shader alapú zenegenerátor, valamint az #ifdef-tengerben megbújó beszédszinti, ami nem jutott be a végleges verziókba.

hg_sdf – a Mercury eszköztára

Posted by Gargaj on December - 16 - 2015

Igazán érdekes és módfelett hasznos dologgal rukkolt elő a Mercury: Nyílt forráskódúvá tették azon shader-libraryjük jelentős részét, amit nem csak a nagysikerű intróikban láthattunk dolgozni, hanem Cupe NVScene-s előadásában még közelebbről is bemutatta, hogy milyen gyorsan lehet vele dolgozni.

Miről is van tehát szó? A hg_sdf névre keresztelt függvény-gyűjtemény a manapság rendkívül népszerű signed distance field renderinget (előjeles távolságtér? Jézusom) hivatott megkönnyíteni: Aki ezt nem ismeri, röviden összefoglalva a módszer lényege annyi, hogy a kirenderelendő objektumokat felületekként kezeljük a kódban, és a tér minden pontjára meghatározzuk, hogy milyen távol van a térben legközelebb lévő felülettől. A technika népszerűsége természetesen IQ / RGBA-nak köszönhető, aki szintén rengeteg infót biztosított már róla – ez a mostani kezdeményezés a Mercury részéről igazolja is az erre való igényt.

hgsdf

Nyilván a technikának megvannak az előnyei és hátrányai, utóbbi például az, hogy mindent matematikailag kell leírni; ebben próbál segítséget nyújtani ez a hasznos kis fájl, amiben az alapvető geometriai formák mellett rengetegféle ismétlődési, vagy épp csatlakoztatási formula van leírva, aminek segítségével sokkal könnyebb magukat az egyszerű formákat kicsit részletesebbé tenni. Az oldalon a leírás és a kód mellett kis dokumentáció is található arról, hogy mit hogyan érdemes megközelíteni (pun not intended), és bár maga a kód maga GLSL-hez készült, semmi olyat nem tartalmaz, ami ne lehetne átültethető HLSL-re is, így gyakorlatilag bárkinek csak a hasznára válhat, aki ilyen jellegű intrót / demót szeretne csinálni, vagy akár csak Shadertoyon szeretne valamível virítani.

Apropó Shadertoy, azt tudtátok, hogy IQ valószínűleg nem erről a bolygóról származik?

Amíg Mau megírja a zárócikket a Functionös demózsemle-sorozatban, addigis itt az egyik előadásról készült videó a partyról. Az előadó az Indexet is megjárt, a scene-t állítása szerint régóta követő Zsolnai-Fehér Károly, a bécsi egyetem kutatómunkatársa.

Az előadás nyilván az ő szakterületének rövid (de közérthető) összefoglalója; ahogy a címből is kitalálható, a raytracing, global illumination, subsurface scattering és ezeknek az alkalmazása, teljesen közérthetően, mindenféle mély-technikai részlet nélkül. Mivel az egész alig fél óra, megtekintése mindenképp javasolt kódereknek kötelezően, mindenki másnak fakultatívan:

Move your world!Az előző cikkben azt ígértem most a mozgatható elemek – alig meglepő módon – mozgatásáról lesz szó. Ez lesz az ami biztosítja nekünk, hogy a kicsit szegény és limitál grafikai tárházunkat meghökkentő trükkökkel, lélegzet elállító látványossággá alakítsuk. Legalább is értékelhetővé tegyük, hogy ne akadjon fel az elő-zsűrin. :) Aki persze játékgyáros ambíciókkal rendelkezik ezt a részt áhítattal kell olvassa! Hiszen félig ettől kelnek életre a kis – ám nagy gonddal megalkotott – játék elemek.

Vágjunk is bele!

Tovább…

[Az előző rész itt tekinthető meg.]

Ahogy ígértem a mostani részben felhasználjuk az eddigieket és megismerkedünk igencsak egzotikus grafikai tárházunkkal. Mostantól nem írok teljes kódlistát, csak az adott kivesézett részt. A teljes forrást és a binárist persze letölthetitek majd.

Tovább…

DSC_8621Mint ígértem folytatom a Solskogen beszámolómat:

  • A szombati nap jóval lasabban indult be, mint azt elsőre vártam, de ez végül semmiképpen sem jelentett hátrányt. Mivel én rendszerint 6kor kelek, ezért 7:30-nál önmagam kénszerítésével sem tudtam tovább aludni (na meg persze a sleeping area sem volt túl meleg! :) BTW: ha valaki megy Norvégiába, még ha nyárról is van szó, NEM ELÉG EGY SZÁL hálózsák + polifoam combo! Vagy valami vastagabb device alulra, vagy mobil ágy preferált.  Szerencsére engem megmentett a síkabátom, de nem volt egyszerű beleimádkozni magam a hálózsákba esténként Michelin babaként :P ) Szóval sikerült belebotlanom a még éppen csak aludni készülő Darklite csapatba, és gyorsan elindítottuk a reggelt egy két poénnal, na meg sörrel. Akik azzal a kritikával szokták illetni a német partykat, vagy akár a FUNCTION-t, hogy túl szoros a program, azoknak szól ez a nap. Egészen este 8-ig nem volt kifejezetten scene related event, cserébe a “real party is outside” dolog a tetőfokára hágott. Én pl. DFox-ékkal egy csapatként reggeli után levágtattam a helyi tóhoz, és úsztam egyet. (5 perccel a vízben hősnek éreztem magam, amíg az egyik Finn srác le nem nyomott egy 15 perces lubickolást, de hát én nem vagyok skandináv no! Mindenesetre Norvégiában úszni csak saját felelősségre. A tó ATOM HIDEG!) Azután amikor visszaértünk hirtelen egy kibontakozó gasztrofesztiválon találtuk magunkat. És nem csak azért, mert egy két csapat mobil grillen sütögetett magának, hanem mert az előző napi Lasagne-ra rálicitálva a szervezők megsütöttek egy fél tehenet darabokban (tényleg komolyan mondom fejenéknt jutott kb. 2 steak meg 1 hambi + 2 kg salát meg öntetek). Ha magyar partyhoz kellene hasonlítanom, akkor kb. Árok hangulat, csak egy picit több kajával.
  • Este 8kor elindultak a kompók, amik aztán egyáltalán nem okoztak csalódást. Kifejezetten élveztem az Oldschool music-ot, Intrót és Demót. SZVSZ a demó kompó messze felülmúlta pl. az idei Revision demóit. A hangulat meg fergeteges volt. A teremben lévő kb. 120 ember lug00ber és Gargaj vezényletével hasonló hangulatot és éljenzést produkált, mint az teli E-Werk Saarbrückenben. A gasztro vonalat követve a kompók felénél tartottak egy gofri szünetet, amit megint csak a szervezők álltak (BTW: én inkább a folyékony waffelt fogyasztottam Santa jóvoltából ;-) ). Aminek különösen örülhettünk, hogy Musk+Citrus duó harmadik lett az intrójával, illetve T101 barátunk végre megcsinálta az első demóját, ami szintén az harmadik helyen végzett. A győztes entrik pedig bármelyik másik partyn megállták volna a helyüket az élvonalban gond nélkül.
  • Kompók után megtörtént a gyors eredményhirdetés, aztán buli reggelig. Egy másik nagyon kellemes élmény volt, hogy reggel nem csak úgy elrohantak a résztvevők, hanem segítettek a szervezőknek valamennyire kipofozni a művházat. Igazi scene összetartás volt…

Mindent egybevetve életem egyik legjobb partyja volt, és mindenkit csak bátorítani tudok, hogy látogasson el minél több külföldi partyra (is). Ha anyagi lehetőségeim engedik, én még megyek idén, de jövőre mindenképpen. Solskogenre biztosan!

 

UPDATE:

Sesse mester kepei a partyrol

UPDATE2:

Pouet eredmenyek

Ugrás a lap tetejére Ugrás a lap aljára