A globális számítógépesítéssel rengeteg érthetetlen kifejezés érkezett világunkba. Mindegyikük kezelése nem olyan egyszerű, mint első pillantásra tűnik. Sok közülük hasonló a nevükben, sokan széles funkcionalitással rendelkeznek. Itt az ideje, hogy megtudja, mi az a shader, honnan származik, mire való és mire való.

Optimalizáló

Valószínűleg lelkes Minecraft játékos vagy, és ezért jöttél, hogy megtudd, mi ez. Rögtön meg kell jegyezni, hogy a "shader" fogalma könnyen elválasztható ettől a játéktól, és külön "élhet" tőle. Akárcsak a modok. Ezért nem érdemes szorosan összekapcsolni ezt a két fogalmat.

Általában a shader a programozásból származik, a szakemberek asszisztenseként jelent meg. Valószínűleg hangos lesz ezt az eszközt optimalizálónak nevezni, de valóban javítja a játék képét. Tehát, ha már elkezdte nagyjából megérteni, mi ez, akkor térjünk át a pontos értelmezésre.

Értelmezés

Mi az a shader? amelyet a videokártya -processzorok hajtanak végre. Ezeket az eszközöket speciális nyelven fejlesztették ki. A céltól függően eltérő lehet. Ezt követően az árnyékolókat feltételesen lefordítják a grafikus gyorsító processzorok utasításaihoz.

Alkalmazás

Azonnal meg kell mondani, hogy az alkalmazás egészét a cél határozza meg. A programok videokártya-processzorokba vannak ágyazva, ami azt jelenti, hogy a háromdimenziós grafika objektumainak és képeinek paraméterein dolgoznak. Különféle feladatokat végezhetnek, beleértve a reflexiót, a fénytörést, a sötétítést, a nyíróhatásokat stb.

Feltevés

Az emberek régóta próbálják kideríteni, mi az a shader. Már a programok előtt a fejlesztők mindent kézzel végeztek. A kép egyes objektumokból történő létrehozásának folyamata nem volt automatizált. A játék születése előtt a fejlesztők maguk végezték el a renderelést. Egy algoritmussal dolgoztak, különböző feladatokra állították össze. Tehát voltak utasítások a textúrák, videoeffektusok stb.

Természetesen néhány folyamatot még beépítettek a videokártyák munkájába. Ilyen algoritmusokat használhatnak a fejlesztők. De nem tudták rávenni algoritmusaikat a videokártyára. A nem szabványos utasításokat a CPU hajthatta végre, amely lassabb volt, mint a GPU.

Példa

A különbség megértéséhez érdemes néhány példát megnézni. Nyilvánvaló, hogy egy játékban a renderelés lehet hardver és szoftver. Például mindannyian emlékezünk a híres Quake 2 -re. Tehát a játékban lévő víz csak egy kék szűrő lehet, ha hardveres renderelésről van szó. De szoftveres beavatkozással egy vízcsepp jelent meg. Ugyanez a helyzet a CS 1.6 -tal is. A hardveres renderelés csak fehér villanást adott, míg a szoftveres renderelés hozzáadott egy pixeles képernyőt.

Hozzáférés

Így világossá vált, hogy szükség van az ilyen problémák megoldására. A grafikus gyorsítók bővíteni kezdték a fejlesztők körében népszerű algoritmusok számát. Világossá vált, hogy lehetetlen mindent "tömni". Meg kellett nyitni a hozzáférést a videokártya -szakértőkhöz.

Mielőtt olyan játékok voltak, mint a "Minecraft" modokkal és árnyékolókkal, a fejlesztők lehetőséget kaptak a GPU blokkokkal való együttműködésre olyan csővezetékekben, amelyek felelősek lehetnek a különböző utasításokért. Így váltak ismertté a "shader" nevű programok. Ezek létrehozásához programozási nyelveket fejlesztettek ki. Tehát a videokártyákat nemcsak szabványos "geometriával" kezdték betölteni, hanem a processzorra vonatkozó utasításokkal is.

Amikor ez a hozzáférés lehetővé vált, új programozási lehetőségek nyíltak meg. A szakemberek megoldhatnának matematikai problémákat a GPU -n. Ezek a számítások GPGPU néven váltak ismertté. Ez a folyamat speciális eszközöket igényelt. Az nVidia CUDA, a Microsoft DirectCompute és az OpenCL keretrendszerből.

Típusok

Minél többet megtudták az emberek az árnyékolókat, annál több információ derült ki róluk és képességeikről. Kezdetben a gyorsítóknak három processzora volt. Mindenki felelős volt a saját shader típusáért. Idővel felváltotta őket egy univerzális. Mindegyiknek volt egy bizonyos utasításkészlete, amely háromféle árnyékolót tartalmazott egyszerre. A mű egységesítése ellenére az egyes típusok leírása a mai napig fennmaradt.

A csúcs típus a sok arcú alakzatok csúcsaival dolgozott. Sok eszközről van szó. Például textúrakoordinátákról, érintő, binormális vagy normál vektorokról beszélünk.

A geometriai típus nemcsak egy csúccsal, hanem egy egész primitívvel is működött. A Pixelt a bitképes illusztrációk és általában a textúrák töredékeinek feldolgozására tervezték.

Játékokban

Ha árnyékolókat keres a Minecraft 1.5.2 -hez, akkor valószínűleg csak javítani szeretné a játék képét. Ennek érdekében a programok "tűz-, víz- és rézcsöveken" mentek keresztül. Az árnyékolókat tesztelték és finomították. Ennek eredményeként világossá vált, hogy ennek az eszköznek vannak előnyei és hátrányai.

Természetesen a különböző algoritmusok összeállításának egyszerűsége hatalmas plusz. Ez egyszerre rugalmasság és észrevehető egyszerűsítés a játékfejlesztési folyamatban, és ezáltal a költségek csökkenése. Az így kapott virtuális jelenetek összetettebbé és valósághűbbé válnak. Ezenkívül maga a fejlesztési folyamat sokszor gyorsabbá válik.

A hiányosságok közül érdemes megjegyezni, hogy meg kell tanulnia az egyik programozási nyelvet, és figyelembe kell vennie azt is, hogy a különböző videokártya -modelleken különböző algoritmuskészletek találhatók.

Telepítés

Ha talált egy árnyékoló csomagot a Minecraft számára, akkor meg kell értenie, hogy sok buktató van a telepítésében. Annak ellenére, hogy a játék népszerűsége már halványul, hűséges rajongói továbbra is megmaradnak. Nem mindenki szereti a grafikát, különösen 2017 -ben. Vannak, akik úgy gondolják, hogy az árnyékolóknak köszönhetően képesek lesznek javítani. Elméletileg ez az állítás helyes. De a gyakorlatban nem sokat fogsz változtatni.

De ha még mindig keresi a módját a "Minecraft 1.7" -nek, akkor először is legyen óvatos. Maga a folyamat nem bonyolult. Ezenkívül a letöltött fájlokkal együtt van egy utasítás a telepítésére. A lényeg az, hogy ellenőrizze a játék és az árnyékoló verzióit. Ellenkező esetben az optimalizáló nem működik.

Az interneten sok helyen telepíthet és letölthet egy ilyen eszközt. Ezután ki kell csomagolnia az archívumot bármelyik mappába. Ott megtalálja a "GLSL-Shaders-Mod-1.7-Installer.jar" fájlt. Az indítás után megjelenik a játék elérési útja, ha helyes, akkor minden további utasítással egyetért.

Ezután át kell helyeznie a "shaderpacks" mappát a ".minecraft" mappába. Most, amikor elindítja az indítót, el kell mennie a beállításokhoz. Itt, ha a telepítés helyes volt, megjelenik a "Shaders" sor. A teljes listából kiválaszthatja a kívánt csomagot.

Ha árnyékolókra van szüksége a Minecraft 1.7.10 számára, akkor csak keresse meg a kívánt verzió shaderpack -jét, és tegye ugyanezt. Az instabil verziók megtalálhatók az interneten. Néha cserélni, újratelepíteni és megfelelőt kell keresni. Jobb, ha megvizsgálja a véleményeket, és kiválasztja a legnépszerűbbeket.

Bevezetés

A 3D -s grafika világa, beleértve a játékokat is, tele van kifejezésekkel. Olyan kifejezések, amelyek nem mindig rendelkeznek az egyetlen helyes meghatározással. Néha ugyanazokat a dolgokat másképp hívják, és fordítva, ugyanazt a hatást nevezhetjük "HDR" -nek, majd "Bloom" -nak, majd "Glow" -nak, majd "Postprocessing" -nek a játék beállításaiban. A legtöbb ember, a fejlesztők dicsekedése miatt azzal, hogy mit építettek be a grafikus motorjába, értetlenül áll azok előtt, amit valójában jelentenek.

A cikk célja, hogy segítsen megérteni, mit jelentenek ezek a leggyakrabban ilyen esetekben használt szavak. E cikk keretein belül nem a 3D grafika minden feltételéről fogunk beszélni, hanem csak azokról, amelyek az utóbbi években egyre elterjedtebbek, mint a játékgrafikus motorokban használt megkülönböztető jellemzők és technológiák, valamint a modern játékok grafikus beállításainak nevei. . Kezdetben nagyon ajánlom, hogy ismerkedjen meg.

Ha valami nem világos ebben a cikkben és Alexander cikkeiben, akkor érdemes a legkorábbi, p. Ezek a cikkek természetesen már kissé elavultak, de az alapvető, legfontosabb és legfontosabb adatok megvannak. Beszélünk veled több "magasabb szintű" kifejezésről. Alapvető ismeretekkel kell rendelkeznie a 3D valós idejű grafikáról és a grafikus folyamat szerkezetéről. Másrészt ne számíts matematikai képletekre, tudományos pontosságra és kódpéldákra - ez a cikk egyáltalán nem erről szól. Feltételek

A cikkben leírt kifejezések listája:

Shader

A shader széles értelemben egy olyan program, amely vizuálisan határozza meg egy tárgy felületét. Ez lehet a világítás, textúrázás, utófeldolgozás stb. Leírása. Az árnyékolók Cook árnyékfáiból és Perlin pixelfolyamnyelvéből nőttek ki. A RenderMan árnyékolónyelv ma a leghíresebb. A programozható árnyékolókat először a Pixar RenderMan rendszerében vezették be, amely többféle árnyékolót határoz meg: fényforrás -árnyékolókat, felületi árnyékolókat, elmozdulási árnyékolókat, hangerőszabályozókat Ezeket az árnyékolókat leggyakrabban univerzális processzorok hajtják végre szoftverekben, és nem rendelkeznek teljes hardver implementációval. Később sok kutató a RenderManhoz hasonló nyelveket írt le, de már hardveres gyorsításra tervezték őket: PixelFlow rendszer (Olano és Lastra), Quake Shader Language (az id Software használja a Quake III játék grafikus motorjában, amely leírta a többlépcsős renderelést), stb. A RenderMan árnyékolók többre törtek A keretbufferben egyesített passzok száma. Később voltak olyan nyelvek, amelyeken a hardvert gyorsítva látjuk a DirectX -ben és az OpenGL -ben. Így igazították az árnyékolókat a valós idejű grafikai alkalmazásokhoz.

A korai videochipek nem voltak programozhatók, és csak előre programozott műveleteket hajtottak végre (fix funkció), például a megvilágítási algoritmus mereven rögzítve volt a hardverben, és semmit sem lehetett megváltoztatni. Ezután a videochipgyártók fokozatosan programozható elemeket vezettek be chipjeikbe, eleinte ezek nagyon gyenge képességek voltak (az NV10, NVIDIA GeForce 256 néven ismert, néhány primitív programra már képes volt), amelyek nem kaptak szoftvertámogatást a Microsoft DirectX API -ban, de mivel idővel a lehetőségek folyamatosan bővültek. A következő lépés mind az NV20 (GeForce 3), mind az NV2A (a Microsoft Xbox játékkonzolban használt videochip) volt, amelyek az első chipek lettek, amelyek hardveresen támogatják a DirectX API árnyékolókat. A DirectX 8 -ban megjelent Shader Model 1.0 / 1.1 verzió nagyon korlátozott volt, minden shader (különösen a pixeles) viszonylag rövid lehet, és nagyon korlátozott utasításkészletet tartalmazhat. Később a Shader Model 1 -et (röviden SM1) továbbfejlesztették a Pixel Shaders 1.4 -el (ATI R200), amely nagyobb rugalmasságot kínált, de túl korlátozott képességekkel is rendelkezett. Az akkori árnyékolókat az úgynevezett assembly shader nyelven írták, amely közel áll az általános célú processzorok összeszerelési nyelvéhez. Alacsony szintje bizonyos nehézségeket okoz a kód és a programozás megértésében, különösen akkor, ha a programkód nagy, mert messze van a modern programozási nyelvek eleganciájától és strukturáltságától.

A Shader Model 2.0 (SM2) verzió, amely a DirectX 9-ben jelent meg (ezt támogatta az ATI R300 videochip, amely az első GPU lett a shader modell 2.0 verziójának támogatásával), jelentősen kibővítette a valós idejű árnyékolók képességeit, hosszabb és összetettebb árnyékolókat és jelentősen kibővített utasításkészletet kínál. Hozzáadták a képességet a lebegőpontos számítások elvégzéséhez pixel árnyékolókban, ami szintén jelentős javulás volt. A DirectX 9 az SM2 képességeivel szemben bevezette a magas szintű shader nyelvet (HLSL) is, amely nagyon hasonlít a C nyelvhez. És egy hatékony fordító, amely a HLSL programokat alacsony szintű, hardverbarát kódgá alakítja. Ezenkívül számos profil áll rendelkezésre a különböző hardver architektúrákhoz. Most a fejlesztő írhat egy HLSL shader kódot, és lefordíthatja a DirectX segítségével a felhasználó által telepített videochip optimális programjába. Ezt követően az NVIDIA, az NV30 és az NV40 chipjei jelentek meg, amelyek egy lépéssel tovább javították a hardver árnyékolók képességeit, még hosszabb árnyékolókat adtak hozzá, a dinamikus átmenet lehetőségét a csúcs- és pixelárnyékolókban, a textúrák lekérésének lehetőségét a csúcsárnyékolókból stb. nem voltak, 2006 vége felé várhatók a DirectX 10 -ben ...

Általánosságban elmondható, hogy az árnyékolók sok új lehetőséget adtak a grafikus csővezetékhez a csúcsok átalakítására és megvilágítására, valamint a képpontok egyéni feldolgozására, ahogyan azt az egyes alkalmazások fejlesztői szeretnék. Mégis, a hardveres árnyékolók képességeit még nem tárták fel teljesen az alkalmazásokban, és mivel képességeik minden egyes új generációs hardverben nőnek, hamarosan látni fogjuk azoknak a RenderMan árnyékolóknak a szintjét, amelyek egykor elérhetetlennek tűntek a videojáték -gyorsítók számára. Eddig a hardveres videogyorsítókkal támogatott valós idejű shader modellekben csak kétféle árnyékoló van definiálva: és (a DirectX 9 API definíciójában). A jövőben a DirectX 10 egyre többet ígér nekik.

Vertex Shader

A csúcsárnyékolók olyan videó chipek által végrehajtott programok, amelyek matematikai műveleteket hajtanak végre csúcsokkal (csúcs, 3D -s objektumokat alkotnak a játékokban), más szóval lehetővé teszik programozható algoritmusok végrehajtását a csúcsok és világításuk paramétereinek megváltoztatásához (T&L - Átalakítás és világítás) ... Minden csúcsot több változó határoz meg, például egy csúcs helyzetét a 3D térben az x, y és z koordináták határozzák meg. A csúcsokat színjellemzőkkel, textúrakoordinátákkal stb. Is le lehet írni. A csúcsárnyékolók az algoritmusoktól függően megváltoztatják ezeket az adatokat munkájuk során, például új koordináták és / vagy színek kiszámításával és írásával. Vagyis a csúcsárnyékoló bemeneti adatai a jelenleg feldolgozás alatt álló geometriai modell egyik csúcsára vonatkozó adatok. Ezek általában térbeli koordináták, normál, színösszetevők és textúrakoordináták. A végrehajtott program eredményei a bemenetként szolgálnak a csővezeték további részéhez, a raszterizátor lineáris interpolációt végez a bemeneti adatokhoz a háromszög felületéhez, és minden pixelhez végrehajtja a megfelelő pixel árnyékolót. Egy nagyon egyszerű és durva (de világos, remélem) példa: a csúcsárnyékoló lehetővé teszi 3D gömb objektum felvételét, és egy csúcsárnyékoló segítségével zöld kockát készít belőle :).

Az NV20 videochip megjelenése előtt a fejlesztőknek két módja volt, vagy saját programjaikat és algoritmusaikat használták, amelyek megváltoztatják a csúcsok paramétereit, de akkor minden számítást a CPU (szoftver T&L) végez, vagy a fix algoritmusok videochipekben, a hardverátalakítás és a világítás támogatásával (hardver T&L). A legelső DirectX shader modell nagy előrelépést jelentett a csúcsok átalakítására és világítására szolgáló fix funkcióktól a teljesen programozható algoritmusokig. Lehetővé vált például, hogy a nyúzás algoritmusát teljes egészében videochipeken futtassák le, és előtte az egyetlen lehetőség az volt, hogy univerzális központi processzorokon hajtották végre. Most, hogy a képességek jelentősen javultak a fent említett NVIDIA chip ideje óta, sokat tehet a csúcsokkal a csúcsárnyékolók használatával (kivéve azok létrehozását) ...

Példák a csúcsárnyékolók alkalmazására és hol:

Pixel Shader

A pixel árnyékolók olyan programok, amelyeket a videochip a kép minden egyes pixelére raszterezés közben hajt végre, textúra mintavételt és / vagy matematikai műveleteket végeznek a képpontok szín- és mélységértékén (Z-puffer). A geometriaátalakítás és a megvilágítási műveletek befejezése után az összes pixel árnyékoló utasítást képpontonként hajtják végre. Munkája eredményeként a pixel shader előállítja a pixel színének végső értékét és a Z-értéket a grafikus folyamat következő szakaszához, a keveréshez. A legegyszerűbb példa egy idézhető pixel -árnyékolóra: banális multitexturing, csak két textúra (például diffúz és lightmap) összekeverése, és a számítás eredményének egy pixelre történő ráerőltetése.

A pixelárnyékolók hardveres támogatásával rendelkező videóchipek megjelenése előtt a fejlesztőknek csak a hagyományos multitexturálás és az alfa -keverés lehetőségei voltak, amelyek jelentősen korlátozták számos vizuális effektus lehetőségeit, és nem tették lehetővé a jelenleg rendelkezésre álló lehetőségek nagy részét. És ha a geometriával valami mást is lehetne programszerűen csinálni, akkor képpontokkal - nem. A DirectX korai verziói (legfeljebb 7,0 -ig) mindig függőlegesen végezték el az összes számítást, és rendkívül korlátozott funkcionalitást kínáltak a pixelenkénti megvilágításhoz (ne felejtsük el az EMBM -et - környezeti bump leképezés és DOT3) a legújabb verziókban. A pixel árnyékolók lehetővé tették, hogy fejlesztő által programozott anyagok felhasználásával pixelről pixelre megvilágítsanak bármilyen felületet. Az NV20 -ban megjelenő 1.1 (DirectX értelemben) képpont -árnyékolók nemcsak többszöveg -feldolgozásra képesek, hanem sokkal többre is, bár az SM1 -t használó játékok többsége egyszerűen a hagyományos többszöveg -feldolgozást használta a legtöbb felületen, és csak a felület egy részén hajtott végre bonyolultabb pixelárnyékolókat. felületek, különféle speciális effektek létrehozásához (mindenki tudja, hogy a víz még mindig a leggyakoribb példa a pixel árnyékolók játékokban való használatára). Most, az SM3 és az azokat támogató videochipek megjelenése után a pixelárnyékolók képességei megnőttek, és lehetővé teszik, hogy segítségükkel, bár bizonyos korlátokkal, akár a raytracing -et is lehetővé tegyék.

Példák a pixel árnyékolók használatára:

Eljárási textúrák

Az eljárási textúrák matematikai képletekkel leírt textúrák. Az ilyen textúrák nem foglalnak helyet a videomemóriában, ezeket a pixel shader hozza létre "menet közben", mindegyik elemük (texel) a megfelelő shader parancsok végrehajtásának eredményeként jön létre. A leggyakoribb eljárási textúrák a következők: különböző típusú zajok (például fraktálzaj), fa, víz, láva, füst, márvány, tűz stb., Vagyis azok, amelyek viszonylag egyszerűen leírhatók matematikailag. Az eljárási textúrák lehetővé teszik animált textúrák használatát is, a matematikai képletek enyhe módosításával. Például az így készített felhők dinamikában és statikában is elég tisztességesnek tűnnek.

Az eljárási textúrák előnyei magukban foglalják az egyes textúrák korlátlan részletességét is, egyszerűen nem lesz pixelesítés, a textúra mindig a megjelenítéshez szükséges méretben jön létre. Az animált is nagy érdeklődésre tart számot, segítségével hullámokat csaphat a vízre, előre kiszámított animált textúrák használata nélkül. Az ilyen textúrák másik előnye, hogy minél többet használják őket egy termékben, annál kevesebb munkát kell végezniük a művészeknek (bár inkább a programozóknak), hogy rendszeres textúrákat hozzanak létre.

Sajnos az eljárási textúrákat még nem használták megfelelően a játékokban, a valós alkalmazásokban még mindig könnyebb betölteni a szabályos textúrát, a videomemória mennyisége ugrásszerűen növekszik, a legmodernebb gyorsítókban már 512 megabájtot telepítenek dedikált videomemória, amelyre nagyobb szükség van, mint kölcsönkérni valamit. Sőt, még mindig gyakran az ellenkezőjét teszik - a pixelárnyékolók matematikájának felgyorsítása érdekében keresési táblázatokat (LUT) használnak - speciális textúrákat, amelyek a számítások eredményeként kapott előre kiszámított értékeket tartalmazzák. Annak érdekében, hogy ne számítsunk néhány matematikai utasítást minden egyes képpontra, egyszerűen kiolvassák a textúrából az előre kiszámított értékeket. De minél tovább, annál inkább a matematikai számítások felé kell helyezni a hangsúlyt, vegye ugyanazokat az új generációs ATI videochipeket: RV530 és R580, amelyek 12 és 48 pixeles processzorral rendelkeznek minden 4 és 16 textúraegységhez. Sőt, ha 3D textúrákról beszélünk, mert ha a kétdimenziós textúrák problémamentesen elhelyezhetők a gyorsító helyi memóriájában, akkor a 3D textúrák sokkal többet igényelnek belőle.

Példák eljárási textúrákra:

Bump Mapping / Specular Bump Mapping

A bumpmapping egy technika a szabálytalanságok szimulálására (vagy a mikrorelief modellezésére, amelyik jobban tetszik) sík felületen, nagy számítási költségek és geometriai változások nélkül. A felület minden egyes pixelére a világítás kiszámítása egy speciális magasságtérkép értékei alapján történik, amelyet bumpmap -nek neveznek. Ez általában 8 bites fekete-fehér textúra, és a textúra színértékei nincsenek átfedve, mint a hagyományos textúrák, hanem a felület érdességének leírására szolgálnak. Az egyes texelek színe határozza meg a megfelelő domborzati pont magasságát, a magasabb értékek magasabb magasságot jelentenek az eredeti felület felett, és az alacsonyabb értékek alacsonyabbak. Vagy fordítva.

Egy pont megvilágításának mértéke a fénysugarak beesési szögétől függ. Minél kisebb a szög a normál és a fénysugár között, annál nagyobb a felület megvilágítása. Vagyis, ha sík felületet vesz fel, akkor a normál értékek minden ponton azonosak és a megvilágítás is azonos lesz. És ha a felület egyenetlen (valójában szinte minden felület a valóságban), akkor a normálok minden ponton eltérőek lesznek. És a megvilágítás más, az egyik ponton több lesz, a másikban kevesebb. Innen ered a bumpmapping elve - a sokszög különböző pontjainak szabálytalanságainak modellezéséhez felületi normákat állítunk be, amelyeket figyelembe veszünk a pixelenkénti megvilágítás kiszámításakor. Ennek eredményeképpen természetesebb képet kapunk a felületről, a bumpmapping részletesebb felületeket ad, mint például a tégla dudorok, a bőr pórusai stb., Anélkül, hogy növelné a modell geometriai összetettségét, mivel a számításokat a pixel szintjét. Ezenkívül, amikor a fényforrás helyzete megváltozik, ezeknek a szabálytalanságoknak a megvilágítása helyesen változik.

Természetesen a csúcsok megvilágítása számítástechnikailag sokkal egyszerűbb, de túl irreálisnak tűnik, különösen viszonylag alacsony poli-geometriával, az egyes pixelek színinterpolációja nem képes a csúcsok számított értékeinél nagyobb értékeket reprodukálni. Vagyis a háromszög közepén lévő pixelek nem lehetnek fényesebbek, mint a csúcs közelében lévő töredékek. Következésképpen azok a területek, ahol a megvilágítás hirtelen megváltozik, mint például a vakítás és a fényforrások nagyon közel a felszínhez, fizikailag nem jelennek meg megfelelően, és ez különösen a dinamikában lesz észrevehető. Természetesen a probléma részben megoldható a modell geometriai összetettségének növelésével, több csúcsra és háromszögre osztva, de a képpontonkénti megvilágítás a legjobb megoldás.

A folytatáshoz emlékeztetnie kell a világítás összetevőire. A felszíni pont színét a jelenet minden fényforrásából származó ideális, diffúz és tükröződő komponensek összegeként számítják ki (ideális esetben mindenkitől, gyakran sokan figyelmen kívül hagyják). Az egyes fényforrások ezen értékhez való hozzájárulása a fényforrás és a felület egy pontja közötti távolságtól függ.

Világítás alkatrészek:

Most adjunk hozzá néhány bump leképezést:

A világítás egységes (környezeti) összetevője egy közelítő, "kezdeti" megvilágítás a jelenet minden pontjára, amelynél minden pont egyformán világít, és a megvilágítás nem függ más tényezőktől.
A fény diffúz komponense a fényforrás helyzetétől és a normál felülettől függ. Ez a világítási komponens az objektum minden csúcsánál más és más, ami hangerőt ad nekik. A fény már nem tölti fel a felületet azonos árnyalattal.
A megvilágítás tükrös összetevője a felszínről érkező fénysugarak visszaverődésében nyilvánul meg. Számításához a fényforrás helyzetének vektorán és a normálon kívül további két vektort használnak: a tekintet irányának vektorát és a visszaverődés vektorát. A Specular világítási modellt először Phong Bui-Tong javasolta. Ezek a fellángolások jelentősen növelik a kép valósághűségét, mert a ritka valódi felületek nem tükrözik a fényt, ezért a szemcsés komponens nagyon fontos. Különösen mozgásban, mert a vakító fény azonnal megmutatja a kamera vagy a tárgy helyzetének változását. Később a kutatók más módszerekkel rukkoltak elő ennek a komponensnek a kiszámításához, bonyolultabbak (Blinn, Cook-Torrance, Ward), figyelembe véve a fényenergia eloszlását, az anyagok általi elnyelését és diffúz komponens formájában történő szórását.

Tehát a Specular Bump Mapping a következőképpen kapható:

És lássuk ugyanezt a játék példájával, a Call of Duty 2 -vel:

A kép első töredéke bumpmapping () nélkül jelenik meg, a második (jobbra fent) tükröződésmentes komponens nélküli bumpmapping, a harmadik a játékban használt normál nagyságú szemcsés komponenssel, és az utolsó , a jobb alsó részről, a lehető legnagyobb tükrös komponenssel.

Ami az első hardveralkalmazást illeti, a bumpmapping egyes típusait (Emboss Bump Mapping) már az NVIDIA Riva TNT chipeken alapuló videokártyák idején elkezdték használni, de az akkori technikák rendkívül primitívek voltak és nem voltak széles körben elterjedtek. A következő ismert típus a Environment Mapped Bump Mapping (EMBM) volt, de akkoriban csak a Matrox videokártyák rendelkeztek hardveres támogatással a DirectX -ben, és a felhasználás ismét erősen korlátozott volt. Aztán megjelent a Dot3 Bump Mapping, és az akkori videóchipek (GeForce 256 és GeForce 2) három passzra szorultak ahhoz, hogy teljes mértékben végrehajthassák egy ilyen matematikai algoritmust, mivel ezeket két, egyszerre használt textúra korlátozza. Az NV20 -tól (GeForce3) kiindulva lehetővé vált, hogy ugyanazt egyetlen lépésben megtehessük a pixel árnyékolók segítségével. Tovább tovább. Kezdtek hatékonyabb technikákat alkalmazni, mint pl.

Példák a bumpmapping használatára a játékokban:

Az elmozdulás -leképezés egy módszer a részletek hozzáadására a 3D objektumokhoz. Ellentétben az ütközésképekkel és más, pixelenkénti módszerekkel, amikor csak egy pont megvilágítását modellezik helyesen a magassági térképek, de térbeli helyzete nem változik, ami csak a felszíni komplexitás növekedésének illúzióját kelti, az elmozdulási térképek lehetővé teszik, hogy valódi összetett 3D objektumok csúcsokból és sokszögekből, korlátozások nélkül. Ez a módszer áthelyezi a háromszögek csúcsait azáltal, hogy az elmozdulási térképek értékei alapján normalizálja őket. Az elmozdulási térkép általában fekete-fehér textúra, és a benne található értékekkel határozzák meg az objektum felületének minden pontjának magasságát (az értékek 8 vagy 16 bites számként tárolhatók) , hasonló a bumpmap -hez. Az elmozdulási térképeket gyakran használják (ebben az esetben magasságtérképeknek is nevezik) dombok és völgyek domborzatának létrehozásához. Mivel a terepet kétdimenziós elmozdulási térkép írja le, szükség esetén viszonylag könnyen deformálható, mivel ehhez csak az elmozdulási térkép módosítására és a felület alapján történő megjelenítésére lenne szükség a következő képkockában.

A képen jól látható az elmozdulási térképek segítségével létrehozott tájkép. Kezdetben 4 csúcsot és 2 sokszöget használtak, ennek eredményeként a táj teljes értékű darabja alakult ki.

Az elmozdulási térképek átfedésének nagy előnye nem csak az, hogy részleteket adhatunk a felülethez, hanem az objektum szinte teljes megalkotása. Egy alacsony poli-objektumot veszünk fel, és több csúcsra és sokszögre osztjuk. A tesszelláció által előállított csúcsokat ezután a normál mentén elmozdítjuk az elmozdulási térképen olvasott érték alapján. Végül egy komplex 3D objektumot kapunk egy egyszerű objektumból a megfelelő elmozdulási térkép segítségével:

A tesszelláció által létrehozott háromszögek számának elég nagynak kell lennie ahhoz, hogy rögzítse az elmozdulási térkép által meghatározott összes részletet. Néha további háromszögek jönnek létre automatikusan N-javítások vagy más módszerek használatával. Az elmozdulási térképeket a legjobban a bump leképezéssel együtt lehet használni, hogy finom részleteket hozzanak létre ott, ahol elegendő a képpontonkénti megfelelő megvilágítás.

Az elmozdulás leképezését először a DirectX 9.0 támogatta. Ennek az API -nak ez volt az első verziója, amely támogatta az elmozdulás -leképezési technikát. A DX9 kétféle elmozdulási leképezést támogat, szűrve és előre mintavételezve. Az első módszert az elfelejtett MATROX Parhelia videochip, a másodikat pedig az ATI RADEON 9700 támogatta. A szűrt módszer annyiban különbözik, hogy lehetővé teszi a mip -szintek használatát az elmozdulási térképekhez és a trilineáris szűrés alkalmazását. Ennél a módszernél az elmozdulási térkép mip szintjét minden csúcshoz a csúcs és a kamera közötti távolság alapján választják ki, vagyis a részletességi szint automatikusan kiválasztásra kerül. Ezzel a jelenet szinte egyenletes felosztása érhető el, ha a háromszögek nagyjából azonos méretűek.

Az elmozdulás -feltérképezés lényegében geometriai tömörítési technikának tekinthető; az elmozdulási térképek használata csökkenti az adott 3D modellrészlethez szükséges memória mennyiségét. A terjedelmes geometriaadatokat egyszerű 2D elmozdulási textúrákkal helyettesítik, általában 8 vagy 16 bites. Ez csökkenti a memória és a sávszélesség követelményeit, amelyek szükségesek ahhoz, hogy a geometriai adatokat a videochipre juttassák, és ezek a korlátozások a mai rendszerek között a legfontosabbak. Alternatív megoldásként, azonos sávszélességgel és tárolási követelményekkel, az elmozdulás leképezése sokkal összetettebb geometriai 3D modelleket tesz lehetővé. A sokkal kevésbé bonyolult modellek használata, amikor háromszög tízezrei vagy százezrei helyett ezres egységeket használnak, lehetővé teszi azok animációjának felgyorsítását is. Vagy fejlessze azt bonyolultabb komplex algoritmusok és technikák alkalmazásával, például textilszimulációval.

További előny, hogy az elmozdulási térképek használatával a bonyolult sokszögű 3D -s háló több, 2D -s textúrává alakul, amelyeket könnyebb feldolgozni. Például a szervezet számára rendszeres mip-leképezést használhat az elmozdulási térképek átfedésére. Ezenkívül a háromdimenziós hálók tömörítésének viszonylag bonyolult algoritmusai helyett a szokásos, akár JPEG-szerű textúrák tömörítési módszereit is használhatja. A 3D objektumok eljárási létrehozásához pedig használhatja a 2D textúrák szokásos algoritmusait.

De az elmozdulási térképeknek is vannak bizonyos korlátai, nem alkalmazhatók minden helyzetben. Például a sima objektumok, amelyek nem tartalmaznak sok apró részletet, jobban ábrázolhatók szabványos hálóként vagy más magasabb szintű felületekként, például Bezier-görbékként. Másrészt a nagyon összetett modelleket, például a fákat vagy növényeket sem könnyű ábrázolni az elmozdulási térképekkel. Használatuk kényelmével is vannak problémák, ez szinte mindig speciális segédprogramokat igényel, mert nagyon nehéz közvetlenül elmozdulási térképeket készíteni (ha nem egyszerű tárgyakról, például tájról beszélünk). Az elmozdulási térképek eredendő problémái és korlátai közül sok ugyanaz, mint azoké, mivel a két módszer lényegében egy hasonló elképzelés két különböző ábrázolása.

Valódi játékokból példaként egy olyan játékot említek, amely textúra mintavételt használ egy vertex shader -ből, ami az NVIDIA NV40 videochipekben és a Shader Model 3.0 -ban jelent meg. A csúcs textúrázása alkalmazható egy egyszerű elmozdulási leképezési módszerre, amelyet teljes egészében a GPU hajt végre, tesszelláció nélkül (több háromszögre bontva). Egy ilyen algoritmus alkalmazása korlátozott, csak akkor van értelme, ha a térképek dinamikusak, vagyis változnak a folyamat során. Például ez a nagy vízfelületek renderelése, ami a Pacific Fighters játékban történik:

A Normalmapping a korábban leírt bumpmapping technika továbbfejlesztett változata, annak kibővített változata. A Blumpmapping -et a Blinn fejlesztette ki még 1978 -ban, ahol a felületi normákat ezzel a domborzati térképészeti módszerrel módosítják a tereptérképezési módszerrel. Míg a bumpmapping csak a meglévő normál értéket változtatja meg a felületi pontoknál, a normalmapping teljesen felváltja a normál értékeket, és lekéri értékeiket egy speciálisan elkészített normál térképről. Ezek a térképek általában textúrák, amelyekben előre kiszámított normál értékek vannak tárolva, és RGB színkomponensként vannak ábrázolva (azonban vannak speciális formátumok a normál térképekhez, beleértve a tömörítésűeket is), ellentétben a 8 bites fekete-fehér magassággal térképek a bumpmappingben.

Általánosságban elmondható, hogy a bump leképezéshez hasonlóan ez is egy "olcsó" módszer a viszonylag alacsony geometriai összetettségű modellek részletességének növelésére, valódi geometria használata nélkül, csak fejlettebb. A technika egyik legérdekesebb felhasználása az alacsony poli-modellek részletességének jelentős növelése a normál térképek használatával, amelyeket ugyanazon nagy geometriai összetettségű modell feldolgozásával kaptak. A normál térképek részletesebb leírást tartalmaznak a felületről, mint a bumpmapping, és lehetővé teszik a bonyolultabb formák ábrázolását. A múlt század 90-es évek közepén hangzottak el ötletek a rendkívül részletes tárgyakból származó információk megszerzésére, de akkor a felhasználásról volt szó. Később, 1998-ban ötleteket mutattak be a részletek normál térképek formájában történő átvitelére a magas poli-modellekről az alacsony poli-modellekre.

A normál térképek hatékonyabb módot kínálnak a részletes felszíni adatok tárolására, mint egyszerűen sok sokszög használata. Az egyetlen komoly korlátozásuk az, hogy nem nagyon alkalmasak nagy részletekre, mert a normál leképezés valójában nem ad hozzá sokszögeket, és nem változtatja meg az objektum alakját, csak megjelenését hozza létre. Ez csak a részletek szimulációja a pixel szintű világítás számításain alapulva. A tárgy szélső sokszögeinél és a felület nagy dőlésszögénél ez nagyon észrevehető. Ezért a normális leképezés legésszerűbb módja az, hogy az alacsony poli modellt kellően részletesre kell állítani az objektum alapvető alakjának megőrzéséhez, és normál térképekkel finomabb részleteket kell hozzáadni.

A normál térképeket általában a modell két változatából, az alacsony és a magas poli -ból állítják elő. Az alacsony poli modell minimális geometriából, az objektum alapvető formáiból áll, a magas poli modell pedig mindent tartalmaz, amire szüksége van a maximális részletességhez. Ezután speciális segédprogramok segítségével összehasonlítják őket egymással, a különbséget kiszámítják és egy normál térképnek nevezett textúrában tárolják. Létrehozásakor ezenkívül bump térképet is használhat nagyon apró részletekre, amelyek még magas poli-modell esetén sem modellezhetők (bőrpórusok, egyéb apró mélyedések).

A normál térképeket eredetileg rendes RGB textúrákként ábrázolták, ahol az R, G és B színkomponenseket (0-1) X, Y és Z koordinátákként értelmezik. A normál térképek kétféle lehetnek: koordinátákkal a modelltérben (általános koordináta -rendszer) vagy érintőtérrel (az orosz kifejezés "érintő tér", egy háromszög helyi koordináta -rendszere). A második lehetőséget gyakrabban használják. Ha normál térképeket mutatnak be a modelltérben, akkor azoknak három összetevőből kell állniuk, mivel minden irány ábrázolható, és amikor a helyi koordinátarendszerben, az érintő térben van, akkor két komponenssel meg lehet birkózni, a harmadikat pedig egy pixelben shader.

A modern valós idejű alkalmazások a képminőség tekintetében még mindig jelentősen felülmúlják az előre renderelt animációt, ez elsősorban a megvilágítás minőségére és a jelenetek geometriai összetettségére vonatkozik. A valós időben számított csúcsok és háromszögek száma korlátozott. Ezért a geometria mennyiségének csökkentésére szolgáló módszerek nagyon fontosak. A normál leképezés előtt számos ilyen módszert fejlesztettek ki, de az alacsony poli modellek, még a bumpmapping esetén is, sokkal rosszabbak, mint a bonyolultabb modellek. Bár a normál leképezésnek számos hátránya van (a legnyilvánvalóbb - mivel a modell továbbra is alacsony poli, ez könnyen látható szögletes határain), a végső renderelési minőség észrevehetően javul, és a modellek geometriai összetettsége alacsony marad. A közelmúltban jól látható volt ennek a technikának a népszerűsége és az összes népszerű játékmotorban való használata. Ennek oka a kiváló eredményminőség és a modellek geometriai összetettségére vonatkozó követelmények egyidejű csökkentése. A szokásos leképezési technikát ma már szinte mindenhol használják, minden új játék a lehető legszélesebb körben használja. Íme egy rövid lista a híres PC-játékokról, amelyek normál leképezést alkalmaznak: Far Cry, Doom 3, Half-Life 2, Call of Duty 2, FEAR, Quake 4. Mindegyik sokkal jobban néz ki, mint a múltbeli játékok, többek között a térképek normáljainak használata.

Ennek a technikának csak egyetlen negatív következménye van - a textúrák térfogatának növekedése. Hiszen egy normál térkép erőteljesen befolyásolja egy objektum kinézetét, és kellően nagy felbontásúnak kell lennie, így a videomemóriára és sávszélességére vonatkozó követelmények megduplázódnak (tömörítetlen normál térképek esetén). De most már 512 megabájt helyi memóriával rendelkező videokártyákat is gyártanak, sávszélessége folyamatosan növekszik, a tömörítési módszereket kifejezetten a normál térképekhez fejlesztették ki, így ezek az apró korlátozások nem nagyon fontosak, sőt. A normál leképezés hatása sokkal nagyobb, lehetővé téve viszonylag alacsony poli-modellek használatát, csökkentve a geometriai adatok tárolásához szükséges memóriaigényt, javítva a teljesítményt és nagyon tisztességes vizuális eredményt adva.

Parallaxis térképezés / eltolás -leképezés

Az 1984 -ben kifejlesztett normál térképezést a Relief Texture Mapping követte, amelyet Olivera és Bishop vezetett be 1999 -ben. Ez egy textúra -leképezési technika, amely mélységi információkon alapul. A módszer nem talált alkalmazást a játékokban, de ötlete hozzájárult a parallaxis -leképezéssel kapcsolatos munka folytatásához és javításához. A Kaneko 2001 -ben vezette be a parallaxis leképezést, amely az első hatékony módszer volt a parallaxis hatás pixelenkénti megjelenítésére. 2004 -ben a walesi demonstrálta a parallaxis leképezés használatát a programozható videochipeken.

Ennek a módszernek talán a legkülönbözőbb nevei vannak. Felsorolom azokat, amelyekkel találkoztam: Parallaxis-leképezés, eltolás-leképezés, virtuális elmozdulás-leképezés, képpontonkénti elmozdulás-leképezés. Az első címet a cikk a rövidség kedvéért használja.
A parallaxis -leképezés egy másik alternatíva a dudor -leképezéshez és a normál leképezési technikákhoz, amely még több betekintést nyújt a felületi részletekbe, a 3D -s felületek természetesebb megjelenítése, túl sok teljesítmény elvesztése nélkül. Ez a technika hasonlít az elmozdulás -feltérképezéshez és a normál leképezéshez egyszerre, valahol a kettő között van. A módszert úgy is tervezték, hogy több felületrészletet jelenítsen meg, mint az eredeti geometriai modell. Hasonló a normál leképezéshez, de a különbség az, hogy a módszer torzítja a textúraleképezést azáltal, hogy megváltoztatja a textúrakoordinátákat úgy, hogy amikor a felületet különböző szögből nézi, akkor domborúnak tűnik, bár a valóságban a felület lapos és nem változik . Más szóval, a Parallax Mapping egy olyan technika, amely közelíti a felületi pontok eltolásának hatását a nézőpont változásától függően.

A technika eltolja a textúra koordinátáit (ezért a technikát néha offset leképezésnek is nevezik), így a felület terjedelmesebbnek tűnik. A módszer lényege, hogy visszaadjuk annak a pontnak a textúrakoordinátáit, ahol a nézetvektor metszi a felületet. Ehhez a magasságtérképhez sugárkövetés (sugárkövetés) szükséges, de ha nincs túl sok változó értéke ("sima" vagy "sima"), akkor a közelítés mellőzhető. Ez a módszer simán változó magasságú felületekre jó, a metszéspontok téves kiszámítása és a nagy eltolási értékek nélkül. Egy ilyen egyszerű algoritmus csak három pixeles árnyékoló utasítással tér el a normál leképezéstől: két matematikai utasítás és egy további lekérés a textúrából. Miután kiszámította az új textúrakoordinátát, tovább olvassa a többi textúraréteget: alap textúra, normál térkép stb. Ez a módszer a parallaxis leképezésre a modern videochipeken majdnem olyan hatékony, mint a hagyományos textúraleképezés, és eredménye egy valósághűbb felületi megjelenítés, mint az egyszerű normál leképezés.

De a hagyományos parallaxis leképezés használata a magasságtérképekre korlátozódik, az értékekben kis különbség van. A "meredek" szabálytalanságokat az algoritmus helytelenül dolgozza fel, különböző műtermékek jelennek meg, textúrák "lebegnek" stb. Számos módosított módszert fejlesztettek ki a parallaxis leképezési technika javítására. Több kutató (Yerex, Donnelly, Tatarchuk, Policarpo) új módszereket írt le, amelyek javítják a kezdeti algoritmust. Szinte minden ötlet a pixelek árnyékolójában alkalmazott sugárkövetésen alapul, hogy meghatározza a felületi részletek metszéspontját. A módosított technikák több különböző nevet kaptak: Parallaxis Térképezés elzáródással, Parallaxis Térképezés Távolsági Funkciókkal, Parallax Okklúziós Térkép. A rövidség kedvéért mindkettőt Parallax Occlusion Mapping -nek fogjuk nevezni.

A Parallax Occlusion Mapping módszerek közé tartozik a sugárkövetés is a magasságok meghatározásához és a texelek láthatóságának figyelembevételéhez. Valójában a felülethez képest szögben nézve a texelek blokkolják egymást, és ezt szem előtt tartva nagyobb mélységet adhat a parallaxis hatásnak. Az így kapott kép valósághűbbé válik, és az ilyen továbbfejlesztett módszerek használhatók a mélyebb megkönnyebbüléshez, kiválóan alkalmas tégla- és kőfalak, járdák stb. Ábrázolására. Különösen meg kell jegyezni, hogy a fő különbség a parallaxis -térképezés és az elmozdulás -leképezés között az, hogy a számítások minden pixeles, és nem felületes. Ezért van a módszernek olyan neve, mint a virtuális elmozdulás-leképezés és a képpontonkénti elmozdulás-leképezés. Nézd meg a képet, nehéz elhinni, de a járda kövei itt csak pixelről pixelre hatnak:

A módszer lehetővé teszi a részletes felületek hatékony megjelenítését anélkül, hogy több millió csúcsot és háromszöget igényelne a geometria megvalósításakor. Ugyanakkor a nagy részletesség megmarad (kivéve a sziluetteket / éleket), és az animációs számítások jelentősen leegyszerűsödnek. Ez a technika olcsóbb, mint a valódi geometria, és lényegesen kevesebb sokszöget használnak, különösen azokban az esetekben, ahol nagyon apró részletek vannak. Az algoritmusnak számos alkalmazása van, és ez a legjobban alkalmas kövek, téglák és hasonlók számára.

Ezenkívül további előny, hogy a magassági térképek dinamikusan változhatnak (vízfelület hullámokkal, golyólyukak a falakon és még sok más). A módszer hátránya a geometriailag helyes sziluettek (az objektum élei) hiánya, mert az algoritmus pixelről-pixelre épül, és nem valós elmozdulási leképezés. Ez azonban teljesítményt takarít meg az átalakítás, a megvilágítás és a geometria animációjának csökkentett terhelése formájában. Megtakarítja a nagy mennyiségű geometriai adatok tárolásához szükséges videomemóriát. A technika előnyei a viszonylag egyszerű integráció a meglévő alkalmazásokba, valamint a szokásos segédprogramok használata a normál leképezéshez.

A technikát már használták az utóbbi idők igazi játékaiban. Eddig egyszerű parallaxis leképezéssel boldogulnak statikus magassági térképek alapján, sugárkövetés és kereszteződések kiszámítása nélkül. Íme néhány példa arra, hogy a parallaxis leképezés hogyan használható játékokban:

Utófeldolgozás

Tág értelemben az utófeldolgozás minden, ami a képalkotás fő lépései után történik. Más szóval, az utófeldolgozás a kép bármilyen módosítása a renderelés után. Az utófeldolgozás speciális vizuális effektusok létrehozására szolgáló eszközkészlet, és ezek létrehozását a jelenet renderelésével kapcsolatos fő munka elvégzése után hajtják végre, vagyis az utófeldolgozó effektusok létrehozásakor egy kész bitképet használnak.

Egy egyszerű példa egy fényképből: tiszta időben fényképezett egy gyönyörű zöldellő tavat. Az ég nagyon világos, és a fák túl sötétek. Betölti a fényképet egy grafikus szerkesztőbe, és elkezdi megváltoztatni a fényerőt, a kontrasztot és a többi paramétert a kép egyes területein vagy a teljes képen. De már nincs lehetősége módosítani a kamera beállításait, elvégzi a kész kép feldolgozását. Ez utófeldolgozás. Vagy egy másik példa: válasszon hátteret portréfotózásban, és alkalmazzon homályos szűrőt az adott területre a mélységélesség érdekében, nagyobb mélységgel. Vagyis amikor módosít vagy javít egy keretet egy grafikus szerkesztőben, akkor utófeldolgozást végez. Ugyanezt meg lehet tenni a játékban, valós időben.

A renderelés utáni képfeldolgozásnak sokféle lehetősége van. Mindenki valószínűleg sok úgynevezett grafikus szűrőt látott a grafikus szerkesztőkben. Pontosan ezt nevezik utószűrőknek: elmosódás, élfelismerés, élesítés, zaj, sima, dombornyomás stb. Valós idejű 3D -s renderelés esetén ez a következőképpen történik - az egész jelenet egy különleges területre, a renderelésre kerül cél, és a fő renderelés után ezt a képet a pixel árnyékolók segítségével is feldolgozzák, és csak ezután jelenítik meg a képernyőn. A játékok utófeldolgozó hatásai közül a leggyakrabban használt ,,. Sok más utóhatás is létezik: zaj, fellángolás, torzítás, szépia stb.

Íme néhány kiváló példa a játékalkalmazások utófeldolgozására:

Nagy dinamikus tartomány (HDR)

A 3D -s grafikákra alkalmazott nagy dinamikus tartomány (HDR) a nagy dinamikatartományú megjelenítés. A HDR lényege, hogy az intenzitást és a színt valós fizikai mennyiségekkel írja le. A kép leírásának szokásos modellje az RGB, amikor minden szín az elsődleges színek összegeként van ábrázolva: piros, zöld és kék, különböző intenzitással, lehetséges 0 és 255 közötti egész értékek formájában, kódolva nyolc bit színenként. A maximális intenzitás és a minimum közötti arányt, amelyet egy adott modell vagy eszköz megjeleníthet, dinamikus tartománynak nevezzük. Tehát az RGB modell dinamikus tartománya 256: 1 vagy 100: 1 cd / m 2 (két nagyságrend). Ezt a színek és intenzitás leírására szolgáló modellt általában alacsony dinamikus tartománynak (LDR) nevezik.

A lehetséges LDR -értékek minden esetben nyilvánvalóan nem elegendőek, egy személy sokkal nagyobb tartományt lát, különösen gyenge fényintenzitás mellett, és az RGB -modell ilyen esetekben (és nagy intenzitás esetén is) túl korlátozott. Az emberi látás dinamikus tartománya 10 -6 és 10 8 cd / m 2, azaz 10.000.000.000.000: 1 (14 nagyságrend). Nem láthatjuk egyszerre a teljes tartományt, de a szemmel látható tartomány minden egyes pillanatban megközelítőleg 10 000: 1 (négy nagyságrend). A látás fokozatosan alkalmazkodik a megvilágítási tartomány másik részéből származó értékekhez, az úgynevezett adaptáció segítségével, amelyet könnyen le lehet írni azzal a helyzettel, amikor éjszaka lekapcsolják a fényt egy szobában - először a szem nagyon keveset lát, de idővel alkalmazkodnak a megváltozott fényviszonyokhoz, és sokkal többet látnak. ... Ugyanez történik, amikor a sötét környezetet visszaállítja világosra.

Tehát az RGB leírási modell dinamikus tartománya nem elegendő ahhoz, hogy olyan képeket ábrázoljon, amelyeket egy személy képes látni a valóságban, ez a modell jelentősen csökkenti a fényerősség lehetséges értékeit a tartomány felső és alsó részében. A HDR -anyagok leggyakoribb példája egy napsütéses napon egy világos utcán egy sötétített, ablakos szoba képe. Az RGB modellnél vagy normál megjelenítést kaphat az ablakon kívülről, vagy csak azt, ami a szobában van. Az LDR -ben a 100 cd / m 2 -nél nagyobb értékeket általában kivágják, ezért is nehéz 3D -s renderelésben a közvetlenül a fényképezőgépbe irányított fényes fényforrásokat megfelelően megjeleníteni.

Eddig maguk az adatmegjelenítő eszközök nem fejleszthetők komolyan, és célszerű elhagyni az LDR -t a számítások során, használhatja az intenzitás és a szín (vagy lineárisan arányos) valós fizikai értékeit, és megjelenítheti a maximumot a monitor. A HDR -reprezentáció lényege abban rejlik, hogy az intenzitás és a színértékeket valós fizikai mennyiségben vagy lineárisan arányos módon kell használni, és nem egész számokat, hanem lebegőpontos számokat használunk nagy pontossággal (például 16 vagy 32 bit). Ez megszünteti az RGB modell korlátait, és drámaian megnöveli a kép dinamikus tartományát. De ekkor bármilyen HDR kép megjeleníthető bármilyen megjelenítési adathordozón (ugyanazon az RGB monitoron), a lehető legjobb minőségben, speciális algoritmusok használatával.

A HDR renderelés lehetővé teszi az expozíció megváltoztatását a kép renderelése után. Lehetővé teszi az emberi látás alkalmazkodásának hatásának szimulálását (a világos nyílt terekről a sötét helyekre való áttérés és fordítva), lehetővé teszi a fizikailag helyes megvilágítást, és egységes megoldás az utófeldolgozási hatások (vakító fények, fények, virágzás) alkalmazására is , elmosódás). A képfeldolgozási algoritmusok, a színkorrekció, a gamma korrekció, a mozgás elmosódása, a virágzás és más utófeldolgozási módszerek jobban teljesítenek a HDR megjelenítésben.

A valós idejű 3D-s renderelő alkalmazásokban (főleg játékok) a HDR-renderelést nem olyan régen kezdték használni, mert számításokat és támogatást igényel a lebegőpontos formátumú renderelési célhoz, amely először csak olyan videóchipeken vált elérhetővé, amelyek támogatják a DirectX 9. A HDR-renderelés szokásos módja a játékokban: a jelenet lebegőpontos pufferre való visszaállítása, a kép utólagos feldolgozása kiterjesztett színtartományban (a kontraszt és a fényerő, a színegyensúly, a vakítás és a mozgás elmosódása, lencsefény és hasonlók), hangleképezés alkalmazásával a végső HDR -kép LDR megjelenítő eszközre kerül. Néha a környezeti térképeket HDR formátumban használják, az objektumok statikus tükrözéséhez a HDR használata nagyon érdekes a dinamikus fénytörések és tükröződések szimulálásában, ehhez lebegőpontos formátumú dinamikus térképek is használhatók. Ehhez további, előre kiszámított és HDR formátumban mentett fénytérképeket adhat hozzá. A fentiek nagy része megtörtént például a Half-Life 2: Lost Coast című filmben.

A HDR rendering nagyon hasznos a hagyományos módszereknél jobb minőségű, komplex utófeldolgozáshoz. Ugyanez a virágzás reálisabbnak tűnik, ha a HDR nézetmodellben számítják ki. Például, ahogy a Crytek Far Cry játékában is, a szabványos HDR -megjelenítési technikákat használja: a Kawase által biztosított virágzási szűrőket és a Reinhard hangleképezési operátort alkalmazza.

Sajnos bizonyos esetekben a játékfejlesztők HDR néven csak a szokásos LDR tartományban számított virágzási szűrőt rejthetik el. És bár a legtöbb, amit a HDR-leképezéssel ellátott játékokban jelenleg végeznek, jobb minőségű virágzás, a HDR-megjelenítés előnyei nem korlátozódnak erre az utóhatásra, ez a legegyszerűbb.

További példák a HDR-megjelenítésre valós idejű alkalmazásokban:

A hangleképezés az a folyamat, amellyel a HDR fénysűrűségtartományt egy kimeneti eszköz, például egy monitor vagy nyomtató által megjelenített LDR tartományba konvertálja, mivel a HDR képek megjelenítéséhez szükség lesz a HDR modell dinamikus tartományának és színskálájának átalakítására a megfelelő LDR dinamikára tartomány, leggyakrabban RGB. Hiszen a HDR -ben megjelenített fényerőtartomány nagyon széles, egyszerre több nagyságrendet jelent az abszolút dinamikus tartományban, egy jelenetben. A hagyományos kimeneti eszközökön (monitorok, televíziók) reprodukálható tartomány pedig csak körülbelül két nagyságrendű dinamikus tartomány.

A HDR -LDR átalakítást hangleképezésnek nevezik, és veszteséges, és utánozza az emberi látás tulajdonságait. Ezeket az algoritmusokat általában hangleképezési utasításoknak nevezik. A kezelők az összes kép fényerejét három különböző típusba sorolják: sötét, közepes és világos. A középtónusok fényerejének értékelése alapján a teljes megvilágítás korrigálásra kerül, a jelenetben lévő képpontok fényerejének értékei újraelosztásra kerülnek a kimeneti tartományba való belépéshez, a sötét képpontok világosabbak és a világosak sötétebbek. Ezután a kép legfényesebb képpontjai a kimeneti eszköz vagy a kimeneti nézet modell tartományához vannak méretezve. Az alábbi képen a HDR kép legegyszerűbb átalakítása látható LDR tartományba, lineáris transzformáció, és egy összetettebb hangleképezési operátor kerül alkalmazásra a központban lévő töredékre, amely a fentiek szerint működik:

Látható, hogy csak a nemlineáris hangleképezés használatával érheti el a kép részleteit, és ha a HDR -t lineárisan hozza, akkor sok apróság egyszerűen elveszik. Nincs egyetlen helyes hangleképezési algoritmus, több operátor is jó eredményeket ad különböző helyzetekben. Íme egy jó példa két különböző hangleképezési állításra:

A HDR megjelenítéssel együtt a hangleképezést nemrégiben használták a játékokban. Lehetségessé vált az emberi látás tulajdonságainak szimulálása: az élesség elvesztése sötét jeleneteknél, az új fényviszonyokhoz való alkalmazkodás a nagyon világos és sötét területek közötti átmenet során és fordítva, érzékenység a kontraszt, színváltozásokra ... Így a Far Cry alkalmazkodási képességének utánzása úgy néz ki, mint a Far Cry. Az első képernyőkép azt a képet mutatja, amelyet a játékos lát, amint éppen sötét szobából élénk megvilágítású nyílt térbe fordul, a második pedig ugyanazt a képet mutatja pár másodperccel az adaptáció után.

Virágzás

A Bloom az egyik filmes utófeldolgozó effektus, amely megvilágítja a kép legfényesebb részeit. Ez a nagyon erős fény hatása, amely izzásként jelenik meg a fényes felületek körül, a virágzó szűrő alkalmazása után az ilyen felületek nem csak további fényerőt kapnak, hanem a tőlük érkező fény (haló) részben befolyásolja a világos felületek melletti sötétebb területeket a keret. Ennek legegyszerűbb bemutatása egy példával:

A 3D Bloom grafikában a szűrő további utófeldolgozással történik - összekeverve az elmosódási szűrő által elmosódott képkockát (a teljes keretet vagy annak egyes világos területeit, a szűrőt általában többször alkalmazzák) és az eredeti keretet. Az egyik leggyakrabban használt virágzás utáni szűrő algoritmus a játékokban és más valós idejű alkalmazásokban:

• A jelenet keretbufferré van alakítva, az objektumok izzási intenzitását a puffer alfa csatornájába írják.
• A framebuffert egy speciális textúrába másolják a feldolgozáshoz.
• A textúra felbontása például 4 -szeresére csökken.
• Az alfa-csatornában rögzített intenzitási adatok alapján a képre többször alkalmaznak elhomályosító szűrőket (elmosódást).
• A kapott kép összekeveredik az eredeti kerettel a framebufferben, és az eredmény megjelenik a képernyőn.

A többi típusú utófeldolgozáshoz hasonlóan a virágzás a legjobb a nagy dinamikatartományú (HDR) rendereléshez. További példák a végső kép feldolgozására egy valós idejű 3D alkalmazásokból származó virágszűrővel:

Elmosódás

Mozgásos elmosódás fordul elő a fényképeken és a filmekben, mivel a képben lévő tárgyak a kép expozíciós ideje alatt elmozdulnak, miközben az objektív zárja nyitva van. A fényképezőgép által készített kép (fotó, film) nem jelenít meg pillanatképet, amely nulla időtartammal készült. A technológiai korlátok miatt a keret egy bizonyos időszakot mutat, amely idő alatt a keretben lévő objektumok el tudnak mozdulni egy bizonyos távolságot, és ha ez megtörténik, akkor a mozgó tárgy minden pozíciója megjelenik az objektív nyitott redőnye alatt a kereten homályos képként a mozgásvektor mentén ... Ez akkor fordul elő, ha az objektum a kamerához képest mozog, vagy a kamera a tárgyhoz viszonyítva, és az elmosódottság mennyisége képet ad a tárgy mozgási sebességének nagyságáról.

A háromdimenziós animációban az adott pillanatban (képkocka) az objektumok bizonyos koordinátákon helyezkednek el a háromdimenziós térben, hasonlóan a végtelenül gyors záridővel rendelkező virtuális kamerához. Ennek eredményeként nincs olyan elmosódás, amely hasonló a fényképezőgép és az emberi szem által a gyorsan mozgó tárgyak megtekintésekor tapasztaltakhoz. Természetellenesnek és irreálisnak tűnik. Vegyünk egy egyszerű példát: több gömb forog valamilyen tengely körül. Itt van egy kép arról, hogyan nézne ki ez a mozgás elmosódással és anélkül:

Az elmosódás nélküli kép alapján még azt sem lehet megállapítani, hogy a gömbök mozognak -e vagy sem, míg a mozgás elmosódása egyértelmű képet ad a tárgyak mozgásának sebességéről és irányáról. Egyébként a mozgás elmosódottságának hiánya is az oka annak, hogy a játékokban a 25-30 képkocka / másodperc sebességű mozgás rángatózónak tűnik, bár a filmek és a videók ugyanolyan képkockasebesség-paraméterek mellett jól néznek ki. A mozgásos elmosódottság hiányának kompenzálására nagy képsebesség (60 kép / másodperc vagy nagyobb) vagy további képfeldolgozási módszerek alkalmazása kívánatos a mozgás elmosódásának hatásának emulálására. Ezt az animáció zökkenőmentességének javítására, valamint a fotó- és filmrealizmus hatására használják.

A valós idejű alkalmazások legegyszerűbb mozgás-elmosási algoritmusa a korábbi animációs képkockák adatainak felhasználása az aktuális kép megjelenítéséhez. De léteznek hatékonyabb és korszerűbb mozgás-elmosási módszerek is, amelyek nem használnak korábbi képkockákat, hanem a keretben lévő objektumok mozgásvektorain alapulnak, és csak egy további utófeldolgozási lépést tesznek hozzá a megjelenítési folyamathoz. Az elmosódási hatás lehet teljes képernyős (általában utófeldolgozásban), vagy egyedi, leggyorsabban mozgó objektumok esetén.

A motion blur effektus lehetséges alkalmazási lehetőségei játékokban: minden versenyjáték (a nagyon nagy mozgási sebesség hatásának létrehozásához és a TV-hez hasonló ismétlések használatához), sportjátékok (ugyanazok az ismétlések, és magában a játékban az elmosódás alkalmazható nagyon gyorsan mozgó tárgyakra, például labdára vagy korongra, harci játékokra (közelharci fegyverek, karok és lábak gyors mozdulatai), sok más játékra (a motoron belüli 3D-s jelenetek során). Íme néhány példa a játékok elmosódott utóhatásaira:

Mélységélesség (DOF)

A mélységélesség röviden az objektumok elmosódása, attól függően, hogy milyen helyzetben vannak a kamera fókuszához képest. A való életben, a fényképeken és a filmekben nem minden tárgyat látunk egyformán tisztán, ez a szem szerkezetének sajátosságaiból, valamint a kamerák és mozikamerák optikájának szerkezetéből adódik. A fotó- és a filmművészeti optika bizonyos távolságra van, a fényképezőgéptől ilyen távolságra elhelyezkedő tárgyak fókuszban vannak és élesnek tűnnek a képen, a fényképezőgéptől távolabb vagy a közelében lévő tárgyak pedig éppen homályosnak tűnnek, az élesség fokozatosan csökken a távolság növekedésével vagy csökkenésével ...

Ahogy sejtette, ez egy fénykép, nem pedig renderelés. A számítógépes grafikában a renderelt kép minden objektuma tökéletesen tiszta, mivel a lencséket és az optikát nem utánozzák a számítások során. Ezért a fotó- és filmes realizmus elérése érdekében speciális algoritmusokkal kell valami hasonlót csinálni a számítógépes grafikához. Ezek a technikák szimulálják az eltérő fókusz hatását a különböző távolságú tárgyakra.

A valós idejű megjelenítés egyik gyakori technikája, hogy az eredeti keretet és annak elmosódott változatát (az elmosódási szűrő többszöri átvitele) összekeverik a kép pixeleinek mélységi adatai alapján. A játékokban a DOF -effektusnak többféle felhasználása is van, például a játékmotorok jelenetei, a sport- és versenyjátékok. Példák a mélységélességre valós időben:

Részletesség (LOD)

A 3D alkalmazások részletessége olyan módszer, amely csökkenti a képkockák renderelésének összetettségét, csökkenti a poligonok, textúrák és egyéb erőforrások számát egy jelenetben, és általában csökkenti annak összetettségét. Egy egyszerű példa: a fő karaktermodell 10 000 sokszögből áll. Azokban az esetekben, amikor a fényképezőgép közelében található a feldolgozott jelenetben, fontos, hogy minden sokszöget használjon, de a kamerától nagyon nagy távolságban csak néhány képpontot foglal el a végső képen, és nincs pont mind a 10 000 sokszög feldolgozásában. Talán ebben az esetben több száz sokszög, vagy akár néhány sokszög és egy speciálisan előkészített textúra elegendő lesz a modell megközelítőleg azonos megjelenítéséhez. Ennek megfelelően közepes távolságokban érdemes olyan modellt használni, amely több háromszögből áll, mint a legegyszerűbb modell, és kevesebb, mint a legösszetettebb.

A LOD módszert általában 3D jelenetek modellezésekor és megjelenítésekor használják, több bonyolultsági szint (geometriai vagy más) objektumok esetén, a tárgyaktól a kamerához mért távolság arányában. A technikát a játékfejlesztők gyakran használják a sokszögek számának csökkentésére egy jelenetben és a teljesítmény javítására. Ha a fényképezőgép közelében vannak, a lehető legtöbb részletet tartalmazó modelleket használják (a háromszögek száma, a textúrák mérete, a textúra összetettsége), a lehető legjobb képminőség érdekében, és fordítva, amikor a modelleket eltávolítják a fényképezőgépből , kevesebb háromszöget tartalmazó modelleket használnak a renderelési sebesség növelésére. A komplexitás megváltoztatása, különösen a modell háromszögeinek száma, automatikusan megtörténhet egy maximális összetettségű 3D-modell alapján, vagy több előre elkészített, különböző részletességű modell alapján. Ha különböző távolságokra kevesebb részletet tartalmazó modelleket használ, a becsült renderelési bonyolultság csökken, és szinte egyáltalán nem romlik a kép általános részlete.

A módszer különösen akkor hatékony, ha a jelenetben nagy számú objektum van, és a kamerától különböző távolságra helyezkednek el. Vegyünk például egy sportjátékot, például jégkorongot vagy foci szimulátort. Az alacsony poli karakteres modelleket akkor használják, ha távol vannak a fényképezőgéptől, és nagyításkor a modelleket nagyszámú sokszöggel helyettesítik. Ez a példa nagyon egyszerű, és bemutatja a módszer lényegét a modell részletességének két szintjén alapulva, de senki sem foglalkozik azzal, hogy több részletességi szintet hozzon létre, hogy a LOD szint megváltoztatásának hatása ne legyen túl észrevehető, így a részletek fokozatosan "nő", ahogy a tárgy közeledik.

A fényképezőgéptől való távolságon kívül más tényezők is fontosak lehetnek a LOD szempontjából - a képernyőn megjelenő objektumok teljes száma (ha egy vagy két karakter szerepel a képkockában, komplex modelleket használnak, és 10-20 között váltanak egyszerűbbekhez) vagy a másodpercenkénti képkockák számát (az FPS értékek korlátai vannak beállítva, amelyeknél a részletességi szint változik, például 30 alatti FPS esetén csökkentjük a képernyőn megjelenő modellek összetettségét, és 60, éppen ellenkezőleg, növekedés). A részletességet befolyásoló egyéb lehetséges tényezők a tárgy mozgási sebessége (alig lesz ideje megvizsgálni a mozgásban lévő rakétát, de könnyen látni egy csigát), a karakter fontossága játék szempontjából ( vegye ugyanazt a futballt - az Ön által irányított játékos modelljéhez bonyolultabb geometriát és textúrákat használhat, azt látja legközelebb és leggyakrabban). Minden az adott fejlesztő vágyaitól és képességeitől függ. A lényeg az, hogy ne vigyük túlzásba, a részletesség gyakori és észrevehető változása bosszantó.

Hadd emlékeztessem önöket, hogy a részletesség szintje nem feltétlenül csak a geometriára vonatkozik, a módszer más erőforrások megtakarítására is használható: textúrázáskor (bár a videochipek már használnak mipmapping -et, néha van értelme a textúrákat menet közben másoknak megváltoztatni) különböző részletekkel), világítási technikák (a közeli tárgyakat komplex algoritmus szerint, a távoli objektumokat pedig egy egyszerű algoritmus szerint világítják meg), textúrázási technika (komplex parallaxis -leképezést használnak közeli felületeken, és normál leképezést használnak távoli felületeken) stb.

Nem olyan egyszerű példát mutatni a játékból, egyrészt a LOD -t bizonyos mértékig szinte minden játékban használják, másrészt ezt nem mindig lehet egyértelműen kimutatni, különben kevés értelme lenne magában a LOD -ban.

De ebben a példában még mindig világos, hogy a legközelebbi autómodell maximális részletességgel rendelkezik, a következő két -három autó szintén nagyon közel van ehhez a szinthez, és minden távoli látható egyszerűsítéssel rendelkezik, itt csak a legjelentősebbek: nincs visszapillantó tükör, rendszám, ablaktörlő stb. És a legtávolabbi modelltől még árnyék sincs az úton. Ez a részletesség algoritmusa működés közben.

Globális megvilágítás

A jelenet valósághű megvilágítását nehéz szimulálni, a valóságban minden fénysugár többször visszaverődik és megtörik, ezeknek a visszaverődéseknek a száma nem korlátozott. A 3D -s megjelenítésben pedig a visszaverődések száma erősen függ a tervezési képességektől, minden jelenetszámítás egyszerűsített fizikai modell, és az így kapott kép csak közel áll a realizmushoz.

A világítási algoritmusok két modellre oszthatók: közvetlen vagy helyi megvilágításra és globális megvilágításra (közvetlen vagy helyi megvilágítás és globális megvilágítás). A helyi világítási modell a közvetlen megvilágítás kiszámítását használja, a fényforrásokból érkező fénytől az első átlátszatlan felületű fénykereszteződésig, a tárgyak kölcsönhatását nem veszik figyelembe. Bár ez a modell ezt kompenzálni próbálja háttér vagy egyenletes (környezeti) megvilágítás hozzáadásával, ez a legegyszerűbb közelítés, a fényforrások minden közvetett sugárzásának rendkívül leegyszerűsített megvilágítása, amely meghatározza a tárgyak megvilágításának színét és intenzitását, ha nincs közvetlen fényforrások.

Ugyanaz a sugárkövetés csak a fényforrások közvetlen sugaraival számítja ki a felületek megvilágítását, és minden felületet, hogy látható legyen, közvetlenül meg kell világítani egy fényforrásnak. Ez nem elegendő a fotorealisztikus eredmények eléréséhez, a közvetlen megvilágítás mellett figyelembe kell venni a más felületekről visszaverődő sugarak másodlagos megvilágítását is. A való világban a fénysugarak többször is visszaverődnek a felületekről, amíg teljesen ki nem alszanak. Az ablakon áthaladó napfény megvilágítja az egész szobát, bár a sugarak nem juthatnak el közvetlenül minden felületre. Minél világosabb a fényforrás, annál többször fog visszaverődni. A fényvisszaverő felület színe befolyásolja a visszavert fény színét is, például egy piros fal vörös foltot okoz a szomszédos fehér tárgyon. Itt van egy egyértelmű különbség, számítás másodlagos világítás nélkül és figyelembe véve:

A globális megvilágítási modellben a globális megvilágítást, a megvilágítást a tárgyak egymásra gyakorolt ​​hatásának figyelembevételével számítják ki, a fénysugarak többszörös visszaverődését és törését a tárgyak felületéről, a maró anyagokat és a felszín alatti szórást. Ez a modell lehetővé teszi, hogy reálisabb képet kapjon, de bonyolítja a folyamatot, és jelentősen több erőforrást igényel. Számos globális megvilágítási algoritmus létezik, gyors pillantást vetünk a sugárzásra (közvetett megvilágítás-számítás) és a fotonleképezésre (globális megvilágítási számítás a nyomkövetés segítségével előre kiszámított fotontérképek alapján). Vannak egyszerűsített módszerek a közvetett megvilágítás szimulálására is, például a jelenet teljes fényerejének megváltoztatása a benne lévő fényforrások számától és fényerejétől függően, vagy a jelenet körül elhelyezett nagy számú pontfény használata a visszavert fény szimulálásához, de mégis ez messze nem egy valós algoritmus.

A sugárzási algoritmus a fénysugarak egyik felületről a másikra, valamint a környezetről a tárgyakra történő másodlagos visszaverődésének kiszámítása. A fényforrásokból származó sugarakat addig követik, amíg erősségük egy bizonyos szint alá nem csökken, vagy a sugarak el nem érnek bizonyos számú visszaverődést. Ez egy gyakori GI technika, a számításokat általában a renderelés előtt végzik, és a számítás eredményei felhasználhatók a valós idejű megjelenítéshez. A sugárzás alapötletei a hőátadás fizikáján alapulnak. A tárgyak felületeit foltoknak nevezett kis területekre osztjuk, és feltételezzük, hogy a visszavert fény egyenletesen szóródik minden irányba. A lámpák fénysugarainak kiszámítása helyett átlagolási technikát alkalmaznak, a lámpákat foltokra osztva az általuk termelt energiaszint alapján. Ez az energia arányosan oszlik meg a felszíni foltok között.

Egy másik módszer a globális megvilágítás kiszámítására, amelyet Henrik Wann Jensen javasolt, a fotonleképezési módszer. A fotonikus térképek egy másik, sugárral követett globális megvilágítási algoritmus, amely szimulálja, hogyan hatnak a fénysugarak a jelenet tárgyaira. Az algoritmus kiszámítja a sugarak másodlagos visszaverődését, a fénytörést az átlátszó felületeken keresztül, a szórt visszaverődéseket. Ez a módszer abból áll, hogy kiszámítja a felületen lévő pontok megvilágítását két menetben. Az első a fénysugarak közvetlen követése másodlagos visszaverődésekkel, ez egy előzetes folyamat, amelyet a fő renderelés előtt hajtanak végre. Ez a módszer kiszámítja a fényforrásból a jelenet tárgyaihoz vezető fotonok energiáját. Amikor a fotonok elérik a felszínt, a foton metszéspontja, iránya és energiája a fotontérképnek nevezett gyorsítótárban tárolódik. A fotonikus térképek lemezre menthetők későbbi használatra, így nem kell minden keretben megjeleníteni őket. A fotonok visszaverődését addig számítják, amíg a munka bizonyos számú visszaverődés után le nem áll, vagy amikor el nem ér egy bizonyos energiát. A második renderelési számításban a jelenet pixelek közvetlen sugarakkal történő megvilágítását számítják ki, figyelembe véve a fotontérképekben tárolt adatokat, a fotonenergia hozzáadódik a közvetlen megvilágítás energiájához.

A nagyszámú másodlagos visszaverődést használó globális megvilágítási számítások sokkal hosszabb ideig tartanak, mint a közvetlen megvilágítási számítások. Vannak olyan technikák a rádióváros valós idejű hardveres számítására, amelyek a legújabb programozható videochipek generációinak képességeit használják, de egyelőre azoknak a jeleneteknek, amelyekre a valós idejű globális megvilágítást számítják ki, meglehetősen egyszerűnek kell lenniük, és sok egyszerűsítést kell végrehajtani. az algoritmusokban.

De a régóta használt statikus előre kiszámított globális megvilágítás, amely elfogadható a jelenetekhez anélkül, hogy megváltoztatná a fényforrások helyzetét és a világítást erősen befolyásoló nagy tárgyakat. Végül is a globális megvilágítás kiszámítása nem függ a megfigyelő pozíciójától, és ha az ilyen tárgyak helyzete a jelenetben és a fényforrások paraméterei nem változnak a jelenetben, akkor a korábban kiszámított megvilágítási értékek használva lenni. Ezt sok játékban használják, a GI számítási adatokat fénytérképek formájában tárolják.

Vannak elfogadható algoritmusok a dinamika globális megvilágításának szimulálására is. Például létezik egy ilyen egyszerű módszer valós idejű alkalmazásokban egy jelenetben lévő objektum közvetett megvilágításának kiszámításához: minden objektum egyszerűsített megjelenítése csökkentett részletességgel (kivéve azt, amelyre a világítást számítják). -felbontási kockatérkép (dinamikus tükröződések megjelenítésére is használható az objektum felületén), majd ennek a textúrának a szűrése (az elmosódási szűrő többszöri áthaladása), és a kiszámított textúra adatainak alkalmazása az objektum megvilágítására kiegészítőként világítás. Azokban az esetekben, amikor a dinamikus számítás túl nehéz, a statikus sugárzási térképek mellőzhetők. Példa a MotoGP 2 játékból, amely világosan mutatja a GI ilyen egyszerű utánzásának jótékony hatását:

"itemprop =" image ">

- Mik azok az árnyékolók? Nagyon gyakori kérdés a kíváncsi játékosoktól és a kezdő játékfejlesztőktől. Ebben a cikkben világos és érthető módon mesélek nektek ezekről a szörnyű árnyékolókról.

A számítógépes játékokat a számítógépes grafika fotorealisztikus képei felé vezető haladás motorjának tartom, ezért beszéljünk arról, hogy mik az „árnyékolók” a videojátékok kontextusában.

Az első grafikus gyorsítók megjelenése előtt a videojáték -keretek renderelésének minden munkáját a gyenge központi processzor végezte.

A keret rajzolása valójában meglehetősen rutinos munka: "geometriát" kell venni - sokszögű modelleket (világ, karakter, fegyver stb.), És raszterezni kell. Mi az a Rasterize? A teljes 3D modell a legkisebb háromszögekből áll, amelyeket a raszterizátor képpontokká alakít (azaz a "raszterizálás" azt jelenti, hogy képpé alakul). A raszterizálás után vegye fel a textúra adatait, a megvilágítás paramétereit, ködöt stb., És számítsa ki a játékkeret minden egyes pixelét, amely megjelenik a játékos számára.

Tehát a központi processzor (CPU - Central Processing Unit) túl okos fickó ahhoz, hogy ilyen rutinra kényszerítse. Ehelyett logikus valamilyen hardvermodult kiosztani, amely leterheli a CPU -t, hogy fontosabb szellemi munkát végezzen.

Ilyen hardvermodul a grafikus gyorsító vagy a videokártya (GPU - Graphics Processing Unit). Most a CPU előkészíti az adatokat, és betölti egy kollégáját rutinmunkával. Figyelembe véve, hogy a GPU ma már nem csak egy kolléga, hanem minions-core tömege, akkor egyszerre megbirkózik ezzel a fajta munkával.

De még nem kaptunk választ a fő kérdésre: Mik az árnyékolók? Várj, erre jutok.

A szép, érdekes és a fotorealizmushoz közel álló grafika megkövetelte a videokártyák fejlesztőitől, hogy számos algoritmust implementáljanak hardver szinten. Árnyékok, fények, fénypontok és így tovább. Ez a megközelítés - az algoritmusok hardveres megvalósításával "Fix pipeline vagy pipeline", és ahol kiváló minőségű grafikára van szükség, már nem található. Helyét a Programozható csővezeték vette át.

A játékosok kérései „hajrá, hozzon be egy jó grafóniumot! meglepetés! ”, a játékfejlesztőket (illetve videokártya -gyártókat) egyre bonyolultabb algoritmusok felé tolta. Eddig valamikor túl kevés a vezetékes hardveres algoritmus számukra.

Itt az ideje, hogy a grafikus kártyák intelligensebbek legyenek. Úgy döntöttek, hogy a fejlesztők tetszőleges folyamatokba programozhatják a GPU blokkokat, amelyek különböző algoritmusokat valósítanak meg. Vagyis a játékfejlesztők, grafikus programozók most képesek voltak programokat írni a videokártyákhoz.

És most végre elérkeztünk a fő kérdésünkre adott válaszhoz.

- Mik azok az árnyékolók?

A Shader (angol shader - árnyékoló program) egy olyan videokártya -program, amelyet háromdimenziós grafikában használnak egy objektum vagy kép végső paramétereinek meghatározására, és tartalmazhatja a fényelnyelés és szóródás leírását, a textúra leképezését, a tükröződést és fénytörés, árnyékolás, felületi elmozdulás stb. sok más paraméter.

Mik az árnyékolók? Például megkaphatja ezt a hatást, ez egy gömbre alkalmazott vízárnyékoló.

Grafikus csővezeték

A programozható folyamat előnye elődjével szemben az, hogy a programozók mostantól saját algoritmusokat hozhatnak létre, és nem használhatnak bekötött opciókat.

Eleinte a videokártyákat több speciális processzorral látták el, amelyek támogatják a különböző utasításkészleteket. Az árnyékolókat három típusra osztották, attól függően, hogy melyik processzor hajtja végre őket. De ekkor a videokártyákat univerzális processzorokkal kezdték el felszerelni, amelyek támogatják az utasítások készletét mindhárom típusú árnyékolóhoz. Az árnyékolók típusokra való felosztása megmaradt az árnyékoló céljának leírására.

Az ilyen intelligens videokártyákkal végzett grafikai feladatok mellett lehetővé vált általános célú (nem számítógépes grafikával kapcsolatos) számítások elvégzése a GPU-n.

Először jelent meg az árnyékolók teljes körű támogatása a GeForce 3 sorozatú videokártyákon, de a kezdeteket a GeForce256-ban valósították meg (Register Combiners formájában).

Shader típusok

A csővezeték szakaszától függően az árnyékolókat több típusra osztják: csúcs, töredék (pixel) és geometriai. A legújabb típusú csővezetékekben pedig vannak tesszellációs árnyékolók is. Nem tárgyaljuk részletesen a grafikai folyamatot, még gondolkodom, hogy írjak -e erről külön cikket azoknak, akik úgy döntenek, hogy tanulmányozzák az árnyékolókat és a grafikus programozást. Írj kommentben, ha érdekel, tudni fogom, hogy érdemes -e időt vesztegetni.

Vertex árnyékoló

A Vertex árnyékolók animációkat készítenek karakterekről, fűről, fákról, hullámokat keltenek a vízen és sok más dologról. Egy csúcsárnyékolóban a programozó hozzáférhet a csúcsokhoz kapcsolódó adatokhoz, például: egy csúcs koordinátái a térben, textúra koordinátái, színe és egy normál vektor.

Geometriai árnyékoló

A geometriai árnyékolók képesek új geometriát létrehozni, és felhasználhatók részecskék létrehozására, a modell részleteinek menet közbeni módosítására, sziluettek létrehozására és egyebekre. Az előző csúccsal ellentétben nemcsak egy csúcsot képesek feldolgozni, hanem egy egész primitívet is. A primitív lehet egy szegmens (két csúcs) és egy háromszög (három csúcs), és ha van információ a szomszédos csúcsokról (angol szomszédság) egy háromszög primitív esetében, akkor legfeljebb hat csúcs feldolgozható.

Pixel árnyékoló

A pixel árnyékolók textúraleképezést, megvilágítást és különféle textúrahatásokat végeznek, például tükröződést, fénytörést, ködöt, ütésleképezést stb.

A pixel árnyékoló bittérkép szeletekkel és textúrákkal dolgozik - feldolgozza a képpontokhoz tartozó adatokat (például szín, mélység, textúra koordináták). A pixel árnyékolót a grafikus folyamat utolsó szakaszában használják egy kép töredékének kialakítására.

Mire írnak az árnyékolók?

Kezdetben az árnyékolókat egy assembler-szerű nyelven lehetett írni, de később voltak a C nyelvhez hasonló magas szintű árnyékoló nyelvek, például a Cg, a GLSL és a HLSL.

Az ilyen nyelvek sokkal egyszerűbbek, mint a C, mert a segítségükkel megoldott feladatok sokkal egyszerűbbek. A típusrendszer ilyen nyelveken tükrözi a grafikus programozók igényeit. Ezért speciális adattípusokkal látják el a programozót: mátrixokat, mintavevőket, vektorokat stb.

RenderMan

Minden, amit fentebb tárgyaltunk, a valós idejű grafikához kapcsolódik. De vannak nem valós idejű grafikák. Mi a különbség - valós időben - valós időben, azaz itt és most - ha 60 képkockát adunk a játékban, ez valós idejű folyamat. De a legmodernebb animációk összetett keretének néhány perces megjelenítése nem valós idejű. A lényeg az időben van.

Például nem kaphatunk valós időben olyan minőségű grafikát, mint a Pixar stúdió legújabb animációs filmjeiben. A nagyon nagy vakolatgazdaságok fényszimulációkat számolnak teljesen eltérő algoritmusok használatával, nagyon drágák, de szinte fotorealisztikus képeket adnak.

Szuper realisztikus grafika Sand piperben

Például nézd meg ezt az aranyos rajzfilmet, homokszemeket, madártollakat, hullámokat, minden hihetetlenül valóságosnak tűnik.

* A videókat ki lehet tiltani a Youtube -ról, ha nem nyílnak meg, google pixar sandpiper - a aranyos és bolyhos rövid rajzfilm a bátor homokfogóról. Megérinti és bemutatja, milyen klassz számítógépes grafika lehet.

Tehát ez a RenderMan a Pixar -tól. Ez lett az első shader programozási nyelv. A RenderMan API a professzionális megjelenítés de facto szabványa, amelyet a Pixar minden munkájában és azon kívül is használnak.

Hasznos információ

Most már tudja, hogy mi az árnyékoló, de az árnyékolók mellett vannak más nagyon érdekes témák a játékfejlesztésben és a számítógépes grafikában, amelyek minden bizonnyal érdekelni fogják Önt:

• egy technika lenyűgöző hatások létrehozására a modern videojátékokban. Áttekintő cikk és videó oktatóanyagokkal az Unity3d effektusok létrehozásáról
• - Ha professzionális karrierként vagy hobbiként gondolkodik a videojátékok fejlesztésén, akkor ez a cikk kiváló ajánlásokat tartalmaz "hol kezdjem", "milyen könyveket érdemes elolvasni" stb.

Ha bármilyen kérdése van

Szokás szerint, ha még mindig vannak kérdései, tegye fel őket kommentben, mindig válaszolok. Bármilyen kedves szóért vagy hibajavításért nagyon hálás lennék.

Ez az oktatóanyag segít az árnyékolók telepítésében a Minecraftba, és ezáltal javítja a játék világát dinamikus árnyékok, szél- és fűzaj, reális víz és még sok más hozzáadásával.

Rögtön meg kell jegyezni, hogy az árnyékolók meglehetősen erősen terhelik a rendszert, és ha gyenge vagy akár integrált videokártyája van, javasoljuk, hogy tartózkodjon a mod telepítésétől.

A telepítés két szakaszból áll, először telepítenie kell a modot az árnyékolókra, majd további árnyékolócsomagokat

1. LÉPÉS - A mod telepítése az árnyékolókhoz

1. Töltse le és telepítse a Java -t
2. Telepítés OptiFine HD
   vagy ShadersMod;
3. A kapott archívumot bárhová kicsomagoljuk;
4. Futtassa a jar fájlt, mert ő szerelő;
5. A program megmutatja a játék elérési útját, ha minden helyes, kattintson az Igen, Ok, Ok gombra;
6. Menj .minecraftés hozzon létre egy mappát árnyékolók;
7. Bemegyünk az indítóba, és a sorban egy új profilt látunk "ShadersMod" névvel, ha nem, akkor manuálisan válasszuk ki.
8. Ezután le kell töltenie a shaderpack -eket

2. LÉPÉS - A shaderpack felszerelése

1. Töltse le az Önt érdeklő shaderpack -et (lista a cikk végén)
2. Nyomja meg a gombokat WIN + R
3. Menj .minecraft / shaderpacks... Ha nincs ilyen mappa, akkor hozza létre.
4. Mozgassa vagy bontsa ki az árnyékoló archívumát ide .minecraft / shaderpacks... Az útnak így kell kinéznie: .minecraft / shaderpacks / SHADER_FOLDER_NAME / shaders / [. fsh és .vsh fájlok]
5. Indítsa el a Minecraftot, és menjen Beállítások> Árnyékolók... Itt láthatja a rendelkezésre álló árnyékolók listáját. Válassza ki a szükségeset
6. Az árnyékoló beállításaiban engedélyezze a "tweakBlockDamage" funkciót, tiltsa le a "CloudShadow" és az "OldLighting" funkciót

A Sonic Ether hihetetlen árnyékolói
Sildur árnyékolói
Chocapic13 Shaders
sensi277 "yShaders
MrMeep_x3 Shaders
Naelego Cel Shaders
Az RRe36 árnyékolói
DeDelner CUDA árnyékolói
bruceatsr44 "savas árnyékolói
Beed28 Shaders
Ziipzaap Shader Pack
robobo1221 Shaders
A dvv16 -os árnyékolók
Stazza85 szuper árnyékolók
hoo00 "Shaders csomag B
A Regi24 hullámzó üzemei
MrButternuss ShaderPack
DethRaid fantasztikus grafikája a nitro -árnyékolókról
Edi Shader ForALLPc
A CrankerMan TME árnyékolói
Kadir Nck Shader (skate702 -hez)
Werrus árnyékolói
Knewtonwako élete Nexus Shaders
CYBOX shaderpack
CrapDeShoes CloudShade Alpha
AirLoocke42 Shader
A CaptTatsu BSL -árnyékolói
Triliton árnyékolói
ShadersMcOfficial Bloominx Shaders (Chocapic13 "Shaders)
dotModded Continuum Shaders
Qwqx71 "Lunar Shaders (chocapic13" shader)

Videokártya -processzorok (GPU) végrehajtására tervezték. Az árnyékolók a speciális programozási nyelvek egyikén (lásd) és a GPU utasításaiba vannak összeállítva.

Alkalmazás

Az árnyékolók használata előtt az eljárási textúragenerálást (például az Unreal játékban a víz és a tűz animált textúráinak létrehozására használták) és a multitexturálást (amelyen a Quake 3 játékban használt shader nyelv alapult) használták. Ezek a mechanizmusok nem nyújtottak olyan rugalmasságot, mint az árnyékolók.

Az újrakonfigurálható grafikus folyamatok megjelenésével lehetővé vált matematikai számítások (GPGPU) elvégzése a GPU -n. A legismertebb GPGPU mechanizmusok az nVidia CUDA, a Microsoft DirectCompute és a nyílt forráskódú OpenCL.

Shader típusok

Vertex árnyékolók

A csúcsárnyékoló a poliéder csúcsaihoz kapcsolódó adatokkal működik, például egy csúcs (pont) koordinátáival a térben, textúra koordinátákkal, csúcsszínnel, érintővektorral, binormális vektorral, normál értékkel vektor. A csúcsárnyékoló használható csúcsok megtekintésére és perspektivikus átalakítására, textúra -koordináták előállítására, világítás kiszámítására stb.

Mintakód egy csúcsárnyékolóhoz a nyelven:

vs.2.0 dcl_position v0 dcl_texcoord v3 m4x4 oPos, v0, c0 mov oT0, v3

Geometriai árnyékolók

Egy geometriai árnyékoló, ellentétben egy csúccsal, nemcsak egy csúcsot képes feldolgozni, hanem egy egész primitívet is. A primitív lehet egy szegmens (két csúcs) és egy háromszög (három csúcs), és ha van információ a szomszédos csúcsokról (angol szomszédság) egy háromszög primitív esetében, akkor legfeljebb hat csúcs feldolgozható. A geometria shader képes primitívek generálására menet közben (a központi processzor használata nélkül).

A geometriai árnyékolókat először az Nvidia 8 sorozatú grafikus kártyákon használták.

Pixel (töredék) árnyékolók

A pixel árnyékoló bittérkép szeletekkel és textúrákkal dolgozik - feldolgozza a képpontokhoz tartozó adatokat (például szín, mélység, textúra koordináták). A pixel árnyékolót a grafikus folyamat utolsó szakaszában használják egy kép töredékének kialakítására.

Minta kód egy pixel árnyékolóhoz a következő nyelven:

ps.1.4 texld r0, t0 mul r0, r0, v0

Előnyök és hátrányok

Előnyök:

• bármilyen algoritmus összeállításának képessége (rugalmasság, egyszerűsítés és a programfejlesztési ciklus költségeinek csökkentése, a megjelenített jelenetek összetettségének és valósághűségének növelése);
• megnövelt végrehajtási sebesség (összehasonlítva ugyanazon algoritmus végrehajtási sebességével a központi processzoron).

Hátrányok:

• új programozási nyelv elsajátításának szükségessége;
• a különböző gyártók GPU -jainak különböző utasításkészletei.

Programozási nyelvek

Számos shader programozási nyelvet hoztak létre a piac különböző igényeinek kielégítésére (a számítógépes grafikának számos alkalmazási területe van).

Általában az árnyékolók írására szolgáló nyelvek speciális adattípusokat (mátrixokat, mintavételezőket, vektorokat stb.) Biztosítanak a programozónak, beépített változók és konstansok készletét (a 3D API szabványos funkcióival való interakcióhoz).

Professzionális renderelés

Az alábbiakban olyan shader programozási nyelvek találhatók, amelyek a maximális megjelenítési minőség elérésére összpontosítanak. Ilyen nyelveken az anyagok tulajdonságait absztrakciók segítségével írják le. Ez lehetővé teszi azok számára, akik nem rendelkeznek speciális programozási ismeretekkel és nem ismerik a hardver megvalósításának sajátosságait. Például a művészek írhatják ezeket az árnyékolókat, hogy a "megfelelő megjelenést" biztosítsák (textúra leképezés, fény elhelyezése stb.).

Általában az ilyen árnyékolók feldolgozása meglehetősen erőforrás-igényes: a fotorealisztikus képek létrehozása nagy számítási teljesítményt igényel. Általában a számítás nagy részét nagyméretű számítógépes fürtök vagy pengerendszerek végzik.

RenderMan A Pixar RenderMan szoftverében megvalósított shader programozási nyelv volt az első shader programozási nyelv. A Rob Cook által kifejlesztett és a RenderMan interfész specifikációban leírt RenderMan API a professzionális megjelenítés de facto szabványa, amelyet a Pixar munkája során használnak. OSL OSL - eng. Az Open Shading Language egy shader programozási nyelv, amelyet fejlesztett Sony Pictures Imageworksés a nyelvre hasonlít. Ezt a Sony Pictures Imageworks által kifejlesztett, renderelésre szánt szabadalmaztatott "Arnold" programban, valamint a háromdimenziós számítógépes grafika létrehozására szánt ingyenes Blender programban használják. Valós idejű megjelenítés GLSL GLSL a nyitott GL S birtoklás L nyelv) az OpenGL szabványban leírt shader programozási nyelv, amely az ANSI C szabványban leírt nyelvváltozaton alapul. A nyelv támogatja a legtöbb ANSI C szolgáltatást, támogatja a háromdimenziós grafikákkal való munkavégzés során gyakran használt adattípusokat (vektorok, mátrixok). A "shader" szó a GLSL -ben egy önállóan összeállított, ezen a nyelven írt egységre utal. A "program" szó összefordított árnyékolók gyűjteményére utal. Cg (eng. C számára g rafikusok) egy shader programozási nyelv, amelyet az nVidia fejlesztett ki a Microsofttal. A nyelv hasonló a Microsoft által kifejlesztett és a rendszerben szereplő HLSL nyelvhez DirectX 9... A nyelv az "int", "float", "half" típusokat használja (16 bites lebegőpontos szám). A nyelv támogatja a funkciókat és struktúrákat. A nyelv sajátos optimalizációkkal rendelkezik „tömörített tömbök” formájában (