full review
All checks were successful
CI / Build thesis PDFs (pull_request) Successful in 1m17s
CI / Verify PDF/A (pull_request) Successful in 47s

This commit is contained in:
Oleg Petruny 2025-07-15 11:32:06 +02:00
parent f50b2e4acb
commit f1219ef8e5
7 changed files with 111 additions and 73 deletions

View File

@ -97,7 +97,7 @@ Samozřejmě to~přináší nějaký overhead, hlavně když se~jedná o~práci
Největší nevýhodou je~překvapivě nepřehlednost kódu, která~nejčastěji značí špatný programátorský návrh nebo lenost autora. Totiž velký počet vizuálních bloků a~jejich propojení není možné umístit přehledně na~jednu obrazovku. To~potom vyúsťuje v~nepřehledný mix různých logických částí, které~jsou dost obtížné na~orientaci a~údržbu. Napravit~to nejde ani~rozdělením jedné funkce do~více funkcí v~samotném Blueprintu. Nepřehledný mix propojení bloků se~pouze změní na~nepřehledný mix oken s~ruzným kódem. Správný postup v~tomto případě je~ručně konvertovat logiku z~Blueprintu do~C++.
\paragraph{C++} Práce s~C++ v~Unreal Engine je~zkutečně podobná práci s~velkými frameworky, například Qt. Použití čistého C++ je~zcela povolené, ale~takový kód potom nelze použít v~blueprintech a~tedy i~editoru. Unreal Engine proto definuje speciální makra jako~třeba UCLASS a~UFUNCTION pro~možnost integrování kódu buď~přímo do~blueprintu nebo~aspoň systému reflexe. Makra se~potom zpracovávají ne~macro preprocessor, ale~Unreal Header Tool nebo~Unreal Build Tool, které~slouží jako~generatory kódu. Generatory potom sami generují potřebné funkce a~proměnné pro~systém reflexe a~editor.
\paragraph{C++} Práce s~C++ v~Unreal Engine je podobná práci s~velkými frameworky, například Qt. Použití čistého C++ je~zcela povolené, ale~takový kód potom nelze použít v~blueprintech a~tedy i~editoru. Unreal Engine proto definuje speciální makra jako~třeba UCLASS a~UFUNCTION pro~možnost integrování kódu buď~přímo do~blueprintu nebo~aspoň systému reflexe. Makra se~potom zpracovávají ne~macro preprocessor, ale~Unreal Header Tool nebo~Unreal Build Tool, které~slouží jako~generatory kódu. Generatory potom sami generují potřebné funkce a~proměnné pro~systém reflexe a~editor.
V~C++ a~navíc s~otevřeným kódem celého enginu, má~vývojář plnou kontrolu nad~během programu nebo~jeho debugováním. Problém je~ale~použití assetů z~editoru nebo~reference objektů v~herním světě. Jsou~možnosti jak~to~obejít, například statické načtení assetu z~registru pomoci konstantní plné cesty k~assetu nebo~přeiterovat všechny objekty ve~světě. Editor samořejmě není schopen takové reference udržovat v~případě přemístění assetu a~časté iterování přes všechny objekty je~citelná zátěž. Proto ve~většíně případů je~potřeba zpřístupnít celou třídu do~Blueprintu a~v~editoru rovněž vytvořit Blueprint podtřídu, která~bude pouze přiřazovat potřebné reference.
@ -143,14 +143,17 @@ Veškeré potřeby pro~animaci libovolného druhu jsou~taktéž pokryté.
\subsection*{- Renderer}
Z~rendererů lze~vybrat mezi~Forward a~Deferred rendererem. Jsou~to~systémy, které~se~starají o~zpracování grafiky a~vykreslování scény. Zajišťují převod 3D~objektů a~jejich vlastností na~obraz, který~se~zobrazí na~monitoru. Renderer pracuje s~osvětlením, stíny a~materiály pro~dosažení realistické nebo~stylizované grafiky. V~Unreal Engine ovlivňuje také dostupné prostředky pro~post-processing.
\label{sec:forwardRenderer}
\paragraph{Forward rendering} Forward rendering je~metoda renderingu, kde~objekty se~renderují pro~každý zdroj světla zvlášť a~výsledné osvětlení je~součtem těchto průchodů. Je~vhodný pro~scény s~malým množstvím světel a~vyžaduje menší paměťovou náročnost. Dnes se~převážně používá v~mobilních a~VR aplikacích, kde~je~důležitá nízka latence. Nevýhodou je například nemožnost použití Screen Space vykreslovacích technik a~omezení na~maximalně 4~dynamických světel na~objekt -- 4~kanály resp.~RGBA.
\label{sec:deferredRenderer}
\paragraph{Deferred rendering} Deferred rendering odkládá aplikaci světelných efektů a~v~první fázi ukládá informace o~geometrii scény do~bufferu (G-buffer). Světla se~aplikují až~v~druhé fázi, což~umožňuje efektivnější práci s~větším množstvím dynamických světelných zdrojů. Tato~metoda se~používá především v~moderních AAA~hrách, kde~je~vyžadována vysoká vizuální kvalita. Je~to~výchozí renderer v~Unreal~Engine, který~navíc umožňuje použití technologií Nanite a~Lumen.
Nevýhodou je~nemožnost použití kvalitních zhlazovacích metod jako~Multisample Anti-Aliasing. MSAA funguje~tak, že~ukládá průměr více vzorků na~pixel během rasterizace, což~dobře funguje u~forward renderingu, kde~se~barva a~hloubka určují okamžitě. V~deferred renderingu se~však barvy a~osvětlení aplikují až~v~pozdější fázi, kdy~se~světelné výpočty provádějí na~pixelech na~základě uložených dat v~G\mbox{-}bufferu. Problém~je, že~MSAA by~muselo být aplikováno na~všechny jednotlivé buffery (normály, hloubku, albedo atd.), což~je~extrémně výpočetně náročné a~neefektivní. Proto se~místo MSAA často používají jiné metody zhlazování, jako~FXAA (Fast Approximate Anti-Aliasing) nebo~TAA (Temporal Anti-Aliasing). Ty~jsou podstatně méně kvalitní a~TAA dokonce způsobuje rozmazávání hran objektů v~dynamických scénach resp. ghosting efekt. SMAA (Subpixel Morphological Anti-Aliasing) je skvělá zhlazovací metoda pro deffered rendering, ale není podporováná v Unreal Engine.
Zároveň deferred shading není schopná poskytnout některé grafické techniky. Například transparentní materiály (např.~skla) nebo~subsurface scattering (rozptyl světla při~průchodu objektem nebo dopadu na~něj) se~musí renderovat na~konci ještě jedním průchodem tzv.~forward passem.
\label{sec:screenspace}
\subsection*{- Postprocessing}
Postprocessing je~technika dodatečného zpracování vyrenderovaného obrazu. Většinou se~jedná o~triviální manipulaci barev, ale~lze~tady dělat i~spoustu designových a~technickych triků. Např.~různé glitch efekty, efekty tepelného/nočního vidění~atd. získané pomocí procedurální nebo~statické modulace obrazu. V~deferred rendereru navíc lze~používat screen space techniky, které~používají vyrenderovaný snímek k~rychlé tvorbě odrazů (SSR - Screen Space Reflections) nebo~zastínění (SSAO - Screen Space Ambient Occlusion).

138
ch2.tex
View File

@ -215,61 +215,59 @@ Již teď je možné předpovědět, co~nebude kompletně fungovat nebo~nebude f
\subsection{Statické objekty}
Engine disponuje modely základních tvarů (krychle, koule, válec) a~navíc lze zdarma vzít libovolné assety z~balíčku Starter Content\footnote{https://dev.epicgames.com/documentation/en-us/unreal-engine/starter-content-in-unreal-engine} nebo~assety použité v~demo projektech společnosti Epic~Games. Přestože assety mají souvislý styl, většinou jsou~zaměřeny na~konkrétní prostředí, a~proto~v~další~hře nemusí najít využití. Zřejmě lze nahrát vlastní modely, které~lze~ručně vytvořit nebo~obstarat na~libovolné online platformě.
V~Unreal Engine verze~5 navíc přidali funkčně bohatý editor 3D~modelů. Tvůrci propagují editor tak, že~v~něm lze vytvářet vlastní modely, protože~množina funkcí dovoluje tvořit hardsurface a~sculpting modely, ale~aktuální provedení není~dostačující ve~srovnání s~dedikovaným softwarem.
V~Unreal Engine verze~5 navíc přidali funkčně bohatý editor 3D~modelů. Tvůrci propagují editor tak, že~v~něm lze vytvářet vlastní modely, protože~množina funkcí dovoluje tvořit hardsurface a~sculpting modely, ale~aktuální provedení není~dostačující ve~srovnání s~dedikovaným softwarem. Drobné editovací funkce na~druhou stranu jsou~užitečné a~šetří čas. Ty~umožňují například editování UV~map, normálových vektorů plošek nebo~změnu středového bodu modelu. ``Best practice'' je~využití tohoto editoru pouze v~případě nouze (například časová výhoda nebo~neexistence původního souboru), jinak~je~v~dlouhodobém měřítku prospěšné editovat původní verzovaný soubor.
\paragraph{Použití cizích assetů} Rychlejší a~občas jednodušší je~získání assetů třetí strany. K~tomu~existují různé volně dostupné webové platformy. Jednou z~takových platform je~FAB\footnote{https://www.fab.com/}, která~navíc má přímou integraci s~UE~5. Objektivně FAB nemá dostatečně velký výběr assetů, jelikož nemá ani~dostatečnou popularitu vývojářů a~tvůrců.
\newpage
Drobné editovací funkce na~druhou stranu jsou~užitečné a~šetří čas. Ty~umožňují například editování UV~map, normálových vektorů plošek nebo~změnu středového bodu modelu. ``Best practice'' je~využití tohoto editoru pouze v~případě nouze (například časová výhoda nebo~neexistence původního souboru), jinak~je~v~dlouhodobém měřítku prospěšné editovat původní verzovaný soubor.
Příčinou jsou~hlavně větší platformní marže z~prodeje a~sice jednoduché, ale~přesto nevýhodné licencování produktů pro~kupující stranu. Tyto a~další problémy popisují i~jiní uživatelé na~fórech\cite{fabRealityCheck}.
\paragraph{Použití cizích assetů} Rychlejší a~občas jednodušší je~získání assetů třetí strany. K~tomu~existují různé volně dostupné webové platformy. Jednou z~takových platform je~FAB\footnote{https://www.fab.com/}, která~navíc má přímou integraci s~UE~5. Objektivně FAB nemá dostatečně velký výběr assetů, jelikož nemá ani~dostatečnou popularitu vývojářů a~tvůrců. Příčinou jsou~hlavně větší platformní marže z~prodeje a~sice jednoduchý, ale~přesto nevýhodné licencování produktů pro~kupující stranu. Tyto a~další problémy popisují i~jiní uživatelé na~fórech\cite{fabRealityCheck}.
Z~finančních důvodů, v~této praci byly využity pouze produkty dostupné zdarma. Neznamená~to, že~vše~končí pouhým stahováním souborů a~vložením do~editoru. Často (v~této práci všech~100\%) assety nevykazují známky optimalizace nebo~profesionální tvorby. Modely tak~mají některé normaly plošek invertované\footnote{Invertované normály plošek jsou při~tvorbě objektů běžné a~triviálně řešitelný problém, který~často způsobuje, že~ploška ve~scéně není vidět, jelikož~se~vykresluje pouze ve~viditelném směru normálového vektoru a~tedy vytváří ``díry'' v~objektu.}, středové body jsou~nesmyslně mimo, textury a~UV~mapy je~potřeba kompletně předělat. Nejhorší jsou primitivní objekty, které~mají bezdůvodně velké množství vrcholů. V~praxi se~nachází i~náhodné vrcholy bezúčelně existující v~prostoru modelu.
Z~finančních důvodů, v~této praci byly využity pouze produkty dostupné zdarma. Neznamená~to, že~vše~končí pouhým stahováním souborů a~vložením do~editoru. Často (v~této práci všech~100\%) assety nevykazují známky optimalizace nebo~profesionální tvorby. Modely tak~mají některé normálové vektory plošek invertované\footnote{Invertované normály plošek jsou při~tvorbě objektů běžné a~triviálně řešitelný problém, který~často způsobuje, že~ploška ve~scéně není vidět, jelikož~se~vykresluje pouze ve~viditelném směru normálového vektoru a~tedy vytváří ``díry'' v~objektu.}, středové body jsou~nesmyslně mimo, textury a~UV~mapy je~potřeba kompletně předělat. Nejhorší jsou primitivní objekty, které~mají bezdůvodně velké množství vrcholů. V~praxi se~nachází i~náhodné vrcholy bezúčelně existující v~prostoru modelu.
\paragraph{Vlastní tvorba} Vlastnoručně jsou tvořeny modely ze~staré verze hry a~během vývoje této práce se~pouze upravovaly nebo tvořily textury. Standardem v~oboru jsou~obecně Maya\footnote{https://www.autodesk.com/products/maya/overview} nebo~3ds~Max\footnote{https://www.autodesk.com/products/3ds-max/overview} pro~víceúčelové zpracování a~úpravy, ZBrush\footnote{https://www.maxon.net/en/zbrush} pro~sculpting a~Substance~Painter\footnote{https://www.adobe.com/products/substance3d/apps/painter.html} pro~texturování objektu. V~tomto projektu byl použit výhradně Blender\footnote{https://www.blender.org/} a~software pro~editaci obrázkových formátů, které~jsou k~dispozici na~internetu zdarma. Výsledný model lze často bez~problémů rovnou využít v~enginu.
\paragraph{Modeling a Sculpting} Nejprve se~vytváří tvar modelu. Toho se~docílí pomocí modelování polygonů nebo~sculptingu. Obě~metody jsou velmi odlišné a~stejně~tak mají odlišný výstup.
Sculpting se~provádí především přes~grafický tablet, kde~pomocí různých 3D~štětců se~natahují nebo~smršťují vrcholy a~celý proces napodobuje tvorbu sochy z~plastického materiálu. Především takový přístup se~používá pro~tvorbu organických modelů nebo~modelů s~měkkým povrchem jako~například živé bytosti, rostliny nebo~oblečení.
Sculpting se~provádí především přes~grafický tablet, kde~pomocí různých 3D~štětců se~natahují nebo~smršťují vrcholy a~celý proces napodobuje tvorbu sochy z~plastického materiálu. Především takový přístup se~používá pro~tvorbu organických modelů nebo~modelů s~měkkým povrchem jako~například živé bytosti, rostliny nebo~oblečení. Modeling na~druhou stranu je obecnější zpracování vrcholů, hran a~ploch. Tady se~manuálně přidávají resp.~odebírají a~posouvají vrcholy. Navíc toto~prostředí obsahuje funkce umožňující různé druhy efektivního instancování, množinových operací mezi objekty a~zjednodušených simulací vrcholů. V~takovém prostředí se~tvoří především komplexní resp.~hybridní nebo~tvrdé povrchy jako~například nábytek, architektura nebo~scény se~sculpting modely.
Specifickou sculpting instancí v~enginu je Landscape\footnote{https://dev.epicgames.com/documentation/en-us/unreal-engine/landscape-overview}, de-facto síť vrcholů předem určené hustoty, kterou~můžeme v~editoru sculptovat a~napodobovat křivý resp.~různě vysoký terén. Manuální sculpting je pomalý a~přináší slabé až~nevyhovující výsledky. Proto místo sculptingu se~používá výšková neboli height~mapa, což~je textura odstínů šedi, kde~každý pixel kóduje výšku v~3D prostoru. Potom stačí naskenovat nějaký povrch v~reálném světě a~získat skvělé výsledky. Stejné height~mapy lze používat i~jako~štětce v~běžném sculptingu, pro~specifické detalizace povrchů, a~samotné height mapy lze získat na~některých online platformách dokonce zdarma.
\newpage
Modeling na~druhou stranu je obecnější zpracování vrcholů, hran a~ploch. Tady se~manuálně přidávají resp.~odebírají a~posouvají vrcholy. Navíc toto~prostředí obsahuje funkce umožňující různé druhy efektivního instancování, množinových operací mezi objekty a~zjednodušených simulací vrcholů. V~takovém prostředí se~tvoří především komplexní resp.~hybridní nebo~tvrdé povrchy jako~například nábytek, architektura nebo~scény se~sculpting modely.
Specifickou sculpting instancí v~enginu je Landscape\footnote{https://dev.epicgames.com/documentation/en-us/unreal-engine/landscape-overview}, de-facto síť vrcholů předem určené hustoty, kterou~můžeme v~editoru sculptovat a~napodobovat křivý resp.~různě vysoký terén. Manuální sculpting je pomalý a~přináší slabé až~nevyhovující výsledky. Proto místo sculptingu se~používá výšková neboli height~mapa, což~je textura odstínů šedi, kde~každý pixel kóduje výšku v~3D prostoru. Potom stačí naskenovat nějaký povrch v~reálném světě a~získat skvělé výsledky. Stejné height~mapy lze používat i~jako~štětce v~běžném sculptingu, pro~specifické detalizace povrchů, a~samotné height mapy lze získat na~některých online platformách dokonce zdarma. Ukázka landscapu je k~dispozici ve~druhé úrovni, kde~povrch terénu jsem vytvořil pomocí textury výšek a~hory jsem tvořil ručně základními štětci.
Ukázka landscapu je k~dispozici ve~druhé úrovni, kde~povrch terénu jsem vytvořil pomocí textury výšek a~hory jsem tvořil ručně základními štětci.
\paragraph{Animace} Animace se~tvoří v~dalším kroku modelingu. Pokud jsme předtím vytvořili model pomocí sculptingu, potřebujeme ho importovat do~modeling prostředí. Začíná~se tvorbou umělé kostry z~tzv.~kostí a~kloubů.
Klouby slouží pouze ke~specifikaci hierarchie mezi kostmi tak, že~kost propaguje vlastní modifikaci na~všechny následující. Navíc specifikují střed rotačního bodu.
Klouby slouží pouze ke~specifikaci hierarchie mezi kostmi tak, že~kost propaguje vlastní otočení a posun na~všechny následující. Navíc specifikují střed rotačního bodu.
Kosti jsou samostatné absraktní označení pro~nosič prostorových transformací, pro~který~můžeme přiřadit množinu vrcholů. Potom v~logice animace stačí pouze posouvat určité kosti a~předrenderovácí engine bude souvislé modifikovat přiřazené vrcholy. Navíc kostí často modifikují vrcholy podle předem určené váhy pro~každý vrchol, čímž~lze škálovat a~skládat posuny různých kostí na~určitých vrcholech. Jen~je~potřeba brát v~úvahu, že~skeleton animace neboli modifikace provedené předrenderovacím enginem jsou spuštěné na~CPU, jelikož jsou řízeny logikou herního světa. Naštěstí moderní procesory s~instrukčními sadami AVX a~více jádry v~takových úlohách dokážou předvádět poměrně skvělé až~nadbytečné výkony.
Kosti jsou samostatné abstraktní označení pro~nosič prostorových transformací, pro~který~můžeme přiřadit množinu vrcholů. Potom v~logice animace stačí pouze posouvat určité kosti a~předrenderovácí engine bude souvislé modifikovat přiřazené vrcholy. Navíc kosti často modifikují vrcholy podle předem určené váhy pro~každý vrchol, čímž~lze škálovat a~skládat posuny různých kostí na~určitých vrcholech. Jen~je~potřeba brát v~úvahu, že~skeleton animace neboli modifikace provedené předrenderovacím enginem jsou spuštěné na~CPU, jelikož jsou řízeny logikou herního světa. Naštěstí moderní procesory s~instrukčními sadami AVX a~více jádry v~takových úlohách dokážou předvádět poměrně skvělé až~nadbytečné výkony.
V~Unreal~Engine~5 přidaly rozhraní pro~tvorbu skeleton animací přímo v~editoru. Předtím bylo možné pouze hotové animace naimportovat. Uvnitř editoru je příliš mnoho způsobů jak~režírovat animace (myšleno přehrávání, slepení přechodů, modifikace, skládání atd.) a~lze se~v~tom jednoduše ztratit. V~základu je předpokládaná tvorba state-machine, který~bude přehrávat a~cyklit jednotlivé animace v~závislosti na~větvení grafu a~podmínkách hran.
V~Unreal~Engine~5 přidaly rozhraní pro~tvorbu skeleton animací přímo v~editoru. Předtím bylo možné pouze hotové animace naimportovat. Uvnitř editoru je příliš mnoho způsobů jak~režírovat animace (myšleno přehrávání, slepení přechodů, modifikace, skládání atd.) a~lze se~v~tom jednoduše ztratit. V~základu je předpokládaná tvorba stavového automatu, který~bude přehrávat a~cyklit jednotlivé animace v~závislosti na~větvení grafu a~podmínkách hran.
Táto práce obsahuje pouze jednoduché animace postav, které~byly přeneseny ze~staré verze. Animace hráče navíc disponuje imersivním\footnote{Imersivita je označení pro~větší stupeň uživatelské odezvy nebo~pocit přítomností a~ponoření do~děje hráčem.} otáčením trupu a~animace nohou jsou přitahovány k~podlaze pomocí inverzní kinematické metody\footnote{Inverzní kinematická metoda umožňuje procedurální modifikaci skeleton animace.}.
Tato práce obsahuje pouze jednoduché animace postav, které~byly přeneseny ze~staré verze. Animace hráče navíc disponuje imersivním\footnote{Imersivita je označení pro~větší stupeň uživatelské odezvy nebo~pocit přítomností a~ponoření do~děje hráčem.} otáčením trupu a~animace nohou jsou přitahovány k~podlaze pomocí inverzní kinematické metody\footnote{Inverzní kinematická metoda umožňuje procedurální modifikaci skeleton animace. Obvykle se jedná o dopočítání pozice kloubů po cestě (např. loktu nebo kolena) pro určenou pozici "listů" (např. dlaně nebo chodidla)}.
\newpage
Tráva viditelná v~první a~druhé úrovní je animovaná pomocí offsetů vrcholů. V~reálném čase pod~hráčem se~generují částice s~barevným gradientem kódující offset v~prostoru. Takové~částice jsou viditelné pouze pro~speciální render target menší velikosti -- snímá~se pouze blízké okolí hráče. Materiál trávy následný render target interpretuje jako~texturu, kterou~interpoluje spolu s~texturou jednoduchého procedurálního shaderu větru dostupného v~enginu. Výsledkem je~výkonná procedurální animace reakce na~vítr a~chůzi hráče v~okolí objektu obsahující velké množství instancí resp.~vrcholů.
\paragraph{Texturování} Za~účelem texturování nejdřív potřebujeme objektu určit jedinečnou UV~mapu, která~bude mapovat plošky 3D~modelu na normalizovaný prostor 2D~obrázku. Často tvůrci mají na~začátku problém pochopit o~co~se~vlastně jedná a~jak~model rozložit. K~tomu může napomoci myšlenka s~rozlepováním resp.~slepováním hran papírové figurky. Celý koncept UV~mappingu je totožný se~zpětným procesem tvorby například papírové krychle, kde~rozbalenou krychli skládáme z~jednoho uceleného kousku materiálu.
\paragraph{Texturování} Za~účelem texturování nejdřív potřebujeme objektu určit jedinečnou UV~mapu, která~bude mapovat plošky 3D~modelu na normalizovaný prostor 2D~obrázku. Často tvůrci mají na~začátku problém pochopit, o~co~se~vlastně jedná a~jak~model rozložit. K~tomu může napomoci myšlenka s~rozlepováním resp.~slepováním hran papírové figurky. Celý koncept UV~mappingu je totožný se~zpětným procesem tvorby například papírové krychle, kde~rozbalenou krychli skládáme z~jednoho uceleného kousku materiálu.
Když máme hotové mapování, můžeme volně přiřazovat textury, které~mohou určovat barvu vrcholů, modifikovat jejich normálový vektor, lesk, matnost, průhlednost a~případně další. Přibližně do~roku~2014, kdy~vznikl Substance Painter a~dnes i~jeho alternativy, jediný způsob texturování objektu bylo manuální kreslení navrch vytvořené mapy. Dnes existují uživatelsky příjemné programy, kde~stačí kreslit rovnou komplexní materiály na~povrch 3D~modelu a~aplikace sama obstará data všech textur.
Když máme hotové mapování, můžeme volně přiřazovat textury, které~mohou určovat barvu vrcholů, modifikovat jejich normálový vektor, lesk, matnost, průhlednost a~případně další. Přibližně do~roku~2014, kdy~vznikl Substance Painter (program na~procedurální tvorbu materiálů a texturování) a~dnes i~jeho alternativy, jediný způsob texturování objektu bylo manuální kreslení navrch vytvořené mapy. Dnes existují uživatelsky příjemné programy, kde~stačí kreslit rovnou komplexní materiály na~povrch 3D~modelu a~aplikace sama obstará data všech textur.
V~tomto projektu většina objektů nepoužívá difuzní textury ale~jednoduché vybarvení určitých skupin plošek. Přesto jsou často využívané normal mapy nebo~masky průhlednosti. Bohužel se~musely zahodit mapy pro~tesselaci\footnote{Teselace je technika podrozdělení a~modifikace plošek za~účelem zvětšení detalizace objektu.} povrchů používané v~staré verzi projektu, jelikož s~příchodem UE~5 tvůrci odebrali celou podporu tesselace kvůli technologii Nanite.
V~tomto projektu většina objektů používá pouze jednobarevné textury pro~vybarvení určitých skupin plošek. Přesto jsou často využívané normal mapy nebo~masky průhlednosti. Bohužel se~musely zahodit mapy pro~tesselaci\footnote{Teselace je technika podrozdělení a~modifikace plošek za~účelem zvětšení detalizace objektu.} povrchů používané v~staré verzi projektu, jelikož s~příchodem UE~5 tvůrci odebrali celou podporu tesselace kvůli technologii Nanite.
\paragraph{Exportování a Importování}
Workflow nebo~pipeline exportu jsou standardizované v~profesionálních softwarech jako~3ds~Max. Blender má pouze základní možnosti exportu, které~je potřeba nejdřív přizpusobit specifickému hernímu enginu. Potřebné minimum je zajištění správné interpretace dopředního a~vrchního vektorů celého modelu. Taky se~vyplatí:
Workflow nebo~pipeline exportu jsou standardizované v~profesionálních softwarech jako~3ds~Max. Blender má pouze základní možnosti exportu, které~je potřeba nejdřív přizpusobit specifickému hernímu enginu. Potřebné minimum je zajištění správné interpretace dopředního a~vrchního vektorů\footnote{Dopřední "forward" a~vrchní "up" vektory určují, jak~program interpretuje osy ve~3D prostoru. Ve~většině programů dopřední vektor odpovídá ose~Z a~vrchní ose~Y, ale~v~UE je~to obrácené.} celého modelu. Taky se~vyplatí:
\begin{itemize}
\item nastavit šablonu pro~všechny budoucí projekty, tak~aby~modelovací program a~herní editor sdíleli měřítko jednotek,
\item vyzkoušet, jak~se~chová exportovaná hierarchie modelů v~jednom souboru,
\item před exportem ověřit, že~všechny plošky modelu mají správně natočený normálový vektor (očekává~se směr mířící ven z~objektu).
\end{itemize}
Unreal Engine je standardem herního oboru a~proto verze~5 implementuje systém importovacích pipelines. Jedná~se o~mocný nástroj, který~citelně zrychluje a~sjednocuje postupy importování různých assetů nebo~dokonce stejných assetů podle specifických filtrů (adresář assetu, typ, obsah, podřetězce názvu atd.). Subjektivně největší výhodou je předání zodpovědnosti specifického importu pouze osobám v~týmu s~odpovídajícími znalostmi.
\newpage
V~praxi týmový senior založí pipelines pro~často využívané importy~tak, aby~odpovídali vnitřním firemním politikám a~proto celý tým nemá žádné starosti při importu assetů.
Unreal Engine je standardem herního oboru a~proto verze~5 implementuje systém importovacích pipelines. Jedná~se o~mocný nástroj, který~citelně zrychluje a~sjednocuje postupy importování různých assetů nebo~dokonce stejných assetů podle specifických filtrů (adresář assetu, typ, obsah, podřetězce názvu atd.). Subjektivně největší výhodou je předání zodpovědnosti specifického importu pouze osobám v~týmu s~odpovídajícími znalostmi. V~praxi týmový senior založí pipelines pro~často využívané importy~tak, aby~odpovídaly vnitřním firemním politikám a~proto celý tým nemá žádné starosti při importu assetů.
\paragraph{Optimalizace} I~když objekty jsou statické, stále vyžadují optimalizace. Takové lze najít i~v~tomto projektu:
\begin{itemize}
\item Instancování se~využívá k~tvorbě prostorů hustých na~specifické modely. V~UE se~jedná o~editovací prostředek sousedící vedle Landscape. Umožňuje pokročilé nastavení různých množin instancí a~jejich parametry náhodného umístění.
\item Optimální topologie objektu pro~minimalizaci vrcholů potřebných k~vykreslování. Převážná většina modelů -- patří sem i~získané od~třetích stran -- mají mnou ručně přepracované topologie. Jedná~se nejen~o~jednoduchou redukci nepotřebných vrcholů, ale~taky použití létající neboli floating geometrie. Tato~metoda spočívá v~protínání plošek, místo skutečného propojení vrcholů někde uprostřed, jelikož takové propojení by~vyžadovalo podrozdělení plošek, což~by~vedlo ke~zbytečnému zvětšení počtu vrcholů (viz \Cref{fig:FloatingGeometry}). Taktéž objekty mají redukovanou k-DOP kolizní topologii, pro~urychlení výpočtů fyzických simulací.
\item Modely náročné na~vykreslování nebo~použité v~instancování používají LOD~technologii (viz \Cref{fig:LodShowcase}). Nanite v~práci nebyl využít.
\item Optimální topologie objektu pro~minimalizaci vrcholů potřebných k~vykreslování. Převážná většina modelů -- patří sem i~získané od~třetích stran -- mají mnou ručně přepracované topologie. Jedná~se nejen~o~jednoduchou redukci nepotřebných vrcholů, ale~taky použití létající neboli floating geometrie.
\newpage
Tato~metoda spočívá v~protínání plošek, místo skutečného propojení vrcholů někde uprostřed, jelikož takové propojení by~vyžadovalo podrozdělení plošek, což~by~vedlo ke~zbytečnému zvětšení počtu vrcholů (viz \Cref{fig:FloatingGeometry}). Taktéž objekty mají redukovanou k-DOP kolizní topologii, pro~urychlení výpočtů fyzických simulací.
\item Modely náročné na~vykreslování nebo~použité v~instancování používají LOD~technologii (viz \Cref{fig:LodShowcase} na~další stránce). Nanite v~práci nebyl využit, jelikož~máme vypnutý deferred renderer (viz \Cref{sec:deferredRenderer}).
\end{itemize}
\begin{figure}
@ -290,76 +288,84 @@ Optimalizace textur je zajištěná pouze hlídáním rozumných rozlišení. Ji
Jiná grafická optimalizace není řešená. Modely použité v~instancování občas mohou vyvolat snížení výkonu, což~by~bylo potřeba už~řešit nahrazením plnohodnotných modelů za~kolekce průhledných textur (billboard metoda popsaná v~další podsekci).
\subsection{Dynamické a procedurální objekty}
\paragraph{Sequencer} Běžná dynamická animace se~vytváří přímo v~editoru objektu Sequencer\footnote{https://dev.epicgames.com/documentation/en-us/unreal-engine/unreal-engine-sequencer-movie-tool-overview}. Taková animace dokáže modifikovat parametry objektů na~úrovní a~volat funkce v~určité okamžiky. Objekty mohou~být určené předem nebo~Sequencer umí dynamicky vyhledat jejich reference před~spuštěním. Právě v~tomto prostředí se~tvoří cutscény nebo~cyklické animace objektů na~úrovni.
\paragraph{Procedurální generování} V~předchozí verzi hry model trávy byl vytvořen pomocí billboard metody, kde~místo vykreslování 3D~geometrie vegetace, se~vykresluje průnik ploch s~texturou vegetace a~průhledným pozadím. Tato~technika je~standardem ve~videohrách, přesto nestačila ke~splnění dizajnových účelů projektu. Buď~vegetace musela být řídká, nebo~vyžadovala nesmyslně mnoho hardwarových prostředků a~občas vzniklo i~drobné zmrazení aplikace.
\newpage
Pro~tento účel jsem implementoval nástroj pro~editor, který~podle určitých parametrů je~schopen vygenerovat náhodnou a~hustou trávu z~trojúhelníků. Výsledný objekt má několikanásobně více geometrických dat než~billboard metoda, přesto~má skvělý výkon a~navíc vegetace působí mnohem hustěji, má kvalitnější vzhled a~lépe reaguje na~offset vrcholů v~shaderech (viz \Cref{fig:GrassShowcase}). Trik~je v~přenesení velké texturové zátěže s~převýpočty průhledností na~vykreslování jednotné a~jednoduché 3D~geometrie. K~tomu, generativní přístup umožňuje kvalitnější pokrytí ploch, jako~například v~tomto projektu, kde~tráva se~generuje pouze v~oblastech určité velikosti a~jestli jsou pokryté určitým materiálem, tedy~tráva se~negeneruje na~cestičkách a~mezi povolenou a~zakázanou plochou je pozvolný přechod ve~velikosti jednotlivých stebel. Takový přístup byl inspirován hrou Ghosts~of~Tsushima od~studia Sucker~Punch~Productions, kde~autoři si~vytvořili podobný proprietární nástroj, jelikož chtěli dosáhnout husté kinematografické a~stylistické vegetace na~konzolích.
\subsection{Dynamické a procedurální objekty}
\paragraph{Sequencer} Běžná dynamická animace se~vytváří přímo v~editoru objektu Sequencer\footnote{https://dev.epicgames.com/documentation/en-us/unreal-engine/unreal-engine-sequencer-movie-tool-overview}. Taková animace dokáže modifikovat parametry objektů na~úrovni a~volat funkce v~určité okamžiky. Objekty mohou~být určené předem, nebo~Sequencer umí dynamicky vyhledat jejich reference před~spuštěním. Právě v~tomto prostředí se~tvoří cutscény nebo~cyklické animace objektů na~úrovni.
\paragraph{Procedurální generování} V~předchozí verzi hry model trávy byl vytvořen pomocí billboard metody, kde~místo vykreslování 3D~geometrie vegetace se~vykresluje průnik ploch s~texturou vegetace a~průhledným pozadím. Tato~technika je~standardem ve~videohrách, přesto nestačila ke~splnění dizajnových účelů projektu. Buď~vegetace musela být řídká, nebo~vyžadovala nesmyslně mnoho hardwarových prostředků a~občas vzniklo i~drobné zmrazení aplikace.
Za~tímto účelem jsem implementoval nástroj pro~editor, který~je schopen na základě určitých parametrů vygenerovat náhodnou a~hustou trávu z~trojúhelníků. Uživatel může specifikovat oblast generování a~cílový Landscape objekt společně s~materiálem, na~kterém má~být tráva generována. K~tomu lze specifikovat hustotu, variabilitu velikostí, minimální a~maximální velikost. Generování se~skládá ze~tří kroků:
\begin{itemize}
\item Rozložíme oblast na mřížku definované hustoty.
\item Z~každé buňky v~mřížce vyšleme kolizní paprsek směrem k~Landscape povrchu, čímž~získáme střed pro~budoucí stéblo.
\item V~prostoru každé buňky náhodně umístíme dva vrcholy ve~výšce středu a~jeden uprostřed s~náhodnou výškou, čímž~získáme trojúhelník, kterému~říkáme stéblo. Z~pozic vrcholů stébla dopočítáme normálové vektory (potřebujeme ke~správnému stínování stébel ve~světě) a~UV~mapu (pokud chceme určit stéblu texturu, např.~gradientu s~přechodem od~tmavé do~světlé zelené).
\end{itemize}
Výsledný objekt má několikanásobně více geometrických dat než~billboard metoda, přesto~má skvělý výkon a~navíc vegetace působí mnohem hustěji, má kvalitnější vzhled a~lépe reaguje na~offset vrcholů v~shaderech (viz \Cref{fig:GrassShowcase} na~další stránce).
Trik~je v~přenesení velké texturové zátěže s~převýpočty průhledností na~vykreslování jednotné a~jednoduché 3D~geometrie. K~tomu generativní přístup umožňuje kvalitnější pokrytí ploch, jako~například v~tomto projektu, kde~tráva se~generuje pouze v~oblastech určité velikosti a~jestli jsou pokryté určitým materiálem, tedy~tráva se~negeneruje na~cestičkách a~mezi povolenou a~zakázanou plochou je pozvolný přechod ve~velikosti jednotlivých stébel. Takový přístup byl inspirován hrou Ghosts~of~Tsushima od~studia Sucker~Punch~Productions, kde~autoři si~vytvořili podobný proprietární nástroj, jelikož~chtěli dosáhnout husté kinematické a~stylistické vegetace na~konzolích.
\begin{figure}
\centering
\includegraphics[width=1\linewidth]{img/GrassShowcase.pdf}
\caption{Ukázka procedurální~(vlevo) a~billboard~(vpravo) metod pro~vykreslování vegetace. Procedurální metoda má přibližně 6-krát menší render time a~paměťové požadavky.}
\caption{Ukázka procedurální~(vlevo) a~billboard~(vpravo) metody pro~vykreslování vegetace. Procedurální metoda má přibližně 6-krát menší render time a~paměťové požadavky.}
\label{fig:GrassShowcase}
\end{figure}
\subsection{Osvětlení}
Téměř každý objekt osvětlení sdílí podobné parametry, které~mohou definovat~to, jak~světlo vypadá nebo~ovlivňuje prostředí. Vedle běžných dizajnových parametrů nechybí ani~široká škála technických triků a~úskalí.
\paragraph{Forward shading} Jelikož celá hra je v~režimu forward shading, -- podle tvůrců enginu obsolete funkcionalita čekající na~plný rework, -- některé technologie jsou značně omezené nebo~nefungují a~zhoršuje~se~to s~každou novou verzi. Například časem přestal fungovat Rect Light, který~ale~můžeme napodobit~tak, že~Point Light zdroji přiřadíme IES~texturu, která~nám specifikuje způsob šíření světla neboli~tvar světla v~herním světě. Stejně~tak lze~vytvořit vlastní Light Function, což~je~materiál definující co~a~jak světelný zdroj vyzařuje.
\paragraph{Forward shading} Jelikož celá hra je v~režimu forward shading (viz \Cref{sec:forwardRenderer}), některé technologie jsou značně omezené nebo~nefungují. Například není podporován Rect Light (světelný zdroj ve tvaru obdelníku), který~ale~můžeme napodobit~tak, že~Point Light (světelný zdroj ve tvaru kruhu) zdroji přiřadíme IES~texturu, která~nám specifikuje způsob šíření světla neboli~tvar světla v~herním světě. Stejně~tak lze~vytvořit vlastní Light Function, což~je~materiál definující, co~a~jak světelný zdroj vyzařuje. Navíc je potřeba pamatovat na~technická omezení enginu pro~forward shadingu, jako~nejvýše tři~zdroje světla na~jeden objekt a~nedostatek SSAO nebo~SSR (viz \Cref{sec:screenspace}). S~čímž~stále si~můžeme poradit. Pokud~je potřeba víc zdrojů světel ve~scéně, můžeme specifikovat tři~různé kanály pro~objekt a~zdroje zvlášť.
\newpage
Navíc je potřeba pamatovat na~reálná technická omezení forward shadingu, jako~nejvýše tři~zdroje světla na~jeden objekt a~nedostatek SSAO nebo~SSR. S~čímž~stále si~můžeme poradit. Pokud~je potřeba víc zdrojů světel ve~scéně, máme k~dispozici tři~kanály, které~můžeme specifikovat pro~konkrétní objekt a~zdroj světla. A~pokud~nutně potřebujeme ambientní okluzi můžeme použít Lightmass Volume\footnote{https://dev.epicgames.com/documentation/en-us/unreal-engine/cpu-lightmass-global-illumination-in-unreal-engine} pro~jeho simulaci a~stejně tak~můžeme použít Planar~Reflections\footnote{https://dev.epicgames.com/documentation/en-us/unreal-engine/planar-reflections-in-unreal-engine} pro simulaci odrazů.
Jestli~nutně potřebujeme ambientní okluzi můžeme použít Lightmass Volume\footnote{https://dev.epicgames.com/documentation/en-us/unreal-engine/cpu-lightmass-global-illumination-in-unreal-engine} pro~jeho simulaci a~stejně tak~můžeme použít Planar~Reflections\footnote{https://dev.epicgames.com/documentation/en-us/unreal-engine/planar-reflections-in-unreal-engine} pro simulaci odrazů.
\paragraph{Základy osvětlení} Kromě bodových světel na~úrovní téměř vždy chceme přidat globální osvětlení, který~sestává z~Directional~Light a~Sky~Light.
\paragraph{Základy osvětlení} Kromě bodových světel na~úrovní téměř vždy chceme přidat globální osvětlení, které~sestává z~Directional~Light a~Sky~Light.
Directional zdroj funguje jako~jeden velký bodový zdroj pro~celou scénu, který~napodobuje funkci slunce a~slouží primárně k~vykreslování stínů. Zdroj typu Sky~Light také~může ovlivňovat stíny, ale~primárně zobrazuje Skybox texturu a~modifikuje ambient složku celého osvětlení.
Directional zdroj funguje jako~jeden velký nekonečně vzdálený zdroj pro~celou scénu, který~napodobuje funkci slunce a~slouží primárně k~vykreslování stínů. Zdroj typu Sky~Light také~může ovlivňovat stíny, ale~primárně zobrazuje Skybox texturu a~modifikuje ambient složku celého osvětlení.
Navíc pokud chceme zobrazit venkovní prostory, je dobré použít nějakou formu mlhy, jako~je Ambient~Fog. Mlha přidá pocit velkého a~neomezeného prostoru i~když ve~skutečnosti je malý a~uzavřený. Navíc mlha výborně skryje a~tedy~umožní horší detailizaci objektů v~dálce, čímž~efektivně zkrátíme dobu vykreslování snímku.
Nakonec se~lze odchýlit k~použití mnoha různých Volume objektů, které~z~důvodů rozsahu práce nebudou podrobně probrány. Pomocí těchto prostorů lze~specifikovat oblastí s~určitými parametry, které~budou napovídat enginu potřebné optimalizace, nebo~zapínat výkonnostně náročné vykreslovací technologie. Pro~představu Lightmass~Importance~Volume\footnote{https://dev.epicgames.com/documentation/en-us/unreal-engine/lightmass-basics-in-unreal-engine} specifikuje oblast, kde~je potřeba propočítat větší počet odrazů paprsků světla.
Nakonec se~lze odchýlit k~použití mnoha různých Volume objektů, které~z~důvodů rozsahu práce nebudou podrobně probrány. Pomocí těchto prostorů lze~specifikovat oblastí s~určitými parametry, které~budou napovídat enginu potřebné optimalizace, nebo~zapínat výkonnostně náročné vykreslovací technologie. Pro~představu Lightmass~Importance~Volume\footnote{https://dev.epicgames.com/documentation/en-us/unreal-engine/lightmass-basics-in-unreal-engine} specifikuje oblast, kde~je potřeba propočítat větší počet odrazů paprsků světla při ``zapekání" statických stínů\footnote{Zapekání světla neboli~light map baking je proces náročného předpočítání osvětlení a stínů tvořených statickými objekty na~statickém povrchu do~formátu textury.}.
\subsection{Post-Processing}
Post-Processing lze~definovat přímo v~kameře nebo~v~již zmíněných Volume objektech. Každá~definice je de-facto materíál, který~lze vrstvit mezi sebou. PP~vyžaduje hlubší grafické znalosti, aby~bylo možné vytvořit něco užitečnějšího než~barevnou korekci. Zároveň kvůli tématice práce pouze nastíním jak~jsem naimplementoval PP~materiály (viz~\Cref{fig:PPShowcase}), které~mají gamedizajnový důvod, ale~se~nestihli použít.
Post-processing jsou funkce, které~pracují s~již vyrenderovaným snímkem před~jeho zobrazením. Tímto způsobem lze např.~napadobit rozmazání/rozostření (depth-of-field), mlhu nebo~efekty popsané níže. Post-Processing lze~definovat přímo v~kameře nebo~v~již zmíněných Volume objektech. Každá~definice je de-facto materíál (v~kontextu~UE), který~lze vrstvit mezi sebou. PP~vyžaduje hlubší grafické znalosti, aby~bylo možné vytvořit něco užitečnějšího než~barevnou korekci. Zároveň kvůli tématice práce pouze nastíním, jak~jsem naimplementoval PP~materiály (viz~\Cref{fig:PPShowcase} na~další stránce), které~mají gamedizajnový důvod, ale~se~nestihli použít.
\begin{figure}
\centering
\includegraphics[width=1\linewidth]{img/PPShowcase.pdf}
\caption{Ukázka post-process materiálů ve~hře. Efekt deště jsem nedokázal rozumně zachytit.}
\caption{Ukázka post-process materiálů ve~hře. Efekt deště jsem nedokázal rozumně zachytit, aby~byl vidět na~statickém obrázku.}
\label{fig:PPShowcase}
\end{figure}
\begin{itemize}
\begin{enumerate}
\item Plovoucí obrazovka - UV~prostor obrazu se~lehce zakřiví pomocí animované šumové textury.
\item Námraza - obraz interpolujeme s~animavanou texturou. Nejlépe použít nějaký gradient uprostřed jako~masku průhlednosti, aby~hráč měl čistší vidění.
\item Stylová dálková kamera - obraz rozložíme na~trochu sesunuté proužky dle~rozlišení výstupu a~zároveň tyto~proužky střídavě obarvíme. Nakonec proužky animujeme posunem nahoru nebo~dolu.
\newpage
\item Déšť - obraz rozložíme na~jemnou mřížku a~v~blocích vygenerujeme různé kapky pomocí složení dvou turbulencí, každá~z~kterých bude mít animovanou lehce odlišnou rychlost posunu, aby~kapky nebyly stále stejné. Paralelně k~tomu znovu rozložíme obraz, ale~teď na~hrubou mřížku, kde~animujeme svislé pády bloků s~gradientním ocasem. Oba~výstupy složíme~tak, že~hruba mřížka představuje animovanou masku průhlednosti, která~nám bude v~různý okamžik otevírat pouze některé kapky. Nakonec přidáme trochu distortion a~výsledek použijeme jako modifikátor UV~výstupního obrazu.
\item Pixelizace - obraz rozložíme na~potřebnou mřížku dle~rozlišení a~modifikujeme UV~prostor výstupního obrazu.
\item Tavení pixelů - vytvoříme netriviální vertikální gradient s~více přechody. Výsledek znečistíme zaokrouhlováním a~násobením dat, zpixelizujeme rozdělením na~mřížku a~výsledek použijeme k~modifikaci UV~prostoru výstupního obrazu a~barevné korekci.
\item Bezpečnostní kamera - obraz rozložíme na~trochu sesunuté proužky dle~rozlišení výstupu a~zároveň tyto~proužky střídavě obarvíme. Nakonec proužky animujeme posunem nahoru nebo~dolu.
\item Slepota - výstupní obraz nahradíme vlastním, ve~kterém zobrazujeme pouze ohraničení objektů s~efektem emise. Ohraničení lze dosáhnout různými způsoby a~v~tomto projektu je~implementováno pomocí drobného posunu hloubkové textury ve~všech směrech. Mezi posuny se~provede rozdíl s~originální hloubkou a~sloučením rozdílů získáme obrysy objektů.
\item Pixelizace - obraz rozložíme na~potřebnou mřížku dle~rozlišení a~modifikujeme UV~prostor výstupního obrazu.
\item Námraza - obraz interpolujeme s~animavanou texturou. Nejlépe použít nějaký gradient uprostřed jako~masku průhlednosti, aby~hráč měl čistší vidění.
\item Tužka a~papír - výstupní obraz nahradíme texturou ambient occlusion.
\end{itemize}
\item Tavení pixelů - vytvoříme netriviální vertikální gradient s~více přechody. Výsledek poškodíme zaokrouhlováním a~násobením dat, zpixelizujeme vzorkováním na~mřížku a~výsledek použijeme k~modifikaci UV~prostoru výstupního obrazu a~barevné korekci.
\item Déšť - obraz rozložíme na~jemnou mřížku a~v~blocích vygenerujeme různé kapky pomocí složení dvou turbulencí, každá~z~nich bude mít animovanou lehce odlišnou rychlost posunu, aby~kapky nebyly stále stejné. Paralelně k~tomu znovu rozložíme obraz, ale~teď na~hrubou mřížku, kde~animujeme svislé pády bloků s~gradientním ocasem. Oba~výstupy složíme~tak, že~hrubá mřížka představuje animovanou masku průhlednosti, která~nám bude v~různý okamžik otevírat pouze některé kapky. Nakonec přidáme trochu distortion a~výsledek použijeme jako modifikátor UV~výstupního obrazu.
\end{enumerate}
\subsection{Materiály a shadery}
Přestože materiály jsou omezené shadery, stále lze pomocí nich definovat mnoho různých a~komplexních grafických funkcí. Základem jsou jednoduché barevné výstupy s~triviálními parametry lesku, matnosti a~emise. Může záležet na druhu objektu, pro~který~materiály tvoříme, tedy~potřebujeme správně nastavit i~druh materiálu, čímž~následně dostaneme další, předtím uzavřené, výstupy a~vstupy. Například za~účelem optimalizace, můžeme přepnout materiál ze~základního režimu osvětlení neboli~Default~Lit do~neosvětleného režimu Unlit, čímž~budeme moci definovat barvu objektu pouze emisní složkou, ale~zmenšíme vykreslovací čas potřebný pro~materiál.
Materiál v~UE je high-level programovátelný objekt popisující vizuální reprezentaci povrchu objektu. Materiál se~programuje pomocí odpovídajících Blueprintů, které~engine převede nejdřív do~HLSL a~potom kompiluje jako~fragment/pixel a~vertex shader.
V~UE materiály resp.~shadery mají mnoho globálních proměnných, z~kterých můžeme získat cenné údaje o~enginu, scéně, vykreslovaném objektu, render buffrech atd. Dokonce můžeme definovat vlastní globální nebo~lokální parametry a~měnit jejich hodnoty v~logice světa. Použití takových proměnných lze často vidět v~již~zmíněných post-procesech, které~přebírají a~modifikují hodnoty výstupního zobrazení nebo~jsou animované pomocí sinusové funkce s~globálním parametrem herního času jako~vstup.
Přestože materiály jsou omezené shadery, stále lze pomocí nich definovat mnoho různých a~komplexních grafických funkcí. Základem jsou jednoduché barevné výstupy s~triviálními parametry lesku, matnosti a~emise. Může záležet na druhu objektu, pro~který~materiály tvoříme, tedy~potřebujeme správně nastavit i~druh materiálu, čímž~následně dostaneme další, předtím uzavřené, výstupy a~vstupy. Například za~účelem optimalizace můžeme přepnout materiál ze~základního režimu osvětlení neboli~Default~Lit do~neosvětleného režimu Unlit, čímž~budeme moci definovat barvu objektu pouze emisní složkou, ale~zmenšíme vykreslovací čas potřebný pro~materiál.
Stojí~za~to zmínit, že~některé materiály se~hodí pouze na~určitý druh objektů podle velikostí a~umístění ve~světě. Jedním z~příkladu v~této hře je materiál skla. Původně navržený shader, který~simuluje zalamování a~vnitřní objem, skvěle funguje na~drobných objektech jako lahve nebo~skleněné střepy. Při~použití na~velkých skleněných plochách jako~jsou~okna, takové simulace vytváří nežádané artefakty. Pro takové situace byl přidán duplicitní shader skla, který~primárně vykresluje poloprůhlednou barvu na~povrchu objektu.
V~UE materiály resp.~shadery mají mnoho globálních(uniform) proměnných, z~kterých můžeme získat cenné údaje o~enginu, scéně, vykreslovaném objektu, render buffrech atd. Dokonce můžeme definovat vlastní globální nebo~lokální parametry a~měnit jejich hodnoty v~logice světa. Použití takových proměnných lze často vidět v~již~zmíněných post-procesech, které~přebírají a~modifikují hodnoty výstupního zobrazení nebo~jsou animované pomocí sinusové funkce s~globálním parametrem herního času jako~vstup.
Stojí~za~to zmínit, že~některé materiály se~hodí pouze na~určitý druh objektů podle velikosti a~umístění ve~světě. Jedním z~příkladů v~této hře je materiál skla. Původně navržený shader, který~simuluje zalamování a~vnitřní objem, skvěle funguje na~drobných objektech jako lahve nebo~skleněné střepy. Při~použití na~velkých skleněných plochách jako~jsou~okna, takové simulace vytváří nežádané artefakty. Pro takové situace byl přidán duplicitní shader skla, který~primárně vykresluje poloprůhlednou barvu na~povrchu objektu.
\paragraph{Funkce} V~materiálech se~lze zbavit duplicitního kódu, čímž~se~zároveň zrychlí kompilace a~běh shader variací. Implementoval~jsem funkce:
\begin{itemize}
\item Škálování vstupné hodnoty podle vzdálenosti objektu od~kamery.
\item Škálování vstupní hodnoty podle vzdálenosti objektu od~kamery.
\item Uniformní škálování a~tiling textury nezávislé na~velikosti objektu.
\item Získání obrysů objektů v~podobě masky.
\item Rotace objektu ve~směru kamery.
\end{itemize}
\subsection{UI}
Před~Unreal~Engine~5 téměř každé~UI byl rastrový a~v~minulosti to~ani~nebyl problém. Stačilo vytvořit mip-mapy pro~menší množinu nejrozšířenějších rozlišení (HD, WSXGA a~Full~HD) a~k~tomu škálovat mip~texturu menšího rozlišení na~potřebný lehce větší výstup. Předtím hry nevypadaly zaostřeně takže nemuselo ani~UI a~dokonce to~rozostření rastrového obrazu nebylo tak~viditelné na~displejích menší velikosti v~té~době. Dnes rastrové~UI vytváří příliš komplikací při~tvorbě a~vykreslování. Je potřeba mnoho mip-map ve~velkých rozlišeních pro~ostrý obraz na~každém displeji, což~vyžadují velké množství paměti a~hlavně velkou propustnost při~čtení dat, což~se~nejvíc projevuje u~rastrových animací.
\subsection{Uživatelské rozhraní}
Uživatelské rozhraní neboli UI je sada 2D~prvků vykreslených na~vyrenderováný obraz 3D~scény. Běžně se~jedná o~menu, titulky nebo~popisky ovládání. Před~Unreal~Engine~5 téměř každé~UI byl rastrový obrázek a~v~minulosti to~ani~nebyl problém. Stačilo vytvořit mip-mapy pro~menší množinu nejrozšířenějších rozlišení (HD, WSXGA a~Full~HD) a~k~tomu škálovat mip~texturu menšího rozlišení na~potřebný lehce větší výstup. Předtím hry nevypadaly zaostřeně takže nemuselo ani~UI a~dokonce to~rozostření rastrového obrazu nebylo tak~viditelné na~displejích menší velikosti v~té~době. Dnes rastrové~UI vytváří příliš komplikací při~tvorbě a~vykreslování. Je potřeba mnoho mip-map ve~velkých rozlišeních pro~ostrý obraz na~každém displeji, které~vyžadují velké množství paměti a~hlavně velkou propustnost při~čtení dat, což~se~nejvíc projevuje u~rastrových animací.
Jelikož původní projekt vznikal ve~čtvrté verzi enginu, ale~v~době již~velkých rozlišení, nebylo realistické pro~dva vývojáře vypracovat přijatelné rastrové~UI. Proto jsem tehdy a~teď vytvořil všechny prvky pomocí černobílých poloprůhledných vektorových čtverců s~transformacemi. Rastrové textury se~používají pouze v~podobě masek nebo gradientů, při~použití~kterých nejsou zřejmé škalovací artefakty.
@ -375,7 +381,7 @@ Každý prvek se~instancuje na~začátku a~udržuje~se v~paměti po~celou dobu.
\end{itemize}
Engine při~instancování určitého FText nebo~FString se~snaží najít již~existující instanci v~paměti, čímž~se~výrazně redukuje duplicita dat zejména v~blueprintech.
Při~tvorbě projektu jsem~si~dal záležet, aby~veškerý text viditelný hráčem byl překladatelný. Zároveň jsem dbal na~zachování unikátností řetězců, aby~se~v~tabulce překladů nevyskytovaly duplicitní záznamy.
Při~tvorbě projektu jsem~si~dal záležet, aby~veškerý text viditelný hráčem byl překladatelný. Zároveň jsem dbal na~zachování unikátností řetězců, aby~se~v~tabulce překladů nevyskytovaly duplicitní záznamy. Engine pochopitelně takové záznamy nemůže eliminovat sám a~ani to~nechceme, protože~každá stejná slova v~jednom jazyce, mohou~být již různá v~jiném jazyce v~závisloti na~gramatice a~kontextu.
\paragraph{Načítací obrazovka} Načítací obrazovka je povinná z~důvodů licenčních podmínek některých knihoven a~programů. Zejména Unreal~Engine a~FMOD vyžadují, aby~produkt obsahoval načítací obrazovku s~logem jejich softwaru. Tato~zdánlivě triviální problematika ve~skutečnosti zahrnuje netriviální množství časové investice a~rozboru startovací sekvence enginu, což~vyúsťuje v~nekompetentní řešení začínajících i~pokročilých vývojářů. Přesně se~jedná~o:
\begin{itemize}
@ -384,9 +390,9 @@ Při~tvorbě projektu jsem~si~dal záležet, aby~veškerý text viditelný hrá
\end{itemize}
Ve~své práci pro~mě bylo zásadní vytvářet věci technicky správně a~tedy vyhýbat~se programátorským workaroundům nebo~technickému ``lhaní'' hráči. Proto~jsem~si~dal záležet i~na~správném provedení načítací obrazovky.
Postup tvorby načítací obrazovky vývojáři enginu nedokumentují a~běžně dostupné návody třetích stran jsou již zmíněné nekvalitní simulace. Dokázal jsem najít pár funkčních ukázek u~kolegů z~Číny, které~mi~umožnily se~zorientovat v~základech a~následně provést reverse engineering celé problematiky. K~mému překvapení jedná~se o~důkladně propracovaný systém, který~je podrobně přizpůsoben specifikům různých platforem.
Postup tvorby načítací obrazovky vývojáři enginu nedokumentují a~běžně dostupné návody třetích stran jsou již zmíněné nekvalitní simulace. Dokázal jsem najít pár funkčních ukázek u~kolegů z~Číny\Cite{chinaLoadingScreen} a~Japonska\Cite{japanLoadingScreen}, které~mi~umožnily se~zorientovat v~základech a~následně provést reverse engineering celé problematiky. K~mému překvapení jedná~se o~důkladně propracovaný systém, který~je podrobně přizpůsoben specifikům různých platforem.
Engine při~načítaní nepodporuje UI vytvořený v~blueprintech, jelikož blueprinty jsou assety s~hlubokou reflexí, kterou~engine již~načítá (po~načtení již~lze zobrazit blueprint načítací obrazovky mezi úrovněmi). Proto~jsem~musel vytvořit navíc UI~v~nízkoúrovňovém Slate.
Engine při~načítaní nepodporuje UI vytvořený v~blueprintech, jelikož blueprinty jsou assety s~hlubokou reflexí, kterou~engine teprve~načítá (po~načtení již~lze zobrazit blueprint načítací obrazovky mezi úrovněmi). Proto~jsem~musel vytvořit navíc UI~v~nízkoúrovňovém Slate.
\section{Audio}
\label{sec:audio}
@ -399,33 +405,33 @@ V~tomto projektu jsem~se~zaměřil primárně na~zprovoznění všech technologi
\end{itemize}
\newpage
Optimalizace audia nebyla mezi cíle této práce, avšak~základní systematická pravidla byla určena.
Optimalizace audia nepatřila mezi cíle této práce, avšak~základní systematická pravidla byla určena.
\begin{itemize}
\item Použít streaming a~kompresi dat kdekoliv to~bude možné,
\item hudební doprovod je~ve~formátu~MP3,
\item hlasy a~jiné zvuky jsou~ve~formátu~WAV.
\end{itemize}
V~budoucnu by~také pomohlo zabalit všechny hlasy a~jiné audio do~samostatných datových balíčků neboli~chunků. Aktuálně všechny herní assety jsou automaticky zabalené do~pár ucelených balíčků, což~může vyvolat sice drobné zpomalení načtení assetů, ale~stále kriticky ovlivnit audio zážitek.
V~budoucnu by~také pomohlo zabalit všechny hlasy a~jiné audio do~samostatných datových balíčků neboli~chunků. Aktuálně všechny herní assety jsou automaticky zabalené do~pár ucelených balíčků, což~sice může vyvolat drobné zpomalení načtení assetů, ale~stále zásadně ovlivnit audio zážitek. Tomu~tak~je, protože uši jsou mnohem ``časově citlivější" než~oči. Zatímco pro~vnímání plynulosti obrazu často stačí vyšší desítky snímků za~sekundu\Cite{videoSampling}, pro~zachycení všech slyšitelných zvukových frekvencí je potřeba nad~40~tisíc vzorků za~sekundu\Cite{audioSampling}. Navíc i~drobné záseky nebo~vypadnutí několika vzorků jsou snadno slyšet.
\subsection{Dynamický hudební doprovod}
Když~mluvíme o~dynamickém doprovodu ve~hrách, často myslíme právě~dynamické přepínání částí skladby v~závislosti na~proměnných světa. Pří~vývoji jsem se~uchýlil k~použití zvukového enginu~FMOD (viz~\Cref{prg:fmod}) a~hudbu jsem skládal sám bez~použití samplů, tedy~pomocí~VST (Virtual~Studio~Technology) hudebních nástrojů. Častí hotových kompozic za~účelem dynamiky by~měly~být nerušivě zacyklené, na~což~jsem kladl největší důraz. Bohužel kvůli~omezenému času jsem~nemohl věnovat dostatečnou pozornost rozmanitosti a~komplexitě hudebních kompozic. Prototypy dynamického doprovodu lze již~zaslechnout v~průběhu třetí úrovně.
Když~mluvíme o~dynamickém doprovodu ve~hrách, často myslíme právě~dynamické přepínání částí skladby v~závislosti na~proměnných světa. Pří~vývoji jsem se~uchýlil k~použití zvukového enginu~FMOD (viz~\Cref{prg:fmod}) a~hudbu jsem skládal sám bez~použití samplů, tedy~pomocí~VST (Virtual~Studio~Technology) hudebních nástrojů. Častí hotových kompozic za~účelem dynamiky by~měly~být nerušivě zacyklené, na~což~jsem kladl největší důraz. Bohužel kvůli~omezenému času jsem~nemohl věnovat dostatečnou pozornost rozmanitosti a~komplexitě hudebních kompozic. Prototypy dynamického doprovodu lze již~zaslechnout v~průběhu třetí úrovně, tedy postupné vrstvení zvukových stop při~propojování kabelů a~adaptivní hudební progrese napříč částmi bludiště.
\subsection{Dabing dialogů}
Jelikož hra by~měla poskytnout prostor pro~AI generovaný obsah, dialogy jsou již~nadabované pomocí~AI. Původně jsem začínal s~python knihovnou Coque~TTS\footnote{https://github.com/coqui-ai/TTS}, ale~dosáhnout v~ní aspoň dobrých výsledků bylo náročné. Proto~jsem~přešel na~knihovnu a~model Zonos\footnote{https://github.com/Zyphra/Zonos}, který~již v~základu poskytuje vynikající výsledky a~navíc má~prostředky pro~udržování kontextu nebo~parametry zabarvení hlasu.
Jelikož hra by~měla poskytnout prostor pro~AI generovaný obsah, dialogy jsou již~nadabované pomocí~AI. Původně jsem začínal s~Python knihovnou Coque~TTS\footnote{https://github.com/coqui-ai/TTS}, ale~dosáhnout v~ní aspoň dobrých výsledků bylo náročné. Proto~jsem~přešel na~knihovnu a~model Zonos\footnote{https://github.com/Zyphra/Zonos}, který~již v~základu poskytuje vynikající výsledky a~navíc má~prostředky pro~udržování kontextu nebo~parametry zabarvení hlasu.
V~modulu VoiceGenerator v~repozitáři hry je~k~dispozici skript pro~jednoduchou instalaci prostředí. Z~časových důvodů jsem~nestihl vytvořit skript, který~by jednoduše generoval množiny resp.~sekvence dialogů přímo z~jednoho textového souboru. Aktuálně je~potřeba ručně generovat každou větu jednotlivě přes~webové rozhraní, které~je~součástí knihovny.
V~modulu VoiceGenerator v~repozitáři hry je~k~dispozici skript pro~jednoduchou instalaci prostředí. Z~časových důvodů jsem~nestihl vytvořit skript, který~by jednoduše generoval množiny resp.~sekvence dialogů přímo z~jednoho textového souboru. Aktuálně je~potřeba ručně generovat každou větu jednotlivě přes~webové rozhraní, které~je~součástí knihovny, ale~naprogramovat klienta, který~bude pro~každou textovou linku volat stejné generující~API a~ukládat výsledky, by~nemělo~být složité.
Ukázkové dialogy lze již~zaslechnout v~průběhu třetí úrovně. Původně jsem~taky~plánoval vytvořit robotický hlas ve~třetí úrovni pomocí modifikace základního hlasu v~novém pro~UE5 zvukovém systému MetaSound. Ten~dokáže komplexně modifikovat zvukový signál za~běhu, ale~na~začlenění takové technologie do~hry nezbýval čas.
\newpage
\section{Co se~nestihlo nebo~změnilo}
Přestože do~práce jsem~vložil mnoho času a~úsilí, nepodařilo se~mi splnit všechny mnou stanovené cíle. Místo herního dema, práce představuje spíš demo technické, neboli~jsem~úspěšně vytvořil technické zázemí, ale~nestihl naplnít hru obsahem. Třetí úroveň nějakým obsahem disponuje a~dohromady lze tuto úroveň považovat za~hru. Jinak~všechny úrovně resp.~celá hra trpí nedostatkem nebo~neobsahuje vůbec:
Přestože do~práce jsem~vložil mnoho času a~úsilí, nepodařilo se~mi splnit všechny mnou stanovené cíle. Místo herního dema práce představuje spíš demo technické, neboli~jsem~úspěšně vytvořil technické zázemí, ale~nestihl naplnít hru obsahem. Třetí úroveň nějakým obsahem disponuje a~dohromady lze tuto úroveň považovat za~hru. Jinak~všechny úrovně resp.~celá hra trpí nedostatkem nebo~neobsahuje vůbec:
\begin{itemize}
\item Grafické prvky jako~animace postav, efekty, 3D modely.
\item Zvukové prvky jako~hudební doprovod, zvuky~interakce se~světem a~UI.
\item Příběhové dialogy, cutscény a~dokončený level design.
\item Balancování herních mechanik a~doladění ovládání.
\item grafické prvky jako~animace postav, efekty, 3D modely,
\item zvukové prvky jako~hudební doprovod, zvuky~interakce se~světem a~UI,
\item příběhové dialogy, cutscény a~dokončený level design,
\item balancování herních mechanik a~doladění ovládání.
\end{itemize}
Nepodařilo~se~mi vytvořit poslední pátou úroveň z~časových důvodů. Zároveň jsem~se~rozhodl změnit žánr této úrovně z~first-person shooter na~top-down shooter. Důvodem změny posloužila analýza náročnosti tvorby obsahu pro~takový žánr. Přestože~first-person shooter se~může zdát jako~jednoduchý koncept, ve~skutečnosti pro~hezký herní zážitek je~potřeba vložit mnoho úsilí a~času. Pro~tento~žánr je~nutné pečlivě odladit všechny prvky hry a~hlavně animace, které~jsou má slabá stránka. Na~druhou stranu top-down shooter neklade tak~vysoké nároky a~dokonce umožňuje skrytí od~hráče nedostačující animace.
\subsection{Obsah mimo hru}
Projekt není~tvořen pouze technickým demem hry, ale~také zahrnuje nasazení a~údržbu sítě s~veřejnou ip~adresou, webového a~git serveru. Postupy nasazení a~údržby z~důvodu zaměření práce nejsou zveřejněny.
Projekt není~tvořen pouze technickým demo hry, ale~také zahrnuje nasazení a~údržbu sítě s~veřejnou ip~adresou, webového a~Git\footnote{https://git-scm.com/} serveru. Postupy nasazení a~údržby vzhledem k~zaměření práce nejsou zveřejněny. Zvolil jsem údržbu vlastní sítě a~zařízení převážně z~finančních důvodů. Vlastní Git server je zapotřebí z~důvodu nadstandardní velikosti repozitáře, kterou~veřejné platformy jako~GitHub\footnote{https://github.com/} a~Gitlab\footnote{https://about.gitlab.com/} již~zpoplatňují. Webový server slouží jako~rozhraní pro~poskytování assetů hráči v~podobě běžné indexovací složky se~soubory, kterou~poskytujé základní implementace serveru Nginx\footnote{https://nginx.org/}.

Binary file not shown.

View File

@ -1,12 +1,12 @@
\chapwithtoc{Úvod}
Běžně příběhové hry jsou navrhnuté předem a~zůstávají neměnné. Existují ale~i~výjimky, například hry žánru rogue-like, kde~ale~stále generování obsahu je~založeno na~použití speciálně vytvořeného a~odladěného algoritmu. Tento algoritmus různé složitosti stále používá pouze prostředky předem navržené a~odladěné vývojáři. To~vše má podstatný důvod, jelikož vývojáři mají za~úkol vytvořit tzv.~dobrý herní zážitek a~zaručit, že~hra bude umělecky správně interpretovaná hráčem. Bohužel, nezávísle na~kvalitě výsledné hry -- počet opakovaného zahrání hry v~nejlepším případě klesá nebo~v~tom horším je~pouze jeden.
Běžně příběhové hry jsou navrhnuté předem a~zůstávají neměnné. Existují ale~i~výjimky, například hry žánru rogue-like, kde~je generování obsahu stále založeno na~použití speciálně vytvořeného a~odladěného algoritmu. Tento algoritmus různé složitosti stále používá pouze prostředky předem navržené a~odladěné vývojáři. To~vše má podstatný důvod, jelikož vývojáři mají za~úkol vytvořit tzv.~dobrý herní zážitek a~zaručit, že~hra bude umělecky správně interpretovaná hráčem. Bohužel, nezávisle na~kvalitě výsledné hry -- počet opakovaného zahrání hry v~nejlepším případě klesá nebo~v~tom horším je~pouze jeden.
Celý problém v~branži příběhových her je~řešen tzv.~mody neboli modifikacemi hry a~to~různých druhů, jako například grafické, kódové a~další. Samotní vývojáři poskytují potřebné prostředky pro~podporu nebo~tvorbu modů. Dokonce i~technicky zdatní hráči dokážou oblíbené hry úpravit, aby~ony jakousi podporu měly. V~každém případě modifikace značně zvětšují počet přehrání her, kde~klasickým příkladem je~hra The Elder Scrolls: Skyrim od~studia Bethesda.
Celý problém v~branži příběhových her je~řešen tzv.~mody neboli modifikacemi hry a~to~různých druhů, jako například grafické, kódové a~další. Samotní vývojáři poskytují potřebné prostředky pro~podporu nebo~tvorbu modů. Dokonce i~technicky zdatní hráči dokážou oblíbené hry úpravit, aby~ony jakousi podporu měly. V~každém případě modifikace značně zvětšují počet znovuzahrání hry, kde~klasickým příkladem je~hra The Elder Scrolls: Skyrim od~studia Bethesda.
Přestože celé řešení zdánlivě funguje, spoléhá~se na~ochotu samotných hráčů módy vytvářet. Jestliže hra nebude mít dostatek hráčů, potom~taktéž nebude mít dostatek nového fanouškovského obsahu a~výsledně počet přehrání neroste. Nedavným příkladem je~hra Starfield od~již zmíněného studia Bethesda. Navíc k~mnoha technickým omezením samotných módů, musí~mít hráči nejen ochotu, ale~i~být technicky a~umělecky zdatní, aby~něco vytvořili. Minimálně musí vynaložit úsilí k~manuálnímu vyhledání, stažení a~instalaci modů.
Přestože celé řešení zdánlivě funguje, spoléhá~se na~ochotu samotných hráčů mody vytvářet. Jestliže hra nebude mít dostatek hráčů, potom~taktéž nebude mít dostatek nového fanouškovského obsahu a~výsledně počet znovuzahrání neroste. Nedavným příkladem je~hra Starfield od~již zmíněného studia Bethesda. Navíc k~mnoha technickým omezením samotných modů, musí~mít hráči nejen ochotu, ale~i~být technicky a~umělecky zdatní, aby~něco vytvořili. Minimálně musí vynaložit úsilí k~manuálnímu vyhledání, stažení a~instalaci modů.
Tato práce se~zaměřuje na~tvorbu hry a~návrh systému který~umožní výše popsaný lidský faktor a~nedostatky eliminovat. Přináší tak příběh rozdělený na~pět žánrově odlišných úrovní a~zavádí high-level API pro~Unreal~Engine na~stahování a~načítání obsahu do~hry přímo za~běhu. Specifický příběh snižuje ludonarativní disonanci\footnote{Souvislost resp.~logické propojení herního světa, příběhu a~gameplaye.} při vzníku nového obsahu ve~hře a~přítomnost více žánrů umožňuje otestovat, jestli toto řešení v~každém z~nich dostatečně funguje. Zároveň tato práce přenechává samotné generování obsahu pomoci AI modelů a~testování výsledků až~jako další rozšíření. Čili primárně se~zaměřuje na~kostru samotné hry, aby~spotom byl prostor, kam nový obsah začlenit.
Tato práce se~zaměřuje na~tvorbu hry a~návrh systému, který~umožní výše popsaný lidský faktor a~nedostatky eliminovat. Přináší tak příběh rozdělený na~pět žánrově odlišných úrovní a~zavádí high-level API pro~Unreal~Engine na~stahování a~načítání obsahu do~hry přímo za~běhu. Specifický příběh snižuje ludonarativní disonanci\footnote{Souvislost resp.~logické propojení herního světa, příběhu a~gameplaye.} při vzniku nového obsahu ve~hře a~přítomnost více žánrů umožňuje otestovat, jestli toto řešení v~každém z~nich dostatečně funguje. Zároveň tato práce přenechává samotné generování obsahu pomocí AI modelů a~testování výsledků až~jako další rozšíření. Čili primárně se~zaměřuje na~kostru samotné hry, aby~potom byl prostor, kam nový obsah začlenit.
\pagebreak
Hlavní témata na~které se~práce zaměřuje:

View File

@ -55,3 +55,31 @@
year = 2024,
note = {[cit. 2025-07-01]. Dostupné z: \url{https://forums.unrealengine.com/t/fab-review-disaster-for-customers-and-sellers/2092291}}
}
@misc{chinaLoadingScreen,
title = {PreLoadScreen and LoadingScreen in Unreal Engine 4 (Translated)},
author = {AGuner58 (Translated)},
year = 2023,
note = {[cit. 2025-07-01]. Dostupné z: \url{https://zhuanlan.zhihu.com/p/608502007}}
}
@misc{japanLoadingScreen,
title = {[UE4] Display an image immediately after launching the app using EarlyStartupScreen (Translated)},
author = {Ogura (Translated)},
year = 2021,
note = {[cit. 2025-07-01]. Dostupné z: \url{https://historia.co.jp/archives/19862/}}
}
@misc{videoSampling,
title = {How to Use Frame Rates in Your Videos},
author = {Daniela Bowker},
year = 2024,
note = {[cit. 2025-07-01]. Dostupné z: \url{https://artlist.io/blog/how-to-use-frame-rates/}}
}
@misc{audioSampling,
title = {Digital audio basics: audio sample rate and bit depth},
author = {Ian Stewart},
year = 2024,
note = {[cit. 2025-07-01]. Dostupné z: \url{https://www.izotope.com/en/learn/digital-audio-basics-sample-rate-and-bit-depth}}
}

View File

@ -132,6 +132,7 @@
\include{ch3}
\include{conclusion}
\include{bibliography}
\listoffigures
\appendix
\include{howto}

View File

@ -1,7 +1,7 @@
% Metadata to be stored in PDF, see documentation of the pdfx package for more details.
\Author{Oleg Petruny}
\Title{Multi-genre game with support for loading new content in real-time}
\Keywords{Computer game\sep Unreal Engine\sep dynamic content loading\sep 3D graphics}
\Title{Vícežánrová příběhová počítačová hra s podporou načítání nového obsahu za běhu}
\Keywords{Počítačová hra\sep Unreal Engine\sep dynamické načítání obsahu\sep 3D grafika}
\Subject{Abstract of thesis}
\Publisher{Charles University}