Chris Lambert o vývoji grafiky pro Hellgate
Zdroj IGN 4.5.2005 (http://pc.ign.com/articles/610/610199p1.html). Není to úplný překlad ale je to skoro všechno.
Byla tmavá bouřlivá noc. Mraky se honily a převalovaly nad tím, co kdysi bývalo ospalým předměstím. Z hospody zbyla jen kostra budovy, polovina oken byla vytlučená, druhá pokrytá prachem jakoby od nárazu větru Tam, kde bývaly dveře, které zadržovaly chlad ale vítaly žíznivé, zbyl jen rám, který nezadržoval nic ale vítal ještě méně Ohnuté pouliční lampy vrhaly dlouhé stíny od hranatého měsíce ..he? hranatý? Hovno.
Alfa blend není dobře nastaven a když se přešlo do full screenu, objekt měsíce si nezachovává srpkovitý tvar, který vytvořil návrhář. Moje chyba.
Stejně jako mnoho jiných her, vyžaduje Hellgate: London těsnou spolupráci mezi grafickými inženýry (tedy mnou) a štábem 3D umělců, aby se vize designéra uvedla v život. Naše hra má mnoho problémů společných s konvenčními grafickými enginy a pak ještě další, které se vyřítí jako hladové opice k večeři v případě, že už máme pocit, že je vše dobré.
Vezměte si ten měsíc. To je úplně standardní úloha v 3D designu: udržovat parametry potřebné k vykreslení objektu (states) se samotným objektem, aby se zajistilo, že až bude potřeba, bud vykreslen správně. V tomto případě bylo pár údajů implicitních, protože měsíc byl renderován již na počátku zobrazení frame. Potom se přepnulo na full screen, což způsobilo, že se provedlo pár jednorázových renderování (zobrazení náhledů v inventáři - o tomhle později) a ty to narušily. Průhlednost (alfa blend) selhala a máme tu hranatý měsíc.
Ok, tohle bylo jednoduché. Teď vylézají ty opice.
Naše levly (oblasti) mají náhodné variace. Podzemí, podzemní dráhy, a rozsáhlé podzemní komplexy se spojují ve třech dimenzích. Vlakové koleje probíhají pod a nad jinými kolejemi a opět se spojují v jeskyňovitých terminálech. Na zemi se tucty variací silničních segmentů, budov a krajiny spojují dohromady v komplexní, zajímavé layouty (půdorysy). Rozsah těch kousků nejsou městské bloky ale malé detailní komponenty. Jsou skládány dohromady při loadování, jakmile se rozhodlo o rozložení levelu.
Zní to skvěle, avšak při tento stupeň náhodnosti způsobuje grafické problémy při zobrazování okolí. Jeden z nich například je, jak udělat celkové osvětlení.
Celkové osvětlení je úloha, která zahrnuje přicházející světlo, které je v interakci s okolím. V tomto případě měsíční svit osvětluje scénu a tvoří stíny na budovách a ulicích. Obloha je tmavě zelená a někdy temně rudá. Přinejmenším nějaké světlo by se mělo odrážet od země a zdí a osvětlovat postavy a ostatní objekty zezadu.
Úkol je, aby se tohle všechno zobrazilo efektivně v reálném čase. Tenhle problém se dá řešit několika způsoby. Většinou se to řešilo tzv světelnými texturami, které se zobrazovaly na všechny globálně osvětlené fixní nepohyblivé objekty. Novější technika je vytvořit sérii funkcí, které by popsaly světlo přicházející z různých směrů, a pak spočítaly a uložily správné hodnoty světla pro celý generovaný svět tak, aby mohly být vyvolány v okamžiku zobrazení. Nejnákladnější proces by byl skutečně počítat plné světlo a stíny v reálném čase pro každý pixel obrazovky,. Obvyklé jsou hybridní způsoby: hry používaly tři světelné mapy pro uložení hodnot světla pro tři aproximační funkce.
My jsme si vybrali techniky na základě analýzy nákladů/výnosů a starého dobrého zkoušení a testování. Fascinující. Já vím. Chtěli byste vidět grafy a tabulky? Ano? Smůla.
Chceme to všechno - skvěle vypadající hru, která bude fungovat i na minimální požadované konfiguraci a řešení, které nezabere 4 roky vývoje a dolaďování. Teď používáme hybridní přístup se světelnou mapou. Pro okolí předgenerujeme světelnou mapu, která obsahuje lokální informace o světle (pouliční světla, atd). Pak, v čase loadování levelu počítáme (doufám, že efektivně) globální osvětlení jako měsíční svit a stíny a přidáváme to k původní světelné mapě pro tenhle kousek prostředí. To nám dalo dobré výsledky a naše pekelné zobrazení Londýna se zdá mít jednotné barvy a stíny tak, jak jsme zvyklí z her s konvenčními fixnimi layouty.
Stačí to? Na jednu věc jsme zapomněli, a to, jak dobře vypadá na normálních mapách rozptýlené světlo na pozadí. To je, že když se díváme na dlažební kostky mimo dosahu aktivního dynamického světla, nevidíme odlesky, které bychom v měsíčním svitu očekávali. Jedna možnost je oddělit některá světla z kroku generování světelné mapy a přesunout je na dobrém hardware do reálného času.
Zvažujeme přidání podpory novějších technik jako renderování -dynamic-range (HDR) a parallax-mapping ale musíme brát v úvahu, jak dlouho by nám trvalo je přidat, co by to přineslo, kolik eventuálních hráčů by je využilo, (kolik má nejnovější karty) a jak by to ovlivnilo frame-rate (snímkování)
Když frame-rate poklesne během vývoje pod určitou mez, musí grafický inženýr prokázat, že to není grafika, která způsobuje zpomalení (ale třeba fyzika nebo AI) nebo to musí spravit, je-li chyba skutečně v grafickém kódu. Tak se v malém týmu jako je náš stane grafický inženýr i technikem pro výkon
Trávím spoustu času nastavováním hry jak pro video tak pro výkon. Mým cílem je udržet rovnováhu charakteristik, nákladů a zátěže. Každá charakteristika má náklady, minimální požadavky na hardware, způsob snížení nákladů a vizuální nebo výkonový užitek. Např uvažujme fullscreenové zkreslení jako tepelné odlesky. Jejich náklad je v stínování pixelů a texturách a přenosová zátěž bufferu (přenos pixelů z a do paměti grafiky). To znamená, že počítače s velmi výkonnou grafickou kartou jsou v podstatě nezatížené. Naopak pro počítače s průměrnou kartou, kde je tohle úzké místo, to bude neuvěřitelně náročné. Metoda snížení zátěže by byla levnější efekty (možná snížit počet průchodů na efektu) nebo použít jednoduchou texturu místo matematického generování pixelů. Minimální specifikace bude zřejmě definovaná jako bod, kdy tato technika je už nepoužitelná. Jestliže je toto příliš vysoko a zisk z efektu je příliš nízký (třeba je použit jen na lehce špinavých skleněných oknech vysoko na zdi, kam se nikdy nedostanete), může být zrušen ve prospěch jiného efektu s vyšším užitkem.
A za vším tím leskem je masivní soustava funkcí a kontejnerů pro ukládání, třídění, zpracování, konvertování a velký - ne, monstrózní - náklad dat přicházejících od umělců ve formě textur, modelů a animací
Pro zpracování v reálném čase je potřeba organizovat data tak, aby se k nim dalo přistupovat co nejrychleji. Když jsme dělali náš první level v krajině, datové struktury, které zvládaly vnitřní prostory, se nedokázaly vypořádat s obrovským nárůstem viditelných objektů a terénu. Teď náš engine zpracovává data pro vnitřní a vnější prostory úplně odlišným způsobem.
Pohled hráče také ovlivňuje, co je viditelné a co ne. Máme 1st person a 3rd person (vlastní a pozorovatel) režimy kamery. Levely, které jsou dobré ve vlastním pohledu, mohou být při pohledu pozorovatele přetíženy, protože kamera se zvedne a vidíte všechny nepřátele, kteří vás obklopují, nejen ty v rozmezí 90 stupňů před vámi. .
Náš náhodný systém generování layoutu plive do tváře několika "nejlepším technikám" pro grafiku v reálném čase. Spojování nejbližších objektů tak, aby se renderovaly dohromady funguje jen tehdy, když víte, že jsou blízko jeden druhému. Nechceme, aby se loadování levelu změnilo na prodlouženou výpočetní fázi, a to je další důvod pro výběr vlastností hry.
Ještě jsem se nezmínil o náhodných odchylkách postav (např potvory s poškozeným brněním nebo různým tetováním) nebo velký seznam věcí. Existuje tolik věcí, že ani neděláme obrázky náhledů (thumbnaily) pro inventář. Místo toho renderujeme věci (s použitím speciálního prostředí, kamery a světelných parametrů) do speciální thumbnailové textury, když se přidají do hráčova inventáře. Tohle je jen další z mnoha věcí, na které narážíme, když náhodnost je pravidlo
Hellgate: London je definitivně jiný druh hry. Technické výzvy, které vyplývají z našeho designu, dělají tvorbu hry skoro tak zábavnou, jako bude ji hrát. Už se nemohu dočkat.
Website Baker, jakpsatweb, jitkara , ceskyhosting.cz
