Tvorba virtuálního prostředí

1. Metodika pro tvorbu virtuálního prostředí

Jednou z největších nevýhod nasazení virtuální a rozšířené reality je kapacitně i finančně náročná příprava obsahu. Tvorba virtuálního prostředí pro výše uvedené aplikace má svoje specifika od tvorby softwarových aplikací běžně tvořených v oblasti průmyslu jako jsou databáze nebo informační systémy.

V rámci všech primárních činností je potřeba vytvářet virtuální obsah. Využití této metodiky má tedy přesah pro všechny fáze Porterova hodnotového řetězce. Z tohoto důvodu byla vytvořena metodika, která podporuje tvorbu tohoto obsahu.

Představená metodika byla navržena na základě předchozích zkušeností v rámci projektů:

·         DIGITOV – Výše uvedený projekt tvorby balíků pro realizaci tvorby virtuální továrny

·         RES (Risk Environment Simulator) – multioborový projekt simulace rizikového prostředí pro alkoholově závislé – „virtuální hospoda“ [1] 

·         Virtual Classroom (https://www.virtualnitrida.cz/) – multioborový projekt tvorby virtuální třídy určené pro studenty pedagogické fakulty

·         Virtual Assembly Instructions – systém pro správu pracovních návodek

·         Další menší projekty

Tvorba podle systematické metodiky je nutná především při zpracovávání rozsáhlejších virtuálních prostředí. Vzhledem k mnoha akcím, které v takovém virtuálním prostředí probíhají, je možné virtuální prostředí považovat za rozsáhlé téměř vždy.

Dílčí východiska a části metodiky byly již publikovány v [2].

Uvažujme také dílčí limity této metodiky:

·         Metodika je primárně určena pro trénink ve VR/AR. Na druhou stranu je po kreativní úpravě využitelná i pro další aplikace.

·         Metodika neřeší napojení na okolní PLM systémy. Uvažujeme, že data jsou k dispozici (neřeší kde).

·         Uvažujeme aplikaci designovanou pro jednoho uživatele (bez kolaborace)

Metodika rozděluje fázi tvorby virtuálního prostředí do několika fází, které jsou popsány v následujících kapitolách.

Zdroje:

[1] Odolnost léčených alkoholiků otestuje v Plzni virtuální hospoda [online]. 2018 [vid. 2019-04-02]. Dostupné z: https://www.novinky.cz/domaci/474718-odolnost-lecenych-alkoholiku-otestuje-v-plzni-virtualni-hospoda.html

[2]      POLCAR, Jiri, Michal GREGOR, Petr HOREJSI a Pavel KOPECEK. METHODOLOGY FOR DESIGNING VIRTUAL REALITY APPLICATIONS. Annals of DAAAM & Proceedings [online]. 2015, 26(1), 768–774. ISSN 17269679. Dostupné z: http://10.0.9.203/26th.daaam.proceedings.107

1.1. Metodika - graficky

Zde graficky prezentovaná metodika bude dále popsána:

1.2. Fáze zadání

Fáze zadání stanovuje podklady pro analýzu virtuálního prostředí, aby bylo možné jej vytvořit podle představ zadavatele, který je v této fázi nejdůležitější.

1. Podnět k tvorbě virtuálního prostředí. Při požadavku na vytvoření virtuálního prostředí je třeba ihned zodpovědět otázky, ze kterých mohou vyplynout další body této fáze.

2. Stanovení cíle virtuálního prostředí. Ihned je nutné zjistit klíčové informace, které ovlivňují celý koncept i druh virtuálního prostředí a na tyto informace pak navazuje veškerá další tvorba. Cílem virtuálního prostředí je například zaškolit pracovníka v konkrétním výrobním procesu nebo naučit zaměstnance únikové cesty z rizikového pracoviště, umístění hasicích přístrojů atp.

3. Stanovení cílové skupiny. Virtuální prostředí je vždy cílené na uživatele, který se např.  jeho pomocí bude vzdělávat. Metodika se zaměří na ovládání virtuálního prostředí jediným uživatelem, nikoli více najednou (analogicky s počítačově herní terminologií pouze pro singleplayer). Je nutné zohlednit, zda bude cílový uživatel virtuálního prostředí bez předchozích zkušeností s počítačem, zda se bude jednat o osoby s narušenou stránkou charakteru, děti atp.

4. Tvorba hrubého scénáře. Nástin scénáře je důležitý pro představu složitosti virtuálního prostředí a dává představu pro všechny další body.

5a. Stanovení míry realističnosti. Vyšší realističnost virtuálního prostředí velmi podstatným způsobem zvyšuje jeho složitost, náchylnost na programové i koncepční chyby a přímo ovlivňuje hardware, v rámci, kterého bude prostředí implementováno. Jedná se jak o realističnost akcí ve virtuálním prostředí, např. reakce NPC (Non-Player Character = počítačem ovládaných postav), tak o realističnost vjemu a kvality imerze. Další rovinou realističnosti je to, zda se má jednat o virtuální prostředí vymodelované na základě skutečné architektury nebo procesu (např. konkrétní proces v konkrétním podniku nebo obecné pracoviště a konkrétní proces).

5b. Stanovení cílového hardware. Tento bod je paralelní k bodu 4a. Na jedné straně při požadavku na vysokou realističnost rostou nároky na kvalitu i druh použitého hardware, na druhé straně je nutné přizpůsobit se hardwaru, který je k dispozici nebo který je možné obstarat.

1.3. Fáze analýzy

Zadání je nutné zanalyzovat a zjistit z něj podklady pro tvorbu virtuálního prostředí. Analýzu je nutné provést kvalitně od začátku, protože chyby způsobené špatnou analýzou mohou zapříčinit, že případná tvorba může začít zcela znovu. Pro urychlení celého projektu je možné již v průběhu analýzy vytvářet jednotlivé zdroje pro virtuální prostředí, tedy dialogové texty, zvuky, animace, modely, grafiku atd. Je to z toho důvodu, že potřeba některých těchto zdrojů vyplývá již z velmi ranné fáze vývoje a sice téměř jistě, například animace chůze.

6. Tvorba detailního scénáře. Při této činnosti se předpokládá intenzivní spolupráce se zadavatelem projektu. Je nutné popsat vše, co se má ve virtuálním prostředí odehrát, kdy, v jakém případě a jak se to má odehrát a kam povede scénář dál. Detailní scénář slouží jako přímý podklad k veškeré další práci.

7a. Analýza a soupis seznamu akcí. Ze scénáře vyplývají akce, které se mají ve virtuálním prostředí odehrávat. Tyto akce se prozatím sepíší do seznamu. Například otevírání dveří, zahájení dialogu s NPC, pití nápoje atp.

7b. Analýza a soupis seznam objektů. Objekty jsou (nejen) všechny prvky, které se ve scénáři vyskytují a jsou označeny podstatným jménem. Jedná se o nositele všech akcí a stavů ve virtuálním prostředí. Objekty můžeme rozlišit v podstatě trojího hlavního druhu – actor, entity a controller. Actor (herec) je postava nebo jiná živá bytost. Entita je většinou objekt reprezentující neživou věc, která nese nějaký stav nebo akci nebo je na těchto závislý. Controller (řídící člen) je pak abstraktní člen, který řídí průběh celého virtuálního prostředí.

8. Definovat stavy objektů. (navazuje na 7b) Objekty mění během virtuálního prostředí svůj stav za pomoci akcí. Stavem objektu rozumíme například sedící/stojící actor, rozsvícené světlo, množství polotovarů v zásobníku atd. Je vhodné zapsat stavy objektů do schémat a určit, které kombinace stavů jsou přípustné a které mají být přípustné.

9. Přiřazení akcí k objektům. (navazuje na 7b a 8) Akce je nutné přiřadit k jednotlivým objektům tak, aby byly zaručeny správné a logické změny stavů. Z tohoto přiřazení vyplývá i nositel akce – zda to má být konkrétní actor, všichni actoři nebo controller.

10. Tvorba stavového diagramu. Stavový diagram představuje mapu stavů, které je mezi sebou možné dosáhnout. Každá možná změna stavu musí být zapříčiněna akcí, byť by se mělo jednat o pouhý přepis proměnné. Každá akce coby změna stavu je realizována pomocí procedury, v rámci, které je například nutné pustit animaci modelu a zvuk tuto animaci doprovázející. Stavový diagram se tak stává podkladem i pro tvorbu zdrojů pro virtuální prostředí.

1.4. Fáze tvorby

Jak již bylo řečeno při popisu předchozí fáze, požadavky na některé zdroje vyplývají již z různých činností v rámci analýzy. V podstatě jde o tvorbu jednotlivých kostiček virtuálního prostředí, které do sebe budou pasovat jako stavebnice. Hranice mezi fází tvorby a fází analýzy tedy může (ale nemusí) být plynulá. Fáze tvorby je stěžejní a nejnáročnější fází celé tvorby virtuálního prostředí. Zadavatel by se o projekt měl v průběhu práce zajímat a kontrolovat jej. Tím pádem se fáze tvorby prolíná i s fází testování. Zadavatel tak má jistotu, že se na projektu pracuje a že projekt předčasně nestáhne. Bez jeho interakce s touto fází totiž může dojít ke ztrátě důvěry ve zdárné dokončení projektu.

Testovat veškeré prvky je nutné v okamžiku, kdy je to možné. Je pak velmi náročné kontrolovat a opravovat příliš velké kusy práce najednou.

Výstupem fáze tvorby jsou veškeré zdroje a program, které tyto zdroje řídí. Zdroje můžeme rozdělit do následujících kategorií.

Skripty

Skripty rozlišujeme na skripty řídící změny stavu objektů dle stavového diagramu, skripty pro zajištění speciálních případů (v podstatě skript pro konkrétní objekt, který je obtížné nebo nemá smysl generalizovat) a skripty pro vývoje stavu virtuálního prostředí dle scénáře. Podkladem pro skripty je stavový diagram.

Texty

Dialogové stromy, popisy objektů a veškeré texty, které budou nějakým způsobem figurovat ve virtuálním prostředí. Podklad pro většinu textů dokáže zajistit už detailní scénář (bod 6).

Grafika

Grafikou rozumíme jak 2D obrázky promítané ve virtuálním prostředí, tak i 3D modely reprezentující jednotlivé objekty nebo statickou architekturu. Dále sem zapadají jsou modely typu humanoid pro zobrazení lidí, textury, světla, rendery, shadery atd.

Podoba statické architektury může zcela vyplývat ze zadání v případě, že se jedná o virtuální model skutečných budov nebo objektů. Modely lidí vyplývají z detailního scénáře a podkladem pro tvorbu dalších modelů je seznam objektů. Textury jsou pak závislé na modelech.

Animace

Animace vyplývají ze stavového diagramu. Animace jsou podstatou interaktivity ve virtuálních prostředích a zpravidla doprovázejí změnu stavu nebo jeho průběh (NPC změní polohu ze stoje do sedu a začne pracovat s mobilním telefonem – animace změny polohy do sedu a animace průběhu stavu práce s telefonem vsedě). Podkladem pro tvorbu animací je tedy stavový diagram. Jiné animace vyplývají z podstaty modelu, například ještě před zhotovením stavového diagramu je možné modelovat chůzi člověka nebo otevírání dveří skříně.

Zvuky

Zvuky ve virtuálním prostředí je rovněž možno seskupovat do jistých kategorií. Jsou jimi dabingy textů k dialogovým stromům, které je možné nahrávat po návrhu těchto textů. Dále jsou to zvuky doprovázející animace nebo přímo změny stavů a zvuky pro doprovod průběhu stavu (například stav soustruhu soustružení). Další kategorií jsou ambientní zvuky, které v případě virtuálního prostředí odpovídajícího skutečnosti vyplývají již z fáze zadání.

Hardware

Součástí fáze tvorby je i přizpůsobení softwarového projektu hardwaru, na kterém bude virtuální prostředí pracovat. Často je fakt nemožné nebo krajně nekomfortní testovat virtuální prostředí v průběhu jeho vývoje na tomto hardwaru přímo, proto je někdy nutné nejdříve vyvinout virtuální prostředí pro „monitor a klávesnici“ a implementovat funkčnost tohoto HW až ke konci vývoje. V tom případě je však více než vhodné otestovat HW alespoň na části projektu nebo na jednoduchém samostatném projektu, aby byla ověřena kompatibilita vývojového prostředí s tímto HW.

1.5. Fáze testování, implementace a provozu

Fáze testování

Fáze testování se nutně prolíná s fází tvorby. Testujeme jednak funkčnost jednotlivých zdrojů ihned po jejich zhotovení nebo i v průběhu. Skripty jsou testovány na správnou funkci, odolnost kódu a hledání neočekávaných výjimek k jejich ošetření. U grafiky, modelů a animací jsou testovány správné modely, kompatibilita ve vývojovém prostředí a samozřejmě i estetické vlastnosti.

Testování probíhá často. Je nutné testovat malé změny ve virtuálním prostředí a jednotlivé zdroje testovat vždy, když je to možné. Toto je dáno zkušenostmi z programování, kdy chyby vznikají velmi často.

Je vhodné dosazovat jednotlivé zdroje po jejich vytvoření ihned. Virtuální prostředí je tak částečně funkční a je možné monitorovat jeho vývoj. Všichni spolupracovníci musí mít neustále k dispozici aktuální verzi, aby mohli testovat svoje zdroje komplexně.

Toto je důležité i zejména proto, že je možné v podstatě ihned a kdykoli kompilovat aktuální verzi ke kontrole nebo demonstraci zadavateli nebo managementu pro kontrolu stavu nebo pro jiné účely.

Testování musí probíhat přímo na HW, pro který je realizace určena: jako je třeba CAVE projekce nebo HMD.

Testování probíhá i ve smyslu validace proti zadání.

Fáze implementace

Fáze implementace se opět překrývá s fází testování v rámci kalibrace hardwaru, například přizpůsobení jasu a kontrastu světelným podmínkám v místnosti, kde bude virtuální prostředí používáno, a především kalibrace případných haptických zařízení vůči stereoskopické projekci (uživatel musí například „vidět, že sahá na stejné místo ve VR i ve skutečnosti“).

Fáze provozu

Fáze provozu je často opomíjena a projekt se považuje za úplně uzavřený. Je však vhodné ponechat si přístup k virtuálnímu prostředí za účelem sbírání zkušeností do budoucna pro vývoj dalších virtuálních prostředí. Není od věci nechat uživatele virtuálního prostředí vyplňovat dotazníky.