Cílem bylo udělat systém, který by jednoduchým způsobem popisoval ``choreografii'' fontány. A tuto ``choreografii'' pak zpracovat až po výslednou animaci.
Zároveň zde byla možnost, že by program mohl být použit při návrhu nových fontán podobného typu. Nešlo by o nějaké testování parametrů fontány, ale spíše o prezentaci.
Původní inspirace si přímo říká o to, aby do prostředků jazyka byly přidány prostředky pro práci s hudbou. Nicméně tomu tak není. Je sice možné synchronizovat scénář s nějakými konkrétními časovými okamžiky, ale již například nelze zahrnout zdroje hudby přímo do scény.
Aby vůbec mohla proběhnout simulace tryskající vody, bylo třeba navrhnout a implementovat popis celé situace (scénář animace).
Pro tento účel byl navrhnut a vyvinut jazyk scénáře JA. Od jazyka scénáře se očekávalo, že bude schopen vyjádřit spojité chování určitých veličin v čase.
Popis scénáře musí zvládnout popis rozmístění trysek, světel a kamery. Nejen jejich rozmístění, ale i změnu jejich vlastností jako je například poloha. U trysky je to dále směr a síla vodního proudu. U světel barva. A tak dále.
Dalším prvkem popisu scénáře jsou tzv. pohlcovací plochy (vodní hladiny). Ty určují místo, kde kapky ``mizí''.
Díky poměrně unifornímu přístupu k těmto objektům je možné, aby se tyto plochy taktéž pohybovaly a měnily velikost a polohu. Nicméně tato vlastnost nevypadá příliš využitelně.
Od popisu scénáře se naopak neočekává, že by definoval objekty scény. Scéna je přidána až při závěrečném raytracingu.
Dá se očekávat, že v animaci se nemusí pohybovat pouze předměty zájmu simulace (tedy trysky, světla, vodní plochy, kamera), ale i jiné blíže nespecifikované. Proto jazykem popisu scénáře můžeme definovat proměnné (typu vektor) a jejich případný pohyb, bez nějakého konkrétního významu v simulaci. Tyto ``propašované'' proměnné budou parametry konkrétního popisu scény.
Původní budovatelský nápad vytvořit i ``intuitivně'' ovládaný grafický editor pro editaci scénáře se ukázal být nad rámec rozsahu diplomové práce.
Největší váha však spočívá na provedení simulace. Zobrazení tryskající kapaliny byl tak trochu krok do neznáma, neboť v době počátku této práce nebylo známo, že by se někdo přímo tryskající vodou zabýval. Blíže viz kapitola teo_jini .
Cílem tedy bylo vymyslet nějaké přístupy a tyto vyzkoušet a porovnat.
Pro simulování kapaliny byl zvolen částicový systém. Jde o to, že celá kapalina je reprezentována mnoha částicemi (v tomto případě jim říkejme ``kapky''). Tyto kapky se v diskrétních krocích pohybují dle ``nějakých'' pravidel.
Pro uchování výsledku simulace byl vyvinut formát buran. Jde o velmi prostý binární formát, ve kterém se ukládají informace spočítané simulací. Poněvadž simulace probíhá v diskrétních krocích, je přirozené, že informace se uchovají po framech (jako by po políčkách filmu). V každém framu je možné uchovávat různé typy informací.
Ty nejzajímavější typy informací jsou: polohy kapek, logovací informace, čas, stav trysek, světel, kamery, pole výchylek poloh hladiny (vlnky) atd.
Je jasné, že spočítat výslednou animaci je časově náročné (o mnoho náročnější než provést samotnou simulaci). Proto se jevilo účelné vytvořit velmi jednoduchý 3d prohlížeč mezivýsledků -- xburan.
Tento prohlížeč pracuje nad mezivýslednou formou buran. Poskytuje pouze základní nadhled na vygenerovanou simulaci. Kupříkladu kapky jsou nahrazeny body, hladina pouhým obdélníkem a podobně.
Prohlížeč umožňuje procházet scénou v prostoru i v čase, zvětšovat detaily, sledovat scénu z pohledu kamery.
Samotný výsledek simulace by nebyl nikterak zajímavý, pokud by nebyl nějakým vhodným způsobem realisticky zobrazen.
Celý systém simulace kapaliny je koncipován tzv. ``offline''. To znamená, že autor zadá scénář a nějakou dobu si počká, než se mu ukáže výsledek. Proto je možné použít rekurzivní sledování paprsku (raytracing), které umožňuje velmi věrné zobrazení, nicméně je časově náročné.
Jednou možností by bylo imlementovat vlastní raytracer. Aby scéna nebyla sestavena pouze z tryskající vody, světel a hladiny, bylo by jistě nutné do tohoto zobrazovače implementovat alespoň základní typy objektů, textur a popřípadě i nějaké urychlovací metody a spoustu dalších vlastností.
Ačkoliv imlementace jednoduchého raytraceru není složitá,
byl zvolen jiný přístup. Pro závěrečné zobrazení byl vybrán již hotový
raytracer povray.
To mělo několik důvodů. Jednak v povray je implementována velká spousta vlastností. Jejich výčet by byl dlouhý, ale stručně by se dalo říci, že to jsou všechny základní metody rekurzivního sledování paprsku. Implementace v takovém rozsahu by zřemě nebyla jednotlivcem zvládnutelná.
Dále povray je ``živý'' program a to zvláště díky tomu, že je vyvíjen podle Open Source Society modelu. To znamená, že zdrojové texty jsou volně šiřitelné a v podstatě každý, kdo má chuť něco přidat či vylepšit, může ``přispět svou troškou do mlýna''.
Jinak celý systém není však tak závislý na povray.
Pro výstup do jiného zobrazovacího programu
by se dal zařídit drobnou upravou programu job.
Viz kapitola
prog_job
.
Celý systém je rozložen do mnoha menších utilitek podle unixového hesla: každý program ať dělá pouze málo, ale ať to dělá dobře.
Cesta od scénáře scény k výsledné animaci vypadá zhruba takto: Nejprve je
jazyk popisu scény (JA) převeden do ``nižšího jazyku'' A.
Následuje zpracování simulace (jmv) jejímž výsledkem je
soubor formátu buran. Ten je možné prohlížet xburan'em
nebo job'em převést do popisu povraye.
Pro paralelní spočítání výsledné animace poslouží soustava scriptů
dish-*. Jednotlivé obrázky se pak dají dohromady nějakým
standardním konverzním programem (zde se osvěčil mpeg_encode).
Blíže k popisu utilitek viz kapitola uziv .