Hogyan készítsünk egy képernyőképet a Quake 3 arénában

Az első Quake nyomkövetési útvonalak világításának javítása Blenderben

A Quake első epizódjának speedronja, amely a cikkben leírt rendszert használva

Bevezetés

Már huszonöt évvel a Quake létrehozta a játékmotorok realizmusának új sávját. Ez volt az egyik első kereskedelmi játék, amely teljesen texturált 3D jelenetekkel és valós idejű rendereléssel, előre kiszámított világító kártyákkal, légköri hozzáadásával.

Mindazonáltal, az év gyenge “hardverén” való valós idejű munkájának szükségessége erősen korlátozta a grafika realizmusát. Ebben a cikkben elmondom, hogyan lehet javítani a játék megjelenését a modern felszerelésen, és a renderelés nem valós idejű.

Megmondom, hogyan írtam egy szkriptet, hogy a Quake demo fájlokat a keverő jelenetre konvertálja. A Blender egy ingyenes és openforrás alkalmazás 3D modellezéshez és rendereléshez. Ő Cycles Rendering utat nyomjelző képesek létrehozni fotorealisztikus képeket, hogy támogatja a funkciók, mint például Motion Blur, mélységélesség, komplex shader rendszer és még sok más. Projekt exportálása a keverőhöz, az összes ilyen funkciót ingyen használhatjuk, anélkül, hogy új renderelőt kellene írnunk. Arra törekszem, hogy maximalizálja az eredeti játék erőforrásainak használatát, és pontos turmixgépet használjon a realizmus növelésére.

A hozzászólásban a forráskódra utalok, amely része a pyquake tárolónak. Ha szeretné importálni saját demóját a keverőnek, írtam utasításokat, de valószínűleg nem fogok válaszolni a jegyekre vagy a PR-re. Ha érdekel a projekt támogatása, azt javaslom, hogy hozza létre.

Összehasonlítás screenshotov
Quake, a keverőben

Képernyőkép a quakespasmusból

Quake, a keverőben

Képernyőkép a quakespasmusból

Quake, a keverőben

Képernyőkép a quakespasmusból

Quake, a keverőben

Képernyőkép a quakespasmusból

Quake, a keverőben

Képernyőkép a quakespasmusból

Quake, a keverőben

Képernyőkép a quakespasmusból

Quake, a keverőben

Képernyőkép a quakespasmusból

Quake, a keverőben

Képernyőkép a quakespasmusból

Quake, a keverőben

Képernyőkép a quakespasmusból

Quake, a keverőben

Képernyőkép a quakespasmusból

Quake, a keverőben

Képernyőkép a quakespasmusból

Képernyőképek készülnek a Quakespasmus kikötőjében a forráskód, amely megőrzi a játék megjelenését.

Demo-rekord elemzése

A Demo fájl egy kompakt játékrekord a Quake-ben, amelyet megoszthat más játékosokkal, vagy megtekintheti magát. Quake – Multiplayer játék, így az ügyfélre és a szerverre oszlik. Valójában a demó írja a forgalmat a kiszolgálóról az ügyfélre a játék során. A demó és a telepített remegés, akkor el lehet fogadni, amit a játékos a felvétel időpontjában láttam:

Illusztráció egy demo rekord. Ügyfél (jobb) kommunikál a kiszolgálóval (balra). Az ügyfél által kapott forgalom a DEMO fájlba kerül.

Érdemes megjegyezni, hogy az egyfelhasználós módban az ügyfél és a kiszolgáló komponensei a kódba kerülnek, csak a tápkábel helyettesítik a memóriában egy egyszerű átvitel, azaz a demó rögzíthető ebben a módban.

Mivel a demo fájlformátum szorosan kapcsolódik a rengéshirdetési protokollhoz, akkor a Quake hálózati kód megfelelő rétegének olvasásával érthető. Ezért meglehetősen egyszerűen írhat egy parser fájlformátumot a Python-on.

Az elemzés során a demotup fájl olvasható, valamint a játék forgatókönyve. Inicializálás csapatok körvonalazza a jelenet, melyben leírja, milyen erőforrások (szint, modellek és hangok) fogják használni a demo:

Aztán ott van egy sor alapvető csapatok kér egy sor szervezetek, amelyek mindegyike kapcsolatban van a fenti modellek, mint a listáját előadók a játék. Az entitások minden objektumot állítanak be a játékban. A lényeg lehet szörny, játékos, elsősegély készlet, lift, gomb. A szint összes, de statikus része:

Végül, a sorrend a frissítés és az idő parancsok beállítja a helyzetben, szög és pozíció testtartás egy adott pillanatban az idő; A játék analógiájában úgy néz ki, mint a színpadi megjegyzések sorrendje:

A fent ismertetett ismétlődik mindegyik demo keret, és minden egyes keret tartalmaz egy parancsot minden egyes entitás.

Itt megtalálható a Python fájlszámlájára a demo elemzésre.

Az erőforrások elemzése

Maga a szint leírja a fájlban .BSP. Tartalmaz információkat a geometria és a szinten textúrák, valamint néhány más adat struktúrák, amelyekre később visszatérünk. A fájlformátum jó, ha elég dokumentálta, hogy Python osztályokban szikrázzon. Olyan elemek, mint a szörnyek, fegyvermodellek és így tovább, a fájlokban tárolva .MDL, emellett jó a dokumentáció. A projektemben lévő hangok nem kerülnek feldolgozásra (a játék elején a videóban csak egy hangfelvételt helyeztem el a játékból), így nem kell a hangerő-erőforrásokat átadni.

A Python kódja a fájlok elemzéséhez .BSP I .Itt megtalálható az MDL (.Bsp) és itt (.MDL).

Quakeuy futása. A fájlban tárolt geometria, textúrák és animációs adatok .Mdl. Fájlok .A BSP tartalmaz mindent, amire szüksége van a szintre.

Letöltés a Blenderhez

A Blendernek gazdag felülete van a python írására. A Blender Interface a Python API-vel való kölcsönhatás miatt működik, így minden, amit az UI-rel végezhet, a szkriptek is megvalósíthatja. Ezzel a Python interfészrel létrehoztam egy szkriptet a fájlok importálásához .BSP és modellek a keverőben. A Quake erőforrásokból származó legtöbb koncepció közvetlen analógokat tartalmaz a keverőben:

• A Quake kártya modellek és a geometria a keverő keverékként jeleníthető meg.
• A Quake modellek modelljei formájúak formájúak lehetnek.
• A Quake textúra adatok képként ábrázolhatók.
• A textúrák koordinátáit UV-kártyák keverő formájában lehet kódolni.
• Az olyan hatások, mint a vízhullámok, animációs textúrák, valamint a Skype árnyékolóként megvalósíthatók.

A fűrészlapok importálására szolgáló kódom .MDL I .A BSP Blenderben itt van (.MDL) és itt (.BSP).
A fűrészárut importálása a bevezető rész olvasásában, amely azt mondja nekünk, hogy mely játékforrásokat (modelleket és kártyákat) kell konvertálni a keverőforrásokhoz, majd az animációt az alapvető pozíciók és a frissítések adatai szerint. Ehhez a Blender Animációs támogatást használom. Különösen azt helyezze kulcsfontosságú személyzet pozíciók, orientáció és az alak Key minden csapat a demo. Hozzáadott kulcskereteket az animált árnyékolók számára, például a vízhullámok számára, hogy a játék aktuális idejének megfelelően mozogjanak. Az alábbiakban az a rekord, amely a demó behozatalának eredményét mutatja a játék első szintjétől. Itt megtalálható a DEMO fájlok Importkódja.

Megnézzük a Blenderben importált demót

Világítás

Tehát már betöltöttük és animált geometriát, valamint a textúrák egy részét. Azonban még nincsenek könnyű forrása. Amikor az eredeti remegés szintjét tervezték, a fényforrásokat meghatározott pontforrásokként állították be. Összeállítási folyamat átalakította ezeket a pontfényforrásokat világító kártyákban. Ez a folyamat, hogy összehasonlítsa a textúra alacsony felbontás minden szinten a szinten, és a számítás, hogy mennyi minden texelnaprain világítja pontszerű fényforrások. Mivel ez a folyamat intézkedéseket csak direkt világítás, szint tervezők hozzáadott másodlagos fényforrások utánozni hatásait tükrözi világítás.

Mivel az eredeti kártyák forrásai rendelkezésre állnak, ezeket a fényforrásokat használhatom a jelenet megvilágítására. Mivel azonban a keverő maga is pontos világítást végezhet többszörös visszaverődéssel, akkor az eredeti fényforrások remek hozzáadásával, a visszavert fény mennyisége megduplázódik, mivel a jelenet túlságosan világít.

Ehelyett a jelenetet közvetlenül a textúrainformációkból megvilágítom. Minden textúra-remegés színpaletta színekkel rendelkezik:

A paletta utolsó 32 színe jellemző, hogy mindig teljes fényerővel jelennek meg, azaz az árnyékban is teljesen megvilágítottak:

A rendszeremben ezeket az élénk színeket a fénykibocsátásként feldolgoztam, hogy lefedjék a körzetet, és fényesnek tűnt a kamrában is:

Ezenkívül olyan forrásokként dolgoztam fel, amelyek fényt kibocsátanak néhány modellt, például a fáklyák modellek.

Szóval, a mi jelenetünk készen áll – létrehoztuk a geometriát, tedd a textúrákat, és megkérdeztük a világítási forrásokat. Kapunk egy képet, és nézzük meg, mi történik:

Azta! Ennek a keretnek a renderelése a GeForce RTX-en, körülbelül 20 másodpercig tartott, és még mindig hihetetlenül szemcsés! Még a beépített keverő-keverőhasználat sem engedélyezte a tiszta kép visszaállítását. Általában a turmixgépek a bonyolultság szintjének jelenetei vannak, így mi történik?

Mintavétel

Ha a Blender megpróbálja kiszámítani a pont megvilágításának szintjét, akkor (alapértelmezett) véletlenszerűen minták a jelenet minden fényforrásából, és átlagolják az egyesek hatását. A jelenet legtöbb szintje sokkal nagyobb fényforrás, mint bármikor látható. Ez azt jelenti, hogy a legtöbb forrás hatása nulla, ezért az eredmény nagyon sumen, és attól függ, hogy a látható fényforrás mintavételezett.

Megmutatjuk ezt az ötletet: mondjuk, mondjuk, hogy a jelenetben vannak fényforrások, amelyek mindegyike a négyzet alatt található négyzetben található a 10x rács mérete. Amíg nem figyelsz a Vörös térre (később visszatérünk). Egy külön pontra, hogy a fényképezőgép látja, az egyes források hatása a tér fényerejére van beállítva. A pont megvilágítására vonatkozó szint geometria átfedése miatt csak tizenöt forrást jelent.

A fényforrások hatása a helyszínen.

Egyszerűen meg tudtuk venni az összes ilyen források átlagos értékét, hogy pontos választ kapjunk, de egy ilyen megoldásnak két problémája van:

• Az összes forrás mintavétele sok időt vesz igénybe.
• A valóságban minden egyes forrás sem befolyásolja a befolyását is: a fényerő attól függ, hogy melyik forrásból végezzük a mintavételt. Jelenítse meg a hosszú fluoreszkáló lámpát, részlegesen borított fal, vagy a fényforrás textúrájával, egyenetlenül kibocsátó fény. Ebben az esetben az összes minta nem lesz elég.

A problémák elkerülése érdekében olyan sztochasztikus megközelítést alkalmazunk, amelyet a véletlenszerű mintavételt alkalmazó Monte Carlo integrációnak nevezünk. Tegyük fel, hogy 32 mintát veszünk fel a vizsgált pontra gyakorolt ​​hatás mérésére. Mi mintavételünk 32-szeres forrásokat, minden alkalommal helyettesítjük őket, és átlagosan átlagosan az eredményeket kapjuk, hogy közepes mintavételt kapjunk. Az Egyesült Államok válasza alkalmanként, mert a mintavételezett értékektől függ. Itt van egy grafikon, amely az átlagos mintavételi értékek eloszlását mutatja minta után:

Az átlagos mintavételi értékek eloszlása ​​az összes fényforrásból származó minták fogadása után. A minták átlagos átlagos értékeit piros vonal jelzi.

Amint láthatja, van egy diszperzió: a közepes mintavétel értéke lehet a tartományban 0 és 0,3 között. Az ilyen diszperzió nem kívánatos, a kész képen zajlik a zaj formájában.

Van-e módja annak, hogy csökkentse az átlagos mintavételi érték diszperzióját, miközben ugyanazt a közeget (átlagos mintavételi értékek) tartja fenn (átlagos mintavételi értékek)? Kiderül, hogy itt használhat egy egyszerű sémát a mintavételi típus (fontos minta). Ha mi előlegkéntTudjuk, hogy a piros téren kívüli források egyike sem befolyásolja a kész képet, akkor egyszerűen csak a kívánt 32 mintát vehetünk az 5×5 négyzetből. Mivel most mintavételünk 25 értékből, és nem ki, érdemes elvárni, hogy az átlagos mintavételi érték négyszeresebb lesz, mint amikor egy teljes forráskészletből származó mintavételezés esetén. Ezért beállítottuk az átlagos mintavételi értéket, négyre osztva. Itt van a beállított átlagok elosztása az új séma használatakor:

A korrigált átlagos mintavételi értékek megoszlása ​​a fényforrások részhalmazából származó értékek fogadása után.

Amint láthatod, a diszperzió csökkent, de az átlag ugyanaz maradt, így kevesebb zajos, de még mindig jobb (a megfelelő) kép.

Ez egy egyszerűsített leírás arról, hogy a keverő minták fényforrásai, de a lényeg ugyanaz marad: a zaj csökkenthető, ha nem mint olyan fényforrásokat, amelyek nem befolyásolják a kész képet. A Blender beépített módja annak, hogy kizárja a forrást a mintavételből, az UI több jelentőségű mintavételhez és a kóddal – . Ez a zászló animálható kulcskeretek segítségével, így a lejátszó aktuális pozíciójától és a fényképezőgép sarkától függően változhatunk.

Azaz, most a mi feladatunk az, hogy hozzon létre heurisztikus trigteen, amennyire csak lehetséges forrásai, amelyek nem érintik a jelenlegi ablakkal. Más szóval, el kell kerülnünk a mintavételi forrásokat, amelyeket nem lehet elérni a fényképezőgépből való visszaverődés után.

BSP láthatósági minősítések

Szerencsére a fájlokban .A BSP beépített adatszerkezeteket tartalmaz, hogy megoldja a hasonló feladatot. Az egyik csodálatos innováció, amely lehetővé tette, hogy az év “hardverével” az év “hardverének” -jén dolgozzon ki, a látható felületek meghatározása volt, vagyis az egyes játékosok pozíciójából látható szintek kiszámítása.

A feladatfájl megoldása .A BSP megosztja a levelek által választott elválasztott térfogatok szintjét. Minden lap több arcot tartalmaz.

A BSP láthatóság információ egy nagy (de tömörített) egy előre meghatározott kétdimenziós bitmap jelentést jelent számunkra, melyik levele lehet látni egymást. Sok levelek, amelyek potenciálisan látni egy speciális lap, az úgynevezett potenciálisan látható szett, PVS:

A játékban lévő felületek a PVS kamerákon kívül vannak. Feladatunk egy kicsit más – mintavételre van szükségünk, és azok a fényforrások, amelyek láthatatlanok a kamerához, de legalább a kamera számára látható egyik pontból láthatóak.

Nézzünk meg egy példát, amelyben a fény befolyásolja a képet. Itt látható a külső screenshot az első folyosón a játék, ahol a fényforrás van jelölve narancssárga starge, és a játékos körül a szög és a kamera jelzi narancssárga piramist. [Ha tudod ezt a szintet, akkor tudod, hogy a szokásos állapotban ezt a folyosót az ajtó blokkolja. Ebben a cikkben feltételezzük, hogy az ajtó nyitva van.]

Az első közelítésként csak akkor tudunk egyszerűen a fényforrást, ha a PVS kamerák közös levelei vannak a PVS forrással. Ha különbséget teszünk a PVS forrás és kamerák, látni fogjuk, hogy a kereszteződést, és valójában van, ezért ezzel a módszerrel, ez a forrás kerül mintába:

A fényforrás PVS elhagyja, és a levelek a PVS kamerákban – kék. A levelek mindkét PV-ben zöld színűek.

Egy ilyen rendszer jól működik, és enyhén javítja a helyzetet. Azonban sokkal többet tudunk tenni. A probléma az, hogy a PV-k túl konzervatívak, vagyis sok teljesen átfedő levelek vannak, amelyek eldobhatók, de még mindig a PV-kben maradnak. Hasonlóképpen, vannak pontok a PVS fényforrás, ami miatt a korlátozott hatalom a forrás és a törvény fordított négyzetes függés nagyon kevés világítás. Emiatt még mindig olyan forrást mintavételezzünk, amelyek nem befolyásolják a jelenetet.

Csonkítás

A helyzet javítása érdekében ismét egy példát használtam a láthatóság számítására a remegésben, és alkalmazott egy mechanizmust, az úgynevezett Frustum Culling (láthatóságú piramis csonkítása). Mi lehet csatlakoztatni a kamera a piramis a láthatóság, vagyis a térfogata, amely megfelel a széleit a képernyő, kialakítva a kiindulási pont a kamra. A láthatósági piramison kívüli pontok láthatatlanok lesznek a kamerához, így kiküszöbölhetjük ezeket a leveleket a PV-kből. Ennek köszönhetően a játékos mögött levő levelek a játékos mögött és általában a kamera felülvizsgálat határain túl vannak.

Hasonló koncepciót alkalmazhat a fényforrás PV-jére: A gyakorlatban a forrás gömbjét a fordított kvadratikus függőség törvénye korlátozza, így minden forrás körül a korlátozó párhuzamú, amelynek mérete meghatározható a forrás fényereje. Ezért csökkenthetjük a PVS fényforrást a korlátozó párhuzamosan metszésponttal.

Az így kapott rendszer alapja annak ellenőrzése, hogy két kedvezményes PVS térfogata metszik:

Ebben az esetben metszenek, de elképzelhető, hogy ha a játékos az ellenkező irányba fordul, akkor nem lenne kereszteződés, és a fényforrás (abszolút helyes) nem lenne minta.

Ez a rendszer jobb, mint a rendszer korlátozások nélkül, és ahogy látja, sokkal jobb, mint a rendszer, egyszerűen csak az összes forrás mintavételezése:

Miután alkalmazta a keverő zajcsökkentését erre az eredményre, még egyértelműebb képet kapunk:

Ez források kiválasztására mintavételre van egy hátránya – figyelmen kívül hagyja a lehetőségét, hogy a hatása több fényvisszaverődést: fényes forrás végén a kanyargós folyosó megvilágítja a másik végét köszönhetően számos gondolatok, de ez a forrás nem kerül mintába ez a módszer. Bár van ilyen probléma az elméletben, nem észrevehető a gyakorlatban.

Legújabb stroke

A végeredmény létrehozása érdekében néhány további szempont szükséges:

• A fényforrások különböző textúrái helyesen nézett ki, különböző fényerővel kell rendelkezniük. Például a Spotlight textúrájának sokkal világosabbnak kell lennie, mint a háttérvilágítás jelzője. Ez az információ nem kódolt a játékban, így a rendszer beolvassa a konfigurációs fájl, amely többek között tartalmazza szépen keres fényerő értékeket az egyes textúra.
• Az ég textúráját a napfény-keverő segítségével fényt emelnek.
• Bár az eredeti játékforrásokban a fény nem függ a textúráktól, a művészek általában olyan forrásokkal rendelkeznek, amelyek a modell vagy a textúra közelében vannak, amelyeket vizuálisan világításra kell emelni. Ennek ellenére az eredeti játékban még mindig vannak olyan területek, amelyeknek logikátlan forrásai vannak, amelyek a renderelésemben túl sötétnek tűnnek. Ha figyelembe vesszük ezt, néhány forrást adtam az eredeti kártyák forrásaiból, hogy megvilágítsák ezeket a régiókat. E források helyét és fényerejét a konfigurációs fájlban rögzítik, amelyet fent mondtam.
• Az eredeti játékban robbanásokhoz használt részecske-rendszer, teleporthatások és így tovább. Megjelenítve őket, használom a Saját Blender részecske rendszerét.

Vannak más dolgok is, amiket hozzáadhat:

• A játékos fegyverének megjelenítése. Az eredeti játékban az aktuális kiválasztott fegyver jelenik meg a képernyő alján.
• Villámhatások. Láthatóak a villámpisztolyban, és az első epizód utolsó szintjén.
• Lencse. A játéknak több sprite van olyan dolgokra, mint egy robbanáshatás (külön a részecskéktől) és a buborékok.
• Animált fényforrások. Az eredeti játék megvilágítási kártyái animáltak lehetnek, ami hasznos a villogó fények és t értékesítéshez.Ns., valamint a játékos kapcsolók általi felvételi és leállítása.

Következtetés

Olyan rendszert hoztam létre, amely a DEMO-felvevők blenderre történő behozatalát és az összeshez kapcsolódó összes forrásokat importálja. Ehhez szükség volt a Quake kliens tisztességes részére a Python-ra, cserélje ki a renderelő kódért felelős kódot, a játék állapotának megduplázását a keverőben. Sok időt vett igénybe, így valószínűleg hatékonyabb lenne a remegő kód egy részét, és alacsonyabb szinten hozzáadhatja a kódomat. Másrészt létrehoztam egy kódkönyvtárat, hogy kölcsönhatásba léphessek több quake fájlformátummal, valamint kiegészítő kóddal (például Simplex Solver). Ez hasznos lehet más Quake közösségi projektekhez.

By the way, az egyéb alkalmazási módokról: A keverőben létrehozott jelenet használható a játékos elemzésére. A győztes vagy veszteségű speedran játékokat gyakran másodpercek részesedése határozza meg. Ha több demót tölthet be egy jelenetbe, és nyomon követheti konkrétan, aki egy adott szakaszban előre, meg tudtuk érteni, hol nyerhetsz időt.

A projekt fejlesztésekor folyamatosan emlékeztem a valós idejű renderelőkkel való összehasonlításra, különösen a Quake II RTX projekt (Q2RTX). Még az összes renderelési optimalizálással is, még mindig néhány másodpercet vesz igénybe egy kereten, és a Q2RTX valós időben történik. A Blender támogatja a hardveres RayTracing-t is, miért még mindig lassabb? Azt hiszem, valószínű okok a következőkben:

• A Q2RTX ideiglenes szűrést használ a képek simításához. Ez azt jelenti, hogy az előző keretekből származó minták hozzájárulnak az aktuális kerethez. A keverő nem teljes mértékben támogatja az ideiglenes szűrést, ezért külön-külön meg kellett adnom minden képet.
• A rendszernek meg kell határoznia a mintavételezhető fényforrásokat minden keretben. Az RTX-alapú rendszer kiválaszthatja a mintákat az útvonal alapján. A felület minden egyes pontjára, amely integrálja az egyes eseményeket, csak a közvetlen PVS számítását kell elvégezni (nulla visszaverődéssel). Természetesen ez arra a tényre vezet, hogy minden képpontnak mintavételezni kell kisebb forrásokat. Az olvasásomról nem tudok bizalommal mondani, hogy ez igaz a Q2RTX-re, de valószínűnek tűnik.
• A ciklusok nevű turmixgépek nagyon általánosítottak, vagyis képes sok különböző típusú jelenetekkel dolgozni – különböző komplexitás geometriájával, különböző számú fényforrással és így tovább. Ellentétben őt, a Q2RTX rendkívül specializált render, így optimalizálható egy adott feladat – renderelés rengeteg szintjén.