Tartalom
- Voxel-probléma
- Elemzés
- Megoldás
- Teljesítmény
- Stressz tesztelés
- Tüntetések
- Megvalósítás: Geometry Shader
- Geometry Shader
- Jövőbeli irányok
- Az időjárással kapcsolatos munka (és inspiráció ehhez az eszközhöz)
Charles szoftvermérnök és egyetemi tanár, akit érdekel a technológia, az orvostudomány, a közgazdaságtan és a táplálkozás.
Voxel-probléma
Ez a projekt akkor kezdődött, amikor lényeket, tárgyakat és tájképeket akartam készíteni voxelekből. Tetszett a voxelek ötlete, mert intuitív módon felhasználhatók objektumok felépítésére és lebontására. A problémák a sebesség, a memóriahasználat és a szabványosítás hiánya voltak.
Tudtam, hogy meg kell írnom a saját voxel csomagomat, ezért rövid felmérést készítettem néhány ingyenes és fizetett eszközről az Unity számára. Legtöbbjük minden felelősség elől kitért a teljesítményért, és alkalmasak voltak arra, hogy néhány tízezer vokselt használhassanak a játékban, ahogyan részecske-effektusokat használhat. A voxeleket szerettem volna játékmechanikusként használni.
A modern PC-k még az egyes voxelekhez használt duzzadt osztályok mellett is annyi RAM-mal rendelkeznek, hogy szinte nem jelent problémát. A legnagyobb problémát a sebesség okozta.
Elemzés
A profilalkotás megmutatta, hogy egy voxel darab háromszög hálóvá alakítása a futási idő több mint 90% -át vette fel. A nagyméretű voxel-térképek gyors létrehozása egyszerűen a Perlin zajfüggvény hívásainak újrafelhasználása volt, és miután hálóvá alakították, a voxel-kötet hasonlóan működik, mint bármely más objektum.
A darabok konvertálása könnyen elvégezhető párhuzamosan, de nyolc szálnál a teljesítmény még mindig nem volt kielégítő. A geometriai árnyékolók használata a voxelek közvetlenebb megjelenítéséhez nem volt segítség, és csak néhány millió voxel mennyiségével kezdett komolyan lemaradni. Csak a felszíni voxelek küldése az árnyékolónak visszaadta a problémát a CPU-szálaknak. A CPU teljesítménye megfelelő a frissítésekhez, de nem a véletlenszerű térkép előállításához szükséges kezdeti hatalmas mennyiségekhez.
Megoldás
Megfelelő megoldásnak bizonyult a Compute Shader kernelek használata térképek előállítására és a látható voxelek tömbjébe tömörítésére. A Geometry Shader képes elfogadni a tömböt tartalmazó GPU puffert, hogy elkerülje a kezdeti megjelenítés előtt a fő rendszer RAM-jába történő másolást.
Az Unity Asset-ben, amelyet ennek a folyamatnak a végrehajtására és tesztelésére írtam, mindkét oldalon 256 kocka voxel darabokra telepedtem, amelyek voxelenként egy bájtot használnak. Egy darab küldése a GPU-ba vagy onnan egy újabb PCIe buszon kevesebb, mint egy másodpercig tart, de még mindig túl lassú. A teljes térképgenerálás és a grafikus kártyán történő kezdeti megjelenítés esetén a CPU felszabadul az egyéb jelenetek beállításához, és a nyers voxel-adatok szükség szerint továbbíthatók (ha egyáltalán vannak).
Teljesítmény
A Compute and Geometry Shaders sebessége a hardvertől függ, de a fedélzeti GPU darabonként körülbelül a másodperc harmadát veszi igénybe. A hálóvá konvertálás valamivel tovább tart, és több memóriát igényel. Az Unity TerrainData konvertálása nagyon gyors, de csak magasságtérképet tárol.
Tizenhat millió voxel (256 x 256 x 256) darabonként 16 MB-ot foglal el. A felszíni voxelek általában 512 KB (128 KB x 4 bájt) vannak minden darabra, amelyek készen állnak a megjelenítésre.
Stressz tesztelés
Ez egy fraktál, amelyet néha használnak a voxel könyvtárak stressz tesztelésére, mert nincsenek rejtett voxeljei. Vagyis minden voxelnek legalább egy látható oldala van valamilyen szögből. 14,3 millió (243 x 243 x 243) összmennyiség, 3,2 millió szilárd voksellel.
Fedélzeti GPU használatával az FPS 5 és 9 között változik, ahogy a kamera az objektum körül mozog.
Tüntetések
A terep bemutató videó 16 darabból álló rácsot mutat, az összes futás közben létrehozott adattal, és a vége közelében láthatja a teljes 1024x1024 térképet. Még egy 256x256 voxel terület is lehet játékjelenet, de ezzel az eszközzel sokkal nagyobb jelenetek generálhatók és tarthatók aktívak, minimális hatással a CPU-ra és a fő RAM-ra.
Megvalósítás: Geometry Shader
A Geometry Shader rendelkezik bizonyos rezsivel. Ennek egyik oka az, hogy változó mennyiségű kimenetet tud előállítani, amelyet egy összefüggő memóriablokkba kell áthelyezni. Megoldásom az, hogy minden geometriai függvényhíváshoz ugyanannyi kimenetet állítsak elő, és amennyire lehetséges, minimalizálom az elágazásokat és a másolásokat.
Mindegyik kockafelülethez négy csúcs szükséges, és a kamera legfeljebb három arcot láthat, a vokselihez viszonyított helyzetétől függően. Ez három olyan ágat eredményez, amelyek nagyon hasonló arcokat rajzolnak, kivéve az egyik tengely mentén történő elmozdulást. A shift változó az ág hatásának minimalizálása céljából van hozzárendelve, és a csúcsok létrehozásakor az arc helyzetének beállítására szolgál.
Lásd a teljes forráskódot az alábbi linken.
- Geometry Shader
Voxel Performance Source Code
Geometry Shader
// Minden olyan szögből látható vokselre festse meg a // három oldalát, amelyet az adott kamera láthat. [maxvertexcount (12)] void geom (point inputGS p [1], inout TriangleStreaminput> triStream) {float4 pos = p [0] .pos * float4 (_Size, _Size, _Size, 1); float4 műszak; float4 voxelPosition = pos + _chunkPosition; float halfS = _Méret * 0,5; // x, y, z a voxel közepe, // a festékoldalakat a pIn1, pIn2, pIn3, pIn4 méret bemenetének fele eltolja; pIn1._color = p [0] ._ szín; pIn1.uv = float2 (0,0f, 0,0f); pIn2._color = p [0] ._ szín; pIn2.uv = float2 (0,0f, 1,0f); pIn3._color = p [0] ._ szín; pIn3.uv = float2 (1,0f, 0,0f); pIn4._color = p [0] ._ szín; pIn4.uv = float2 (1,0f, 1,0f); shift = (_cameraPosition.x voxelPosition.x)? float4 (1, 1, 1, 1): float4 (-1, 1, -1, 1); pIn1.pos = mul (UNITY_MATRIX_VP, mul (_worldMatrixTransform, pos + shift * float4 (-halfS, -halfS, halfS, 0)); triStream.Append (pIn1); pIn2.pos = mul (UNITY_MATRIX_VP, mul (_worldMatrixTransform, pos + shift * float4 (-halfS, halfS, halfS, 0))); triStream.Append (pIn2); pIn3.pos = mul (UNITY_MATRIX_VP, mul (_worldMatrixTransform, pos + shift * float4 (-halfS, -halfS, -halfS, 0)); triStream.Append (pIn3); pIn4.pos = mul (UNITY_MATRIX_VP, mul (_worldMatrixTransform, pos + shift * float4 (-halfS, halfS, -halfS, 0))); triStream.Append (pIn4); triStream.RestartStrip (); ...
Jövőbeli irányok
Ezt az eszközt saját használatra hoztam létre, reményeim szerint egyszerű, teljesítő és újrafelhasználható formában. Van ötletem a későbbi verziókhoz, de szívesen meghallgatnám a tiédet is, ha hajlandó vagy megosztani őket, vagy tudasd velem, hogyan használod ezt az eszközt a voxelek világának meghódítására.
Az egyik ötlet, amellyel az utóbbi időben játszottam, megváltoztatja a megjelenítés előtti optimalizálási lépést, hogy csak egy helyett több GPU-puffert adjon vissza. Ez lehetővé tenné a speciálisabb árnyékolók számára a különféle voxel-információk kezelését, például a felhők, folyadékok támogatását vagy a különböző voxel-arcok grafikai változását.
Tudasd velem mire gondolsz!
Az időjárással kapcsolatos munka (és inspiráció ehhez az eszközhöz)
Az alábbiakban bemutatott videó bemutatót Charles Humphrey készíti, aki tudós és úriember bemutatja, hogyan lehet GPU-puffert átvinni egy Compute Shader-ről egy Geometry Shader-re. Ez a technika a közelmúltban volt elérhető a Unity-ben, így kissé fekete művészet marad. Az oktatóanyag azt is bemutatja, hogyan lehet elérni néhány időjárási hatást a Unity-ben az óriásplakát mód használatával, így a hópelyhek mindig a kamera felé néznek. Ez egy csomó ügyes árnyékoló trükk, amelyet szerintem tovább szeretne folytatni és betenni az egyik vagyonába a Unity áruházban, de tíz különböző irányba húzza egyszerre.
Ez a cikk pontos és a szerző legjobb tudása szerint hű. A tartalom csak tájékoztató vagy szórakoztató célokat szolgál, és nem helyettesíti a személyes vagy üzleti tanácsokat üzleti, pénzügyi, jogi vagy technikai kérdésekben.
