Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
statnice:bakalar:b4b39hry [2025/05/28 15:10] – [5. Skinning (Linear Blend Skinning)] zapleka3 | statnice:bakalar:b4b39hry [2025/06/06 21:23] (current) – zapleka3 | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ==== Komponenty herního enginu, herní smyčka. Detekce kolizí a základy herní fyziky. Reprezentace a výpočet animací. Základní optimalizační metody pro herní engine. ==== | + | ====== Komponenty herního enginu, herní smyčka. Detekce kolizí a základy herní fyziky. Reprezentace a výpočet animací. Základní optimalizační metody pro herní engine. |
[[https:// | [[https:// | ||
Line 12: | Line 12: | ||
==== 1. Přehled komponent herního enginu a jejich funkce ==== | ==== 1. Přehled komponent herního enginu a jejich funkce ==== | ||
- | **Herní engine** je software, který | + | **Herní engine** je komplexní softwarová platforma, která |
- | * **AI** – řídí | + | * **AI (Artificial Intelligence)** – zajišťuje |
- | * **Fyzika** – zpracovává kolize, gravitaci, | + | * **Fyzika** – simuluje reálné i stylizované fyzikální jevy. Obsahuje systémy pro detekci a řešení kolizí, gravitaci, |
- | * **Rendering** – zajišťuje | + | * **Rendering** – stará se o vizuální |
- | * **Zvuk** – spravuje hudbu, | + | * **Zvuk |
- | * **UI/Input** – zpracovává uživatelský vstup (myš, klávesnice, | + | * **UI / HID (Human Interface Device)** – zpracovává |
- | * **Scripting** – umožňuje | + | * **Scripting** – umožňuje |
- | * **Síť** – zajišťuje multiplayerové funkce, synchronizaci | + | * **Síť |
+ | |||
+ | * **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í, | ||
+ | * **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. | ||
+ | |||
+ | {{: | ||
==== 2. Herní smyčka ==== | ==== 2. Herní smyčka ==== | ||
- | Herní smyčka představuje jádro | + | Herní smyčka představuje jádro |
- | - **ProcessInput** – zpracování | + | Základní struktura smyčky zahrnuje: |
- | | + | |
- | | + | * **ProcessInput** – zpracování vstupu |
+ | | ||
+ | | ||
+ | |||
+ | {{: | ||
+ | |||
+ | 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í). | ||
=== Varianty herní smyčky === | === Varianty herní smyčky === | ||
- | Herní smyčka může | + | Herní smyčka může |
- | * **Fixní simulační krok** – doba každého kroku smyčky je konstantní, což zajišťuje | + | * **Fixní simulační krok (Fixed timestep)** – každý krok simuluje |
- | * **Proměnlivý simulační krok** – smyčka běží co nejrychleji. Výhodou | + | * **Proměnlivý simulační krok (Variable timestep)** – každé UpdateGame používá reálný časový rozdíl od předchozího kroku. Odezva |
+ | * **Kombinovaný přístup** – proměnlivý krok pro většinu aktualizací, | ||
+ | |||
+ | 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**, | ||
+ | |||
+ | {{: | ||
==== 3. Souvislost reálného a herního času ==== | ==== 3. Souvislost reálného a herního času ==== | ||
- | Časy používané ve hře: | + | Ve hře se pracuje s několika druhy času: |
- | * **Reálný čas** (wall-clock time) – odpovídá skutečnému času. | + | |
- | * **Herní čas** – interní | + | * **Reálný čas (wall-clock time)** – čas měřený reálnými hodinami, např. pomocí `GetCurrentTime()`. |
- | * **CPU/GPU čas** – doba potřebná | + | * **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“, | ||
+ | * Při nízkém FPS se mohou některé kolize „propadnout“ (bullet through paper problem). | ||
+ | |||
+ | Příkladem robustního přístupu je herní | ||
+ | |||
+ | < | ||
+ | ```c | ||
+ | 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í. | Synchronizace herního času s reálným časem zajistí konzistentní herní zážitek bez ohledu na výkon zařízení. | ||
Line 50: | Line 96: | ||
Jednotlivé komponenty enginu jsou propojeny s částmi smyčky: | Jednotlivé komponenty enginu jsou propojeny s částmi smyčky: | ||
- | * **ProcessInput** komunikuje s komponentou vstupu. | + | * **ProcessInput** komunikuje s komponentou vstupu, UI, (Input manager). |
* **UpdateGame** propojuje fyziku, AI, zvuk, skripty a síť (aktualizace objektů a chování). | * **UpdateGame** propojuje fyziku, AI, zvuk, skripty a síť (aktualizace objektů a chování). | ||
- | * **Render** komunikuje s renderingovou částí enginu. | + | * **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. | * 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, | ||
+ | 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. | ||
==== 5. Zpracování dlouhých procedur ==== | ==== 5. Zpracování dlouhých procedur ==== | ||
- | Dlouhé operace, jako například načítání velkých scén, lze řešit několika | + | 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“, |
- | * **Threading** – paralelní vykonávání operací. | + | * **Threading |
- | * **Rozdělení na menší části** – postupné vykonání delších | + | * **Rozdělení na menší části** – dlouhá úloha se rozdělí na více menších |
- | * **Loading screen** – vizuální | + | * **Loading screen |
- | * **Coroutines** (např. | + | * **Coroutines** |
+ | |||
+ | Použitím těchto technik lze dosáhnout vyšší stability hry, lepší odezvy a komfortu pro hráče. | ||
==== 6. Synchronizace fyzikální simulace a zobrazování ==== | ==== 6. Synchronizace fyzikální simulace a zobrazování ==== | ||
- | Problém nesynchronizace | + | Simulace a zobrazení nemusí nutně probíhat ve stejném čase nebo frekvenci. V praxi to znamená, že mezi výpočtem polohy objektu |
- | * **Interpolací** – dopočítávání stavu mezi dvěma | + | * **Interpolace** – při vykreslování |
- | * **Extrapolací** – předpověď stavu na základě | + | * **Extrapolace** – předpovídáme budoucí stav objektu |
+ | * **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. | ||
- | Alternativně lze použít vyšší frekvenci | + | Synchronizace je zásadní pro kvalitní vizuální výstup a konzistentní |
+ | Správná implementace synchronizace má přímý vliv na hratelnost – zejména v rychlých akcích, závodních hrách nebo VR. | ||
===== 2. Detekce kolizí a základy herní fyziky ===== | ===== 2. Detekce kolizí a základy herní fyziky ===== | ||
==== 1. Motivace, princip, využití ==== | ==== 1. Motivace, princip, využití ==== | ||
- | Fyzikální simulace ve hrách | + | Fyzikální simulace ve hrách |
+ | |||
+ | Typické oblasti využití: | ||
+ | * **Detekce | ||
+ | * **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 | ||
+ | * **Interaktivní objekty** – např. | ||
+ | * **Deformovatelné objekty a šaty** – tkaniny, lano, měkké tělesa (cloth / soft bodies). | ||
+ | * **Částicové a fluidní systémy** – kouř, voda, magie. | ||
+ | |||
+ | Fyzikální simulace | ||
==== 2. Typy kolizních objektů ==== | ==== 2. Typy kolizních objektů ==== | ||
- | Kolizní tělesa aproximují reálné objekty jednoduchými geometrickými tvary pro rychlou | + | Pro detekci kolizí |
+ | Výběr typu kolizního tělesa je **kompromisem mezi přesností a výpočetní náročností**: | ||
- | * **Koule (Sphere)** – rychlá detekce, jednoduchá aktualizace, | + | * **Koule (Sphere)** |
- | * **AABB (Axis-Aligned Bounding Box)** | + | * Definována středem a poloměrem. |
- | * **OBB (Oriented Bounding Box)** | + | * Výpočet kolize je extrémně rychlý (porovnání vzdáleností). |
- | * **k-DOP (Discrete Oriented Polytope)** | + | * Rotace objektu nemá vliv – **rotace invariantní**. |
- | * **Konvexní obálka (Convex Hull)** | + | * 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 | ||
+ | * Snadná aktualizace, rychlý test průniku. | ||
+ | * Trochu přesnější | ||
+ | * Vhodné pro statické objekty nebo jako zjednodušený obal. | ||
+ | * **OBB (Oriented Bounding Box)** | ||
+ | * Natočený kvádr, | ||
+ | * 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ý | ||
+ | * 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ší | ||
+ | * Výpočetně | ||
+ | * 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). | ||
+ | |||
+ | {{: | ||
==== 3. Algoritmy pro detekci kolizí ==== | ==== 3. Algoritmy pro detekci kolizí ==== | ||
=== Separating Axis Theorem (SAT) === | === Separating Axis Theorem (SAT) === | ||
- | Princip spočívá v projekci objektů na testované | + | Separating Axis Theorem (teorém separační osy) říká, že **pokud existuje |
+ | |||
+ | * 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ů | ||
+ | * Na každé ose se vytvoří 1D interval (projekce rozsahu objektu). | ||
+ | * Pokud existuje alespoň jedna osa, kde se tyto intervaly **nepřekrývají**, | ||
+ | |||
+ | 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 algoritmus === | === GJK algoritmus === | ||
- | Vhodný | + | |
+ | GJK (Gilbert–Johnson–Keerthi) algoritmus je obecný a velmi výkonný algoritmus | ||
+ | |||
+ | **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ý | ||
+ | |||
+ | {{: | ||
+ | |||
+ | Princip GJK: | ||
+ | * Vytváří tzv. **simplex** (bod, hrana, trojúhelník, | ||
+ | * 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**, | ||
+ | * Pokud nelze simplex směrem k počátku rozšířit, | ||
+ | |||
+ | 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, | ||
+ | |||
+ | **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. | ||
==== 4. Fáze detekce kolizí ==== | ==== 4. Fáze detekce kolizí ==== | ||
+ | |||
+ | 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 (Broad Phase) === | === Široká fáze (Broad Phase) === | ||
- | Rychle identifikuje páry objektů, které | + | Široká fáze se snaží rychle vyřadit objekty, které |
- | * **Mřížka (Grid)** – konstantní čas detekce | + | * **Mřížka (Grid)** – prostor je rozdělen na buňky; |
- | * **Hierarchie obalových těles (Bounding Volume Hierarchy)** – struktura | + | * **Hierarchie obalových těles (Bounding Volume Hierarchy, BVH)** – stromová |
=== Filtrování kolizí === | === Filtrování kolizí === | ||
Pomocí vrstev a kolizních masek určujeme, které objekty mohou kolidovat. | 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, | ||
=== Úzká fáze (Narrow Phase) === | === Úzká fáze (Narrow Phase) === | ||
Přesná detekce kolizí vybraných dvojic objektů. | 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. | ||
==== 5. Kolizní dotazy a jejich varianty ==== | ==== 5. Kolizní dotazy a jejich varianty ==== | ||
- | | + | Kolizní dotazy slouží k aktivnímu zjišťování, |
- | * **Shapecast** – detekce | + | |
+ | | ||
+ | * 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í, | ||
+ | * Výstupem je průsečík (pozice), vzdálenost, | ||
+ | |||
+ | * **Shapecast** – „kolize posunutého objemu“ | ||
+ | * Místo paprsku testujeme pohyb nějakého objemu | ||
+ | * 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. | ||
==== 6. Smyčka fyzikální simulace ==== | ==== 6. Smyčka fyzikální simulace ==== | ||
- | | + | 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: |
- | - Výpočet sil, aplikace impulsů, vazby. | + | |
- | - Simulační krok: | + | |
- | * Numerická integrace. | + | * Zpracují se vstupy od uživatele |
- | * Detekce kolizí. | + | * Herní |
- | * Řešení kolizí. | + | * Připraví se nové požadavky na pohyb, otáčení, přechod mezi stavy atd. |
- | - Aktualizace objektů podle výsledků | + | - **Výpočet sil a aplikace impulsů** |
- | - Kolizní dotazy. | + | * Na objekty se aplikují síly (např. gravitace, tření, pružnost) a momenty. |
- | - Render. | + | * Mohou se upravit |
+ | * Herní skripty mohou aplikovat dodatečné síly nebo reakce (např. výbuch, zásah). | ||
+ | - **Simulační krok** | ||
+ | | ||
+ | | ||
+ | | ||
+ | * 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ě). | ||
+ | - **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). | ||
+ | - **Aktualizace | ||
+ | * 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“). | ||
+ | - **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.). | ||
+ | - **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. | ||
==== 7. Řešení pohybové rovnice ==== | ==== 7. Řešení pohybové rovnice ==== | ||
+ | |||
+ | 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í === | === Analytické řešení === | ||
- | Integrace pohybových | + | |
+ | Analytické řešení využívá klasickou integraci | ||
+ | |||
+ | \[ | ||
+ | F(t) = m \cdot g = m \cdot v' | ||
+ | \] | ||
+ | \[ | ||
+ | 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é řešení === | === Numerické řešení === | ||
- | Výpočet diskrétních kroků: | ||
- | * **Eulerova metoda:** | + | Numerická integrace je použita v simulacích, |
- | | + | |
- | \text{nová\_pozice} = \text{stará\_pozice} + \text{rychlost} \cdot \Delta t | + | |
- | | + | |
- | * **Verletova metoda** | + | {{: |
+ | |||
+ | == Eulerova metoda == | ||
+ | |||
+ | | ||
+ | | ||
+ | |||
+ | \[ | ||
+ | v(t + \Delta t) = v(t) + \frac{F(t)}{m} \cdot \Delta t | ||
+ | \] | ||
+ | \[ | ||
+ | r(t + \Delta t) = r(t) + v(t) \cdot \Delta t | ||
+ | \] | ||
+ | |||
+ | == Verletova metoda | ||
+ | |||
+ | | ||
+ | | ||
+ | |||
+ | \[ | ||
+ | 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} | ||
+ | \] | ||
+ | |||
+ | == Rychlostní Verletova metoda (Velocity Verlet) == | ||
+ | |||
+ | Výpočetně náročně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 | ||
+ | \] | ||
+ | |||
+ | == Odpor vzduchu == | ||
+ | |||
+ | 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). | ||
+ | |||
+ | == Praktické poznámky == | ||
+ | |||
+ | * 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. | ||
==== 8. Typy vazeb mezi objekty ==== | ==== 8. Typy vazeb mezi objekty ==== | ||
- | | + | 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. |
- | * **Kloub (Ball joint)** | + | |
- | * **Pant (Hinge)** | + | Typické vazby mezi objekty: |
- | * **Píst (Slider)** | + | |
- | * **Tlumená pružina** – simulace | + | |
+ | * Objekty jsou pevně | ||
+ | * 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čí, | ||
+ | * Používá se, pokud není žádoucí fyzicky slučovat těla do jednoho. | ||
+ | |||
+ | * **Kloub (Ball joint / Spherical | ||
+ | * 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 | ||
+ | * 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 | ||
+ | * Umožňuje pouze **lineární | ||
+ | * 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 | ||
+ | * Udržuje tělesa ve vzdálenosti s pružnou silou. | ||
+ | * Parametry: | ||
+ | * **Tuhost** (spring stiffness) | ||
+ | * **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. | ||
==== 9. Výpočet reakce na kolize a fyzikální materiály ==== | ==== 9. Výpočet reakce na kolize a fyzikální materiály ==== | ||
- | Při kolizi se vypočítává impuls podle materiálových vlastností (tření, odrazivost) a dalších parametrů: | ||
- | | + | Při detekci kolize mezi dvěma objekty nestačí pouze zjistit, že ke kolizi došlo – je nutné také určit |
- | * **Tření (friction)** – statické a dynamické. | + | |
- | | + | |
- | Tato kapitola podrobně shrnuje základy detekce kolizí | + | === Výpočet impulzu při kolizi === |
+ | |||
+ | 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}' | ||
+ | \] | ||
+ | |||
+ | kde: | ||
+ | * \(\vec{p}_1 = m_1 \vec{v}_1\), | ||
+ | * \(\vec{p}' | ||
+ | * \(\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}' | ||
+ | \vec{v}' | ||
+ | \] | ||
+ | |||
+ | 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í**, | ||
+ | |||
+ | === Penalizační síly === | ||
+ | |||
+ | 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 | ||
+ | |||
+ | === Fyzikální materiály === | ||
+ | |||
+ | Fyzikální vlastnosti kolize jsou řízeny tzv. **materiály**, | ||
+ | |||
+ | * **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ů, | ||
+ | |||
+ | === Kontakty === | ||
+ | |||
+ | 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 " | ||
+ | |||
+ | 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. | ||
===== 3. Reprezentace a výpočet animací ===== | ===== 3. Reprezentace a výpočet animací ===== | ||
Line 164: | Line 515: | ||
Cílem animace je rozpohybovat objekty – pro účely hry, realismu nebo stylizace. Existuje několik typů animací, které se používají podle potřeby: | 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í | + | * **Sprite animace (2D)** – střídání |
- | * **Rigidní hierarchická animace** – změna transformací v hierarchii scény, | + | * **Rigidní hierarchická animace** – změna transformací v hierarchii scény, |
- | * **Per-vertex animace** – animace jednotlivých vrcholů: | + | * **Per-vertex animace** – animace jednotlivých vrcholů |
- | * **Blend shapes (morphing)** – výrazy obličeje. | + | * **Blend shapes (morphing)** – přechod mezi různými tvary sítě, |
- | * **Procedurální animace** – hladiny, vlny (šumové funkce). | + | * **Procedurální animace** – automaticky generované deformace podle funkcí |
- | * **Fyzikální simulace** – např. šaty. | + | * **Fyzikální simulace** – využívá dynamiku pro deformace měkkých objektů, |
- | * **Skeletální animace** – klíčová pro postavy, podrobně popsána | + | * **Skeletální animace** – klíčová pro postavy; model je řízen vnitřní kostrou, kde se pohyby kostí přenášejí na povrchový mesh. |
+ | |||
+ | |||
+ | |||
+ | |||
==== 2. Skeletální animace a reprezentace kostry ==== | ==== 2. Skeletální animace a reprezentace kostry ==== | ||
Line 199: | Line 555: | ||
==== 4. Míchání animačních klipů ==== | ==== 4. Míchání animačních klipů ==== | ||
- | * **LERP/ | + | * **LERP/ |
- | * Možné přechody (např. z běhu do skoku). | + | * Možné přechody |
- | * **Blending tree** – výpočet na základě parametrů (rychlost, směr). | + | * **Blending tree** – výpočet |
+ | * **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)**: | * **Animační automat (ASM)**: | ||
- | * Množina stavů (Idle, Walking, Jumping, …). | + | * Množina stavů (Idle, Walking, Jumping, Attacking, …), každý stav má vlastní strom klipů. |
- | * Přechody s interpolací. | + | * Přechody s interpolací |
- | * Více vrstev animace (např. tělo vs. ruce), kombinace | + | * Více vrstev animace |
+ | * Komplexní kombinace jako chůze + střelba | ||
+ | |||
+ | * **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é, | ||
==== 5. Skinning (Linear Blend Skinning) ==== | ==== 5. Skinning (Linear Blend Skinning) ==== | ||
- | Skinning je technika | + | **Skinning** je metoda |
- | * **Rigid skinning** – každý vrchol ovládán jedním kloubem (zastaralé). | + | * **Rigid skinning** – každý vrchol ovládán jedním kloubem. Rychlý, ale vytváří nepřirozené zlomy v oblasti kloubů. |
- | * **Linear Blend Skinning (LBS)** – každý vrchol ovlivněn několika klouby (2–4) s váhami | + | \[ |
- | * Váhy jsou **konvexní** (součet = 1, každá váha \( \geq 0 \)). | + | \vec{v}' |
- | * Výsledná pozice | + | \] |
+ | * **Linear Blend Skinning (LBS)** – každý vrchol | ||
+ | * Výhody: plynulé deformace, efektivní výpočet, běžné ve většině herních enginech. | ||
+ | | ||
+ | * Výsledná pozice: | ||
\[ | \[ | ||
- | | + | |
\] | \] | ||
- | * kde \( T_i \) je transformace daného kloubu a \( P_0 \) je původní pozice. | ||
- | * Výhody: rychlý výpočet, jednoduchá implementace. | + | * **Duální kvaterniony** – lepší zachování objemu a rotací. |
- | * Nevýhody: artefakty | + | * **Pomocné klouby** – pro přesnější deformaci v problematických místech |
- | ==== 6. Animační křivky ==== | ||
- | Animační křivky určují, jak se transformace mění mezi klíčovými snímky. | ||
- | | + | ==== 6. Animační křivky, princip a využití ==== |
- | * **Catmull–Rom spline** – prochází dvěma | + | |
+ | **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. | ||
+ | |||
+ | ===== Požadavky ===== | ||
+ | * Plynulost (spojitá derivace). | ||
+ | * Intuitivní ovládání a editace. | ||
+ | * Rychlý výpočet. | ||
+ | |||
+ | ===== Lineární interpolace ===== | ||
+ | * Jednoduchá, | ||
+ | * Nevhodná pro přirozený pohyb. | ||
+ | |||
+ | ===== Hermitova kubika ===== | ||
+ | * 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 | ||
+ | * Umožňuje snadné nastavení rychlosti nástupu a odeznění. | ||
+ | |||
+ | {{: | ||
+ | |||
+ | ===== Catmull–Rom spline | ||
+ | | ||
+ | * Každý segment | ||
+ | * Spojitá první derivace | ||
+ | * 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. | ||
- | Používají se pro: | ||
- | * interpolaci transformací v čase, | ||
- | * řízení pohybu kamery, | ||
- | * procedurální animace. | ||
===== 4. Základní optimalizační metody pro herní engine ===== | ===== 4. Základní optimalizační metody pro herní engine ===== | ||
Line 270: | Line 662: | ||
* **Neprůhledné objekty**: odložené vykreslování. | * **Neprůhledné objekty**: odložené vykreslování. | ||
* **Průhledné objekty**: dopředné vykreslování. | * **Průhledné objekty**: dopředné vykreslování. | ||
+ | * **Post-process**: | ||
==== 3. Optimalizace pomocí LOD ==== | ==== 3. Optimalizace pomocí LOD ==== | ||
- | LOD (Level of Detail) | + | **LOD (Level of Detail)** je technika pro snižování zátěže GPU tím, že se místo plně detailního |
- | * **Diskrétní LOD** – předpočítané verze modelu, | + | === Diskrétní LOD === |
- | * **Spojité LOD** – plynulá změna detailu | + | |
- | * Optimalizace také pomocí: | + | * Přepínání může být viditelné |
- | * **Normal map, bump map** – náhrada detailní geometrie texturou, | + | * **Alpha blending** – plynulý přechod pomocí průhlednosti. |
- | * **Mip-mapy, atlasy** – zmenšené | + | * **Bitové masky** – postupné skrývání detailů. |
- | * **Indexované geometrie** – snížení počtu volání. | + | * LOD modely lze generovat automaticky (např. Blender, MeshLab). |
+ | |||
+ | === Spojité LOD === | ||
+ | * Geometrie je dynamicky zjednodušována | ||
+ | * Plynulé přechody bez skoků v detailech. | ||
+ | * Výpočetně náročné, ale vizuálně kvalitní. | ||
+ | * Příklady: **UE5 Nanite** – hierarchická rasterizace a culling mikropolygony. | ||
+ | |||
+ | === Pseudo-spojité LOD === | ||
+ | * Kombinace hierarchických LOD a clusterů. | ||
+ | * Různé části modelu (clustery) mají vlastní LOD. | ||
+ | * Dynamicky přepínány podle viditelnosti a detailu. | ||
+ | |||
+ | === Další optimalizační techniky === | ||
+ | | ||
+ | * **Mip-mapy** – předpočítané | ||
+ | * **Texturové atlasy** – sloučení více textur do jedné, snižují | ||
+ | * **Indexovaná geometrie** – opětovné použití vrcholů pomocí indexů, snižuje paměťové nároky a volání. | ||
+ | |||
+ | LOD je klíčovým prvkem pro škálování grafické náročnosti a udržení plynulého výkonu při zobrazování rozsáhlých scén. | ||
==== 4. Předpočítané osvětlení a sondy odrazu ==== | ==== 4. Předpočítané osvětlení a sondy odrazu ==== | ||
Line 299: | Line 711: | ||
==== 5. Redukování podle viditelnosti (Culling) ==== | ==== 5. Redukování podle viditelnosti (Culling) ==== | ||
- | Culling | + | **Culling** |
- | === View frustum culling | + | === View Frustum Culling |
+ | * Kontroluje, zda je objekt uvnitř **zorného jehlanu (frustum)** kamery. | ||
+ | * Objekty zcela mimo frustum jsou **vynechány z renderingu**. | ||
+ | * Používá se obvykle jako **první filtr** při vykreslování scény. | ||
- | | + | === Occlusion Culling === |
- | * Objekty mimo frustum se **nevykreslují**. | + | |
+ | | ||
+ | | ||
+ | * **Online** – výpočet **za běhu** pomocí: | ||
+ | * **Depth bufferu**, **hierarchického Z-bufferu**, | ||
+ | * **softwarové rasterizace** s jednoduchými tvary (occludery). | ||
- | === Occlusion culling === | + | === Potenciálně |
- | + | * Pro každou | |
- | * Testování, | + | * Při běhu se pak **vykreslují jen tyto objekty**. |
- | * 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). | + | |
- | + | ||
- | === Potenciálně | + | |
- | + | ||
- | * Pro každou **buňku | + | |
- | * Při běhu se vykreslí pouze tyto objekty. | + | |
* Výpočet: | * Výpočet: | ||
- | * **Offline** – náročný, ale velmi efektivní při běhu. | + | * **Offline** – náročný |
- | * **Online** – rychlejší, | + | * **Online** – rychlejší, vhodný pro dynamické scény, ale méně přesný. |
- | + | ||
- | === Hierarchické zpracování === | + | |
- | + | ||
- | * Používá se hierarchie prostorových struktur (např. octree, kd-tree). | + | |
- | * Redukce počtu testů pomocí **konzistence mezi snímky** – tzv. **coherent hierarchy**. | + | |
+ | === Hierarchické Zpracování a Konzistence === | ||
+ | * Scéna je strukturována pomocí prostorových hierarchií (např. **Octree**, **kd-tree**). | ||
+ | * Efektivní redukce díky **coherent hierarchy** – využití podobnosti mezi snímky. | ||
+ | * Pomáhá omezit opakované testy pro podobné oblasti. |