B4B39HRY Webové stránky předmětu

• Komponenty herního enginu, herní smyčka – přehled komponent herního enginu a jejich funkce. Herní smyčka a její varianty, fixní a proměnlivý simulační krok (využití a způsob realizace), souvislost reálného a herního času. Vazba komponent herního enginu na herní smyčku. Zpracování dlouhých procedur. Synchronizace fyzikální simulace a zobrazování.
• Detekce kolizí a základy herní fyziky – motivace, princip, využití. Typy kolizních objektů, algoritmy pro detekci kolizí jednoduchých objektů (koule, AABB, OBB), teorém separačních rovin (SAT), princip algoritmu GJK. Fáze detekce kolizí, filtrování kolizí, akcelerace pomocí mřížky a hierarchie obalových těles. Kolizní dotazy a jejich varianty, reprezentace kolize. Smyčka fyzikální simulace. Analytické řešení pohybové rovnice, řešení numerickou integrací, Eulerova metoda, příklady. Typy vazeb mezi objekty a jejich využití. Výpočet reakce na kolize a fyzikální materiály.
• Reprezentace a výpočet animací – typy animací a jejich využití. Podrobný popis skeletální animace, reprezentace kostry. Animační klipy – vytváření, reprezentace, výpočet animované kostry. Míchání animačních klipů – způsob výpočtu a příklady. Skinning – způsob výpočtu pozic vrcholů metodou linear blend skinning. Animační křivky – princip, využití, Hermitova kubika, Catmull-Rom spline.
• Základní optimalizační metody pro herní engine – dopředné a odložené vykreslování, princip, srovnání. Optimalizace scény pomocí LOD, typy LOD a způsob jejich přepínání. Předpočítání osvětlení pomocí osvětlovacích map a sond odrazu – princip, způsob použití, omezení. Redukování podle viditelnosti: redukování pohledovým jehlanem, redukování podle zastínění (online a offline), potenciálně viditelné množiny (PVS) – výpočet a použití.

Herní engine je komplexní softwarová platforma, která poskytuje základní strukturu pro vývoj her. Nabízí framework, který umožňuje efektivní práci s jednotlivými částmi hry bez nutnosti tvořit vše od nuly. Obsahuje jak core systémy, tak nástroje pro práci s daty a prostředky (assets), a často také podporuje multiplatformní vývoj a integraci třetích stran (např. middleware, SDK).

• AI (Artificial Intelligence) – zajišťuje chování nehráčských postav (NPC), zahrnuje pathfinding (např. A* algoritmus), rozhodovací stromy, stavové automaty či plánování akcí. AI komponenta může být jednoduchá (reakce na hráče) nebo velmi složitá (taktické plánování).
• Fyzika – simuluje reálné i stylizované fyzikální jevy. Obsahuje systémy pro detekci a řešení kolizí, gravitaci, pohybové rovnice, síly, impulsy nebo vazby mezi objekty. Některé enginy využívají externí fyzikální knihovny jako NVIDIA PhysX nebo Havok.
• Rendering – stará se o vizuální výstup hry, tedy vykreslování 2D/3D grafiky. Řeší transformace objektů do obrazového prostoru, stínování, světla, efekty (např. bloom, motion blur), částečně také optimalizace jako LOD nebo culling. Rozlišujeme různé přístupy: dopředné a odložené vykreslování.
• Zvuk (Audio) – spravuje zvukové stopy, hudbu, efekty i prostorový zvuk. Zahrnuje přehrávání, slučování stop, mixování, zpoždění a útlum podle vzdálenosti. V některých případech i generování zvuků v reálném čase.
• UI / HID (Human Interface Device) – zpracovává vstupy od uživatele jako myš, klávesnice, gamepad, joystick nebo dotykové obrazovky. Obsahuje také systém pro zobrazování a správu uživatelského rozhraní – tlačítka, menu, HUD apod.
• Scripting – umožňuje dynamicky upravovat logiku hry bez nutnosti překladu hlavního kódu. Nejčastěji používá skriptovací jazyky jako Lua, Python nebo vlastní jazyky enginu. Pomocí skriptů se definuje chování objektů, animace, UI události, nebo řízení scén.
• Síť (Networking) – komponenta zajišťující síťovou komunikaci, klient-server synchronizaci, replikaci objektů, detekci lagů, a často i zabezpečení (např. anti-cheat systémy). V moderních hrách je klíčová zejména pro multiplayer.

• Jádro – Scéna / Data (Core Systems) – spravuje základní strukturu hry: herní smyčku, správu paměti, přístup k souborům, správu scén, serializaci a správu objektů ve scéně. Je to centrální komponenta, na kterou jsou napojeny všechny ostatní.
• Resources (Assets Management) – komponenta pro načítání, správu a ukládání herních prostředků: textury, modely, zvuky, animace. Umožňuje efektivní využití paměti (např. streamování obsahu), často i konverzi mezi formáty.
• 3rd Party SDKs a Middleware – nástroje třetích stran integrované do enginu (např. fyzika, zvuk, analýza výkonu, monetizace, in-app nákupy). Umožňují rychlejší vývoj a využití již hotových řešení.
• Platform Abstraction Layer – vrstva zajišťující kompatibilitu mezi různými operačními systémy a zařízeními. Vývojář se nemusí starat o specifika Androidu, iOS, Windows atd. – engine vše sjednocuje.

Herní smyčka představuje jádro řízení běhu hry – zajišťuje zpracování vstupů, aktualizaci herního světa a vykreslení obrazu. Tento cyklus probíhá opakovaně po celou dobu běhu hry, často desítky až stovky krát za sekundu (FPS).

Základní struktura smyčky zahrnuje:

• ProcessInput – zpracování vstupu od hráče nebo zařízení (klávesnice, myš, gamepad).
• UpdateGame – aktualizace stavu herního světa. Patří sem herní logika, animace, detekce kolizí, fyzikální simulace, AI nebo zvuk.
• Render – vykreslení scény na základě aktualizovaných dat (kamerová pozice, viditelné objekty apod.).

Smyčka typicky běží nezávisle na hráči – tedy i v případě, že hráč nedává žádné vstupy, se svět aktualizuje dál (např. pohyb NPC, efekty prostředí).

Herní smyčka může být řízena různými způsoby podle toho, jak zachází s časem:

• Fixní simulační krok (Fixed timestep) – každý krok simuluje konstantní časový úsek \( \Delta t_{\text{FIX}} \). Tato metoda zajišťuje stabilní a deterministické chování fyziky, AI nebo animací, ale může způsobovat zpoždění, pokud aktualizace nestíhá. V takovém případě může engine provést více kroků UpdateGame za jeden krok Render.
• Proměnlivý simulační krok (Variable timestep) – každé UpdateGame používá reálný časový rozdíl od předchozího kroku. Odezva je rychlejší a přirozenější, ale simulace může být méně stabilní. Je nutné vztáhnout výpočty (např. síly) na uplynulý čas, jinak dojde k rozdílům mezi zařízeními.
• Kombinovaný přístup – proměnlivý krok pro většinu aktualizací, ale fyzika běží v pravidelném fixním intervalu. Používá např. Unity (FixedUpdate vs. Update).

Tato struktura se dá doplnit o další části, jako je LateUpdate pro úpravy po výpočtu kolizí nebo fyziky (např. nastavení kamery), nebo Coroutines, které umožňují rozdělení výpočtů do více snímků.

Ve hře se pracuje s několika druhy času:

• Reálný čas (wall-clock time) – čas měřený reálnými hodinami, např. pomocí `GetCurrentTime()`.
• Herní čas – logický čas hry, může být zpomalen, zastaven nebo zrychlen (např. bullet time).
• CPU / GPU čas – doba, kterou výpočet nebo rendering skutečně zabere (pro analýzu výkonu).

Nesoulad mezi časy (např. kvůli výkonu HW) může vést k nedeterministickému chování. Z tohoto důvodu je třeba správně volit simulační krok a synchronizaci.

Příklad problémů při různém FPS:

• Při vysokém FPS bude hra běžet „rychleji“, pokud není logika vázána na čas.
• Při nízkém FPS se mohou některé kolize „propadnout“ (bullet through paper problem).

Příkladem robustního přístupu je herní smyčka s akumulací času:

double previous = GetCurrentTime();
double lag = 0.0;
while (running) {
    double current = GetCurrentTime();
    double delta = current - previous;
    previous = current;
    lag += delta;
 
    ProcessInput();
    while (lag >= FIXED_STEP) {
        UpdateGame(FIXED_STEP);
        lag -= FIXED_STEP;
    }
    Render();
}

Synchronizace herního času s reálným časem zajistí konzistentní herní zážitek bez ohledu na výkon zařízení.

Jednotlivé komponenty enginu jsou propojeny s částmi smyčky:

• ProcessInput komunikuje s komponentou vstupu, UI, (Input manager).
• UpdateGame propojuje fyziku, AI, zvuk, skripty a síť (aktualizace objektů a chování).
• Render komunikuje s renderingovou částí enginu, (nastavení pohledu, světel, kamer).
• Případný LateUpdate (např. v Unity) využíván pro specifické úlohy jako aktualizace kamery nebo následné úpravy fyziky.

Interní komponenty jako fyzika, animace nebo zvuk jsou často aktualizovány automaticky v rámci hlavní smyčky, nebo pomocí událostí (např. OnCollision, OnRender, OnPreUpdate). V některých enginech je možné explicitně řídit pořadí aktualizací, např. pomocí ScriptExecutionOrder. Pokud dojde ke zpomalení v některé části (např. fyzika), může to ovlivnit celkový dojem ze hry – proto se používají paralelizace (vlákna), dělení na fáze a interpolace stavu.

V průběhu hry může dojít k operacím, které jsou výpočetně náročné a trvají déle než jeden snímek. Pokud by byly vykonány „naráz“, mohlo by to způsobit zpomalení hry, snížení FPS nebo dokonce zaseknutí aplikace. Proto je důležité tyto operace vhodně řídit a rozdělit.

• Threading (vícevláknové zpracování) – těžké úlohy (např. načítání dat ze souboru, síťová komunikace, výpočty AI) se přesunou do samostatného vlákna. Hlavní smyčka tak zůstává plynulá. Je třeba řešit synchronizaci (např. pomocí mutexů), aby se předešlo kolizím mezi vlákny.
• Rozdělení na menší části – dlouhá úloha se rozdělí na více menších částí, které se postupně vykonávají v jednotlivých snímcích. To umožní plynulé pokračování hry i při náročném výpočtu. Např. načtení velké scény může být rozděleno na: geometrie → textury → světla → AI.
• Loading screen (načítací obrazovka) – vizuální zástupce pro uživatele, který poskytuje čas na provedení dlouhých operací. Často doplněn o animace, tipy nebo indikátor průběhu.
• Coroutines (v enginu Unity a podobných) – speciální funkce, které lze přerušit a pokračovat později (např. `yield return new WaitForSeconds(1.0f)`). Používají se pro plánování dlouhých nebo zpožděných operací bez blokování hlavní smyčky. Např. animace zjevení předmětu v čase, opakované pokusy o připojení, krokové načítání světa.

Použitím těchto technik lze dosáhnout vyšší stability hry, lepší odezvy a komfortu pro hráče.

Simulace a zobrazení nemusí nutně probíhat ve stejném čase nebo frekvenci. V praxi to znamená, že mezi výpočtem polohy objektu a jeho vykreslením může uplynout čas – což vede k viditelným nesouladům, například k „cukání“ pohybu (stuttering) nebo k chybám v pozici.

• Interpolace – při vykreslování dopočítáme polohu objektu mezi dvěma známými simulovanými stavy. Například: pokud fyzika běží 30× za sekundu a rendering 60×, interpolujeme objekt mezi předchozí a aktuální pozici. Interpolace je vhodná, pokud renderujeme „napřed“ a máme k dispozici předchozí data.
• Extrapolace – předpovídáme budoucí stav objektu na základě jeho poslední známé pozice a rychlosti. Extrapolace se hodí v případě, že rendering předbíhá fyziku. Je však méně přesná – může vést ke zjevným chybám při náhlé změně směru.
• Zvýšení frekvence simulace – pokud fyzika běží např. 120× za sekundu, zatímco rendering 60×, rozdíl mezi aktualizacemi je menší a chybovost nižší. Tento přístup ale zvyšuje výpočetní náročnost.

Synchronizace je zásadní pro kvalitní vizuální výstup a konzistentní fyzikální interakce. Používá se také tzv. double buffering stavu, kdy si engine pamatuje dva poslední stavy pro interpolaci nebo porovnání. Správná implementace synchronizace má přímý vliv na hratelnost – zejména v rychlých akcích, závodních hrách nebo VR.

Fyzikální simulace ve hrách umožňuje realistické (nebo stylizované) chování objektů a prostředí – zajišťuje, aby se postavy, předměty nebo částice pohybovaly a reagovaly přirozeně. Využívá se nejen pro efekty a interakce, ale i jako součást samotné herní mechaniky.

Typické oblasti využití:

• Detekce kolizí – klíčová pro správné fungování pohybu, interakce s prostředím, AI nebo střelbu.
• Gravitace a síly – simulace pádu, výbuchů, odrazů a dalších fyzikálních jevů.
• Ragdoll animace – fyzikálně řízený pád postav místo předem nahrané animace.
• Interaktivní objekty – např. rozbití bedny, kutálející se koule, otevření dveří nárazem.
• Deformovatelné objekty a šaty – tkaniny, lano, měkké tělesa (cloth / soft bodies).
• Částicové a fluidní systémy – kouř, voda, magie.

Fyzikální simulace může být real-time (běží spolu s hrou), nebo předpočítaná (např. pro cutscény nebo animace). Je často nejnáročnější částí enginu, zejména ve hrách s komplexním prostředím a mnoha objekty.

Pro detekci kolizí se objekty neporovnávají pomocí celé své geometrie (ta může být velmi složitá), ale pomocí tzv. kolizních těles (colliders). Ty představují jednoduché geometrické útvary, které přibližně obalují objekt. Cílem je rychlý test kolize, případně i výpočet průniku nebo kontaktních sil. Výběr typu kolizního tělesa je kompromisem mezi přesností a výpočetní náročností:

• Koule (Sphere)
  • Definována středem a poloměrem.
  • Výpočet kolize je extrémně rychlý (porovnání vzdáleností).
  • Rotace objektu nemá vliv – rotace invariantní.
  • Nevýhoda: slabá přesnost, často „přetéká“ skutečný objekt.
  • Vhodné pro jednoduché předměty, efekty nebo do široké fáze detekce.
• AABB (Axis-Aligned Bounding Box)
  • Osově zarovnaný kvádr (osa souřadnic odpovídá krabici).
  • Snadná aktualizace, rychlý test průniku.
  • Trochu přesnější než koule, ale rotací objektu ztrácí přesnost (musí se přepočítat).
  • Vhodné pro statické objekty nebo jako zjednodušený obal.
• OBB (Oriented Bounding Box)
  • Natočený kvádr, kopíruje orientaci objektu.
  • Přesnější než AABB, ale kolize se řeší pomocí náročnějších algoritmů (např. SAT).
  • Výhodou je, že se dobře hodí k protáhlým objektům (např. loď).
  • Používá se v užší fázi detekce.
• k-DOP (Discrete Oriented Polytope)
  • Obalový mnohostěn tvořený „k“ rovinnými stranami.
  • Množinu stran definuje k/2 jednotkových normál (např. k=14, 18, 26).
  • Čím více stěn, tím přesnější (ale pomalejší) výpočet.
  • Např. k=6 odpovídá AABB.
  • Vhodné pro složitější tvary, ale stále rychlejší než konvexní obálky.
• Konvexní obálka (Convex Hull)
  • Nejpřesnější konvexní obal kolem objektu.
  • Výpočetně velmi náročné – používá se např. GJK algoritmus.
  • Výhodou je velmi přesná detekce bez potřeby plné geometrie.
  • Hodí se pro objekty, kde záleží na přesnosti (postavy, fyzicky simulované objekty).

Separating Axis Theorem (teorém separační osy) říká, že pokud existuje nějaká osa, na kterou lze objekty promítnout tak, že se jejich projekce neprotínají, pak tyto objekty nekolidují. Naopak: pokud na všech relevantních osách projekce překrývají, pak objekty pravděpodobně kolidují.

• Separační osa je definována jako normála mezi dvěma potenciálně kolidujícími plochami nebo hranami.
• Pro každý pár objektů se určí vhodná sada os, na které se oba objekty promítnou.
• Na každé ose se vytvoří 1D interval (projekce rozsahu objektu).
• Pokud existuje alespoň jedna osa, kde se tyto intervaly nepřekrývají, je kolize vyloučena.

Počet testovaných os závisí na typu objektů:

• AABB vs AABB – pouze 3 osy (osa X, Y, Z).
• k-DOP vs k-DOP – k/2 os (např. 7 pro k=14).
• OBB vs OBB – až 15 os: 3 hlavní osy z každého OBB a 9 kombinací jejich křížových součinů.

SAT je velmi efektivní pro kolizní testy mezi konvexními objekty, např. OBB nebo jednoduchými polygonálními útvary. Je oblíbený pro svoji srozumitelnost a přijatelný výkon i u složitějších scén.

GJK (Gilbert–Johnson–Keerthi) algoritmus je obecný a velmi výkonný algoritmus pro detekci kolize konvexních objektů v libovolném rozměru. Je založen na Minkowského rozdílu dvou objektů.

Minkowského rozdíl: \[ A \ominus B = \{ a - b \mid a \in A, b \in B \} \] Geometricky tento rozdíl zahrnuje všechny možné vektory z bodu B do bodu A. Pokud výsledný rozdíl obsahuje počátek souřadnic, znamená to, že se objekty A a B překrývají.

Princip GJK:

• Vytváří tzv. simplex (bod, hrana, trojúhelník, tetrahedron…) v prostoru Minkowského rozdílu.
• Tento simplex se iterativně rozšiřuje pomocí tzv. support funkce – hledá nový bod nejblíže směrem k počátku.
• Pokud simplex zahrnuje počátek, kolize nastala.
• Pokud nelze simplex směrem k počátku rozšířit, kolize nenastala.

GJK se výborně hodí i pro velmi komplikované kolizní objekty (např. konvexní obálky). Výhoda oproti SAT: nemusíme předem znát osy – ty se určují dynamicky během běhu algoritmu. Nevýhoda: složitější implementace, závislá na správném zpracování podporujících bodů.

Shrnutí:

• SAT: jednodušší a efektivní pro AABB/OBB, více os testovaných najednou.
• GJK: výkonný a obecný pro libovolné konvexní tvary, zvládá složitější případy.

Detekce kolizí probíhá ve více fázích, které postupně zužují množinu objektů, jež je třeba detailně testovat. To umožňuje udržet výpočty efektivní i ve složitých scénách.

Široká fáze se snaží rychle vyřadit objekty, které se zjevně nemohou dotýkat. Provádí hrubé testy mezi obalovými tělesy, často s využitím akceleračních struktur.

• Mřížka (Grid) – prostor je rozdělen na buňky; kolize se testují jen mezi objekty ve stejné nebo sousední buňce. Funguje dobře pro rovnoměrně rozložené objekty.
• Hierarchie obalových těles (Bounding Volume Hierarchy, BVH) – stromová struktura, kde vnitřní uzly představují obálky více objektů. Umožňuje logaritmické vyhledávání potenciálních kolizí.

Pomocí vrstev a kolizních masek určujeme, které objekty mohou kolidovat.

• Kolizní vrstvy a masky – určují, které objekty spolu mohou kolidovat (např. hráč vs. projektil, ale ne projektil vs. projektil).
• Kolizní materiály – přenášejí informace o tření, odrazu apod., a mohou se využít pro modifikaci reakce na kolizi.
• Callbacks – herní logika může zasáhnout a kolizi v určité situaci zrušit (např. nezranitelnost, duchové).

Přesná detekce kolizí vybraných dvojic objektů.

• Používají se konkrétní algoritmy jako SAT nebo GJK.
• Zjišťuje se: zda objekty kolidují, kde je kontaktní bod, jaká je normála kolize, případně hloubka průniku.
• Výpočetně nejnáročnější fáze – používá se pouze u opravdu nutných dvojic.

Kolizní dotazy slouží k aktivnímu zjišťování, zda a kde objekt koliduje s prostředím nebo jinými objekty. Na rozdíl od klasické detekce kolizí se provádějí explicitně – často jako součást herní logiky, pohybu postav, AI nebo fyzikálních interakcí.

• Raycast – „paprsková kolize“
  • Simulujeme paprsek (často nekonečně tenký) vycházející z určitého bodu směrem do scény.
  • Slouží k detekci nejbližšího objektu na trase – ideální pro střelbu, výběr objektů, zjištění, co je „před hráčem“.
  • Výstupem je průsečík (pozice), vzdálenost, normála, typ kolidovaného objektu apod.

• Shapecast – „kolize posunutého objemu“
  • Místo paprsku testujeme pohyb nějakého objemu (např. koule, kapsule, kvádru) po určité dráze.
  • Typicky se používá pro predikci kolize pohybujících se objektů – např. kamera při zoomu, postava při pohybu do prostoru, AI při plánování cesty.
  • Umožňuje detekci budoucích kolizí a přípravu reakce (např. zastavení před překážkou).

• Overlap testy (např. OverlapSphere) – detekce, zda určitý objem právě teď koliduje s něčím jiným.
  • Např. detekce, zda se hráč nachází v oblasti výbuchu, nebo jestli jsou dva objekty příliš blízko.
  • Často používané u trigger oblastí nebo pasivní kolize bez fyzikální reakce.

Tyto dotazy se často spouštějí v každém snímku nebo na vyžádání a bývají napojeny přímo na fyzikální engine. Výsledkem dotazu může být:

• true/false (existuje kolize),
• informace o nejbližším zásahu,
• seznam všech objektů v dotčeném prostoru.

Fyzikální simulace probíhá v pravidelných krocích v rámci hlavní herní smyčky nebo samostatně (např. s vyšší frekvencí). Každý krok zahrnuje sadu operací, které zajistí realistické chování objektů ve scéně. Níže je uvedena typická struktura smyčky:

1. Aktualizace herních objektů
   • Zpracují se vstupy od uživatele (např. GUI, stisk klávesy, skripty).
   • Herní logika ovlivní objekty (např. aktivuje animaci nebo spustí sílu).
   • Připraví se nové požadavky na pohyb, otáčení, přechod mezi stavy atd.
2. Výpočet sil a aplikace impulsů
   • Na objekty se aplikují síly (např. gravitace, tření, pružnost) a momenty.
   • Mohou se upravit vazby (např. klouby mezi objekty, řetězce, tuhé spojení).
   • Herní skripty mohou aplikovat dodatečné síly nebo reakce (např. výbuch, zásah).
3. Simulační krok
   1. Numerická integrace – pomocí metod jako Eulerova nebo Runge-Kutta se spočítá nová pozice a rychlost objektů podle působících sil.
   2. Detekce kolizí – zjistí se, které objekty spolu kolidují, pomocí technik jako SAT, GJK, AABB testy.
   3. Řešení kolizí – pokud se kolize vyskytují:
      • Vypočítají se kontaktní síly nebo penalizační impulzy.
      • Aplikují se korekce pozice (např. posunutí objektu, aby „nevlezl“ do jiného).
      • Mohou být vytvořeny dočasné vazby (např. postava stojící na pohybující se plošině).
   4. Iterace – v případě potřeby se celý krok může několikrát opakovat pro lepší přesnost nebo stabilitu (např. v enginu PhysX nebo Bullet).
4. Aktualizace herních objektů podle simulace
   • Nové pozice, rotace a stavy se promítnou do herních objektů.
   • Např. postava se přesune, předmět se kutálí, dveře se pohnou atd.
   • Možné je odeslání notifikací o změnách (např. „hráč spadl na zem“).
5. Kolizní dotazy
   • Provádějí se raycasty nebo shapecasty na základě aktuálního stavu světa.
   • Používají je AI, kamera, ovládání nebo herní logika (např. jestli je hráč ve výhledu, co má postava pod nohama apod.).
6. Render
   • Na závěr se podle aktualizovaných dat vykreslí scéna.
   • To zahrnuje pozice objektů, rotace, animace, efekty apod.

Tato smyčka je klíčová pro realistický pohyb a interakce objektů. V moderních enginech může být implementována samostatně od hlavní herní smyčky a může běžet s vyšší frekvencí (např. 120× za sekundu), což zvyšuje stabilitu a přesnost simulace.

Pohyb objektu ve fyzikální simulaci se řídí druhým Newtonovým zákonem:

\[ F(t) = m \cdot a(t) = m \cdot \frac{dv(t)}{dt} = m \cdot \frac{d^2r(t)}{dt^2} \]

kde:

• \( F(t) \) je síla působící na těleso v čase \( t \),
• \( m \) je hmotnost objektu,
• \( a(t) \) je zrychlení,
• \( v(t) \) je rychlost a \( r(t) \) je poloha.

Výsledkem jsou diferenciální rovnice, které lze řešit dvěma základními způsoby:

Analytické řešení využívá klasickou integraci rovnic pohybu. Je přesné, ale omezené na jednodušší případy (např. konstantní síla, střela pod vlivem gravitace):

\[ F(t) = m \cdot g = m \cdot v'(t) \] \[ v(t) = \int g \, dt = g \cdot t + v(0) \] \[ r(t) = \int v(t) \, dt = \frac{1}{2} g t^2 + v(0) t + r(0) \]

Tento přístup se používá pro přesně definované trajektorie (např. let střely bez odporu vzduchu).

Numerická integrace je použita v simulacích, kde není možné nebo výhodné použít analytický přístup. Využívá se diskrétních kroků v čase \( \Delta t \). Základními metodami jsou:

• Jednoduchá, ale méně přesná a náchylná k chybám při vyšších krocích.
• Předpokládá konstantní rychlost během intervalu.

\[ v(t + \Delta t) = v(t) + \frac{F(t)}{m} \cdot \Delta t \] \[ r(t + \Delta t) = r(t) + v(t) \cdot \Delta t \]

• Vyšší přesnost než Euler, vhodná pro simulace s malými odchylkami.
• Využívá polohu v předchozím i aktuálním kroku.

\[ r(t + \Delta t) = 2r(t) - r(t - \Delta t) + \frac{F(t)}{m} \cdot \Delta t^2 \] \[ v(t + \Delta t) = \frac{r(t + \Delta t) - r(t)}{\Delta t} \]

Výpočetně náročnější, ale přesnější: \[ r(t + \Delta t) = r(t) + v(t) \cdot \Delta t + \frac{1}{2} a(t) \cdot \Delta t^2 \] \[ v\left(t + \frac{1}{2} \Delta t\right) = v(t) + \frac{1}{2} a(t) \cdot \Delta t \] \[ a(t + \Delta t) = \frac{1}{m} F\left(t + \Delta t,\, r(t + \Delta t)\right) \] \[ v(t + \Delta t) = v\left(t + \frac{1}{2} \Delta t\right) + \frac{1}{2} a(t + \Delta t) \cdot \Delta t \]

V reálné simulaci střely musíme zohlednit odpor vzduchu, který je závislý na rychlosti:

• Síla odporu: \( F_d = -k \cdot v(t) \), kde \( k \) je koeficient odporu.
• Těleso zpomaluje a trajektorie je zkrácená (viz graf).

• Fyzikální objekty jsou často svázány s kolizními objekty (např. ve PhysX).
• Lineární a rotační pohyb se často řeší odděleně – pro rotaci je třeba používat moment síly a kvaterniony.
• Pro rychlé simulace se používají jednoduché metody (Euler), pro stabilitu Verlet.

Ve fyzikální simulaci často dochází k situacím, kdy mezi objekty existují určité omezení pohybu – tzv. vazby. Tyto vazby slouží k simulaci realistického chování složených těles nebo strojních mechanismů. Zavedením vazeb vzniká soustava diferenciálních rovnic s omezeními, které se často řeší iterativně během každého simulačního kroku.

Typické vazby mezi objekty:

• Pevný kontakt (Fixed joint)
  • Objekty jsou pevně ukotveny k sobě nebo k prostoru.
  • Vhodné např. pro připevnění objektu ke scéně nebo propojení částí modelu.
  • Lze nastavit hraniční sílu – pokud ji interakce překročí, spoj se „rozpadne“.
  • Používá se, pokud není žádoucí fyzicky slučovat těla do jednoho.

• Kloub (Ball joint / Spherical joint)
  • Těleso je připojeno k bodu v prostoru, může se volně rotovat kolem všech os.
  • Simuluje například ramenní kloub nebo závěs postavy.
  • Často používán ve spojení s ragdoll fyzikou.

• Pant (Hinge joint)
  • Těleso je spojeno s jiným objektem nebo bodem a může se rotovat pouze kolem jedné osy.
  • Lze nastavit limity rotace a síly motoru.
  • Typický příklad: dveře, kolo.

• Píst (Slider joint)
  • Umožňuje pouze lineární posuv podél jedné osy, bez rotace.
  • Příkladem může být mechanický píst, tlačítko nebo výsuvná součást.
  • Lze definovat minimální a maximální vzdálenost.

• Tlumená pružina (Damped spring)
  • Udržuje tělesa ve vzdálenosti s pružnou silou.
  • Parametry:
    • Tuhost (spring stiffness) – síla, jakou pružina působí při změně délky.
    • Tlumení (damping) – snižuje oscilace.
    • Min / Max délka – omezující rozsah deformace.
  • Použití: lanové systémy, šaty, fyzikální efekty pro zbraně nebo vozidla.

• Poháněné vazby (Motors)
  • Umožňují aplikaci síly nebo momentu přímo ve vazbě.
  • Používají se pro:
    • aktivní řízení pohybu (např. otáčení kol),
    • nepřímou animaci – ovládání fyzických objektů pomocí animovaných cílů,
    • řízení ragdoll postavy tak, aby přebírala přibližnou pózu.

Vazby jsou důležité i pro herní logiku a interakci hráče s objekty – např. držení předmětů ve VR, otevírání dveří nebo simulace vozidel.

Při detekci kolize mezi dvěma objekty nestačí pouze zjistit, že ke kolizi došlo – je nutné také určit reakci těchto těles, tj. jak se budou pohybovat dál. Tento proces se označuje jako řešení kolize (collision response) a typicky se provádí výpočtem impulzu, který objektům dodá správný směr a velikost změny pohybu.

Kolize dvou těles je popsána jako změna hybnosti. Uvažujeme zákon zachování celkové hybnosti izolované soustavy:

\[ \vec{p}_1 + \vec{p}_2 = \vec{p}'_1 + \vec{p}'_2 \]

kde:

• \(\vec{p}_1 = m_1 \vec{v}_1\), \(\vec{p}_2 = m_2 \vec{v}_2\) jsou původní hybnosti,
• \(\vec{p}'_1 = \vec{p}_1 + \Delta \vec{p}\), \(\vec{p}'_2 = \vec{p}_2 - \Delta \vec{p}\) jsou nové hybnosti po kolizi,
• \(\Delta \vec{p}\) je impuls působící mezi tělesy (opačný pro každé těleso, podle zákona akce a reakce),
• \(\vec{n}\) je normála kolizního kontaktu.

Impuls se vypočítá podle:

\[ \Delta \vec{p} = \frac{(1 + \epsilon)(\vec{v}_2 \cdot \vec{n} - \vec{v}_1 \cdot \vec{n})} {\frac{1}{m_1} + \frac{1}{m_2}} \cdot \vec{n} \]

kde:

• \(\epsilon \in [0,1]\) je koeficient pružnosti (restituce),
• \(\epsilon = 0\) – plastický kontakt (žádný odraz),
• \(\epsilon = 1\) – elastický kontakt (dokonalý odraz).

Rychlosti po kolizi:

\[ \vec{v}'_1 = \vec{v}_1 - \frac{\Delta \vec{p}}{m_1}, \quad \vec{v}'_2 = \vec{v}_2 + \frac{\Delta \vec{p}}{m_2} \]

Síla vzniklá z impulzu:

\[ \vec{F} = \frac{\Delta \vec{p}}{\Delta t} \]

Tento výpočet probíhá pro každý kolizní kontakt v simulaci. Složitější simulace navíc používají iterativní řešení, kdy se opakovaně upravují pozice a rychlosti těles, dokud se neodstraní nebo nezminimalizují průniky.

Pokud tělesa mírně penetrují (pronikají do sebe), lze jejich oddělení řešit penalizační silou – síla je úměrná hloubce průniku a působí opačným směrem. Výhodou je jednoduchost, nevýhodou méně přesná simulace.

Fyzikální vlastnosti kolize jsou řízeny tzv. materiály, které jsou přiřazeny objektům. Ty definují:

• Koeficient pružnosti (ε) – určuje odrazivost při kolizi:
  • 0 – plastický kontakt (bez odrazu),
  • 1 – elastický kontakt (plný odraz).
• Tření (friction):
  • Statické tření – odpor před uvedením objektu do pohybu.
  • Dynamické tření – odpor během pohybu (kinetické tření).
• Kombinační metody:
  • Pokud mají dvě tělesa různé hodnoty materiálů, výsledná hodnota (např. tření nebo pružnost) se určuje metodou: průměr (avg), minimum (min), maximum (max), násobení (multiply).

Kolizní systém často detekuje i tzv. kontakty těsně před skutečným průnikem – tyto se využívají např. pro detekci stání na zemi, lehkého dotyku či “trigger” zón.

Každý kontakt obsahuje: pozici kontaktu, kolizní normálu (směr síly), hloubku průniku, lokální souřadnice.

Tyto informace se pak předávají do kolizních callbacků (např. `OnCollisionEnter`) nebo herní logiky.

Cílem animace je rozpohybovat objekty – pro účely hry, realismu nebo stylizace. Existuje několik typů animací, které se používají podle potřeby:

• Sprite animace (2D) – střídání jednotlivých předkreslených snímků (cel/sprite), používané v 2D hrách pro postavy, efekty nebo UI prvky.
• Rigidní hierarchická animace – změna transformací v hierarchii scény, používaná pro objekty, které se skládají z pevných částí (např. otvírání dveří, animace robota).
• Per-vertex animace – animace jednotlivých vrcholů modelu pro detailní deformační efekty:
  • Blend shapes (morphing) – přechod mezi různými tvary sítě, často využívané pro mimiku nebo mluvení.
  • Procedurální animace – automaticky generované deformace podle funkcí (např. Perlinův šum), simulují vlny nebo vítr.
  • Fyzikální simulace – využívá dynamiku pro deformace měkkých objektů, např. látky, vlasy nebo šaty.
• Skeletální animace – klíčová pro postavy; model je řízen vnitřní kostrou, kde se pohyby kostí přenášejí na povrchový mesh.

Skeletální animace používá kostru (hierarchický strom kloubů), která ovládá deformaci polygonálního modelu („kůže“).

• Kostra: reprezentována stromem; uzly = klouby, hrany = kosti.
• Model (kůže): polygonální síť (mesh).
• Oba jsou definovány v referenční póze (např. T-pose).
• Transformace kloubů jsou hierarchicky skládány: Scale → Rotace (Quaternion) → Translace (často jen rotace + posun).

Čtyři základní techniky animace kostry:

• Forward kinematika (FK) – přímé ovládání kloubů, často pomocí klíčových snímků.
• Motion capture – záznam pohybu skutečného herce, následné zpracování dat.
• Inverse kinematika (IK) – nepřímé řízení pomocí cílové pozice (např. noha na zemi), řešeno iterativně.
• Forward dynamika (ragdoll) – řízeno fyzikální simulací.

• Krátké sekvence pohybů – např. chůze, běh, útok.
• Definovány jako sada transformací kloubů v čase.
• Reprezentace:
  • Motion capture,
  • Klíčové snímky (keyframes),
  • Interpolace (např. pomocí křivek),
  • Blend shapes.

• LERP/SLERP mezi transformacemi (Scale, Translate, Rotate) – lineární interpolace pozice a měřítka (LERP), sférická interpolace rotací (SLERP) pomocí kvaternionů.
• Možné přechody mezi klipy (např. z běhu do skoku) se realizují jako plynulé interpolace v čase (tzv. cross-fade).
• Blending tree – výpočet výsledné animace na základě vstupních parametrů (rychlost, směr, stav), umožňuje plynulé kombinace více animačních klipů podle situace.
• Interpolační míchání – probíhá přímo na transformačních datech kloubů (SQT: scale, quaternion, translation). Pokročilejší přístupy používají parametrizované prostory (např. rozsah -1..1 pro náklon hlavy) pro intuitivnější ovládání a omezení neplatných póz.
• Aditivní míchání – místo interpolace se používá složení transformací. Využívá se u detailních animací (např. dýchání, švihnutí mečem), které se přičítají k základnímu pohybu.
• Animační automat (ASM):
  • Množina stavů (Idle, Walking, Jumping, Attacking, …), každý stav má vlastní strom klipů.
  • Přechody s interpolací mezi stavy (cross-fade) umožňují plynulé změny.
  • Více vrstev animace – každá vrstva je samostatný ASM (např. dolní tělo běží, horní tělo střílí), vrstvy se kombinují pomocí vah a masek (např. AvatarMask v Unity).
  • Komplexní kombinace jako chůze + střelba nebo běh + zásah se vytvářejí skládáním vrstev.

• Inverzní kinematika (IK) – používá se jako post-process po smíchání animací. Umožňuje doladit pozici koncových efektorů (např. poloha ruky na klice, noha na zemi). Algoritmus určí rotace všech relevantních kloubů tak, aby efektor dosáhl cíle. IK řešení může být víceznačné, nemusí existovat nebo může být nestabilní v čase, a proto je třeba zajistit plynulost a konzistenci.

Skinning je metoda deformace polygonálního modelu (kůže) podle animace kostry (skeletonu). Každý vrchol modelu je ovlivněn jedním nebo více klouby v závislosti na typu skinningu.

• Rigid skinning – každý vrchol ovládán jedním kloubem. Rychlý, ale vytváří nepřirozené zlomy v oblasti kloubů.

\[ \vec{v}' = F(j) \cdot A^{-1}(j) \cdot \vec{v} \]

• Linear Blend Skinning (LBS) – každý vrchol je ovlivněn několika klouby (typicky 2–4), každý s určitou vahou \( w_i \).
  • Výhody: plynulé deformace, efektivní výpočet, běžné ve většině herních enginech.
  • Nevýhody: artefakty při rotacích – např. zmenšení objemu (gumový efekt), nezachování ortonormality.
  • Výsledná pozice:

\[ \vec{v}_{\text{new}} = \sum_{i=1}^{m} w_i \cdot F(j_i) \cdot A^{-1}(j_i) \cdot \vec{v} \]

• Duální kvaterniony – lepší zachování objemu a rotací.
• Pomocné klouby – pro přesnější deformaci v problematických místech (např. ramena).

Animační křivky určují průběh hodnot (např. pozice, rotace, barvy) mezi klíčovými snímky. Používají se pro plynulou interpolaci v čase, řízení pohybu kamery či procedurální animace.

• Plynulost (spojitá derivace).
• Intuitivní ovládání a editace.
• Rychlý výpočet.

• Jednoduchá, ale nespojitá v derivaci.
• Nevhodná pro přirozený pohyb.

• Definována dvěma body \( P_0, P_1 \) a jejich tečnými vektory \( P_0', P_1' \).
• Výhodná pro řízený a plynulý přechod mezi body.
• Umožňuje snadné nastavení rychlosti nástupu a odeznění.

• Speciální případ Hermitovy kubiky – tečné vektory se určují automaticky.
• Každý segment prochází dvěma body, tvar ovlivněn sousedními.
• Spojitá první derivace → přirozený pohyb.
• Vyžaduje alespoň čtyři body (první a poslední slouží k výpočtu tečen).

Použití:

• interpolace transformací v čase (rotace, pozice),
• řízení kamery,
• fyzikálně věrohodné trajektorie,
• animace parametrů (např. zoom, světlo),
• procedurální pohyby.

Křivky jsou zásadní pro dosažení realistického nebo stylizovaného pohybu bez nutnosti ručního nastavování každého snímku.

Cílem optimalizací je udržet stabilní snímkovou frekvenci (FPS) – např. 60 FPS, pro VR až 90 FPS. Největší zátěž obvykle představuje rendering.

• Jednoprůchodové – osvětlení všech světel spočteno jedním shaderem.
• Víceprůchodové – opakované vykreslení objektů s různými světly.
• Výhody:
  • Jednoduché shadery,
  • přesné pro průhlednost.
• Nevýhody:
  • Více průchodů přes geometrii,
  • omezený počet světel.

• První průchod: renderování geometrie do G-bufferu (barva, normály, hloubka…).
• Druhý průchod: výpočet osvětlení jako postprocess.
• Výhody:
  • Osvětlení pouze na viditelných pixelech,
  • snadná integrace postprocesů (motion blur, FXAA).
• Nevýhody:
  • Paměťově náročné,
  • problémy s průhledností,
  • složité multisampling (antialiasing).

• Neprůhledné objekty: odložené vykreslování.
• Průhledné objekty: dopředné vykreslování.
• Post-process: Tone mapping (HDR, korekce barev), Screen space motion blur / depth of field, FXAA (antialising jako postprocess s detekcí hran), Exposure, glow, gamma, etc.

LOD (Level of Detail) – různé úrovně detailu modelu podle vzdálenosti od kamery.

• Diskrétní LOD – předpočítané verze modelu, přepínání mezi nimi (může být viditelné).
• Spojité LOD – plynulá změna detailu za běhu, výpočetně náročnější (např. Nanite v UE5).
• Optimalizace také pomocí:
  • Normal map, bump map – náhrada detailní geometrie texturou,
  • Mip-mapy, atlasy – zmenšené verze textur,
  • Indexované geometrie – snížení počtu volání.

• Statické globální osvětlení vypočítané offline a uložené jako textury.
• Pouze pro statické objekty, nevhodné pro pohyblivé nebo dynamické scény.

• Simulace odrazu okolí pomocí cubemapy.
• Používá se pro lesklé povrchy, např. sklo, voda.
• Nevýhody:
  • Omezené rozlišení,
  • zastaralé nebo neaktuální záznamy při změnách scény.

Culling = vyloučení neviditelných objektů z renderingu.

• Testujeme, zda objekt leží v pohledovém jehlanu (frustum kamery).
• Objekty mimo frustum se nevykreslují.

• Testování, zda objekt není zakryt jiným.
• Může být:
  • Offline – rozdělení scény na buňky (PVS = Potentially Visible Set),
  • Online – výpočet za běhu (např. pomocí depth bufferu).

• Pro každou buňku prostoru se předem určí množina objektů, které mohou být viditelné.
• Při běhu se vykreslí pouze tyto objekty.
• Výpočet:
  • Offline – náročný, ale velmi efektivní při běhu.
  • Online – rychlejší, ale méně přesný.

• Používá se hierarchie prostorových struktur (např. octree, kd-tree).
• Redukce počtu testů pomocí konzistence mezi snímky – tzv. coherent hierarchy.