Screenshot

DooM Open 2010

Účastníci prosincové DooM Open 2010, chybí Bubuss se synem...

Technologie Doom 3 část 2.

[ Draza ] [ 04.08.2004 ]
Úvod

Doom 3 engine pro začátečníky, část 2.

Konečne jsem se po dlouhé době dostal k dokončení druhé části článku o použitých technologiích v Doom 3. Musím připomenout, že tyto dvě části článku (první část: SK, CZ) byly napsané krátce před dokončením Dooma 3 a obsahují tedy jen informace, které byly v té době známé. Nějakou dobu po vydání hry, případně její SDK snad budeme moudřejší co přesně a jak funguje a možná bude následovat třetí, upřesňující část. Ale teď pokračujme v teorii.

Jako první věc musím napravit jeden můj omyl: v první části článku jsem při psaní o světle používal výraz "lightning"... Správná formulace je "lighting", takže se jedná o světlo, nikoli blesk. Nesprávný tvar jsem používal celé roky bez toho, aby sem si to uvědomil a až při hledání informací o specular lighting přes google jsem zjistil, jak má správný tvar vypadat; mimochodem, Google najde asi 55000 odkazů na specular lighting oproti 2900 na specular lightning takže asi nejsem sám:) Každopádně se omlouvám za zmatek, který jsem mohl vyvolat.

Když už jsem u podobných matoucích výrazů: na IRC mi bylo navrhnuto přeložit výraz shading jako "stínování", to však není možné, protože výraz stínování značí tvorbu stínů, alias shadowing (jako při: stencil shadowing, dynamic shadows), zatímco shading se týka barevných odstínů nebo už v souvislosti s dopadajícím světlem (např. phong shading) a nebo při tvorbě barevné škály (256 shades of gray = 256 odstínů šedé) a podobně. Sice se často při opise herních enginů setkávám s nesprávným překladem slova "shading" jako "stínování", avšak důvod pro tuto anomálii je jednoduchý - až do představení Doom 3 enginu nebyly dynamické stíny v hrách téměr vůbec používané a tak jsme se s výrazem "shadowing" nesetkávali často. Není divu, že v našich končinách těžko preložitelný pojem "shading" se chápal jako stíňování. Takže pro pořádek: (obr. 1 = Shading, obr. 2 = Shadowing)

ShadingShadowing


Ale teď už pokračujeme v popisu Doom 3 enginu.


Specular lighting


Při opětovném pohledu na postavičku z Quake 3 je jasné, že bump-mapping pomohl vyřešit správné nasvětlení drobných nerovností, avšak je tu ještě jedna "výtvarnická licence", nasvětlené plochy na znamení lesklého povrchu. V hrách je důležité emulovat tento efekt už jen proto, že matné materiály mají tendenci nudit. Na dosáhnutí žádaného stavu (obecně známého jako "specular highlights") má výtvarník opět několik možností:

1) Nakreslit patřičné změny v lesklosti povrchu přímo do textury. Klasické řešení, které neodráží skutečný stav osvětlení scény.
2) Vytvořit zhruba takovouto texturu: Highlight a nechat jí běhat po povrchu. Tento způsob se používá hlavně v neinteraktivních demech, protože ve hře se nedá  zaručit, že se tato textura bude nacházet přesně na místě, kde má být zhlediska osvětlení světlé místo. Této textuře se říká různě, např: "light map", "spotlight", "specular highlight", což jsou mimochodem všechno názvy, které kolidují s terminologií používanou v herních enginech.

3) Enviromental mapping: šikovná technika, která sice původně slouží trouchu jinému účelu (napodobit zrcadlovou odraznost), ale dá sa použít také na tvorbu specular highlights. Je však nepříliš dobře použitelná v kombinaci s bump-mappingem a realným osvětlením.

4) Specular lighting.

V herních enginech jsou v podstatě 3 známé způsoby interakce světla s povrchem:

1) Ambient lighting - světlo dopadá na povrch odevšad a objekt se jeví osvětlený z libovolného bodu pozorování.
2) Diffuse lighting - známá je poloha a parametry zdroje světla, které zárovneň ovlivňuje nasvětlený povrch. Viditelným výsledkem je nějaký způsob shadingu (flat, Gourard...). Nasvětlení povrchu zůstává stejné bez ohledu na bod pozorování. Tato technika je použitelná na osvětlení matných materiálů.
3) Specular lighting - funguje podobně jako diffuse lighting (obvykle je na něm závislý), ale povrch se jeví jinak nasvětlený z různých úhlů pohledu.

Celý specular lighting slouží k vytvoření iluze lesklého materiálu na základě zjednodušené fyziky. Matné materiály jsou charakteristické tím, že nejsou dokonalé hladké a světlo se na jejich povrchu rozptyluje všemi směry, zatímco na ideálně hladkém povrchu se jen odráží v závislosti na normálovém vektoru:


Matný povrch Lesklý povrch


Teoreticky se tedy bude nerovný povrch jevit stejně z libovolného úhlu pohledu, proto si vystačí s nasvětlením bez diffuse lighting. Při lesklém materiálu se bere v úvahu i ten:

Specular lighting

Jestli to někoho zajímá, tak tady jsou vysvětlivky:

P = bod, osvětlený přes specular lighting
L = vektor světla (určuje úhel dopadu a intenzitu)
N = normálový vektor
V = úhel pozorování (zase jen vektor)
R = vektor odrazu světla

Specular lighting se od diffuse lighting tedy liší hlavně tím, že bere v potaz i úhel mezi V a R. Čím je tento úhel menší, tím jasnější bude efekt specular highlight na dotyčném pixelu.

Zábavné je, že použít specular lighting na všechno, co se ve hře vyskytuje, má za následek slušně psychedelický efekt (viď 3DMark03 - Ragtroll test), protože ne všechno může být stejně odrazivé. V reálném životě tento atribut povrchu záleží od jeho drsnosti, co v 3D není tak jednoduché napodobit (možná v budoucnu, až se budou používat na bump-mapping 10x detailnější textury než dnes). Na tento účel sa používá další textura - specular map - která v sobě obsahuje informace o "jasnosti" jednotlivých pixelů. Může být černobílá (čím světlejší bod, tím větší jasnost; černá známená žádnou změnu) a nebo barevná, přičemž barva napovídá cosi o vlastnosti povrchu. Do modra zbarvená specular map (tedy její jednotlivé pixely) přidá materiálu jakýsi kovový nádech.

Specular lighting může být brán jako per-vertex nebo per-pixel. Druhá - dokonalejší metoda dokáže fungovat v kombinaci s bump-mappingem (protože BM upravuje normálové vektory). S pomocí Java appletu od pravděpodobného autora 'TheCray' jsem vytvořil drobnou ukázku, na které je vidět, že grafik ze mě asi nebude. Na zobrazení je nutné mít v prohlížeci nainstalovanou Javu.

Takto může vypadat specular lighting na 3D modelu (v tomto případě se jako specular mapa použila přímo základní textura): (obr. 1 = Bez specular, obr. 2 = Specular)

Specular shipSpecular ship

A samozřejmě nemůžeme zapomenout na specular lighting na postavách:

Specular lighting na postave

Na závěr o této technice stačí říct, že jí využívá Doom 3 engin a proto jsme se s ní vůbec zabývali:)


Dynamická světla

Světlo je jeden ze zásadních objevů v 3D grafice a jedná se o funkci, kterou je grafická karta schopná akcelerovat přes OpenGL. Napříč tomu měla donedávna v některých enginech jen omezenou funkci. Vrátím se k rozebírání Quake 3, který používá více druhů světel, přičemž každé funguje trochu jinak, např:

1) Statická světla: která vložil grafik do levelu při jeho tvorbě slouží na tvorbu lightmapy (v editoru). Engine Quake 3 zároveň použije informaci o nich na správné nasměrování stencil shadows a nasvětlení pohyblivých modelů pomocí Gouraud shading.
2) Dynamická světla: Quake 3 sice podporuje pohyblivá světla, která mění nasvětlení objektů a jejich stíny, jsou však pozorovatelná převázně jako barevné skvrny provázející letící rakety a tak jim náléži pojmenování "dynamická světla" s uvozovkami.

Světlo je ale zbytečné, když není co osvětlovat. Povrchy v Q3A se od sebe liší ještě radikálněji:

1) Statické povrchy mají  hybridní nasvětlení: v reálném čase pomocí Gouraud shading od statických světel (třebaže to není dobře viděž, protože se jedná o per-vertex lighting) a stínované jsou pomocí lighmapy. "Dynamická světla" alias pohyblivé světlé skvrny způsobují další lokální změny.
2) Dynamické, pohyblivé povrchy představují modely hráčů, krabice s municí a podobně. Tyto záležitosti není možné stínovat pomocí lightmapy a tak na nich nejsou žádné síny (v této věci si budeme ještě protiřečit). Osvětlené jsou per-vertex od statických i dynamických světel (tentokrát bez uvozovek).

Při této rozmanitosti je podivuhodné, že to spolu může fungovat. Statické povrchy trpí najvíce: jsou osvětlené per-vertex v reálném čase, ostínované neostrou (zubatou) lightmapou, kterou naruší žlutý světlý kruh provázející letící rakety a výsledek ješte může provázet občasný dynamický stíň. Výsledek je zkrátka nekonzistentní. Proč tolik vrstev na jeden povrch a nepoužilo sa jen osvětlení per-vertex + Gouraud shading v reálnom čase? Ono totiž na malé červené kuličce nebo na postavě vypadá per-vertex osvětlení dobře, ale jak má polygon šírku místností, nemá engine jinou možnost než vysvítit ho celý naráz. Lightmapy totiž neslouží jen na vytvoření stínu tam kde je světlo blokované jiným (statickým) objektem, ale i na navození pocitu lepšího osvětlení jako takového. To jsou screenshoty z jedné scény Quake 3, první se zapnutými lightmapami a druhý jen s per-vertex lighting...

Quake 3 - lightmap Quake 3 - vertex lighting

Možné řešení je jediné: real-time per-pixel lighting, což je technika kterou už známe. To by umožnilo principiálně stejnou, prakticky samozřejme o mnoho lepší kvalitu osvětlení než vidíme na obrázku s lightmapou (lightmapa je totiž omezená rozměry textury do které je vytvořená, což je nedostatek, který při renderovaní v reálném čase nehrozí). Odehrával by se tento postup by v reálnem čase? Ano a to znamená: 1) žádné lightmapy (stíny ješte vyřešíme); 2) realistická světla je možné zapínat/vypínat, pohybovat a různě manipulovat přímo v hře, opět v reálném čase; 3) dvě základní podmínky (per-pixel a real-time) zaručují, že je možné použít stejný způsob osvětlení na statické a dynamické povrchy. A to ješte nemluvím o výhodě bump-mappingu.

V době Quake 3 ješte nic takového neexistovalo, ale dnes už máme k dispozícii pár enginů s patričnými schopnostmi. Kromě Doom 3 je to například šikovný AMP II engine:

Dynamické svetlo Dynamické svetlo

Na podlaze je vidět efekt, který dosáhla lightmapa na screenshotu Quake 3. Jenže tady se mění patričně s pohybem světla, stejně jako nasvětlení nerovností tvořených bump-mappingem a zářivost per-pixel specular lighting.

Per-pixel dynamická světla mají ješte jednu zajímavou vlastnost: dokáží s sebou nést jakoukoliv obrazovou informaci. Světelný zdroj je zkrátka možné použít jako projektor textury nebo videa, které se bude promítat na nejbližší povrch (ano bavíme se stále o světle uprostřed hry). Na screenshotu z dema AMP2 je možné tento efekt pozorovat na vzdálenější stěne - světelný zdroj má na sobě mřížku vytvořenou z textury. Této technice se říká projected textures. Myslím, že tímto způsobem bude řešená baterka v Doom 3, ale tady máme ješte jeden příklad:

Projected textures

Teď mám pocit, že jsem zapomněl na dva detaily, které si zaslouží vysvětlení.

1) Průhlednost textury. Víme, že textura je běžný grafický soubor obvykle ve formátu TGA. Běžná textura obsahuje 24-bitovou barevnou hloubku, 8 bitů na každou základní barvu (červená, zelená, modrá - RGB). 8 bitů sa rovná 256 odstínů na každou barvu, 8 bitů × 3 barvy = spolu 24 bitů, 256^3 = 2^24 = 16777216 možných odstínů dohromady. Každá barva má v souboru TGA vlastní kanál, zajímavé je, že formát TGA umožňuje uschovat čtyři kanály, pričemž ten čtvrtý se nazývá alfa kanál, který má také 8 bitů a vznikne 32-bitová textura RGBA. Alfa kanál uschovává dodatečnou informaci, 256 možností na každý pixel. V textuře sa jedná o abstraktní informaci, engine si ale může těchto 256 odstínů vyložit různě. Najčastejší využití je právě průhlednost, například hodnota 0 alfa kanálu dotyčného pixlu případně chybějící alpha kanál značí nulovou průhlednost a 256 plnou průhlednost nebo opačně. Instrukce jak s informací obsaženou v alpha kanálu naložit může mít engine natvrdo naprogramovaný nebo může být tato instrukce uložená v textovém souboru nazvaném shader. Každá textura nebo povrch může mít vlastní shader.

2) Při promítání textury na povrch vzniká otázka, jak vlastně engine rozezná kam má patričné pixely promítnou? Je to maličkost pro část grafické karty, které se říká Z-buffer. Ten počítá v jaké vzdálenosti na ose Z (osa smeřující od pohledu kamery do nekonečna rovně vpřed) se nacházejí jednotlivé pixely v 3D prostoru. Hlavním účelem je zajistit, aby se z vícero překrývajících se pixlů (které patří různým polygonům a objektům) na obrazovku dostal jen ten, který je nejblíže na ose Z (při tomto musí brát v úvahu i případnou průhlednost). Protože se Z-buffer obvykle dostává ke slovu ješte před nanášaním textur na polygony, dokáže jednak ušetrit výkon grafické karty (tím, že zabrání, aby se zpracovaly pixely, které by hráč neviděl) a jednak dokáže při technice projected textures presně označit místo, kde se pixely promítané textury objeví.


Dynamické stíny

Dynamická světla jsou pěkná, ale ke světlu neodlučitelně patří i stíny. Stín má "objem" (shadow volume), který představuje prostor mezi předmětem, který stín vrhá (shadow occluder) a nejbližším povrchem, který stín přijímá (shadow receiver). Na vytvoření shadow volume je potřebné poznat hlavně polohu světla a tvar předmětu, který stín vrhá. Tvar předmětu z hlediska tvorby stínu představuje jeho silueta. Na tomto screenshotu je silueta zvýrazněná:

Silueta

Siluetu v zásadě představují hrany polygonů, které zároveň ohraničují viditelnou plochu předmětu (3D modelu). Poznat siluetu modelu je důležité i při běžném renderovaní, protože z pohledu hráče je potřebné zobrazovat jen polygony, které jsou viditelné. Jedná sa o hardwarově akcelerovanou funkci OpenGL, i když v případě tvorby stínů není z pohledu hráče, ale světelného zdroje. Dalším krokem je vytvoření samotného shadow volume:

Shadow volumes

Silueta je tvořená hranami polygonů a hrany jsou ohraničené vrcholy polygonů. Při tvorbě shadow volume se vytvoří polopřímky spojující zdroj světla a jednotlivé vrcholy polygonů. Takto se celá silueta promítne prakticky do nekonečna, proto se střetáváme i označením "infinite shadow volumes". Protože Z-buffer už dopředu vykreslil celou scénu z hlediska hloubky, engin už ví, kde se promítnutá silueta protne s nejbližším povrchem a tam vytvoří obraz stínu:

Tieň

Poznámka: model rytíře visí ve vzduchu a nepodařilo se mi ho posadit na podlahu, proto stín nevypadá tak dobře.

JAk na model dopadá světlo z více zdrojů, musí se celá procedura od siluety po výsledný stín opakovat z pohledu každého světelného zdroje.

Teď se o slovo hlásí další buffer, stencil buffer. Tento univerzální pomocník funguje v 2D prostoru a dokáže přidělit bit informace (má 8-bitovou preciznost, takže 256 možností, ale obvykle sa používá jen atribut 0 a 1) každému pixlu na obrazovce podle nějakého kritéria, v tomto případě nese stencil bit informaci, zda je pixel pod stínem nebo ne. Pri nanášení pixlů na polygony se potom kromě kontroly hloubky na ose Z kontroluje i patričný stencil bit. Když by například pixel byl za normálních okolností nasvětlený světelným zdrojem ale stíní mu objekt, je jeho stencil bit vzhledem na dotyčný světelný zdroj nastavený na opačnou hodnotu tak, jako kdyby nebyl ve stínu a dopad toho světelného zdroje na barvu pixlu se ignoroje. Ať se dělá s pixlem cokoliv (phong shading, bump-mapping, specular mapping...), jediným viditelným výsledkem je, že se mění jeho barva. Každý pixel tak musí byt grafickou kartou zpracovaný tolikrát, kolikrát se z nějakého důvodu mění jeho barva. Vždy když sa takto kompletně překreslí 3D scéna, výsledek se průbežně ukládá do frame buffera, který nakonec pošle výsledek na monitor. Takže když se v Doom 3 setkáme se stínem a v místnosti je jen jeden zdroj svetla, je pravděpodobné, že v rámci toho stínu není renderované vůbec nic a situaci nezlepší ani zvýšení gamma na 10, ani vytáhnutí nejvyššího jasu na monitoru :)

Stencil shadowing není jediným řešením tvorby stínů, ale zdá se, že momentálně nejlepším - už jen proto, že si ho Carmack vybral. Zajímavou schopností stínování pomocí stencil bufferu je self-shadowing, při kterém jedna část 3D modelu vrhá stín na jinou část toho samého modelu. Stencil shadowing se objevil ve hrách už před nějakou dobou, podporuje ho i Quake 3 engine, avšak v samotném Q3A plnému využití brání nutnost interakce s různymi formami nasvětlení; dynamický stín na lightmapě nebo na modelu osvetleném per-vertex vypadá trochu pomýleně. Stíny tvoří na dynamické objekty a tvoří vždy jen jeden stín podle nejsilnějšího zdroje světla. Zábavné sledovat změnu po zapnutí cg_shadows 2; dokonce funguje i self-shadowing:

Stencil shadow v Quake 3

Ze starších her se z tohoto pohledu nejlépe ukazuje Severance: Blade of Darkness z roku 1999, ve které je stencil buffer použitý dokonce na odrazy ve vodě; stále však není přítomný univerzální způsob osvětlování a stencil shadows. Engine se nekamarádí se screenshoty, takže s nimi nemůžu posloužit, ale doporučuji vyzkoušet demo.

Stencil shadows mají proti lightmapě dvě nevýhody: přechody mezi stínami jsou ostré (okraje stínů bývají ve skutečnosti různě rozmazané) a principiálně dokáží vytvořit shadow volume jen pomocí siluety.

Co se týká první zmiňované záležitosti, už nyní vidím zástupy hráčů counter-strike jako vyčítají Doom 3 ostré stíny, bohužel při pokusu o tvorbu fyzikálne korektních "soft shadows" se tvrdě narazí na výkon dnešního hardwaru. Protože se vývoj nedá zastavit, už existuje několik projektů na renderovaní takovýchto stínů v reálném čase; jeden z nich jako minimum vyžaduje FX5900 nebo R9700 na ostínování pár krabic v místnosti. Existuje fígl jak trochu zjemnit stencil shadow volumes: po kompletním prepočítání jednoho stínu se trochu posune zdroj světla a stín se vykreslí z této pozice. Na dosáhnutí stínu, jehož okraje budou dostatečně "soft" je potřeba několik přechodů a výsledky je ješte potřebné interplovtť (bohužel netuším jak, jestli někdo víte dejte vědět) anebo nechat přeblikávat, aby výsledek nevypadal jako stín ve stínu. Samozřejme, že tento postup je příliš náročný na výkon aby se dal použít. Mluví se ale o tom, že Doom 3 tuto techniku podporuje, jak je vidět na některých místech ve videu z E3 2003:

Video Doom 3 Video Doom 3

Druhým problémem je schopnost tvořit stíny jen okopírováním siluety, zatímco např. při tvorbě lightmapy sa bere v úvahu i průhlednost textury (hodnota alfa kanálu). Výsledkem je, že například plot, který je tvořený malým počtem polygónů a průhledný jen díky textuře, bude vrhat stín jen podle své vnější siluety. Rešením je vypnutí stínů na patričný objekt a jejich nahrazení promítanou texturou, jak je vidět na screenshotu z dema AMP II, nebo i na na některých obrázků z Doom 3:

Screenshot Doom 3

Tento postup nahrazování stínů se dá logicky použit jen na nepříliš dynamické objekty (v místech, kde se textura použije jako maska, která brání světlu) a teda se v podstatě jedná o krok zpět na cestě k úplné jednotnosti všech světel a stínů. Důležité však je, že tyto "stíny" jsou v podstatě světla a chovají se stejně jako per-pixel a real-time, jejich intrakce s povrchem neprojevuje žádné anomálie a ješte důležitější, že toto je v Doom 3 a co dělá id Software, dělá dobře a v zájmu atmosféry. Existuje zdokonalená verze této techniky, kde se používají dvě cubemapy (cube map je svazek 6 textur tvořících kostku, výsledkem je, že bodové světlo obložené cubemapou může vrhat tento "stín" na všechny strany), pričemž jedna cubemapa je rozostřenou verzí té druhé. "Stín" je potom výsledkem porovnaní těchto dvou cubemap v závislosti na vzdálenosti od světelného zdroje. Tento trik stojí za stíny v Unreal Engine 3, ale nejsou náznaky, že by se objevil v Doom 3, enginu by nedělalo problém něco takového podporovat. Programátor der_ton, který vytvořil přehladač formátu 3D modelů použitých v Doom 3, do svého výtvoru už tuto techniku zakomponoval:

Cubemap demo


Detaily

Kromě podpory těchto technologií nám Doom 3 engine ješte přinese:

  • Particle system: částicový systém by měl poprvé být kompletně zakomponovaný do systému světel a stínů jako jakýkoliv jiný objekt a světlo jsou schopné i vytvářet. Na videách z E3 2003 a 2004 je taktéž vidět, že částice se budou moct naprogramovat, aby vykonávali nějakou činnost, ať už vytvořili logo nebo sledovali dráhu větru... Nepochybuji, že budou také ovlivněné fyzikou okolních objektů a tak bude možné je efektně rozdýchat letícími projektily, nebo stíny deště...
  • Per-polygon fyzikální model: prakticky všechny dnes používané fyzikální systémy ve hrách vytvoří okolo (dynamického) objektu škatulku fixních rozměrů, která definuje správu modelu; pro ilustracii:
Box
Interakce nastává, když se střetnou dva takové boxy (raketa s hráčem, hráč s quad damage...). Kontrola jestli se boxy setkávají se vykonává periodicky v závislosti od nastavení (například v Quake 3 je to standardně 20× za sekundu). V Doom 3 sa bude všechna fyzika počítat na jednotlivé polygóny, výsledkem toho bude známý fakt, že bude možné netrefit raketometem jen proto, že projektil proletěl nepřítelovi pod rukou. Kontrola jestli se střetávají jednotlivé polygóny má být řešená jinak než periodickou kontrolou, bohužel detailami nedisponujem, protože sem nedostal odpověď na mail, který jsem posílal do id :( Fyzikální model v Doom 3 si skutečně zaslouží pomenování "fyzikální", protože se řídí naemulovanými pravidlami fyziky. K tomu mají dnešní systémy často daleko, když nepočítám "ragdoll" a občasný podařený efekt v Havoc engine.
  • Zvukový engine sa také řídí pravidly běžného světa a přítomného fyzikálneho modelu. Připravené zvukové soubory se v reálném čase upravují podle potřeby (např. úhel dopadu vystřelené kulky na povrch). Uvidíme, co na tomto změní implementace EAX kterou si vynutilo Creative.
  • Podpora pro moddery: Doom 3 bude natívně podporovat přinejmenším formáty Lightwave a Maya, takže 3D model si stačí vytvořit ve svém 3D programu a Doom ho bude akceptovat. Hra a editor levelů sdílejí společný .exe a stejný souborový formát, takže v editoře je možné vidět finální výsledek (žádné několikahodinové kompilování lightmapy) a všetky mapy které tvoří Doom 3 bude možné upravovat podle svého gusta. Taktéž se zavrhlo C++ na tvorbu módů a používat se budou jednoduché textové skripty které jsou schopné ovládat úplně všechno.
  • Podpora HLSL - High Level Shading Language. Teprve nedávno jsme se z mailu od R. Duffyho dozvědeli, že Doom 3 engine podporuje Vertex a Fragment shadery (OpenGL obdoba Vertex a Pixel shaderov), ale bude je používat jen na detaily kterých si zřejme nikdo nevšimne. HLSL však umožňuje naprogramovat vlastní efekty přet tyto technologie - už nyní se objavují plány na implementaci Virtual Displacement Mapping.
A to bude asi všechno co bych nyní mohl napsat o engine Doom 3... Teď si už je třeba si zahrát plnou hru, nejlépe asi tři krát za sebou :)

goodoldalex



Zdroje obrázků:

Pinky demon - oficiální screenshot Doom 3, zdroj Gamespot
BloodRayne - Terminal Reality, http://www.bloodrayne2.com
ostatní obrázky goodoldalex
screenshoty z programů:
- Projected Shadows, Specular Spaceship, Projected Textures; zdroj http://www.sulaco.co.za/opengl.htm, autor Jan Horn
- demo AMP II engine, http://4drulers.com/amp.html
- Infinite Stenciled Shadow Volumes, http://developer.nvidia.com/object/inf_shadow_volumes.html
- Quake III: Arena
- GtkRadiant, http://www.qeradiant.com
- Model viewer http://www.doom3world.org/phpbb2/viewtopic.php?p=25180, autor der_ton

Java applet zapůjčený z http://home.comcast.net/~doomiii/bump256.html

Použitá nebo doporučená literatura:

http://developer.nvidia.com/object/all_docs_by_date.html !!!
http://doomworld.com/lordflathead/zaldron.html
http://www.flipcode.com/demomaking/issue07.shtml
http://freespace.virgin.net/hugo.elias/graphics/x_polybm.htm
http://www.delphi3d.net/articles/viewarticle.php?article=bumpmapping.htm
http://www.no-x-files.webz.cz/glossary/slovnicek.htm
http://www.firingsquad.com/guides/videolightfilter/default.asp
http://computer.howstuffworks.com/question484.htm
http://www.whisqu.se/per/docs/graphics9.htm
http://futuretech.mirror.vuurwerk.net/lights.html
http://www.opengl.org/resources/tutorials...
http://www.whisqu.se/per/docs/graphics10.htm
http://www.delphi3d.net/articles/viewarticle.php?article=phong.htm
http://www.sulaco.co.za/opengl.htm
http://www.extremetech.com/article2/0,1558,1171855,00.asp
http://www.gamedev.net/columns/hardcore/shadowvolume/default.asp
http://www.firingsquad.com/features/carmack/default.asp
http://finger.planetquake.com/plan.asp?userid=johnc&id=16154