Ahoj všichni grafikové,
musíte mi všichni prominout, že jsem se na delší dobu odmlčel, ale zcela jistě už víte, že CZEX nadobro opustili scénu a věnují se pouze komerčním projektům. Navíc už hezky dlouho nemám doma počítač Atari, takže mi chvíli trvalo, než jsem sám sebe k něčemu donutil. Ale jak vidíte, podařilo se, takže jdeme na věc.
Dnešním tématem je shrnutí "matematické" (vlastním počítačem tvořené) grafiky. Něco už jsem nakousl v předcházejících dílech tohoto malého seriálu, ale dnes bych rád všechno shrnul do jednotného celku.
Nejprve bych Vám chtěl říci něco o renderingu, raytracingu a fraktálech. Jsou to zase velice nepěkně znějící slova, ovšem v poslední době velice často používaná, takže se bez jejich znalosti v grafice ztratíte. Nejprve rendering: Všeobecně vzato slovo "rendering" znamená vytvoření bitmapy na základě matematických výpočtů. Cokoli týkající se bitmapové grafiky je možné nazvat renderingem, pokud jste to ručně nenakreslili v grafickém programu. Používáte v grafickém programu připravené textury? Pak počítač provádí rendering. V demu se objevila rotující 3D kostka a její stěny pokrývají bitmapy? Pak počítač provádí rendering. Ještě jednou - rendering je všechna ta část bitmapové grafiky, na jejímž konečném vzhledu pracuje jenom a pouze počítač samotný.
Raytracing je "podmnožina" renderingu, tzn. že je jedním z jeho způsobů. Česky znamená raytracing "sledování paprsku" (Ray - paprsek, tracing - sledování). Celý vtip spočívá v tom, že grafickému programu zadáváte nejčastěji síťové 3D objekty vyplňující výslednou scénu. Nevím, jaká je současná situace u Atari, ale např. u LightWave na Amize (stejný program funguje i na SGI a Macintoshi) se používají tzv. b-splines, tzn. křivky, které je možné v reálném čase pouhým uchopením editovat a přímo tak myší deformovat celý 3D objekt. Například si takto vytvoříte jednoduchou vázu a rozhodnete se provést raytracing. Program po Vás nejprve bude vyžadovat, z jakého materiálu chcete vázu mít - to je důležité pro další průběh. Vlastní raytracing probíhá následujícím postupem - program "vypustí" paprsek světla do levého horního rohu obrazovky a pozoruje, co se s ním děje. Pokud paprsek jednoduše proletí do nekonečna, na daném místě na obrazovce bude vykreslen bod pozadí. Při dalším pokusu program zjistí, že jeho paprsek narazil na objekt vázy. Podle fyzikálních zákonů se paprsek světla v určitém úhlu odrazí a může se na jiném místě zrcadlit (pokud narazí na jakoukoliv lesklou plochu), nebo zanikne. Takto musí program pustit paprsek světla na všechny body obrazovky - pokud tedy budete pracovat v rozlišení 320x200, pak musí zjistit dráhu celkem 64 tisíc paprsků! Samozřejmě záleží také na paletě barev, se kterou pracujete. Hodnota 64 tisíc by samozřejmě platila pouze pro scénu se dvěma barvami. Čím víc barev použijete, tím vícekrát musí paprsek proletět stejnou dráhu. Tím se docílí velice reálných efektů - nevýhodou je samozřejmě rychlost. U raytracingu Vám nepomůže žádný zákaznický obvod (blitter nebo jiné grafické čipy). Je to otázkou čistě početního výkonu v MIPS Vašeho počítače. Do raytracingu se běžně zapojují pouze hlavní procesory a matematický koprocesor (u ST je to pouze MC68000, u Falcona 68030+DSP+FPU). Proto i ty nejjednodušší scény budete na Atari ST renderovat několik hodin, ty složitější i několik dní. Falcon, díky kvalitnějšímu hardware, bude obrázky v 320x200 v 256 barvách renderovat minuty i vteřiny. Moje akcelerovaná Amiga1200 dosahuje se 100MHz procesorem a 50MHz matematickým koprocesorem časy počítané na vteřiny, jednodušší scény renderuje v reálném čase. Pro porovnání - scéna v rozlišení 640x256 a 16 milionech barev (dva objekty, podklad, rendering oblohy, zamlžení pozadí) trvala 10 sekund. Podle X_Hackerových zkušeností uvedených na FIDOnetu trvá na Falconu jednodušší scéna 320x200 (16MHz 030, 32MHz DSP, 16MHz FPU) 30 vteřin, což je na těchto frekvencích velice slušné.
A nyní něco k fraktálům. To je velice rychle se rozpínající grafický obor, ale jenom malá skupina lidí je dokonale zasvěcena do problému a ještě menší skupina lidí je schopna fraktály používat. Fraktál je také rendering a jde o čistě matematickou metodu. Na základě speciálních matematických rovnic se sleduje chování vývin hodnot rovnice v mnoha krocích. Jednodušeji řečeno, ze zadaných hodnot počítač sleduje, co se s proměnnými děje v čase a tyto hodnoty vyjadřuje graficky. Fraktálových rovnic je veliká spousta a jejich výsledky jsou velice rozdílné. V praxi stačí nepatrně pozměnit vstupní parametry fraktálu a grafický výsledek se neuvěřitelně změní. A kde můžete fraktály vidět? Dnes prakticky všude - od základních "stromových fraktálů" (jednoduchý grafický efekt se zmenšuje a zároveň většinou rotuje - Mandelbrotovy množiny), jednoduché pohybující se 3D útvary připomínající hory až po texturami potažené fraktály znázorňující pohoří, řeky, domy, cokoliv... Vzhledem k výpočetní náročnosti jsou však fraktály vytvářené v reálném čase doménou poněkud silnějších počítačů, než jsou Atari ST. Ale už Falcon si s nimi často poradí velice obstojně...
Grafické stanice, jako jsou Macintosh, silné Amigy a samozřejmě hlavně počítače Silicon Graphics ve svých renderovacích programech používají většinou kombinované techniky. Tzn. že v grafickém programu vytvoříte pomocí b-splines drátěné modely výsledné scény a přiřadíte jí příslušné atributy - tzn. kolik bude světelných zdrojů, jak silně budou svítit, kolik bude objektů, jak budou rozmístěny, z jakého budou materiálu (důležitý je lesk, barva, pohlcování světla apod.). Potom programy tvoří fraktálové modely tam, kde si to budete přát - například fraktálové nerovnosti na povrchu modelů. Následuje proces renderování textur, kdy počítač přiřazuje 3D objektům povrchy, sleduje kolize objektů, světelné zdroje. Konečným stádiem je vlastní raytracing, tzn. osvětlení celé scény. Například SGI, který se nachází na naší univerzitě v Brně (jinak využíván jako internetový server) je schopen v reálném čase renderovat jakkoliv složité scény v rozlišení 1024x1024 bodů a barevné hloubce 24 bitů. To je ale hardware pohybující se v cenách milionů dolarů... Pro Atari se zatím nejvýkonnější urychlovací karty vyrábějí s procesorem MC68040 na 40MHz a přetaktovaným DSP, což už dává opravdu slušný výkon, ovšem podle mě nevyhovující ceně - standardní Falcon počítejte za 25.000,-, skoro to samé dáte za samotnou kartu, teď ještě velký harddisk (1GB Barracuda stojí asi 9.000,-), kvalitní multisync monitor... U Amigy je už čtvrt roku v prodeji karta s MC68060 na interní frekvenci 100MHz s FPU/50Mhz, která Vás přijde na současných 20.000,- korun. Tento procesor je díky své architektuře mnohokrát rychlejší než 040 a jeho výkon se pohybuje na hranici 100MIPS. Rádi byste měli něco takového ve Falconu? Pak si budete muset nejspíš ještě hodně dlouho počkat, protože žádná ze známých firem podobnou kartu neplánuje. Ale snad se celá zúžující se ataristická obec dočká.
A teď vektory. Ty jsou jednoznačně doménou slabších počítačů, jako je i Atari ST (nebudeme si nalhávat, že Atari ST je na tom v současnosti s výkonem nějak dobře). Už z matematiky na základní škole si určitě pamatujete, co to vlastně vektor je - jde o spojnici dvou bodů v rovině nebo prostoru, která má svůj daný směr. Z vektorů se potom skládají v nejjednodušším případě rovinné obrazce (čtverce, trojúhelníky, kružnice), složitější jsou pak 3D objekty - jednoduché "síťové", s vyplněnými stěnami a nejsložitější jsou tzv. "lightsourced", tedy "osvětlené" vyplněné vektorové objekty. Vypočítat souřadnice vektorových objektů v rovině i prostoru není žádný problém (jak Vám potvrdí každý coder) a i Atari ST je schopno v reálném čase počítat stovky souřadnic vektorových objektů najednou. Hlavním problémem je vektory zobrazit. Znovu Vám potvrdí každý zkušenější coder (který měl co dělat s grafikou), že vůbec nejsložitější věcí je sestavit rutinu, která by byla schopná velice rychle na obrazovku vykreslit jediný pixel. Zní to sice paradoxně, ale právě toto je nejtěžší částí veškeré grafiky. Jistě, i každý začínající coder je schopen vykreslit na obrazovku pixel jedné barvy, ale jen elita to dokáže opravdu rychle. Viděli jste třeba morfující 3D pixel objekty v demu Froggies over the Fence? Právě takto má vypadat opravdu rychlá rutina... Pro zrychlení se používají nejrůznější finty, jako prekalkulace, používání animací apod., ale i realtime to samozřejmě jde.
Techniky vykreslování vektorů jsou vcelku jednoduché. Teď trochu zaběhnu do problémů coderů, ale třeba Vás to bude zajímat. Podíváme se na teoretický způsob, jak vykreslit 3D rotující, vyplněnou a lightsourced krychli. Protože je papír i obrazovka pouze dvourozměrná, musíme vycházet z 2D pohledu. Proto všechno musí začínat od 2D modelu. Představte si prostý nákres krychle na papíře. Krychle má osm vrcholů, které mají v 3D prostoru každý tři souřadnice (X,Y,Z). My ale vycházíme z 2D představy (i když je to trochu nepřirozené) - je nutné vytvořit algoritmus, který bude schopen rotovat jednotlivé vrcholy krychle - v X a Y to není až takový problém, Z osa dá zabrat. Pokud umíte zacházet s funkcemi sinus a cosinus, dejte se do práce. Chce to trochu deskriptivy a schopnost orientace v 3D prostoru. Když už máte spočítané souřadnice, přichází problém, jak to všechno zobrazit, když obrazovka má osy jenom dvě. Existuje velice jednoduchý algoritmus, kterým je možné vypočítat z 3D souřadnic souřadnice 2D. Teď jsme získali rotující vrcholy krychle v prostoru. Aby to ale doopravdy byla krychle, musíte jednotlivé vrcholy spojit úsečkami. To ještě pořád není problém. Ten se objeví, až se rozhodnete stěny vyplnit. Jsou dva způsoby, jak to provádět - buď jednoduše spojíte jednotlivé vrcholy a sestavíte rutinu na vyplnění prostoru mezi nimi, anebo (což je mnohem rychlejší) budete při spojování vrcholů úsečkami zároveň spojovat i jednotlivé body rovnoběžných úseček každé stěny krychle (samozřejmě jenom ty viditelné). Tak dostanete rotující krychli s vyplněnými stěnami. Ta ovšem vypadá velice nepřirozeně, protože její stěny mají pořád stejnou - neměnící se barvu. Je nutné jim dodat reálné světlo. Zkuste si vzít do ruky dětskou kostku tak, aby na ni svítilo světlo ze směru, kterým se díváte. Čím větší bude kolmice stěny krychle svírat úhel s paprskem světla, tím bude ta která stěna krychle tmavší. Ale jak toho docílit? Každá stěna naší krychle musí být vyplněná jinou barvou - musíme tedy počítat s šesti barvami. Samozřejmě všechny barvy budou stejné, mění se jenom odstíny. Algoritmus reálnosti je jednoduchý. Při své coderské praxi jsem vymyslel následující (a velice rychlý) způsob - stačí porovnávat Z souřadnice vrcholů protilehlých stěn. Čím větší bude rozdíl (kladný i záporný) mezi Z souřadnicemi těchto vrcholů, tím tmavší bude mít tato stěna odstín. Velice jednoduché, ale velice účinné. Pak už stačí si sestavit rozumné intervaly pro změny barev a provádět - Vaši rutinu to nijak moc nezbrzdí (stačí odečítat pouhých šest hodnot pro celou krychli) a výsledek stojí za to!!!
Trauma/CZEX + HEADACHE + MORPHOSE CREW