PŘENOS GEOMETRIE 3D SCÉNY PO SÍTI

Transkrypt

1 VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY FAKULTA INFORMAČNÍCH TECHNOLOGIÍ ÚSTAV POČÍTAČOVÉ GRAFIKY A MULTIMÉDIÍ FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF COMPUTER GRAPHICS AND MULTIMEDIA PŘENOS GEOMETRIE 3D SCÉNY PO SÍTI BAKALÁŘSKÁ PRÁCE BACHELOR S THESIS AUTOR PRÁCE AUTHOR JAROSLAV ROZEHNAL BRNO 2009

2 VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY FAKULTA INFORMAČNÍCH TECHNOLOGIÍ ÚSTAV POČÍTAČOVÉ GRAFIKY A MULTIMÉDIÍ FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF COMPUTER GRAPHICS AND MULTIMEDIA PŘENOS GEOMETRIE 3D SCÉNY PO SÍTI STREAMING OF 3D GEOMETRY OVER NETWORK BAKALÁŘSKÁ PRÁCE BACHELOR S THESIS AUTOR PRÁCE AUTHOR VEDOUCÍ PRÁCE SUPERVISOR JAROSLAV ROZEHNAL Ing. JAROSLAV PŘIBYL BRNO 2009

3 Abstrakt Tato práce se zabývá problematikou přenosu trojrozměrných dat po síti a jejich následným vykreslením. Důraz je kladen na efektivitu přenosu, což je zajištěno implementací vlastního komunikačního protokolu fungujícího nad protokolem UDP a adaptací technologie statického Level of Detail pro potřeby přenosu. Pro vykreslení přenesené geometrie je navrhnut triviální grafický engine. Závěrem jsou prezentovány testy efektivity výsledného protokolu. Klíčová slova 3D grafika, OpenGL, Level of Detail, POSIX, klient-server, sít ový protokol, UDP Abstract This thesis is oriented on problematics of streaming 3D geometrics over network. Main importance is seen in efectivity of streaming, for what there is presented special protocol, working over protocol UDP, and adaptation of Level of Detail. For visualization of transmitted geometry trivial graphical engine is developed. In the end there are presented results of tests, oriented on protocol s efectivness Keywords 3D graphics, OpenGL, Level of Detail, POSIX, client-server, network protocol, UDP Citace Jaroslav Rozehnal: Přenos geometrie 3D scény po síti, bakalářská práce, Brno, FIT VUT v Brně, 2009

4 Přenos geometrie 3D scény po síti Prohlášení Prohlašuji, že jsem tuto bakalářskou práci vypracoval samostatně pod vedením Ing. Jaroslava Přibyla... Jaroslav Rozehnal Poděkování Rád bych poděkoval Ing. Jaroslavu Přibylovi za pomoc při tvorbě této práce. c Jaroslav Rozehnal, Tato práce vznikla jako školní dílo na Vysokém učení technickém v Brně, Fakultě informačních technologií. Práce je chráněna autorským zákonem a její užití bez udělení oprávnění autorem je nezákonné, s výjimkou zákonem definovaných případů.

5 Obsah 1 Zadání 3 2 Úvod 4 3 Teorie Možnosti přístupu ke grafickému rozhraní pro vykreslování 3D modelů Reprezentace modelu v paměti počítače Statické (diskrétní) LoD Dynamické (spojité) LoD Na pohledu závislé LoD Uložení modelu v souboru PLY Popis formátu Přenos modelů přes sít Protokol TCP Protokol UDP Návrh Obecný návrh aplikace Úkol klienta Úkol serveru Návrh grafického rozhraní a návrh implementace LoD Rozhýbání scény Návrh komunikačního protokolu Popis zprávy protokolu Popis komunikace protokolu Implementace Rozvržení implementace Hlavičkový soubor exceptions Hlavičkový soubor globaldebug Modul globaltypes Modul clientserver Modul plyloader Modul filedb Modul netarray Modul messagecomposer Modul protocol Hlavičkový soubor universalarray

6 Modul gl Modul scenedescriptionloader Soubor ibp.cpp Popis jednotlivých řešených problémů Přenos typu float Struktura adresáře s daty serveru a podporované typy souborů Načítání souboru s modelem objektu ze souboru PLY Návrh a vytvoření modelů pro LoD Načítání souboru s popisem scény Vykreslování a příjem dat scény Přístup k sít ovému rozhraní a implementace protokolu Testování chování protokolu Smysl testování Prostředí, ve kterém byly testy prováděny Testování optimálního nastavení Testování chování programu za nestandardních podmínek Optimální nastavení programu Testování chování programu v simulovaném sít ovém prostředí Omezení přenosové rychlosti Prostředí se ztrátou zpráv Závěr a diskuze výsledků Manuál k použití programu Přeložení projektu a generování dokumentace Spuštění projektu a popis parametrů Popis ovládání kamery Diskuze výsledku a možných rozšíření A Konfigurace počítače pro testování programu 37 B Plakátek 38 C Průběh stahování ukázkové scény 39 2

7 Kapitola 1 Zadání Tato práce je zaměřena na efektivní přenos geometrie trojrozměrné scény po síti mezi dvěma subjekty s využitím běžných sít ových prostředků jako jsou například ty poskytované sítěmi Ethernet a Internet. Efektivnost přenosu je zajištěna nejenom speciálně navrženým protokolem, ale také využitím technologie Level of Detail. Nutno podotknout, že tato technologie je zpravidla použita pro snížení náročnosti dynamických scén, což je v mírném rozporu s cílem této práce, kde je hlavní důraz kladen na rychlost přenesení geometrie scény a to i na úkor grafického vzhledu. Vedlejším zaměřením této práce je vytvoření primitivního grafického enginu pro zobrazení přenášené geometrie scény. 3

8 Kapitola 2 Úvod Dnešní doba je pevně spjata s nástupem komunikačních technologií a jen zřídka si dnes běžný člověk představí počítač, jenž není připojen k síti Internet nebo alespoň k nějaké lokální síti. Obdobně, jak dochází k nárůstu propojenosti jednotlivých počítačů, je kladen stále větší a větší důraz na grafický vzhled aplikací a jejich realističnost. Tato práce se zabývá kombinací těchto dvou dnes velmi populárních témat a přenosem geometrie trojrozměrné scény po síti. Co si pod tímto poměrně abstraktním názvem vůbec představit? Jak víme, data potřebná i pro jednoduchou trojrozměrnou scénu jsou značně objemná a složitější projekty musí použít různé technologie, jenž zajistí plynulost jejich zpracování i v rámci jednoho počítače. Tento problém se poté zvyšuje, je-li potřeba zobrazovaná data získávat z jiného počítače, obzvlášt pokud nejsou propojeny spolehlivou homogenní sítí. Tato práce se zaměřuje právě na řešení tohoto problému. Kapitola třetí se věnuje popisu stávajících technologií, jejichž použití jsem při návrhu systému studoval a zvažoval. Jsou zde stručně popsány s odkazy na případný detailnější popis, jsou vyzdvihnuty jejich výhody a zmíněny nevýhody. Čtvrtá kapitola je věnována popisu návrhu projektu. Kapitola zmiňuje, které z dříve popsaných technologií jsou v programu použity, jakých prostředků bude použito při implementaci. Jsou také vybrány externí knihovny, jenž poskytnou potřebný základ pro přístup k jednotlivým komponentám počítače. Kapitola pátá popisuje rozdělení programu do jednotlivých na sobě více či méně nezávislých modulů a přináší také řešení konkrétních problémů, na které jsem v průběhu implementace návrhu narazil. V kapitole šesté je provedeno ověření funkčnosti výsledného systému, zjištěno na jakých podmínkách je závislá rychlost přenosu dat a jaké je nastavení zajišt ující maximální rychlost přenosu. V poslední kapitole je nejprve uveden způsob použití programu a nastavení parametrů. Dále je provedeno zhodnocení výsledků práce, jsou diskutována možná rozšíření a vylepšení stávajícího řešení. 4

9 Kapitola 3 Teorie Tato kapitola popisuje stávající používané technologie pro vykreslování grafických modelů, jejich reprezentaci v paměti počítače a možnosti přenosu přes sít. 3.1 Možnosti přístupu ke grafickému rozhraní pro vykreslování 3D modelů V současné době nejsou pokročilé knihovny zprostředkovávající přístup ke grafickému subsystému počítače omezeny pouze na komerční software. Existuje velká řada knihoven a grafických enginů uvolněná k volnému použití, případně vyvíjená jako svobodný a otevřený software. Mezi nejznámějšími můžeme jmenovat například OpenInventor vyvinutý firmou SGI, případně komunitně vyvíjený projekt OGRE. At už se však jedná o komerční, volně šiřitelný nebo otevřený software, všechny tyto knihovny a grafické enginy používají jeden ze dvou standardů pro přístup ke grafické kartě počítače OpenGl či DirectX firmy Microsoft. Grafické rozhraní DirectX firmy Microsoft je pevně svázáno s jejími operačními systémy Windows. Především díky velkému rozšíření tohoto operačního systému se stala podpora DirectX klíčovou u všech výrobců grafických karet i přesto, že standard OpenGl již nějakou dobu existoval. V současné době je poslední verze DirectX 10 podporována pouze na operačním systému Windows Vista a starší verze Windows se musí spokojit s DirectX ve verzi 9. Standard OpenGl byl vytvořen firmou Silicon Graphics a dnes je spravován a dále vyvíjen neziskovým konzorciem Kronos Group Inc. Ve své poslední verzi 3.0 je srovnatelný s grafickým rozhraním DirectX 10 firmy Microsoft. Na rozdíl od DirectX není rozhraní standardu OpenGl nijak vázáno na operační systém či výrobce počítače. Jedinou podmínkou je vytvoření fungujícího ovladače pro toto rozhraní. Hlavní výhodou použití některé z knihoven oproti standardu OpenGl či DirectX je vyšší úroveň abstrakce kterou poskytují. Při vývoji trojrozměrných her již programátor nemusí programovat funkce pro načítání modelů, obrázků ani programovat kód pro obsluhu kamery. Někdy je knihovnou poskytnut i jednoduchý kolizní systém. Další výhodou jsou častá doplnění standardů dalšími funkcemi, které umožňují realističtější vykreslení scény. Příkladem v tomto případě může být implementace podpory raytracingu (používaný při zrcadlení) nebo částicových systémů (reálně vypadající simulace ohně). Mezi knihovnami vyvíjenými v podobě otevřeného softwaru je poměrně častá podpora obou výše zmíněných standardů, a tak může výsledný produkt nejen fungovat na více než jednom operačním systému, ale může na operačním systému Windows použít DirectX, na Unixu OpenGl a na 5

10 systému bez 3D grafické karty softwarové renderování (například na mobilních zařízeních). Na druhou stranu přináší tato snaha o poskytnutí komplexního řešení i mnoho problémů. Často dochází k situacím, kdy potřeby vytvářeného programu nejsou totožné s přístupem, jaký je použit v konkrétní knihovně a programátor tak musí použít postupy, které vedou ke zpomalení výsledného programu a znesnadňují mu práci. Knihovny vytvářené v podobě operačního systému zase nebývají vždy kompletní, případně používají u některých prvků knihovny příliš velké zjednodušení. Často se tedy tvůrci daného projektu mohou rozhodnout pro použití samotného OpenGl či DirectX a naprogramovat si vlastní engine sami přímo pro potřeby daného projektu. Vzhledem k tomu, že standard OpenGl poskytuje prostředky pro zobrazování dvourozměrné a třírozměrné grafiky, je nutno toto rozhraní doplnit o použití jiné knihovny pro vytvoření okna a zachytávání vstupů aplikace. V praxi je zpravidla použito bud rozhraní používaného okenního manažeru jako je rozhraní X serveru, GTK pro okenní manažer GNOME či QT okenního manažeru KDE, nebo některé ze specializovaných knihoven jako je pro použití s OpenGl určený GLUT, či knihovna pro tvorbu dvourozměrných her SDL. 3.2 Reprezentace modelu v paměti počítače Pro zobrazení jednoho modelu objektu reálného světa je potřeba vykreslit zpravidla několik set primitiv - jednoduchých dvourozměrných n-úhelníků, ze kterých je model složen. Je tedy potřeba uchovávat v paměti počítače pozice jednotlivých vrcholů a jejich seřazení do n-úhelníků. To již samo o sobě přináší nezanedbatelnou pamět ovou náročnost. Vezmeme-li v úvahu, že pro každý z těchto vrcholů je třeba uchovávat hodnoty normálového vektoru a koordináty pro navázání textury, je jasné, že každý složitější reálně vypadající model, může obsahovat i několik megabajtů dat. To často způsobuje problémy i při vykreslování na počítači, o přenosu přes sít ové zařízení ani nemluvě. Jedním z řešení, jak velikost přenášených či vykreslovaných modelů zmenšit, je použití technologie Level of Detail (úroveň pohledu). Toto řešení vychází z faktu, že ne všechny objekty, které se ve scéně nachází, je třeba vykreslovat v plné kvalitě. Množství objektů, nacházejících se ve větších vzdálenostech od kamery, zabírá po výsledném renderování pouze malou část obrazu a je možné je nahradit méně kvalitním modelem, případně pouze dvourozměrnou náhradou. Metoda nahrazování složitých modelů jejich jednoduššími variantami je nazývána Level of Detail, zkráceně LoD. Následující tři sekce jsem si dovolil volně přeložit a pro potřeby tohoto dokumentu upravit z knihy [2] Statické (diskrétní) LoD Diskrétní přístup k LoD byl navrhnut Clarkem v roce 1976 a je dodnes bez modifikace používán v grafických systémech. Tento přístup vytváří několik verzí každého modelu ještě před spuštěním aplikace. V průběhu vykonávání aplikace si vykreslovací systém vybírá nejvhodnější z verzí modelu, kterou použije. Vzhledem k tomu, že jsou verze vytvořeny ještě před během aplikace, nelze určit pod jakým úhlem bude objekt pozorován. Model je tedy zjednodušen rovnoměrně v celé své ploše. Diskrétní LoD je označováno jako na pohledu nezávislé. Tento přístup má mnoho výhod. Fakt, že je zjednodušení modelu nezávislé na vykreslování, činí tuto metodu jednoduchou pro implementaci. Vzhledem k tomu, že jednotlivé verze modelů jsou vytvářeny ještě před během aplikace, mohou vývojáři přizpůsobit tyto modely přímo potřebám programu. Na obrázku 3.1 můžete vidět model koule zobrazený ve třech kvalitách, které obsahují po řadě zleva 20, 80 a 320 stran. 6

11 Obrázek 3.1: Model koule v několika kvalitách vhodný pro diskrétní LoD Dynamické (spojité) LoD Spojité LoD na rozdíl od statického, vytváří jednu datovou strukturu, která za běhu aplikace vytváří model v požadované kvalitě. Největší výhodou tohoto přístupu je větší množství kvalit modelů. Vzhledem k tomu, že je model v dané kvalitě vytvářen během vykreslování, je možné tento model vytvořit přesně v potřebné kvalitě. Takto je použito přesně tolik n-úhelníků, kolik je potřeba a oproti diskrétnímu přístupu tak dochází k úspoře paměti počítače. Dynamické LoD tedy oproti statickému lepe využívá pamět počítače. Dynamické Lod navíc podporuje možnost serializace, je proto vhodnější pro přenos velkých modelů po síti nebo jejich načítání z disku Na pohledu závislé LoD Na pohledu závislé LoD (View-dependent LoD) rozšiřuje spojitý přístup k LoD. Při generování modelů v potřebné kvalitě bere v potaz i úhel, pod kterým uživatel objekt pozoruje. Tento přístup umožňuje části složitých objektů, na které se pozorovatel dívá přímo, vykreslovat ve větší kvalitě než ty, na které se pozorovatel dívá pod velkým úhlem. Tento přístup poskytuje ještě větší přesnost v kvalitě vykreslovaného modelu a tak ještě větší úsporu paměti počítače. 3.3 Uložení modelu v souboru PLY Tuto sekci jsem přeložil a upravil ze stránek Paula Bourkeho [1]. Formát PLY v anglickém jazyce nazývaný Polygon File Format (polygonální souborový formát) nebo také Stanford Triangle Format (Standfordský trojúhelníkový formát) je jednoduchý formát pro uložení trojrozměrných modelů popsaných posloupností polygonů. Tento formát byl vyvinut na Standfordské univerzitě a jeho největší výhoda tkví hlavně v jednoduchosti a účelnosti Popis formátu Soubor PLY je složen z hlavičky, popisující způsob uložení dat, seznamu vrcholů (vertexes) nacházejících se v modelu a seznamu stran (faces) spojujících jednotlivé vrcholy do vykreslovaných polygonů. Dále mohou následovat další doplňující elementy. Header Vertex List Face List (lists of other elements) 7

12 Hlavička je posloupnost koncem řádku ukončovaných příkazů, které popisují zbytek souboru. Hlavička obsahuje informaci o typech jednotlivých elementů, včetně jejich jména a počtu v modelu a dále seznam vlastností asociovaných s tímto elementem. Hlavička také popisuje v jakém kódování jsou hodnoty uloženy. Níže můžete vidět příklad souboru obsahujícího model krychle. Binární verze tohoto souboru by namísto označení ascii obsahovala bud binary_little_endian či binary_big_endian. Komentáře ve složených závorkách nejsou součástí souboru, pouze přidané poznámky tohoto příkladu. Řádné komentáře jsou jednotlivé řádky začínající slovem comment. ply format ascii 1.0 { ascii či binární format a~číslo verze } comment made by Greg Turk { příklad komentáře } comment this file is a~cube element vertex 8 { definuje element vrchol s~osmi záznamy } property float x { koordinát na ose x } property float y { na ose y } property float z~{ a~na ose z~} element face 6 { soubor obsahuje 6 definicí stran } property list uchar int vertex_index { vertex_indicies je definováno jako seznam čísel vrcholů } end_header { ukončuje hlavičku } { začátek seznamu vrcholů } { začátek seznamu stran } Tento příklad demonstruje základ souborů ply. Za povšimnutí stojí, že soubor vždy začíná řádkem obsahující slovo ply, který slouží především pro snadnou identifikaci souboru jako modelu ve formátu ply. Po tomto označení typu souboru je uveden řádek s definováním formátu a jeho verzí. Následně je uvedena definice elementů a jejich vlastností, kde pořadí zápisu elementů a vlastností indikuje jejich pořadí v datech. Elementy jsou vždy definovány zobecněnou formou: element property property property 8

13 element property Každá vlastnost je uvozena slovem property, za nímž následuje její typ a název. Typy vlastností jsou vždy skalární s výjimkou složeného typu seznam. Velikost jednotlivých typů s popisem můžete vidět v tabulce 3.1. name type number of bytes char character 1 uchar unsigned character 1 short short integer 2 ushort unsigned short integer 2 int integer 4 uint unsigned integer 4 float single-precision float 4 double double-precision float 8 Tabulka 3.1: Typy vlastností v souboru ply Speciálním typem je typ seznam, který je vždy uvozen slovem list, za nímž následuje typ použitý pro uložení počtu prvků seznamu a až na druhém místě je typ těchto prvků. Konec hlavičky je uvozen pomocí klíčového slova end_header na samostatném řádku, po němž následují přímo hodnoty prvního z elementů. 3.4 Přenos modelů přes sít Při přenosu modelu přes sít je tento model nejprve nutné serializovat, tj. převést model z datové reprezentace na proud informací tento model popisujících. Vzhledem k tomu, že i při použití LoD jsou modely poměrně velké, je třeba klást velký důraz na režii přenosu a efektivní využití přenosového pásma. Zároveň je však pro vykreslování objektů důležité, aby nebyly některé části dat ztraceny nebo poškozeny. Vzhledem k tomu, že většina dnešních sítí je kompatibilní se sítí Internet, je výběr vhodných protokolů omezen na protokoly založené bud na protokolu TCP nebo na protokolu UDP. Pro získání základního přehledu o výhodách a nevýhodách těchto protokolů se můžeme podívat například na českou verzi populární Wikipedie. Zajímá nás stránka s popisem protokolu TCP [4] a stránka s popisem protokolu UDP [5] Protokol TCP Protokol TCP je orientovaný na přenos toku bajtů na transportní vrstvě se spolehlivým doručováním. Aplikace tedy ke vzájemné komunikaci využívají spolehlivé spojení na způsob roury. Protokol TCP tedy zajišt uje doručení všech paketů ve správném pořadí. Toho dosahuje jednak číslováním odeslaných paketů a jednak znovu vyžádáním paketů ztracených, tj. těch, pro které nedošlo odesílateli potvrzení Protokol UDP Protokol UDP je obdobně jako protokol TCP protokolem transportní vrstvy. Na rozdíl od protokolu TCP, orientovaného na proudový přenos, je tento protokol orientován na přenos 9

14 dat v podobě zpráv. Takto přenášená data se mohou ztrácet, mohou dojít v jiném pořadí, než ve kterém byly odeslány, nebo dokonce některé zprávy mohou přijít vícekrát. Na druhou stranu je tato komunikace rychlejší, nebot již není nutné čekat na ztracené zprávy, ani není nutné pozdržet již přijaté novější zprávy v případě, že předchozí zpráva nepřišla. 10

15 Kapitola 4 Návrh Zde je popsán návrh projektu, výběr použitých technologií a specifikace komunikačního protokolu. 4.1 Obecný návrh aplikace Na základě dřívějších zkušeností jsem se rozhodl vyvíjet tuto práci v jazyce C++ se zaměřením na operační systémy kompatibilní se standardem POSIX, jako je například operační systém Linux. Z tohoto důvodu byl můj výběr knihoven pro vykreslování výsledné trojrozměrné scény omezen na knihovny založené na standardu OpenGl. V prvních fázích vývoje jsem zvažoval použití knihoven OpenInventor, nicméně později jsem je nahradil přímým použitím OpenGl, především ze vzdělávacích důvodů. Pro doplnění úzce zaměřeného systému OpenGl jsem použil knihovny SDL, se kterými jsem již měl zkušenosti a nemusel jsem se tak seznamovat s jejich použitím. Vzhledem k tomu, že jsem se rozhodl vyvíjet projekt s přihlédnutím k standardu POSIX, využil jsem pro přístup k sít ovému rozhraní knihoven BSD sockets, které jsou součástí tohoto standardu. V průběhu vývoje jsem byl kvůli problémům s výkonností donucen k rozdělení běhu klienta do dvou vláken, k čemuž jsem využil POSIX threads. V poměrně obecném zadání,,přenos geometrie 3D scény po síti jsem se zaměřil především na část přenosu dat přes sít. V této části jsem navrhl vlastní protokol, který využívá rychlosti protokolu UDP, ale doplňuje jej o spolehlivost doručení zaslaných zpráv. To umožňuje při dobrém nastavení rychlejší přenosovou rychlost než by byla možná při použití protokolu TCP, především při ztrátě nepřesahující 1-2% celkového množství přenášených dat. To je umožněno především tím, že na rozdíl od protokolu TCP moje implementace nezajišt uje přijetí zpráv ve stejném pořadí v jakém byly odeslány. Při návrhu aplikace jsem samozřejmě nezůstal pouze u přenosu trojrozměrných dat, ale vzal jsem v potaz také využití technologie Level of Detail. Konkrétně jsem zvolil diskrétní LoD, především pro jeho jednoduchost. Jednotlivé verze modelů v různé kvalitě jsem vytvářel ručně za použití programu Blender. 4.2 Úkol klienta Klientská část projektu se stará především o příjem a zpracování zasílaných dat a jejich následné vykreslování do inicializovaného okna. Úkoly klienta probíhají v následném pořadí. 11

16 Klient nejprve načte soubor, ve kterém je popsána scéna. Tento popisovací soubor obsahuje jména modelů, jejich pozice a jejich případné zvětšení či otočení. Po načtení scény klient vypočítá potřebnou kvalitu pro každý z modelů ve scéně. Tato kvalita je vypočítána pro všechny zobrazení stejného modelu a to na základě vzdálenosti modelu od kamery a jeho případné změně velikosti. Klient následně požádá server o doručení modelu v nejvyšší kvalitě, k jaké dospěl během výpočtu. Po přijetí celého modelu jej klient zařadí do vykreslovací smyčky a požádá o zaslání dalšího z modelů. Po celý průběh stahování lze pohybovat kamerou, nicméně je nutno brát v potaz, že kvalita modelů je počítána pro výchozí pozici kamery, takže modely vzdálené od výchozí pozice kamery budou v nízké kvalitě i v případě, že bude kamera umístěna v jejich těsné blízkosti. Někomu může připadnout zvláštní, že při použití statického LoD jsou vykreslovány jednotlivé instance stejného modelu v jedné nejvyšší kvalitě, nicméně toto je dáno faktem, že se tento projekt zaměřuje na minimalizaci přenosu dat, nikoli na zvýšení efektivity vykreslování. 4.3 Úkol serveru Úkolem serveru v tomto projektu je správná obsluha připojení klienta a zajištění, že obdrží to, co požaduje. Server po svém spuštění nejprve načte předaný adresář s modely a následně začne naslouchat na určeném portu. V průběhu načítání server nejprve najde všechny soubory s příponou ply, zjistí jejich kvalitu a následně se pokusí najít jejich texturu. Pokud jakákoli z těchto akcí selže, server daný model vyřadí ze své databáze. Obsluha klienta poté sestává z několika kroků. Po příchodu úvodní zprávy komunikace najde server model, který nejvíce odpovídá požadované kvalitě a ten následně odešle klientovi (i s texturou). V případě, že se model na serveru nenachází, je klientovi odeslána zpráva indikující, že model nemohl být nalezen. Vzhledem k tomu, že je komunikace mezi klientem a serverem založena na transportním protokolu UDP, implementuje server iterační obsluhu klientů, což by v případě TCP klienta nebylo možné. Proto server není určen pro obsluhu většího množství klientů současně. 4.4 Návrh grafického rozhraní a návrh implementace LoD Vzhledem k tomu, že cílem projektu je zobrazení statické scény, jejíž geometrii přenese přes sít ové rozhraní, bylo grafické rozhraní navrhnuto s ohledem na jeho jednoduchost. Scéna je osvětlena pouze tzv. okolním světlem (z anglického ambient light), které osvětluje všechny objekty rovnoměrně a pozadí vykreslovaných objektů je nastaveno na černou barvu. Účelem tohoto grafického rozhraní bylo v původním návrhu pouze vykreslení statické scény, nicméně později jsem je rozšířil o pohyblivou kameru, která umožní lepší prozkoumání vykreslené scény. Jednotlivé modely jsou v souladu s teorií statického Level of Detail vytvořeny v několika stupních kvality, která je pro jednoduchost vyjádřena v procentech. Dle tohoto modelu jsou i indexovány serverem. V momentě, kdy klient zjistí, na kterých pozicích ve scéně má zobrazit který model, vypočítá na základě vzdálenosti jejich požadovanou kvalitu. U každého modelu je kvalita počítána pro jeho nejbližší výskyt ve scéně. Vzhledem k tomu, že modely jsou na serveru vytvořeny v konkrétních kvalitách, použije server kvalitu, která je nejbližší té požadované. 12

17 Algoritmus pro výpočet kvality modelu jsem navrhl převážně na základě experimentování s již funkční implementací. Je počítána ze vzdálenosti modelu od kamery dle následujícího vzorce: Kvalita = (Vzdálenost objektu od zadní ořezávací roviny * (Vzdálenost zadní ořezávací roviny od kamery / 100))^ Rozhýbání scény Vzhledem k tomu, že možnosti prohlížení mnou zobrazované a přenášené statické scény byly příliš omezené, rozhodl jsem se implementovat pohyblivou kameru. Jelikož však pohyblivá kamera není hlavním, možná že ani vedlejším tématem mnou zvoleného zadání a plně funkční pohyblivá kamera je implementačně poměrně náročná, omezil jsem implementaci kamery pouze na několik jednoduchých možností pohybu. Pohyb kamery vpřed a vzad, otáčení kamery podle jedné z jejích os a pro doplnění jsem implementoval také možnost pohybu ve směru kolmém na osu pohledu. Veškeré tyto pohyby jsou prováděny pomocí myši, kdy grafické rozhraní snímá vzdálenost, jakou myš urazila a na základě toho provádí patřičné otočení či posun. Provedení pohybu kolmého či rovnoběžného k ose pohledu Implementovat pohyb po přímce svírající s osou pohledu pravý úhel nebo s osou pohledu rovnoběžnou, bylo poměrně snadné. Pro provedení této operace je třeba nejprve zjistit vektor, kterým směřuje kamera a následně vypočítat novou pozici kamery a vektorů, které určují její orientaci. Toho lze snadno dosáhnout získáním aktuální matice OpenGl, provedením vektorového součinu jednotkové matice s vektorem pohybu, který chceme vykonat, a následné vynásobení výsledku původní maticí. Pohyb dopředu je proveden jednoduchým posunem scény ve směru osy z a pohyb kolmý k ose pohybu patřičným posunutím v rovině definované osami x a y. Proto lze informace získané snímáním pohybu myši použít přímo pouze po vynásobení vhodnou konstantou ovlivňující její citlivost. Provedení otočení kamery Vzhledem k tomu, že hodnoty získané snímáním pohybu myši odpovídají ploše, po které se ukazatel myši pohybuje, je třeba nejprve vypočítat úhel, o který je kameru potřebné otočit, a směr, kterým toto otočení provést. Zjištění směru otočení kamery není nijak problematické. Stačí si uvědomit, že tento vektor je totožný s úhlopříčkou obdélníku daným relativní změnou pozice kurzoru vůči osám okna. Vzhledem k tomu, že vektor je zadáván pomocí jeho složek, lze zjištěné hodnoty jednoduše přiřadit směrovému vektoru a následně tento vektor normalizovat. Nutno dodat, že tyto změny je třeba nejprve invertovat - při pohybu myši doprava od středu obrazovky chceme zpravidla provést otočení opačným směrem. SměrOtočení = [-ZměnaX, -ZměnaY, 0] Normalizuj(SměrOtočení) Druhým problémem, tentokrát o něco složitějším, je výpočet požadovaného úhlu. Ze získaných hodnot můžeme snadno získat vzdálenost, kterou kurzor myši po obrazovce počítače urazil. Vzdálenost = sqrt(změnax^2 + ZměnaY^2) 13

18 Na obrázku 4.1 můžete vidět vztah mezi vzdáleností, kterou urazila myš a úhlem, o který se má otočit. Pro zjednodušení je vzdálenost kamery od místa, na které se dívá, ve výpočtu nahrazena jedničkou. Vztah mezi podstavou rovnoramenného trojúhelníka - v našem případě původní směr pohledu nový směr pohledu Vzdálenost / 2 1 úhel otočení/2 Kamera Obrázek 4.1: Vztah mezi vzdáleností, kterou urazila myš a úhlem otočení kamery vzdáleností, jenž urazil kurzor po obrazovce a úhlem, který svírají jeho ramena - úhlem otočení kamery, lze vyjádřit následovně: Vzdálenost = 2 * sin(úhel otočení/2) Samotný výpočet otočení kamery je pak již snadnou úpravou předchozího vztahu. Úhel otočení = 2 * arcsin(vzdálenost / 2), kde Vzdálenost <= 2 Následně lze provést rotaci kamery obdobným postupem jako při jejím posunu. 4.5 Návrh komunikačního protokolu Vzhledem k tomu, že cílem této aplikace je zajistit efektivní a spolehlivý přenos dat mezi serverem a klientem s přihlédnutím k rychlosti přenosu, použil jsem protokol UDP. Tento protokol, sám o sobě nespolehlivý, jsem doplnil o mechanismus zajišt ující ověření doručení dat. Protokol však nebere v potaz zabezpečení spojení ani ochranu před poškozením dat. Protokol nebyl navržen celý naráz, ale jeho návrh byl postupně doplňován tak, jak to vývoj aplikace vyžadoval. První použitá verze protokolu sloužila pouze pro přenos faces 14

19 a vertexů. Případné nedoručené zprávy byly ignorovány a přenesený model tak často obsahoval díry způsobené chybějícími daty. Proto jsem protokol postupně rozšířil o mechanismus pro zajištění doručení všech dat, podporu přenosu textur a chybovou zprávu oznamující, že server neindexuje hledaný model Popis zprávy protokolu Komunikace mezi klientem a serverem je realizována pomocí výměny zpráv různých typů. Typ každé ze zpráv je uveden jako první ve zprávě a na základě tohoto typu je určeno složení zprávy, potažmo i její výsledná délka. Každý z typů zpráv má v komunikaci specifický význam a v některých případech jsou zprávy zasílány pouze kvůli tomuto významu. Příkladem mohou být zprávy ACK a ERROR, které jiné informace než kód zprávy neobsahují. Popis jednotlivých zpráv a jejich typy můžete nalézt v tabulce 4.1. Typ zprávy Odesílatel Popis GET Klient Tato zpráva zahajuje komunikaci mezi serverem a klientem. Klient jí dává najevo, o který model má zájem a v jaké kvalitě. DESC Server Popis přenášeného modelu. Odpověd na zprávu GET. ERROR Server Zpráva oznamující chybu při vyhledávání modelu na serveru. Odpověd na zprávu GET DATA Server Zpráva obsahující část dat (vertexes a faces) modelu. TEXTURE Server Zpráva obsahující část textury modelu. ACK Klient Zpráva oznamující serveru, že daná část komunikace byla v pořádku přijata RESEND Klient Zpráva oznamující serveru čísla zpráv, která nebyla přijata. Klient očekává, že je server okamžitě začne znovu odesílat. Tabulka 4.1: Typy zasílaných zpráv Jak můžete vidět z další tabulky 4.2 lze na základě složení zpráv jednotlivé zprávy rozdělit na ty, které jsou odesílány klientem a na ty odesílané serverem. Toho lze dosáhnout především na základě pozorování, že, až na dvě výjimky, zprávy klienta obsahují jednobajtovou položku Id, která označuje zprávy pocházející od již známého klienta. Ony dvě zmíněné výjimky jsou právě zprávy, kterými se inicializuje spojení a přiděluje identifikační číslo Popis komunikace protokolu Spojení mezi klientem se skládá ze tří částí. Každou z těchto částí klient potvrzuje a kromě zahajovací části může vždy zažádat o doposlání zpráv, které byly v průběhu komunikace ztraceny. Pokud jsou zprávy serveru číslovány, je jejich číslo pro každou část jedinečné. První částí je část zahajovací. Zde klient pomocí zprávy GET zažádá server o konkrétní model v konkrétní kvalitě. Server na tuto žádost odpoví zprávou typu DESC, která obsahuje informace o modelu a jeho textuře, počet zpráv obsahujících texturu modelu, počet zpráv obsahujících data modelu a přidělí v ní klientovi jeho jedinečné identifikační číslo. Od tohoto okamžiku až do konce spojení označuje klient všechny své zprávy tímto číslem. Zprávy serveru označovány nejsou. Následně klient potvrdí přijetí této zprávy zasláním ACK. V průběhu této ustavující komunikace může dojít ke dvěma nestandardním situacím. 15

20 GET ERROR DESC DATA TEXTURE ACK RESEND Akce [1 bajt] Délka jména modelu [1 bajt] Jméno modelu [délka jména modelu * 1 bajt] Kvalita [1 bajt] Akce [1 bajt] Akce [1 bajt] Id [1 bajt] Celkový počet n-úhelníků v~modelu [4 bajty] Celkový počet vrcholů v~modelu [4 bajty] Formát textury [4 bajty] Počet barev textury [1 bajt] Šířka textury [4 bajty] Výška textury [4 bajty] Počet zpráv textury [4 bajty] Počet zpráv s~daty [4 bajty] Akce [1 bajt] Číslo zprávy [2 bajty] Počet n-úhelníků ve zprávě[1 bajt] Počet vrcholů ve zprávě[1 bajt] n-úhelníky [Počet n-úhelníků * 3 * 4 bajty] Vrcholy [Počet vrcholů * 8 * 4 bajty] Akce [1 bajt] Číslo zprávy [1 bajt] Délka části textury [2 bajty] Pozice části textury [4 bajty] Část textury [Délka části textury * 1 bajt] Akce [1 bajt] Id [1 bajt] Akce [1 bajt] Id [1 bajt] Počet chybějících zpráv [2 bajty] Čísla chybějících zpráv [Počet chybějících zpráv * 2 bajty] Tabulka 4.2: Složení zpráv protokolu Když v průběhu zpracování zprávy GET zjistí server, že požadovaný model se v jeho databázi nenachází, nepřidělí klientu žádné identifikační číslo a zašle mu zprávu ERROR, čímž okamžitě ukončí přenos modelu. Tuto zprávu klient nepotvrzuje. V druhém případě server při obdržení zprávy GET zjistí, že již obsluhuje určité množství klientů a nemá již prostředky pro obsluhu tohoto klienta. V tomto případě server zprávu GET zahodí a klient o tento model zažádá později znovu, stejně jako by reagoval v případě, že by byla zpráva GET nebo zpráva DESC v úvodní komunikaci ztracena. Druhou částí spojení je přenos textury modelu. Tato část následuje okamžitě po ACK zaslaném klientem. Jakmile server toto potvrzení obdrží, začne odesílat zprávy typu TEX- TURE. V případě, že klient neobdrží všechny zprávy, a po určitou dobu mu nedojde žádná z chybějících, odešle serveru zprávu RESEND, ve které uvede čísla chybějících zpráv. Server tyto zprávy klientu dopošle. Zaslání zprávy RESEND se v případě špatného spojení může opakovat i několikrát. V momentě, kdy má klient všechny zprávy, odešle serveru zprávu ACK, čímž potvrdí, že zprávy přijal. V třetí části jsou klientu zasílána data modelu. Vlastní komunikace probíhá naprosto stejně jako při druhé části, pouze s tím rozdílem, že server odesílá zprávy typu DATA. Po odeslání zprávy ACK, v případě serveru po jejím přijetí, komunikace mezi subjekty končí a server uvolní identifikační číslo pro použití dalším klientem. Jedno spojení mezi serverem a klientem tedy slouží pro stáhnutí právě jednoho modelu. Pokud klient potřebuje stáhnout více modelů, musí o každý z těchto modelů zažádat ve zvláštním spojení. V tabulce 4.3 můžete vidět schematicky znázorněnou výměnu zpráv, realizující úspěšný 16

21 přenos modelu, jehož textura je obsažena ve třech zprávách a data ve čtyřech. V průběhu této ukázkové komunikace dojde ke ztracení dvou zpráv typu DATA o jejichž přeposlání si klient zažádá. Server Směr přenosu Klient <- GET DESC[TEX:3, DATA:4] -> <- ACK TEXTURE[0] -> TEXTURE[1] -> TEXTURE[2] -> <- ACK DATA[0] -> DATA[1] -> DATA[2] -> DATA[3] -> <- RESEND[2,3] DATA[2] -> DATA[3] -> <- ACK Tabulka 4.3: Příklad komunikace klienta a serveru 17

22 Kapitola 5 Implementace Tato kapitola popisuje rozvržení projektu do jednotlivých modulů a dále se věnuje řešeným problémům, na které jsem narazil v průběhu implementace. 5.1 Rozvržení implementace Z prostorových důvodů se v této sekci věnuji pouze rozvržení projektu do jednotlivých modulů, nikoli konkrétnímu rozvržení do tříd. Při případném zájmu o rozvržení do tříd si dovoluji čtenáře odkázat na dokumentaci generovanou ze zdrojového kódu, jejíž generování je popsáno v kapitole 7. Celý projekt jsem rozdělil celkem do deseti částí, v závislosti na problematice jímž se věnují. Některé tyto části jsou implementovány jako plnohodnotné moduly, jiné jsou z různých důvodů, jimž se budu věnovat v patřičných sekcích, implementovány pouze v rámci hlavičkových souborů. Vazby mezi jednotlivými moduly jsou popsány dále v textu nebo je možné je vidět na obrázku 5.1. Obrázek 5.1: Graf znázorňující vazby mezi jednotlivými moduly Hlavičkový soubor exceptions V této části projektu jsou definovány veškeré výjimky, ke kterým může v programu dojít. Vzhledem k tomu, že jsou definice tříd velmi krátké, jsou zapsány přímo v hlavičkovém souboru a není nutné tuto část projektu překládat samostatně. Tento hlavičkový soubor je 18

23 použit prakticky ve všech modulech, a proto již nebude jeho použití explicitně vyjádřeno v následujících sekcích Hlavičkový soubor globaldebug V tomto souboru jsou definována makra, která byla použita během tvorby a ladění projektu. Tento soubor v projektu zůstal i po jeho odladění, což umožnilo snadné zrušení výpisu ladících informací. Obdobně jako hlavičkový soubor exceptions je použit napříč celým projektem a nebude již zmiňován dále Modul globaltypes Tento modul obsahuje veškeré typy, které jsou používány napříč všemi moduly. Jeho použití v dalších modulech již nebude explicitně vyjádřeno Modul clientserver V tomto modulu je vytvořeno rozhraní zprostředkovávající přístup k sít ovému rozhraní. Současná implementace je realizována pomocí knihoven BSD sockets. Díky tomuto rozhraní je možné nahradit tento modul za jiný, využívající jiných knihoven Modul plyloader Jak lze již poznat z názvu modulu, je zde popsán algoritmus pro načtení datového souboru ve formátu ply Modul filedb Tento modul tvoří základ pro implementaci severu. Zde je implementován algoritmus pro prohledávání adresáře s daty. Data jsou zde načítána a dělena do shluků, které je možné umístit do jednotlivých zpráv. Pro načítání textur využívá tento modul knihoven SDL a pro načítání souborů ply využívá služeb modulu plyloader Modul netarray Tento modul definuje jedinou třídu, která symbolizuje jednu zasílanou zprávu. Tato třída umožňuje jak přímý přístup k neformátovaným datům, jenž je nutný pro příjem a odesílání dat, tak poskytuje sekvenční čtení a zápis jednoduchých datových typů Modul messagecomposer Tento modul, obdobně jako modul netarray, implementuje jedinnou třídu, jejímž cílem je poskytnout mechanismus pro tvorbu či čtení zpráv a také pro serializaci a deserializaci dat. V tomto modulu je implementován kód ovlivňující složení každé ze zpráv. Tento modul využívá služeb modulu netarray Modul protocol Zde je implementován kód ovlivňující způsob odesílání zpráv a jejich návaznosti. Tento modul využívá služeb modulů netarray a messagecomposer. 19

24 Hlavičkový soubor universalarray V tomto souboru je vytvořena třída, která zjednodušuje přístup k seznamům vrcholů a stran předávaným knihovně OpenGl. Vzhledem k tomu, že je třída vytvořena v podobě šablony, bylo nutné ji definovat v hlavičkovém souboru Modul gl Zde je implementován jednoduchý renderovací engine aplikace, jenž využívá hlavičkového souboru universalarray Modul scenedescriptionloader V rámci tohoto modulu je vytvořena jediná třída, která slouží pro parsování a čtení souborů s popisem scény Soubor ibp.cpp Tento soubor obsahuje funkci main a je zde implementováno jak chování klienta tak serveru na nejvyšší úrovni abstrakce. Tento soubor využívá modulů protocol, clientserver, gl, scenedescriptionloader a filedb. 5.2 Popis jednotlivých řešených problémů V této sekci se věnuji popisu problémů a implementačních zajímavostí, na které jsem během tvorby programu narazil Přenos typu float Při psaní programu jsem záhy narazil na jeden nepředpokládaný problém. Většina knihoven pro přístup k soketům neřeší přenos čísel s plovoucí řádovou čárkou přes sít. Vzhledem k tomu, že ne všechny POSIX operační systémy používají stejný způsob ukládání čísel v plovoucí řádové čárce, nemohl jsem použít jednoduché přetypování typu float na typ se stejným počtem bitů, byt se tento způsob implementace zdál být funkčním. Variantu, kdy je reálné číslo převedeno nejprve na text a po přenosu přes sít zase zpátky do nativní reprezentace operačního systému počítače, jsem záhy vyloučil. Tato varianta, jakkoliv funkční a kompatibilní napříč operačními systémy, má jednu zásadní vadu. Přenášená data jsou mnohonásobně větší než jejich nejmenší možná reprezentace. To společně s faktem, že modely jsou popisovány téměř výhradně reálnými čísly, mě donutilo hledat jiné řešení. Nakonec jsem zvolil variantu překódování čísel do formátu ieee-754, jehož jednoduchá implementace je popsána v [3]. Tento jednoduchý enkodér a dekodér reálných čísel převádí plný rozsah 4 bajtového typu float do výše zmíněného formátu při zachování velikosti jeho pamět ové náročnosti. Čtyřbajtové číslo je tedy překódováno do čtyřbajtového přenositelného formátu. Po implementování a otestování se ukázalo, že překódování, které se provádí mnohokrát v průběhu přenesení dat modelu, nepředstavuje žádnou výraznou výkonovou ztrátu. Jedinou nevýhodou tohoto mnou použitého kódovacího mechanizmu zůstává vynechaný převod čísel NaN a nekonečno, což však vzhledem k tomu, že data modelu mají vždy svou konkrétní hodnotu zobrazitelnou v oboru reálných čísel, nevadí. 20

25 5.2.2 Struktura adresáře s daty serveru a podporované typy souborů V současné podobě umožňuje server nastavení jednoho adresáře, ve kterém jsou předpokládána všechna data, ke kterým server zprostředkovává přístup. Jména souborů v tomto adresáři se řídí určitými pravidly tak, aby je server po svém spuštění našel a správně zařadil. V případě, že server zjistí chybu v pojmenování některého ze souborů určitého modelu, je tento soubor ignorován a server k němu nezprostředkovává přístup i v případě, že není načten žádný model a server tedy neposkytuje žádná data. V průběhu načítání algoritmus nejprve vyhledá všechny soubory s příponou ply a následně pro všechny tyto soubory vyhledává soubory s texturou, tedy příponou obrázku. Pokud není soubor s texturou nalezen, je soubor s daty modelu vyřazen z výběru. Po nalezení souborů s daty a souborů s texturami je vytvořen seznam obsahující jména a kvalitu modelů. Program v současné době načítá data modelu pouze v textové verzi formátu ply (tedy nenačítá binárně uložená data) a textury ve formátech BMP, PNM, XPM, LBM, PCX, GIF, JPEG, PNG, TGA a TIFF. Jméno každého ze souborů v adresáři je složeno následujícím způsobem: <jméno modelu>.<kvalita modelu>.<přípona> <jméno modelu> zde zastupuje označení konkrétního modelu, které je později použito v definici scény na klientské části programu. <kvalita modelu> označující kvalitu daného souboru, je zapsána jako celočíselná hodnota v intervalu od 1 do 100. V případě, že by kvalita modelu obsahovala i jiné znaky než číslice, případně se jednalo o jiný interval, byl by soubor ignorován. <přípona> souboru, jak je ostatně běžné na všech operačních systémech, označuje typ souboru. Dle této přípony program rozeznává, jedná-li se o texturu, nebo soubor s daty modelu a jaký algoritmus má pro jeho čtení použít. V případě, že sada modelů obsahuje pouze jeden soubor s daty a více různě kvalitních textur nebo jednu texturu a více různě kvalitních dat, nemusí tvůrce kopírovat tento soubor do adresáře s různými jmény, ale může použít jak fyzických tak symbolických odkazů. Výsledný výpis adresáře tedy může vypadat například takto: Cube.100.ply Cube.100.tga Cube.12.ply Cube.12.tga Cube.25.ply Cube.25.tga Cube.50.ply Cube.50.tga Načítání souboru s modelem objektu ze souboru PLY Přestože jsou k dispozici programy pro načítání modelů v tomto formátu, rozhodl jsem se vytvořit vlastní implementaci načítání tohoto formátu. V poslední verzi je modul pro načítání souborů ply omezen na ascii kódování dat, které však plně postačuje pro potřeby tohoto programu. Načtení hlavičky zprávy je, obdobně jako například implementace protokolu, realizováno pomocí konečného automatu, jehož schéma můžete vidět na obrázku 5.2. Automat ve svých stavech provádí jak načtení parametrů příkazu, tak ověření jejich validity a podpory v aplikaci. Přechody mezi stavy automatu jsou následně prováděny na základě načtení klíčového slova následující položky. V případě načtení uvozujícího slova comment, je celý řádek ignorován bez ohledu na jeho obsah. Modul má vestavěnou kontrolu typů, takže v případě nekompatibilního typu uvedeného v hlavičce souboru vypíše varování, případně načítání souboru ukončí, pokud by bylo pravděpodobné, že model nebude správně načten. Přestože je implementována plná podpora všech datových typů souboru ply včetně typu seznam je doporučeno používat v modelech shodné rozdělení typů, jaké je používáno v modelech běžně dostupných na Internetu, tj. jmenovitý výčet typů pro seznam vrcholů a typ seznam pro seznam stran. 21

26 Obrázek 5.2: Konečný automat zobrazující princip načtení hlavičky souboru ve formátu ply Návrh a vytvoření modelů pro LoD Pro správné fungování statického LoD je třeba dobře navrhnout a vytvořit jednotlivé modely tak, aby poměrně rovnoměrně pokrývaly celou šíři kvalit, ve kterých mohou být modely žádány. Jednotlivé instance modelů v určité kvalitě lze bud vytvářet ručně, nebo za užití automatizovaného nástroje. Pro potřeby tohoto projektu jsem jednotlivé instance modelů vytvářel ručně, čehož následkem je nerovnoměrné pokrytí šíře kvality. Některé modely jsem vytvořil v různé kvalitě s ohledem na jejich texturu (model Cube), některé s ohledem na kvalitu modelu (model Monkey), případně jsem zjednodušoval texturu i model (model Sphere) Načítání souboru s popisem scény Jak již bylo řečeno dříve, hlavním účelem klienta v tomto projektu je stažení a zobrazení trojrozměrných modelů. Pro popis scény jsem si vytvořil vlastní formát souboru. Jedná se o textový soubor, kde každý řádek definuje pozici pro vykreslení jednoho modelu. Příklad tohoto řádku můžete vidět níže. Sphere;1.0;1.0;1.0;0.0;0.0;0.0;0.0;0.0;0.0; Jedná se o řádek, jehož jednotlivé záznamy jsou odděleny středníkem. Na prvním místě se vždy nachází řetězec určující jméno modelu, rozlišuje velká a malá písmena, následuje trojice hodnot určující zvětšení či zmenšení modelu podle osy x, y a z. Následuje čtveřice čísel, z nichž první určuje velikost úhlu rotace a následující tři normalizovaný vektor směru rotace. Trojice čísel na konci záznamu definuje posun modelu. Jednotlivé operace jsou s modelem 22

27 prováděny ve stejném pořadí, jak se vyskytují v záznamu, tedy nejprve je provedeno zvětšení či zmenšení modelu, následuje rotace a nakonec je výsledek posunut na danou pozici. Vzhledem k tomu, že jsem v průběhu práce často tyto soubory měnil, implementoval jsem možnost komentářů, které jsou podobně jako u mnoha skriptovacích jazyků uvozeny znakem #. Takto označené řádky jsou parsovacím programem ignorovány. Klient, po svém spuštění, načte soubor s popisem scény předaný jako parametr, prohledá jej a zjistí, které vykreslení je pro každý z různých modelů nejblíže ke kameře a dle tohoto nastavení pozice modelu vypočítá jeho potřebnou kvalitu Vykreslování a příjem dat scény V prvních verzích projektu bylo vykreslování a načítání scény prováděno ve formě iterace, obdobně jako je prováděna obsluha klientů serverem. Data, čekající na sít ovém rozhraní, klient zpracovával přednostně a pokud žádná data nepřicházela, prováděl vykreslování obrazovky. Vzhledem k tomu, že se jednalo o statickou scénu s pevně umístěnou kamerou, byla tato implementace plně dostačující. To však přestalo platit v momentě, kdy jsem implementoval pohyblivou kameru. Při prioritizaci příjmu dat ze sítě měla aplikace příliš nízký počet snímků za vteřinu, při prioritizaci vykreslování zase nebylo velké množství dat přijato, protože čekaly na vstupu příliš dlouho. Z tohoto důvodu jsem byl donucen změnit stávající kód a implementovat vykreslovací smyčku a smyčku příjmu dat do dvou synchronně běžících vláken. Hlavní vlákno aplikace po spuštění klienta provede inicializaci grafického rozhraní a vytvoří nové vlákno, které dle popisu scény stahuje modely a přidává je třídě zastřešující přístup k OpenGl rozhraní. Hlavní vlákno dále pokračuje smyčkou, která provádí vykreslovaní a obsluhu vstupů uživatele. Vzhledem k tomu, že výše zmíněná třída přístupu k OpenGl rozhraní není implementována s ohledem na bezpečnost při použití vláken, ošetřil jsem jakýkoli přístup k ní pomocí mutexů Přístup k sít ovému rozhraní a implementace protokolu Přístup k sít ovému zařízení je realizován pomocí standardních knihoven BSD sockets, používaných na všech POSIX systémech. Vzhledem k tomu, že je v tomto projektu často používáno knihoven boost, provedl jsem pokus o nahrazení BSD soketů knihovnami asio, které jsou distribuovány společně s knihovnami boost a umožnily by kompatibilitu i s některými POSIX nekompatibilními systémy. Nicméně z důvodů částečné nekompatibility těchto knihoven s již napsaným kódem tohoto projektu jsem byl nucen navrátit se zpět k BSD knihovnám. Pro implementaci logiky protokolu jsem se po předchozích zkušenostech s programováním sít ových aplikací rozhodl použít konečných automatů. Jejich výhodou je snadná a jednoduchá implementace jak stavů, které reagují na příchozí zprávy, tak stavů reagujících na čekání na jiná zařízení (například načítání souborů z disku). Grafy tohoto konečného automatu můžete vidět na obrázku 5.3 pro server a na obrázku 5.4 pro klienta. V obou grafech je využito označení zpráv, tak jak bylo popsáno v kapitole 4. Přechody mezi stavy jsou závislé zpravidla na přijetí či odeslání nějaké zprávy. Jména stavů jsou vytvořena dle jednoduchého pravidla. První znak vyznačuje, zda-li je nějaká zpráva ve stavu očekávána (znak A) či odesílána (znak O). Pokud jméno zprávy obsahuje pouze dvě části, tj. pouze jeden znak _, označuje druhá část jméno očekávané/odesílané zprávy. Při více než dvou částech názvu, označuje druhá část jméno zprávy, na jejíž odeslání jsou očekávané či odesílané zprávy závislé. Všechny další části poté označují očekávané či odesílané zprávy. Například stav 23

28 pojmenovaný A_TEX_ACK_RESEND označuje stav, kdy je očekávána jedna ze zpráv ACK či RESEND, která přijde jako odpověd na zprávu TEX. Obrázek 5.3: Konečný automat zobrazující činnost serveru 24

29 Obrázek 5.4: Konečný automat zobrazující činnost klienta 25

30 Kapitola 6 Testování chování protokolu V této kapitole jsou prezentovány výsledky testů, které jsem s dokončeným programem provedl. Dále je popsáno prostředí a podmínky, za kterých bylo testování prováděno. Všechny testy jsou zaměřeny na komunikační protokol vyvíjeného programu. 6.1 Smysl testování Během vývoje programu jsem prováděl dva typy testů. Prvním typem je jednoduché testování programu za běžných podmínek, jehož cílem bylo zjistit optimální nastavení pro běh programu. Během tohoto testování jsem sledoval pouze jednu veličinu a to s jakým nejmenším nastavením funguje program za běžných podmínek optimálně. Druhý typ testu má za cíl zjistit, jak se aplikace chová za podmínek netestovatelných v běžném sít ovém prostředí, jako je vliv různé rychlosti linky mezi serverem a klientem, či ztráta přenášených zpráv. 6.2 Prostředí, ve kterém byly testy prováděny Prostředí testování je zde popsáno pouze stručně s ohledem na jednotlivé druhy testů. Konkrétní popis konfigurace hostujícího počítače a nastavení použitého softwaru můžete najít v příloze A Testování optimálního nastavení Veškeré testy optimálního nastavení byly prováděny na sít ové smyčce mého počítače, případně na sít ovém spojení mezi mým počítačem a školním serverem Merlin Testování chování programu za nestandardních podmínek Testy chování programu za nestandardních podmínek byly prováděny na mém počítači, kde jsem pro simulaci druhého počítače vytvořil virtuální stroj připojený do lokální počítačové sítě. Jako operační systém virtuálního stroje jsem použil systém totožný s operačním systémem mého počítače. Kvalitu sít ového prostředí jsem simuloval za použití programu Transmission Control, jenž je součástí balíku iproute2 dostupného ve většině současných linuxovych distribucí. Pro simulaci omezení rychlosti sítě bylo použito algoritmu Hierarchical Token Bucket (hierarchické značkování paměti), jenž je implementován v programu Transmission Control. Vzhledem k malému množství přenášených dat od klienta 26

31 k serveru a náročností simulace obousměrného omezení sít ového spojení bylo omezováno pouze spojení od virtuálního počítače, na kterém byl spuštěn server, k počítači hostitelskému. 6.3 Optimální nastavení programu Pro rychlost přenosu modelů je kritická velikost zpráv v jakých jsou zasílány. Jsou-li zprávy příliš malé, dojde vlivem vyšší režie na skládání a rozkládání zpráv k výraznému snížení rychlosti přenosu dat. Proto je v zájmu uživatele nastavit velikost zprávy na co nejvyšší hodnotu. Přestože je maximální teoretická velikost zprávy protokolu UDP 64KB, je reálná maximální velikost použitelná v síti Internet mnohem nižší. Nikde totiž není definováno, jak velké UDP zprávy mají nebo mohou být a tak si tuto hodnotu určují výrobci a majitelé sít ových zařízení sami. Četnými experimenty jsem zjistil, že při spuštění klienta i serveru na jednom počítači, kdy je jejich komunikace realizována přes sít ovou smyčku, lze skutečně této teoretické hodnoty dosáhnout. Nicméně při komunikaci přes Internet jsou zprávy větší než zhruba 5000 bajtů zahazovány vždy a zprávy větší než zhruba 3500 bajtů pouze někdy, v závislosti na tom, jak jsou konkrétní zařízení, přes které datový tok proudí, konfigurována. Tyto hodnoty jsou však platné pouze pro komunikaci mezi mnou testovanými počítači, konkrétně mezi školním serverem Merlin a mým počítačem. Proto je lze brát pouze jako orientační a konkrétní nastavení serveru a klienta je nutné prozkoumat omezení používané sítě. Ve výchozím nastavení aplikace je použita hodnota 3500 bajtů, což je přibližně maximum, které zajišt ovalo při mých experimentech spolehlivý provoz. Dalším z parametrů, který ovlivňuje rychlost přenosu dat, je správná synchronizace mezi serverem a klientem. Vzhledem k tomu, že mnou implementovaný protokol nemá žádný synchronizační mechanizmus, je nutné nastavit serveru, jehož odesílací algoritmus je mírně rychlejší než přijímající algoritmus klienta, zpoždění, které zajistí, že server nebude data odesílat rychleji, než je klient schopen přijímat. Tento problém způsobuje, že klient si musí vyžádat doposlání zpráv, které nestihl přijmout a především díky nutné prodlevě před tímto znovu vyžádáním, je zpomalována rychlost přenosu dat modelu. Příčinou tohoto rozdílu v rychlosti mezi odesílacím algoritmem serveru a přijímacím algoritmem klienta lze připsat na vrub větší složitosti operací, které musí klient při příjmu dat provádět. Pro otestování chování této charakteristiky programu jsem provedl dva testy. První spočíval ve spuštění serveru i klienta na stejném počítači a provedení série testů, ve kterých jsem pozoroval, zda-li klient požadoval po serveru doposlání dat. Velikost zpoždění serveru potřebného pro hladký průběh komunikace jsem takto vyměřil na 3 ms. Druhým testem byla realizace komunikace přes reálné sít ové prostředí. Proces serveru jsem spustil na školním serveru Merlin, ke kterému jsem připojil klienta ze svého domácího počítače. Při experimentování na tomto spojení jsem se zaměřil především na zjištění, ovlivňuje-li vzdálenost mezi komunikujícími subjekty potřebnou dobu zpoždění serveru. Po sérii testů jsem ke svému překvapení zjistil, že se tato zjišt ovaná hodnota zvětšila na celých 9 ms. Zopakoval jsem ještě několikrát test s hodnotou zpoždění serveru nastavenou na 8 ms a 9 ms se zjištěním, že nedochází k pozorovatelným rozdílům v závislosti na změnách ve vytížení sítě. Na základě tohoto posledního měření jsem dospěl k závěru, že změna v hodnotě potřebného zpoždění serveru je zapříčiněna především výrazně větším výpočetním výkonem školního serveru Merlin. Posledním z parametrů ovlivňujících chování protokolu přenášejícího modely je nastavení doby, po kterou se čeká na další část dat. Když klient přijímá data, resetuje při každém přijetí dat vnitřní čítač, po jehož vypršení prohlásí zbytek nepřijatých dat za ztracená a zažádá o jejich doposlání. Vzhledem k implementačním závislostem je přesnost tohoto 27

32 čítače omezena na celé vteřiny (ve smyslu doplnění hodnoty na celou vteřinu, tj ms je rozeznáno jako 2 vteřiny) a to i přes to, že jeho hodnota je zadávána v ms. Aby nedocházelo ke zbytečnému přetěžování počítače smyčkou čekající na nové příchozí zprávy, je v modulu obsluhující sít ové rozhraní nastaveno čekání na přijetí zprávy na 1 vteřinu. Až po této jedné vteřině dojde k navrácení ze smyčky přijímající příchozí data s nepříznivým výsledkem a pouze v tomto případě ověřuje konečný automat klienta, zda-li nevypršel čas pro čekání na další zprávu. Z tohoto důvodu je doporučeno ponechat pro kvalitní připojení na minimální hodnotě čekání na přeposlání, která je 1 vteřina. Pouze v případě, že je spojení velmi nekvalitní a rozdíl v latenci sítě může přesáhnout 1 vteřinu (například u mobilních připojení), je změna tohoto nastavení relevantní. 6.4 Testování chování programu v simulovaném sít ovém prostředí Měření bylo prováděno na přenosu modelu Monkey, jenž je složen ze vrcholů a z trojúhelníků s texturou v rozlišení 1024x1024 pixelů, což dohromady činí přibližně 10MB dat. Během testů byl sledován čas kompletního stažení modelu a má-li simulovaný faktor nějakou vazbu na některé z nastavení aplikace. U parametrů programu, které nejsou uvedené v tabulce, nebyla pozorována přímá vazba na simulovanou podmínku. Vzhledem k tomu, že simulace jsou poměrně časově náročné, bylo testování omezeno pouze na jedno měření Omezení přenosové rychlosti Tento test sledoval, jaký vliv na běh programu má omezení přenosové rychlosti od serveru ke klientu. Jako výchozí hodnoty pro parametry během testů jsem použil optimální nastavení programu při nelimitovaném přenosu. Při zpoždění serveru nastaveném na 2ms, je model přenesen bez ztráty dat během 9537ms. Jak můžete vidět z tabulky 6.1, jediným parametrem, u nějž byla pozorována závislost na přenosové rychlosti, je optimální zpoždění serveru (parametry, u kterých závislost pozorována nebyla, nejsou uváděny). U tohoto parametru lze pozorovat celkem tři etapy vývoje. Každá z nich je zapříčiněná odlišnou vazbou na přenosovou rychlost. První etapa je při přenosové rychlosti menší než přibližně 200 kbit/s. Zde dochází k problému zapřičiněnému tím, že omezení rychlosti bylo simulováno na úrovni odchozí komunikace virtuálního počítače. Pokud není nastaveno zpoždění, běžící proces serveru odesílá data tak rychle, že dojde k přeplnění vyrovnávacího bufferu počítače a některé zprávy jsou zahazovány. V druhé etapě, k níž dochází při rychlostech přibližně mezi 200 kbit/s až 7000 kbit/s, lze pozorovat stav, kdy server odesílá dostatečně pomalu, aby nedošlo k zaplnění vyrovnávacího bufferu, ale zprávy jsou omezením sítě zpožděny natolik, že se neprojeví vyšší rychlost serveru. V poslední etapě, při rychlosti přesahující 7000 kbit/s, již nedochází ke zkracování přenosové doby - rychlost přenosu je již omezována výkonem počítače a nikoli prováděnou simulací. Zde lze pozorovat, že hodnota optimálního zpoždění serveru je totožná jako při neomezené simulaci. Z obrázku 6.1, ve kterém jsou použity i hodnoty, které jsem z důvodů jejich vysokého počtu vynechal v tabulce 6.1, lze rozpoznat, že čas, za který je model přenesen, klesá s přibývající rychlostí exponenciálně. Důvodem této exponenciální závislosti je především omezený výkon počítače, který při vyšších rychlostech limituje reálnou rychlost přenášených dat. 28

33 Rychlost přenosu v kbit/s Naměřený čas v ms Optimální zpoždění serveru v ms Tabulka 6.1: Tabulka měření času stažení dat v závislosti na přenosové rychlosti Prostředí se ztrátou zpráv Obdobně jako u předchozího testu byla i u tohoto sledována především doba, za kterou jsou data modelu přenesena, a to na jinak neomezeném sít ovém spojení. Dalšími sledovanými informacemi byl počet žádostí o doposlání zpráv při přenosu textury a při přenosu modelu. Program byl testován s nastavením zpoždění serveru na 2ms, žádost o přeposlání dat odesílanou po 1 vteřině a velikost zpráv nastavenou na výchozích 3500 bajtů. Jak je vidět z tabulky 6.2, nebyla tentokrát zjištěna žádná závislost mezi počtem ztracených zpráv a nastavením programu. Jediným parametrem, který by ovlivnil rychlost přenesení modelu, je délka čekání na znovu zažádání o data, ale ten je v optimální konfiguraci nastaven na 1 vteřinu, což je jeho minimální funkční nastavení, a proto také není uveden v tabulce. Na obrázku 6.2 lze vidět, že vztah mezi rostoucí ztrátou paketů a dobou stažení modelu je lineární. Mírnou nepřesnost naměřených hodnot v tomto grafu lze přičíst na vrub především nedostatečné velikosti modelu a nedostatečnému počtu testů pro kompenzování statistické chyby. Bohužel, jak již bylo uvedeno dříve, větší počet testů nebylo možné provést především z důvodů velké časové náročnosti každého z testů. 29

34 Obrázek 6.1: Graf závislosti délky přenosu na rychlosti sítě Počet ztracených Počet žádostí Počet žádostí Délka přenosu zpráv o doposlání o doposlání při v procentech při přenosu přenosu dat textury Tabulka 6.2: Výsledky simulace sítě s různým počtem ztracených zpráv 30

35 Obrázek 6.2: Graf závislosti délky přenosu na počtu ztracených zpráv 31

36 Kapitola 7 Závěr a diskuze výsledků Zde je provedeno zhodnocení činnosti, popsáno uživatelské rozhraní projektu a doporučené parametry. 7.1 Manuál k použití programu Přeložení projektu a generování dokumentace Program je jednoduše přeložitelný pomocí programu make na počítači s POSIX operačním systémem a instalovanými knihovnami OpenGl či Mesa, SDL, SDL_image, POSIX thread (pthread) a v neposlední řadě také knihovnou boost ve verzi nejméně Pro samotný překlad je potřeba programu make a kompilátor gcc, či jejich plnohodnotná kompatibilní náhrada. Pro automatické generování dokumentace lze využít program doxygen. Překlad projektu a vygenerování dokumentace lze provést pomocí spuštění příkazu make bez parametrů v adresáři se zdrojovými soubory: $ make V případě, že uživatel nechce generovat dokumentaci, lze použít příkaz: $ make ibp Nakonec samotné generování dokumentace je provedeno pomocí: $ make doc Přeložení projektu na serveru Merlin a počítačích v učebnách Během testování protokolu jsem spouštěl server na školním serveru Merlin, přičemž jsem zjistil problém při sestavení programu, kdy utilita sdl-config knihovny SDL vygeneruje chybné odkazy na knihovny (kombinuje 32bitové a 64bitové knihovny). Tento problém jsem pozoroval výhradně na serveru Merlin, na počítači v učebnách proběhlo sestavení programu bez problémů. Pro kompilaci programu na serveru Merlin je třeba v souboru Makefile nahradit řádek SDLFLAGS = sdl-config --cflags --libs -lsdl_image za řádek 32

37 SDLFLAGS = -I/usr/include/SDL -D_GNU_SOURCE=1 \\ -D_REENTRANT -L/usr/lib -lsdl -lpthread -lsdl_image Tato úprava obchází systém generující parametry pro sestavení programu, a proto je funkční pouze při stávající konfiguraci serveru Merlin Spuštění projektu a popis parametrů Přeložením projektu je v pracovním adresáři vytvořen mimo jiné také spustitelný soubor ibp. Ten obsahuje implementaci jak serveru tak klienta a nejsou tedy vytvářeny dva oddělené programy pro klienta a server. Server a klienta je možné spustit následovně: $./ibp client <popis sceny> <adresa> <port> [prepinace] $./ibp server <port> <adresar> [prepinace] Kde <popis sceny> označuje soubor s popisem scény (soubory s příponou sc), <adresa> označuje adresu ip protokolu nebo doménové jméno serveru, <port> označuje číslo portu, případně jeho označení, tak jak je uvedeno v souboru/etc/services. Posledním z povinných parametrů je <adresar>, jenž označuje adresář s daty modelu. Nepovinné parametry jsou označeny [prepinace] a jejich popis můžete nalézt v tabulkách 7.1 a 7.2. Přepínač Význam přepínače -sw ms Nastaví délku pauzy v milisekundách, po kterou server čeká vždy, když odešle zprávu klientovi. Slouží pro zamezení zahlcení klienta. Výchozí nastavení je 0 ms. -s vel Nastaví maximální přípustnou velikost jedné zprávy. Hodnota vel udává velikost zprávy v bajtech. Výchozí nastavení je na Vypne použití akční mapy. Tato mapa zobrazuje aktuální činnost serveru (jaké zprávy jsou odesílány a přijímány). Tabulka 7.1: Volitelné přepínače serveru Popis ovládání kamery Pohyb ve scéně je ovládán výhradně pomocí myši, klávesnici lze použít pro snadné ukončení klienta. Jednotlivé možnosti můžete najít v tabulce Diskuze výsledku a možných rozšíření Cílem této bakalářské práce bylo naprogramování systému pro přenos trojrozměrné geometrie statické scény přes sít ové rozhraní, což se mi přes množství možných vylepšení, obzvláště v grafickém a uživatelském rozhraní, zdařilo. Během programování této bakalářské práce jsem získal spoustu znalostí ohledně grafické knihovny OpenGl, rozhraní SDL, vytváření a programování komunikačního protokolu, ale také jazyka C++ a jeho standardních knihoven. Bohužel získávání nových znalostí se neobešlo bez omylů a pozdních zjištění a tak existuje v kódu aplikace mnoho míst, které by bylo možné napsat jinak - efektivněji a jednodušeji. Velikým přínosem bylo také získání 33

38 Přepínač Význam přepínače -s vel Nastaví maximální přípustnou velikost jedné zprávy. Hodnota vel udává velikost zprávy v bajtech. Výchozí nastavení je rw wait Nastaví časovou lhůtu, po kterou se čeká na příchod zpráv. Pokud je tato lhůta překročena, je zažádáno o doposlání zprávy. -w width Nastaví požadovanou šířku okna či rozlišení aplikace. Výchozí nastavení je h height Nastaví požadovanou výšku okna či rozlišení aplikace. Výchozí nastavení je d depth Nastaví požadovaný počet barev. Výchozí nastavení je 32. -f Nastaví automatické přepnutí aplikace do fullscreenu. Tabulka 7.2: Volitelné přepínače klienta Vstup uživatele klávesa escape pohyb myši při stisknutém levém tlačítku pohyb myši při stisknutém pravém tlačítku otočení kolečkem myši Výsledná akce Provede okamžité ukončení klienta Provede pohyb kolmý k ose pohybu Provede otočení kamery kolem své osy Pohyb kupředu a vzad ve scéně Tabulka 7.3: Popis ovládání aplikace pomocí myši a kláves praktických zkušeností v programování systému, který zpracovává poměrně velké množství dat v krátkém čase, řádově několika milisekundách. Vzhledem k náročnosti a obecnosti zadání, připomíná poslední verze výsledného systému stále spíše verzi uprostřed vývoje než hotový systém. Mnoho nových vylepšení by mohlo být vypracováno pro grafické a uživatelské rozhraní aplikace, mimo jiné implementace bodových světel, specifických různých materiálů pro různé modely a mnoho dalšího. Uživatelské rozhraní by zajisté využilo kameru s lepšími možnostmi pohybu ve scéně, případně i u- živatelské menu a výpis informací o stavu stahování modelů ze serveru. Sít ové rozhraní, obdobně jako rozhraní grafické, by těžilo z výhod progresivních meshů a jejich možnosti serializace. Dále by také bylo možné vytvořit nový protokol, lépe ošetřující ztracené zprávy například pomocí jejich potvrzování po skupinách nezávisle na příjmu ostatních zpráv. Dalším, velice přínosným vylepšením, by bylo rozšíření komunikačního protokolu o mechanismus dynamické změny rychlosti zasílání zpráv tak, aby pokud je klient nestíhá přijímat, zpomalil server jejich odesílání. 34

39 Literatura [1] Paul Bourke. Ply - polygon file format. pbourke/dataformats/ply/. [2] D. Luebke, M. Reddy, J. Cohen, A. Varshney, B. Watson, and R. Huebner. Level of Detail for 3D Graphics. Morgan Kaufmann Publishers, ISBN [3] WWW stránky. Beej s guide to network programming. [4] WWW stránky. Česká wikipedie - stránka o protokolu tcp. [5] WWW stránky. Česká wikipedie - stránka o protokolu udp. 35

40 Seznam příloh A Konfigurace počítače pro testování programu B Plakátek C Průběh stahování ukázkové scény D Přiložené CD se zdrojovými kódy implementovaného programu 36

41 Příloha A Konfigurace počítače pro testování programu Pro testování programu jsem použil svůj osobní počítač AMD Athlon XP s 1GB RAM a grafickou kartou ATI Radeon X1600. Na počítači je nainstalován operační systém Archlinux v 64 bitové verzi. Pro simulaci druhého stroje bylo použito volně šiřitelného virtualizačního nástroje VirtualBox. Na virtuálním stroji byla instalována také 64 bitová verze operačního systému Arch Linux. 37

42 Příloha B Plakátek 38

43 Příloha C Průběh stahování ukázkové scény Během ukázkového spuštění je nejprve třeba spustit server server, jenž okamžitě načte veškeré dostupné modely v předaném adresáři a začne naslouchat na předaném portu (obrázek C.1). Obrázek C.1: Inicializace serveru Jakmile začne server naslouchat, je spuštěn klient, který po inicializaci (obrázek C.2) začne stahovat první model. Obrázek C.2: Inicializace klienta Pokud je na serveru zapnut informační výpis actionmap, lze na serveru sledovat průběh komunikace mezi klientem a serverem. Ve snímku C.3, zachycujícím právě takovouto situaci, můžete vidět průběh celé komunikace. Veškeré serverem odesílané zprávy, tj. zprávy DESC, 39

44 TEX a DATA, jsou označeny pismenem S, kdežto přijímané zprávy jsou rozlišovány pismeny G pro GET, A pro ACK a R pro RESEND. Jednotlivé bloky komunikace, přenos popisu modelu (zpráva DESC), přenos textury (zprávy TEX) a přenos dat modelu (zprávy DATA) lze rozlišit podle přijímaných zpráv ACK. Obrázek C.3: Odeslání modelu koule z pohledu serveru Klient o průběhu komunikace informuje stručněji než server. Po dokončení každého bloku vypíše informaci o jeho úspěšném stažení, jak lze vidět na obrázku C.4. Obrázek C.4: Příjem modelu koule z pohledu klienta Po stažení každého z modelů, je model okamžitě přidán do výsledné scény. Nejprve je proto zobrazena prázdná scéna, následuje scéna s koulí (obrázek C.5) k níž přibude nejprve kostka (obrázek C.5) a následně i opice (obrázek C.7). Na obrázku C.8 je zobrazena stejná scéna z jiného úhlu tak, aby byla názorně vidět nízká kvalita modelu koule, jenž je umístěna daleko od výchozí pozice kamery. 40

45 Obrázek C.5: Scéna po přijetí modelu koule 41