Az elmúlt napokban blogolás helyett kódoltam, méghozzá (és itt Beast vigyorogni fog!) C++ban! Elég durva volt rájönni, hogy bizonyos értelemben már hiányzott a nyelv. Ami a még meglepőbb, hogy azt hittem, a sok-sok C#-al töltött óra után fapadosnak fogom érezni újra a C++t. De nem, kicsit sem. Elővettem pár régi projectemet, engine-kezdeményt, miegymást, s innen már egyenes út vezetett oda, hogy… nos, igen… megint engine-fejlesztésen törjem a fejem. C++, OpenGL, BASS, Lua – mondhatni vissza a gyökerekhez. Jah, és ami a legjobb az egészben: úgy tűnik, Tao-s kódot C++ra visszaportolni egyszerűbb, mint C++ kódot Tao-ra Ha ehhez hozzáveszem, amit az elmúlt években tanultam (GLSL, GL3, hálózat, miegymás), illetve azt, hogy őrületes mennyiségű C#/C++ basecode-om van felhalmozva archív DVD-ken, akkor azt mondhatom, egész jó kiindulási alapom van, hogy végre alkossak (folytassak? ) valamit. Terveim mindenesetre, egy rakat papír formájában – már szépen vannak.

Ami még hozzájön a dologhoz, hogy végre nem kell azon törnöm a fejem, hogy a régi CRT monitoromtól mikor vakulok meg, ugyanis a múlt héten beújítottam egy ilyen jóságot. Mielőtt azonban igazán bele tudnék lendülni a dologba, egy dolog még hátra van: egy fullos OS reinstall. Lejár ugyanis a Windows 7 trialom egy héten belül, így választhatok: vissza az XP-re, vagy veszek egy OEM Windows 7-et. Nos, valszeg az utóbbi lesz. Egyrészt, mert beleszerettem abba az OS-be, másrészt mert Visual Studio 2010 Expressre szeretnék most már építeni, annak meg, ha jól tudom, kell a Win7. Szóval, fejlesztésre fel!

Na kicsit technikaibb és kicsit hosszabb cikk következik, most hogy a munkahelyi őrület is alábbhagyott és a videokártya-probléma is megoldódott. A téma nálam nagyon nem új, mondhatni végigkisért(ett)e az elmúlt 5 évet nálam. A dolog nem más, mint a regressziós teszt – vagyis olyan teszt, amikor van egy rakat teszteseted, amit lefuttatsz egy szoftver régi verziójával, majd az újjal, s a teszteredmények különbségéből meg tudod látni, hogy mondjuk egy új feature kifejlesztése behozott-e új bugot. Az ideális eset valami a következőhöz hasonló:

Van egy szoftvered, mondjuk egy engine, amiből a V1 verziót fejleszted, s közben teszteseteket (egy engine esetében pl. mini teszt-jeleneteket) irkálsz hozzá. Mikorra elkészülsz az első verzióval, lesz mondjuk X darab teszteseted, amik mind szépen futnak, stb. Ez után jön a pont, mikor összeszedsz egy feature-listát, amire azt mondod, hogy az előző verzióhoz hozzáadva ezeket megkapod a következő verziót. Miközben fejleszted a második verziót, természetesen megint irkálsz teszteseteket, mondjuk Y darabot. Ez annyit jelent, hogy a V2 verzió kifejlesztése végére van X + Y darab teszteseted, amiből az első X darab feltételezed, hogy jó, hiszen jók voltak (és jó alatt itt azt értem, hogy a futtatásuk során az elvárt eredményt látod), mikor a V1 verziót lezártad. Igen ám, de mi van, ha a V2 fejlesztése közben becsúszott egy bug, s valami, ami működött korábban, most már nem működik? Hogy lehet ezt megkerülni? Természetesen úgy, hogy minden egyes, a V2 verziót érintő változtatás után szépen újrafuttatsz minden tesztesetet. Ez biztos megoldás, amíg mondjuk egy félmaréknyi tesztesetről van szó. De mi a helyzet ha mondjuk van 40-50-100-akármennyi? Baj. Megőszülsz, mire mindezt manuálisan végigfuttatod minden egyes alkalommal. A megoldás kézenfekvő: automatizálni kell a dolgot.

És itt jön a dolog vicces része: egy render engine esetében miről szól egy test case? Röviden a következőkről:

• Bemenet: content, avagy textúrák, modellek, shaderek, etc
• Kimenet: renderelt állókép / animáció
• A döntés (avagy a teszfutás “jósága”): azt látjuk-e, amit látni szeretnénk?
• A döntés eszköze: az emberi látás / képérzékelés
• A döntés alapja (vagyis az “etalon”): első futtatáskor: amit elképzeltünk (expected result). Minden további futtatáskor: az utolsó jó eredmény (reference result).

Na, akkor itt meg is állnék egy pillanatra. Hogyan zajlik ez a döntés, algoritmikusan gondolkodva? Röviden valahogy úgy, ahogy itt az alábbi folyamatábrán látszik:

Na most, a képen két dolgot jelöltem meg más színnel – igen, azt a két dolgot, amit muszáj vagyunk emberi beavatkozással megcsinálni. A dolog szépsége, hogy ebből a kettőből is az egyik csupán, ami a tesztelés folyamatának szerves része. A konklúzió: a tesztelést mindenképpen automatizálni kell. Az egyetlen tisztázásra váró dolog a “nem-manuális” összehasonlítás, avagy a referenciával történő összehasonlítás. Mit is jelent ez? Az, hogy az engine kimenetét, ami egy kép vagy egy animáció, összehasonlítjuk egy már eltárolt – referencia kimenettel. Jobban belegondolva ez egyszerű is meg nem is. Egyszerű, hiszen az engine kimenetéről csinálunk egy screenshotot, azt eltároljuk és később ezzel hasonlítunk. Az összehasonlítás maga nem nagy művészet, több tucat algoritmus létezik, melyel jóval igényesebbek két kép pixelenkénti összehasonlításánál. (További olvasnivaló, etc. itt!)

A dolog még animáció esetén sem túlságosan bonyolult: fogunk egy adott időtartamot, aminek az elteltével csinálunk egy screenshotot, majd ha megint eltelt ez az időtartam, akkor még egyet, etc. Az, hogy ez az időtartam mennyi, mi szabjuk meg – ez gyakorlatilag egy mezei kvantálás. Egy mondjuk egy perces futás alatt veszünk 60 mintát, majd azt a 60at hasonlítjuk az eltárolt 60hoz… Easy business. Ez persze a gyakorlatban egy kis trükközést igényel, hiszen utána ebből valami kézzelfogható eltérést (mondjuk ideális esetben egy százalékos mennyiséget) kellene barkácsolnunk, hogy eldönthessük, jól futott-e le a teszteset.

Na most, amit itt elmondtam, szinte mind leprogramozható – egy aprócska feltételezéssel: az engine-ünk lehetővé tesz ilyen szintű automatizálást. Nos, alapállapotban a klasszikus engine + content + application = product felállást követve ilyesminek kellene lennie a szituációnak:

Itt ugye arról van szó, hogy hogyan épülnek egymásra a dolgok – az ábra nem pont UML-kompatibilis, de a céknak megfelel A dolog tehát szintén egyszerű: az alkalmazást “leszedjük” az engine tetejéről és helyette egy tesztframeworkot rakunk rá. Programozói szemszögből: az engine .DLL-jét nem a Game.exe-ből, hanem az AutomatedTestFramework.exe-ből hívjuk fel Ha ilyen fajta szétválasztást az alkalmazás és az engine között nem tudunk könnyűszerrel megejteni, akkor van egy rossz hírem: az engine-ünk a klasszikus értelemben véve nem engine – valamit rosszul csinálunk!

Mit kell tudnia egy ilyen tesztframeworknek?

• Legyen teljesen automatikus – ez muszáj ahhoz, hogy ne kelljen a gép előtt ülni amíg a tesztesetek lefutnak
• Tároljon el, amit tud – logolja az egyes tesztesetek futását, tárolja el az eredményeket – bármilyen felülvizsgálatnál jól jöhetnek
• Csináljon statisztikákat, méréseket a futás alatt – egy regresszió igazán akkor jó, ha az egymást követő futások ugyanolyan környezetben futnak le, hiszen ez is egy viszonyításai alap. Hiába adja az engine ugyanazt a vizuális kimenetet, ha épp fele annyi FPS-el teszi, mint a korábbi verzióban – de ugyanazon a rendszeren.
• Legyen hibatűrő – ha egy teszteset “beragad” és vele együtt a tesztframework is, akkor hosszú-hosszú ideig fogunk szenvedni a regresszióval…..
• Az egyes tesztesetek futása ne befolyásolja egymást.

Hát ennyit hirtelen… Gondolkodtam, hogy ezt megírom tutorialnak, de inkább csak egy kis elmélkedés, így marad blog entry Remélem azért valakinek hasznosnak bizonyul – nekem mindenesetre támadt 1-2 jó ötletem!

Adott egy gép: MSI K9N Neo V3 alaplappal (legyen ez “A”) es LeadTek 8600GT VGA-val (“B”), ami évek óta megvan szépen piszkálás nélkül. Adott egy másik gép: GigaByte GA-M720-US3 alaplap (“C”) es GigaByte 9800GT VGA (“D”). Ez kb. egy éve van így egyben. Na most, ma reggel indult a banzai: az első gép azt mondja a POST alatt, hogy 1 hosszú es 8 rövid síp. Mivel AMI BIOS-a van, ez VGA init hibát jelent. (Ezért hangsúlyoztam csak az alaplapokat és a VGA-kat a post elején) Tehát, A+B kombó nem indul. Jönnek a további kombók:

C+D megy (még jó…)
A+D megy!
C+B megy!

A+B további sokadik szétszedés-összerakás után sem megy, mindig ugyanaz a síp-kód jön elő.

(és lehet holnap sem… és holnapután sem… és… )

Valaki, valami ötletet tud mondani esetleg? (Kollegám intelligensen annyit mondott, hogy ennyi év unalom után biztos ráfért az alkatrészekre a párcserés szex és az öreg VGA-nak annyira bejött a friss, fiatal PCI-E slut… izé, slot, hogy most már nem akar visszamászni az öreg alaplapba…)

Teljesen véletlenül futottam bele egy érdekes kis cikkbe – igaz angolul van, de gondoltam nem árthat, ha itt leközlöm, miután nincs még túl sok OpenGL 3.x témájú cikk a Weben. Tehát a link:

http://rastergrid.com/blog/2010/01/uniform-buffers-vs-texture-buffers/

Még egy érdekesség: a cikket író srác romániai magyar a CV-je alapján. Lehet, hogy majd írok neki, hogy lefordítanám, amit írt – illetve esetlegesen ha lesznek még OpenGL-es írásai a jövőben, akkor azokat is.

Másik téma: csak sikerült visszafordulnom a Twitterhez kicsit. Nem azért, mert írogatni akarok rá, hanem egy lehetőséget láttam meg benne, egészen pontosan a Twitter és a Wordpress kapcsolatában: létezik egy Wordpress plugin, ami képes tweeteket csinálni abban a pillanatban, ahogy én itt postolok valamit. Szóval belőttem ezt is jól… Tehát, kedves twitter fanatic olvasóim, mostantól iNi @ Twitter (megint )…

Sajnos eléggé dolgos hét elé nézek, így a hétvégi alkotásomat nem sikerült befejeznem, s feltölteni sem. Amikor csak van időm, feltöltök ezt-azt a sitera a régi tartalmak közül, de többre most nem futja Hogy azért ne unatkozzatok, egy rövidke OpenGL-es hír…

Úgy tűnik a GLEW lett AZ OpenGL extension library C++hoz. Ezt bizonyítja az is, hogy többek között az nVidia és az OpenGL (Khronos) SDK-kba is ez került be. Ezek nem is igazán új hírek mondjuk… Ami viszont többé-kevésbé az, hogy alig két hete kidobtak egy új verziót belőle (1.5.2), ami full OpenGL 3.2 kompatibilitást kinál és az összes létező extension támogatását. Akik C++ban serénykednek OpenGL területen, azoknak talán érdekes lehet az itt letölthető release.

Tudom, hogy előbb utóbb valaki – akinek mondjuk nem jött be a film annyira, mint nekem – fújni fog ezért, de akkor is, muszáj. Még egy Avatar-ral kapcsolatos blogbejegyzés…

Szóval, egy “hogyan készült” jellegű cikk a CG Societyn. Ajánlom kedves öcsém, Chaotic figyelmébe! A sajnos nem túl hosszú cikk itt olvasható. Elég sok érdekességet írnak benne a megvalósításról, lehet látni fázisképeket a különböző munkafolyamatokról, miegymás. Ilyenkor sajnálom igazán, hogy valahogy sohasem volt igazán készségem a 3D modellezéshez, renderhez, miegymáshoz.  Jelen pillanatban marha büszke lehetek arra is, hogy azzal a csekélyke kéttucat orányi Blender tapasztalattal a hátam mögött legalább egy lowpoly 3D űrhajót össze tudtam hozni… A vicces, hogy érdekelne a téma, de ha a világ összes ideje az enyém lenne, akkor se tudnék mindent kipróbálni, ami érdekel. Meh…

A másik, hogy – valószinűleg én vagyok lemaradva – most tudtam meg, hogy a filmből trilógia lesz. Yay! A héten eddig a legjobb hír, amit hallottam. Persze van egy olyan érzésem, hogy a következő rész legalább két év… Na mindegy, addig is lesz még mit nézni bőven.

A másik jó hír az, hogy közeledik a hétvége és nagy terveim vannak – mint mindig! Meglátjuk mi sül ki belőlük…

Nos, tegnap másodszorra is megnéztem a filmet, s ezúttal már a tudomány oltárán némi filmélményt feláldozva néha le-levettem a szemüveget, hogy megnézzem, hogy is néz ki a mögöttes CG. Nos, gondoltam leírok pár dolgot, amit megfigyeltem. Elöljáróban még annyit, hogy direkt hangsúlyozom: a dolog theorycraft jellegű, megfigyelés és “hogy a fenébe csinálhatták?” fejtörés eredménye, semmi hivatalos. Még annyi, hogy abból indultam ki: miután a film kb. 90%-a CG, alapvetőleg 3D renderben gondolkodtam és nem mondjuk több kamerával felvett, utána digitálisan összevágott, de alapvetőleg 2D film postprocessén – ami jó is, hiszen OpenGLben szeretnék valami hasonlót megvalósítani.

• A térhatáshoz őrületes mennyiségű depth of field (DOF) társul. Néhol úgy érzi az ember, hogy a valósághoz kicsit talán túl is lőtték. Mindig van egy tárgy, egy arc, stb. ami tökéletesen éles, s ez a tárgy mindig a kép nagy részét kitölti.
• A jó öreg anaglyph 3D megoldás a multé – a szemüveg ugyan passzív filteres, mint az anaglyph szemüvegek, de a technologia egy kissé más: Dolby 3D Digital Cinema (infók itt és itt).
• Magával a stereo 3D effektel elég visszafogottan dolgoztak, a kép 70%-a simán nézhető szemüveg nélkül is – gondolom ez csökkenti a színveszteséget. (Emellett a dolby 3d leírásánál említenek egyfajta színkorrekciós preprocesst is). Ahol a 3D offset látványos, azok általában a fókuszponttól közelebb levő dolgok, pl. arcunkba lógó faág, miegymás. Itt persze megint érvényesül a depth of field is.

Ezt úgy összességében OpenGL-re úgy fordítanám le, hogy a jelenetet egyszer renderelem normál módon, egyszer depth texture-ként a DOF-hoz, valamint csak a fókusznál közelebbi dolgokat kétszer a stereo 3Dhez.

A stereo 3Ds render nem tűnik annyira durvának, ha jól láttam minimalista módon fixed function pipeline-al is megcsinálták már, évekkel ezelőtt – nem mintha én azzal akarnám Ha ezekkel megvagyok, valami jópofa postprocesst kéne összehozni, amivel összekombinálom az egészet.

A kérdés még az, hogy a stereo 3Dhez hogy nézzen ki a színfilter – ugyanis a Dolby féle technológia felejtős. Elméletben lehetne talán hasonlót reprodukálni, a szemüveg viszont nehezen beszerezhető – az ebayen láttam egyet 50 fontért… (Nem akarom tudni honnan vette, még a moziban látott lopásgátló is rajta volt!) Tehát marad a stereo 3D, ahogy mondtam is. Az itteni leírás szerint lila/zöld vagy kék/borostyán színfilter jöhetne képbe, a vörös/cián első körben nagyon durva színveszteségnek tűnik – nem csak a leírás, hanem a neten fellelhető képek alapján is.

Eh… dolgozni kell… Folyt. köv.

Nem, nem lesz újra angol a site! Emellett a cikknek köze nincs a StarCraft II-höz, bármennyire is várjuk mindannyian. Viszont egy annál érdekesebb hír, amiről muszáj vagyok blogolni…

Nos, úgy tűnik, hogy végre egy játékfejlesztő cég (újra) elkezdett fantáziát látni az OpenGL-ben! Nevezetesen az Epic Games döntött úgy, hogy a szép lassan gyarapodó Khronos group-hoz csatlakozik, mint az OpenGL egyik új élharcosa. (Press release) Nos, már a cikkből is süt, hogy elsősorban OpenGL|ES-ben gondolkodnak, DE! és itt jön a DE… Ha van egy engine, amihez létezik OpenGL|ES port, ki az a hülye, aki nem teszi meg, hogy mondjuk az ES port mellett akkor már csinál egy GL2/GL3 portot? Hiszen akárhogy is nézzük, szép és jó a DirectX, de még mindig nem multiplatform, s az MS semmi hajlandóságot sem mutat arra, hogy ez rohamosan megváltozni készüljön.

Bárhogy is lesz, szivesen olvasok ilyen híreket – igencsak meghozzák a kedvem az OpenGL programozáshoz!

Ez van, beleszerettem ebbe a filmbe. Asszem megyek megint megnézni, remélem még a héten végig játsszák és lesz időm is rá. Na és persze bízok benne, hogy megint 3D-ben tudom megnézni. Ha már itt tartunk, a filmnek volt egy másodlagos hatása is rám: fejembe vettem, hogy addig nem nyugszom, míg nem sikerült 3D Stereo rendert összeeszkábálnom OpenGLben. Mondjuk ez azért elgondolkodtató… miután a 3D stereot felfoghatjuk egy postprocessként, amihez kétszer kell a jelenetet renderelni, nem egyszerű mondjuk 3D stereo + deferred shading együtt például. Na jó, azt hiszem le kellene lőnöm magam… Vagyis nem. Ez van, beindult a fantáziám. Miután az itthoni monitorom döglődik, s valószinűleg egy sexy 23″-os TFT kerül helyére, most azon töröm a fejem, hogy beszerzek egy 3D szemüveget. Nem, nem az nVidia féle 3D Vision csodára gondolok – ahhoz bankot kéne rabolni! Viszont alap anaglyph szemüvegek, amelyek a 3D Stereohoz tökéletesen jók, már elég olcsóak, pl itt.

Jah, akit érdekel a film soundtrackje, annak jó hír: összeszedtem egy playlistet belőle YouTube-on. A full soundtrack itt figyel.

Hát sorry. Nem hagyhattam ki a szokásos 300-poént, hiszen a 300. bejegyzéshez ért a blog. Na igen. És magyar lett újra. Hogy miért? Nos, sok-sok okom van erre. Első körben a legfontosabb az, hogy rájöttem, nagyon nem jó az, ahogy az oldal most áll: a cikkek magyarul, a blog meg (egy ideje) angolul. Választani kellett a két nyelv között, hogy melyiken vigyem tovább az oldalt, s ezen agyaltam már egy ideje. Nos, ha totálisan mindent lefordítottam volna angolra, akkor az iNi egy site lett volna a sok közül odakint a WWW-n. Amíg magyar volt, többé-kevésbé kuriózumnak számított: nincs ugyanis túl sok, 3D programozással foglalkozó tutorialsite. Nem mintha az oldal a klasszikus értelemben tutorialsite volna, de mégis ez tette valamennyire ismertté. Mi értelme hát még egy oldalt csinálni, amiből sok van? Így aztán döntöttem.

Nem mellesleg egy másik ok volt a döntésem mellett a nosztalgia is – elkezdtem feltölteni a régi blogbejegyzéseket (sajna lassabban megy, mint gondoltam) és valahogy magával ragadott az oldschool érzés, az egyetemi éveim emléke, miegymás. A site magyarul indult és OpenGL-lel foglalkozott. Kb. itt lenne az ideje visszatérni a rendes kerékvágásba, nem? De. Igyekszem tehát amint lehet a tartalmat feltölteni, az oldalt magyarul folytatni a cikkekkel együtt – ami blogbejegyzés angolul van az valószinűleg angolul is fog megmaradni, de az újak már magyarul lesznek.

Na, még egy másik téma: gondolom mindenki látta már az Avatar-t. Nos, volt szerencsém 3Dben megnézni és ütött. A történetre nem fektettek ugyan akkora hangsúlyt, mint számítottam rá, de a hangulat… Na, az OMG kategóriás volt. Kijöttem a moziból és hirtelen jelentéktelennek, szürkének, üresnek és igencsak röghözkötöttnek éreztem az életem. Sohasem volt még olyan érzésem, hogy mindent csak úgy eldobnék egy kis szabadságért, távol ettől az úgymond civilizált világtól, a betontól, a pénztől, a politikától, az utca kicsinyes és önző emberétől… Gondolom ez kb. full nem érdekli az átlag olvasót, de muszáj vagyok leírni, már csak azért is, hogy X év múlva visszanézve az oldalt emlékezzek erre az érzésre. Ami ezt az érzést legjobban előhozza belőlem, az mindjárt a film kezdőzenéje, “You don’t dream in cryo…”

Aki még nem nézte meg a filmet, annak csak ajánlani tudom!