Suorituskyvyn vapauttaminen: Syväsukellus WebGL:n klusteripohjaiseen eteenpäin renderöintiin ja valojen indeksoinnin optimointiin

Reaaliaikaisen 3D-grafiikan maailmassa webissä lukuisten dynaamisten valojen renderöinti on aina ollut merkittävä suorituskykyhaaste. Kehittäjinä pyrimme luomaan rikkaampia, immersiivisempiä näkymiä, mutta jokainen lisätty valonlähde voi eksponentiaalisesti kasvattaa laskennallista kuormaa, vieden WebGL:n äärirajoilleen. Perinteiset renderöintitekniikat pakottavat usein vaikeaan valintaan: uhrata visuaalinen laatu suorituskyvyn vuoksi tai hyväksyä alhaisemmat ruudunpäivitysnopeudet. Mutta mitä jos olisi olemassa tapa saada molempien maailmojen parhaat puolet?

Tässä astuu kuvaan klusteripohjainen eteenpäin renderöinti, joka tunnetaan myös nimellä Forward+. Tämä tehokas tekniikka tarjoaa hienostuneen ratkaisun, joka yhdistää perinteisen eteenpäin renderöinnin yksinkertaisuuden ja materiaalijoustavuuden viivästetyn varjostuksen valaistustehokkuuteen. Se mahdollistaa näkymien renderöinnin sadoilla tai jopa tuhansilla dynaamisilla valoilla säilyttäen samalla interaktiiviset ruudunpäivitysnopeudet.

Tämä artikkeli tarjoaa kattavan tutkimuksen klusteripohjaisesta eteenpäin renderöinnistä WebGL-kontekstissa. Käsittelemme sen peruskäsitteitä näkökartion jakamisesta valojen karsintaan ja keskitymme tiiviisti kaikkein kriittisimpään optimointiin: valojen indeksoinnin dataketjuun. Tämä on mekanismi, joka välittää tehokkaasti tiedon siitä, mitkä valot vaikuttavat mihinkin ruudun osaan, suorittimelta (CPU) grafiikkasuorittimen (GPU) fragment shaderille.

Renderöinnin kenttä: Eteenpäin vs. viivästetty renderöinti

Ymmärtääksemme, miksi klusteroitu renderöinti on niin tehokasta, meidän on ensin ymmärrettävä sitä edeltäneiden menetelmien rajoitukset.

Perinteinen eteenpäin renderöinti

Tämä on suoraviivaisin renderöintitapa. Jokaista objektia kohden verteksivarjostin (vertex shader) käsittelee sen verteksit, ja fragmenttivarjostin (fragment shader) laskee lopullisen värin jokaiselle pikselille. Valaistuksen osalta fragmenttivarjostin tyypillisesti käy silmukassa läpi jokaisen yksittäisen valon näkymässä ja laskee yhteen sen vaikutuksen. Ydinongelma on sen huono skaalautuvuus. Laskennallinen kuorma on karkeasti verrannollinen kaavaan (Fragmenttien määrä) x (Valojen määrä). Jo muutamalla kymmenellä valolla suorituskyky voi romahtaa, kun jokainen pikseli tarkistaa turhaan jokaisen valon, jopa ne, jotka ovat kilometrien päässä tai seinän takana.

Viivästetty varjostus (Deferred Shading)

Viivästetty varjostus kehitettiin ratkaisemaan juuri tämä ongelma. Se erottaa geometrian valaistuksesta kaksivaiheisessa prosessissa:

1. Geometriavaihe: Näkymän geometria renderöidään useisiin koko näytön tekstuuripinnoitteisiin, joita kutsutaan yhteisnimellä G-puskuri (G-buffer). Nämä tekstuurit tallentavat tietoa, kuten sijainnin, normaalit ja materiaaliominaisuudet (esim. albedo, karkeus) jokaiselle pikselille.
2. Valaistusvaihe: Piirretään koko näytön kokoinen neliö (quad). Jokaista pikseliä varten fragmenttivarjostin lukee G-puskurista arvot pinnan ominaisuuksien rekonstruoimiseksi ja laskee sitten valaistuksen. Keskeinen etu on, että valaistus lasketaan vain kerran pikseliä kohden, ja on helppoa määrittää, mitkä valot vaikuttavat kyseiseen pikseliin sen maailman sijainnin perusteella.

Vaikka se on erittäin tehokas näkymissä, joissa on paljon valoja, viivästetyllä varjostuksella on omat haittapuolensa, erityisesti WebGL:lle. Se vaatii suurta muistikaistanleveyttä G-puskurin vuoksi, sillä on vaikeuksia läpinäkyvyyden kanssa (joka vaatii erillisen eteenpäin renderöintivaiheen) ja se monimutkaistaa reunojenpehmennystekniikoiden, kuten MSAA:n, käyttöä.

Välimuodon puolustus: Forward+

Klusteripohjainen eteenpäin renderöinti tarjoaa elegantin kompromissin. Se säilyttää eteenpäin renderöinnin yksivaiheisen luonteen ja materiaalijoustavuuden, mutta sisältää esikäsittelyvaiheen, joka vähentää dramaattisesti valaistuslaskelmien määrää fragmenttia kohden. Se välttää raskaan G-puskurin, mikä tekee siitä muistiystävällisemmän ja yhteensopivan läpinäkyvyyden ja MSAA:n kanssa suoraan paketista.

Klusteripohjaisen eteenpäin renderöinnin peruskäsitteet

Klusteripohjaisen renderöinnin keskeinen ajatus on olla älykkäämpi siinä, mitä valoja tarkistamme. Sen sijaan, että jokainen pikseli tarkistaisi jokaisen valon, voimme ennalta määrittää, mitkä valot ovat riittävän lähellä mahdollisesti vaikuttaakseen tiettyyn ruudun alueeseen, ja saada kyseisen alueen pikselit tarkistamaan vain ne valot.

Tämä saavutetaan jakamalla kameran näkökartio (view frustum) pienempien tilavuuksien 3D-ruudukkoon, joita kutsutaan klustereiksi (tai tiiliksi).

Kokonaisprosessi voidaan jakaa neljään päävaiheeseen:

• 1. Klusteriruudukon luominen: Määritellään ja rakennetaan 3D-ruudukko, joka osittaa näkökartion. Tämä ruudukko on kiinteä näkymäavaruudessa ja liikkuu kameran mukana.
• 2. Valojen kohdistaminen (karsinta): Määritetään jokaiselle ruudukon klusterille lista kaikista valoista, joiden vaikutusalueet leikkaavat sen kanssa. Tämä on ratkaiseva karsintavaihe.
• 3. Valojen indeksointi: Tämä on keskittymisemme kohde. Pakkaamme valojen kohdistusvaiheen tulokset tiiviiseen tietorakenteeseen, joka voidaan tehokkaasti lähettää GPU:lle ja lukea fragment shaderilla.
• 4. Varjostus (Shading): Päärenderöintivaiheen aikana fragment shader määrittää ensin, mihin klusteriin se kuuluu. Sitten se käyttää valojen indeksointidataa noutaakseen kyseisen klusterin relevanttien valojen listan ja suorittaa valaistuslaskelmat *vain* tälle pienelle valojen osajoukolle.

Syväsukellus: Klusteriruudukon rakentaminen

Tekniikan perusta on hyvin jäsennelty ruudukko. Tässä tehdyt valinnat vaikuttavat suoraan sekä karsinnan tehokkuuteen että suorituskykyyn.

Ruudukon mittojen määrittely

Ruudukko määritellään sen resoluution mukaan X-, Y- ja Z-akseleilla (esim. 16x9x24 klusteria). Mittojen valinta on kompromissi:

• Korkeampi resoluutio (enemmän klustereita): Johtaa tiiviimpään ja tarkempaan valojen karsintaan. Klusteria kohden kohdistetaan vähemmän valoja, mikä tarkoittaa vähemmän työtä fragment shaderille. Se kuitenkin lisää valojen kohdistusvaiheen kuormitusta CPU:lla ja klusterien tietorakenteiden muistijalanjälkeä.
• Matalampi resoluutio (vähemmän klustereita): Vähentää CPU-puolen ja muistin kuormitusta, mutta johtaa karkeampaan karsintaan. Jokainen klusteri on suurempi, joten se leikkaa useampien valojen kanssa, mikä johtaa suurempaan työmäärään fragment shaderissa.

Yleinen käytäntö on sitoa X- ja Y-mitat näytön kuvasuhteeseen, esimerkiksi jakamalla näyttö 16x9 tiileen. Z-mitta on usein kriittisin säädettävä.

Logaritminen Z-leikkaus: Kriittinen optimointi

Jos jaamme näkökartion syvyyden (Z-akselin) lineaarisiin viipaleisiin, törmäämme perspektiiviprojektioon liittyvään ongelmaan. Valtava määrä geometrisia yksityiskohtia on keskittynyt lähelle kameraa, kun taas kaukana olevat objektit vievät hyvin vähän pikseleitä. Lineaarinen Z-jako loisi suuria, epätarkkoja klustereita lähellä kameraa (missä tarkkuutta tarvitaan eniten) ja pieniä, tuhlailevia klustereita kaukana.

Ratkaisu on logaritminen (tai eksponentiaalinen) Z-leikkaus. Tämä luo pienempiä ja tarkempia klustereita lähelle kameraa ja asteittain suurempia klustereita kauemmas, mikä kohdistaa klusterien jakautumisen perspektiiviprojektion toimintatavan kanssa. Tämä varmistaa tasaisemman fragmenttien määrän klusteria kohden ja johtaa paljon tehokkaampaan karsintaan.

Kaava i:nnen viipaleen syvyyden `z` laskemiseksi `N` viipaleen kokonaismäärästä, kun on annettu lähitaso `n` ja kaukotaso `f`, voidaan ilmaista seuraavasti:

Tämä kaava varmistaa, että peräkkäisten viipaleiden syvyyksien suhde on vakio, mikä luo halutun eksponentiaalisen jakautuman.

Asian ydin: Valojen karsinta ja indeksointi

Tässä tapahtuu taika. Kun ruudukkomme on määritelty, meidän on selvitettävä, mitkä valot vaikuttavat mihinkin klustereihin, ja pakattava tämä tieto GPU:lle. WebGL:ssä tämä valojen karsintalogiikka suoritetaan tyypillisesti CPU:lla JavaScriptin avulla jokaisessa ruudussa, jossa valot tai kamera liikkuvat.

Valo-klusteri-leikkaustestit

Prosessi on käsitteellisesti yksinkertainen: käy läpi jokainen valo ja testaa sen leikkauskohta jokaisen klusterin rajaavan tilavuuden (bounding volume) kanssa. Klusterin rajaava tilavuus on itsessään kartio (frustum). Yleisiä testejä ovat:

• Pistevalot: Käsitellään palloina. Testi on pallo-kartio-leikkaus.
• Kohdevalot: Käsitellään keiloina. Testi on keila-kartio-leikkaus, mikä on monimutkaisempaa.
• Suuntavalot: Näiden katsotaan usein vaikuttavan kaikkeen, joten ne käsitellään tyypillisesti erikseen eikä niitä sisällytetä karsintaprosessiin.

Näiden testien tehokas suorittaminen on avainasemassa. Tämän vaiheen jälkeen meillä on vastaavuus, ehkä JavaScript-taulukoiden taulukossa, kuten: clusterLights[clusterId] = [lightId1, lightId2, ...].

Tietorakennehaaste: CPU:lta GPU:lle

Miten saamme tämän klusterikohtaisen valolistan fragment shaderille? Emme voi vain välittää vaihtelevan pituista taulukkoa. Shader tarvitsee ennustettavan tavan hakea nämä tiedot. Tässä kohtaa Globaali valolista ja valojen indeksilista -lähestymistapa tulee apuun. Se on elegantti tapa litistää monimutkainen tietorakenteemme GPU-ystävällisiksi tekstuureiksi.

Luomme kaksi ensisijaista tietorakennetta:

1. Klusterin tietoruudukkotekstuuri: Tämä on 3D-tekstuuri (tai 2D-tekstuuri, joka emuloi 3D-tekstuuria), jossa jokainen tekseli vastaa yhtä ruudukkomme klusteria. Jokainen tekseli tallentaa kaksi elintärkeää tietoa:
   • Siirtymä (offset): Tämä on aloitusindeksi toisessa tietorakenteessamme (Globaali valolista), josta tämän klusterin valot alkavat.
   • Määrä (count): Tämä on tähän klusteriin vaikuttavien valojen lukumäärä.
2. Globaali valolistatekstuuri: Tämä on yksinkertainen 1D-lista (tallennettu 2D-tekstuuriin), joka sisältää kaikkien klustereiden kaikkien valoindeksien yhdistetyn jonon.

Tietovirran visualisointi

Kuvitellaan yksinkertainen skenaario:

• Klusteriin 0 vaikuttavat valot indekseillä [5, 12].
• Klusteriin 1 vaikuttavat valot indekseillä [8, 5, 20].
• Klusteriin 2 vaikuttaa valo indeksillä [7].

Globaali valolista: [5, 12, 8, 5, 20, 7, ...]

Klusterin tietoruudukko:

• Tekseli klusterille 0: { siirtymä: 0, määrä: 2 }
• Tekseli klusterille 1: { siirtymä: 2, määrä: 3 }
• Tekseli klusterille 2: { siirtymä: 5, määrä: 1 }

Toteutus WebGL:ssä & GLSL:ssä

Yhdistetään nyt käsitteet koodiin. Toteutus sisältää JavaScript-osuuden karsintaa ja datan valmistelua varten sekä GLSL-osuuden varjostusta varten.

Datan siirto GPU:lle (JavaScript)

Suoritettuasi valojen karsinnan CPU:lla, sinulla on klusteriruudukon data (siirtymä/määrä-parit) ja globaali valolistasi. Nämä on ladattava GPU:lle joka ruudussa.

1. Pakkaa ja lataa klusteridata: Luo `Float32Array` tai `Uint32Array` klusteridatallesi. Voit pakata kunkin klusterin siirtymän ja määrän tekstuurin RG-kanaviin. Käytä `gl.texImage2D` luodaksesi tai `gl.texSubImage2D` päivittääksesi tekstuurin tällä datalla. Tämä on sinun klusterin tietoruudukkotekstuurisi.
2. Lataa globaali valolista: Samoin, litistä valoindeksisi `Uint32Array`-taulukkoon ja lataa se toiseen tekstuuriin.
3. Lataa valojen ominaisuudet: Kaikki valodata (sijainti, väri, voimakkuus, säde jne.) tulisi tallentaa suureen tekstuuriin tai Uniform Buffer Objectiin (UBO) nopeita, indeksoituja hakuja varten shaderista.

Fragment Shaderin logiikka (GLSL)

Fragment shader on paikka, jossa suorituskykyhyödyt realisoituvat. Tässä on askel-askeleelta logiikka:

Vaihe 1: Määritä fragmentin klusteri-indeksi

Ensin meidän on tiedettävä, mihin klusteriin nykyinen fragmentti kuuluu. Tämä vaatii sen sijainnin näkymäavaruudessa.

            
// Uniform-muuttujat, jotka antavat ruudukon tiedot
uniform vec3 u_gridDimensions; // esim. vec3(16.0, 9.0, 24.0)
uniform vec2 u_screenDimensions;
uniform float u_nearPlane;
uniform float u_farPlane;

// Funktio Z-viipaleen indeksin saamiseksi näkymäavaruuden syvyydestä
float getClusterZIndex(float viewZ) {
  // viewZ on negatiivinen, tee siitä positiivinen
  viewZ = -viewZ;
  // CPU:lla käyttämämme logaritmisen kaavan käänteisfunktio
  float slice = floor(log(viewZ / u_nearPlane) / log(u_farPlane / u_nearPlane) * u_gridDimensions.z);
  return slice;
}

// Päälogiikka 3D-klusteri-indeksin saamiseksi
vec3 getClusterIndex() {
  // Hae X- ja Y-indeksi ruudun koordinaateista
  float clusterX = floor(gl_FragCoord.x / u_screenDimensions.x * u_gridDimensions.x);
  float clusterY = floor(gl_FragCoord.y / u_screenDimensions.y * u_gridDimensions.y);
  
  // Hae Z-indeksi fragmentin näkymäavaruuden Z-sijainnista (v_viewPos.z)
  float clusterZ = getClusterZIndex(v_viewPos.z);

  return vec3(clusterX, clusterY, clusterZ);
}

            

              
                Copy
              
            
          

Vaihe 2: Hae klusterin data

Käyttämällä klusteri-indeksiä, luemme klusterin tietoruudukkotekstuurimme saadaksemme siirtymän ja määrän tämän fragmentin valolistalle.

            
uniform sampler2D u_clusterTexture; // Tekstuuri, joka tallentaa siirtymän ja määrän

// ... main()-funktiossa ...
vec3 clusterIndex = getClusterIndex();
// Litistä 3D-indeksi 2D-tekstuurikoordinaatiksi tarvittaessa
vec2 clusterTexCoord = ...; 

vec2 lightData = texture2D(u_clusterTexture, clusterTexCoord).rg;
int offset = int(lightData.x);
int count = int(lightData.y);

            

              
                Copy
              
            
          

Vaihe 3: Käy silmukka läpi ja kerää valaistus

Tämä on viimeinen vaihe. Suoritamme lyhyen, rajoitetun silmukan. Jokaisella iteraatiolla haemme valoindeksin globaalista valolistasta, sitten käytämme sitä indeksiä saadaksemme valon täydet ominaisuudet ja laskemme sen vaikutuksen.

            
uniform sampler2D u_globalLightIndexTexture;
uniform sampler2D u_lightPropertiesTexture; // UBO olisi parempi

vec3 finalColor = vec3(0.0);

for (int i = 0; i < count; i++) {
  // 1. Hae käsiteltävän valon indeksi
  int lightIndex = int(texture2D(u_globalLightIndexTexture, vec2(float(offset + i), 0.0)).r);

  // 2. Hae valon ominaisuudet tällä indeksillä
  Light currentLight = getLightProperties(lightIndex, u_lightPropertiesTexture);

  // 3. Laske tämän valon vaikutus
  finalColor += calculateLight(currentLight, surfaceProperties, viewDir);
}

            

              
                Copy
              
            
          

Ja siinä se! Sen sijaan, että silmukka ajaisi satoja kertoja, meillä on nyt silmukka, joka saattaa ajaa 5, 10 tai 30 kertaa, riippuen valon tiheydestä kyseisessä näkymän osassa, mikä johtaa valtavaan suorituskyvyn parannukseen.

Edistyneet optimoinnit ja tulevaisuuden näkymät

• CPU vs. Compute: Tämän tekniikan ensisijainen pullonkaula WebGL:ssä on se, että valojen karsinta tapahtuu CPU:lla JavaScriptissä. Tämä on yksisäikeistä ja vaatii datasynkronoinnin GPU:n kanssa joka ruudussa. WebGPU:n saapuminen on mullistava asia. Sen compute shaderit mahdollistavat koko klusterin rakennus- ja valojen karsintaprosessin siirtämisen GPU:lle, tehden siitä rinnakkaisen ja kertaluokkia nopeamman.
• Muistinhallinta: Ole tietoinen tietorakenteidesi käyttämästä muistista. 16x9x24-ruudukolle (3 456 klusteria) ja enintään, sanotaanko, 64 valolle per klusteri, globaali valolista voisi potentiaalisesti sisältää 221 184 indeksiä. Ruudukon virittäminen ja realistisen enimmäismäärän asettaminen valoille per klusteri on olennaista.
• Ruudukon virittäminen: Ruudukon mitoille ei ole olemassa yhtä ainoaa maagista lukua. Optimaalinen konfiguraatio riippuu vahvasti näkymäsi sisällöstä, kameran käyttäytymisestä ja kohdelaitteistosta. Profilointi ja erikokoisten ruudukoiden kokeileminen ovat ratkaisevan tärkeitä huippusuorituskyvyn saavuttamiseksi.

Yhteenveto

Klusteripohjainen eteenpäin renderöinti on enemmän kuin vain akateeminen kuriositeetti; se on käytännöllinen ja tehokas ratkaisu merkittävään ongelmaan reaaliaikaisessa web-grafiikassa. Jakamalla älykkäästi näkymäavaruuden ja suorittamalla erittäin optimoidun valojen karsinta- ja indeksointivaiheen, se katkaisee suoran yhteyden valojen määrän ja fragment shaderin kuorman välillä.

Vaikka se lisää monimutkaisuutta CPU-puolella verrattuna perinteiseen eteenpäin renderöintiin, suorituskykyhyöty on valtava, mahdollistaen rikkaampia, dynaamisempia ja visuaalisesti houkuttelevampia kokemuksia suoraan selaimessa. Sen menestyksen ydin piilee tehokkaassa valojen indeksointiketjussa – sillassa, joka muuttaa monimutkaisen spatiaalisen ongelman yksinkertaiseksi, rajoitetuksi silmukaksi GPU:lla.

Kun web-alusta kehittyy WebGPU:n kaltaisten teknologioiden myötä, klusteripohjaisen eteenpäin renderöinnin kaltaisista tekniikoista tulee vain helpommin saavutettavia ja suorituskykyisempiä, hämärtäen entisestään natiivien ja verkkopohjaisten 3D-sovellusten välistä rajaa.