Jõudluse vallandamine: Süvaanalüüs WebGL-i klasterdatud edasisuunalise renderdamise ja valgusindekseerimise optimeerimisest

Veebis reaalajas 3D-graafika maailmas on arvukate dünaamiliste valguste renderdamine alati olnud märkimisväärne jõudlusprobleem. Arendajatena püüame luua rikkalikumaid ja kaasahaaravamaid stseene, kuid iga täiendav valgusallikas võib arvutuskulusid eksponentsiaalselt suurendada, viies WebGL-i oma piirideni. Traditsioonilised renderdamistehnikad sunnivad sageli tegema raske valiku: ohverdada visuaalne kvaliteet jõudluse nimel või leppida madalamate kaadrisagedustega. Aga mis siis, kui oleks olemas viis saada mõlemast maailmast parim?

Siin tulebki mängu klasterdatud edasisuunaline renderdamine (Clustered Forward Rendering), tuntud ka kui Forward+. See võimas tehnika pakub keerukat lahendust, ühendades traditsioonilise edasisuunalise renderdamise lihtsuse ja materjalide paindlikkuse edasilükatud varjutamise (deferred shading) valgustusefektiivsusega. See võimaldab meil renderdada stseene sadade või isegi tuhandete dünaamiliste valgustitega, säilitades samal ajal interaktiivsed kaadrisagedused.

See artikkel pakub põhjalikku ülevaadet klasterdatud edasisuunalisest renderdamisest WebGL-i kontekstis. Me analüüsime põhimõisteid, alates vaatefrustumi jaotamisest kuni valguste kärpimiseni, ja keskendume intensiivselt kõige kriitilisemale optimeerimisele: valgusindekseerimise andmetorule. See on mehhanism, mis edastab tõhusalt teavet selle kohta, millised tuled milliseid ekraaniosi mõjutavad, CPU-lt GPU fragmendivarjutajale.

Renderdamismaastik: edasisuunaline vs. edasilükatud

Et mõista, miks klasterdatud renderdamine on nii tõhus, peame esmalt aru saama meetoditest, mis sellele eelnesid, ja nende piirangutest.

Traditsiooniline edasisuunaline renderdamine

See on kõige otsekohesem renderdamisviis. Iga objekti puhul töötleb tipuvarjutaja selle tippe ja fragmendivarjutaja arvutab iga piksli lõpliku värvi. Valgustuse osas käib fragmendivarjutaja tavaliselt tsüklis läbi iga stseenis oleva valguse ja akumuleerib selle panuse. Põhiprobleem on selle halb skaleeruvus. Arvutuskulu on ligikaudu proportsionaalne valemiga (fragmentide arv) x (valguste arv). Juba mõnekümne valgusega võib jõudlus järsult langeda, kuna iga piksel kontrollib liiaselt iga valgust, isegi neid, mis on kilomeetrite kaugusel või seina taga.

Edasilükatud varjutamine (Deferred Shading)

Edasilükatud varjutamine arendati välja just selle probleemi lahendamiseks. See eraldab geomeetria valgustusest kahekäigulises protsessis:

1. Geomeetriakäik (Geometry Pass): Stseeni geomeetria renderdatakse mitmesse täisekraani tekstuuri, mida ühiselt tuntakse G-puhvrina (G-buffer). Need tekstuurid salvestavad iga piksli kohta andmeid nagu asukoht, normaalid ja materjali omadused (nt albeedo, karedus).
2. Valgustuskäik (Lighting Pass): Joonistatakse täisekraani nelinurk. Iga piksli jaoks loeb fragmendivarjutaja G-puhvrist andmed pinna omaduste taastamiseks ja seejärel arvutab valgustuse. Peamine eelis on see, et valgustus arvutatakse ainult üks kord piksli kohta ja on lihtne kindlaks teha, millised tuled seda pikslit selle maailmaasukoha põhjal mõjutavad.

Kuigi see on paljude valgustitega stseenide puhul väga tõhus, on edasilükatud varjutamisel omad puudused, eriti WebGL-i jaoks. Sellel on G-puhvri tõttu kõrged mäluriba laiuse nõuded, see on hädas läbipaistvusega (mis nõuab eraldi edasisuunalise renderdamise käiku) ja raskendab silumisvastaste tehnikate, nagu MSAA, kasutamist.

Kesktee otsingul: Forward+

Klasterdatud edasisuunaline renderdamine pakub elegantset kompromissi. See säilitab edasisuunalise renderdamise ühekordse läbimise olemuse ja materjalide paindlikkuse, kuid sisaldab eeltöötlusetappi, et dramaatiliselt vähendada valgusarvutuste arvu fragmendi kohta. See väldib rasket G-puhvrit, muutes selle mälu-sõbralikumaks ning ühilduvaks läbipaistvuse ja MSAA-ga ilma lisatööta.

Klasterdatud edasisuunalise renderdamise põhimõisted

Klasterdatud renderdamise keskne idee on olla targem selles osas, milliseid valgusteid me kontrollime. Selle asemel, et iga piksel kontrolliks iga valgust, saame eelnevalt kindlaks teha, millised tuled on piisavalt lähedal, et potentsiaalselt mõjutada teatud ekraani piirkonda, ja lasta selle piirkonna pikslitel kontrollida ainult neid tulesid.

See saavutatakse kaamera vaatefrustumi jaotamisega 3D-ruudustikuks väiksemateks mahtudeks, mida nimetatakse klastriteks (või paanideks).

Kogu protsessi võib jagada neljaks peamiseks etapiks:

• 1. Klastriruudustiku loomine: Määratletakse ja konstrueeritakse 3D-ruudustik, mis jaotab vaatefrustumi. See ruudustik on fikseeritud vaateruumis ja liigub koos kaameraga.
• 2. Valguste määramine (kärpimine): Iga ruudustiku klastri jaoks määratakse nimekiri kõigist valgustest, mille mõjualad sellega ristuvad. See on kriitiline kärpimisetapp.
• 3. Valgusindekseerimine: See on meie fookuses. Me pakendame valguste määramise etapi tulemused kompaktsesse andmestruktuuri, mida saab tõhusalt saata GPU-le ja lugeda fragmendivarjutajast.
• 4. Varjutamine: Peamise renderdamiskäigu ajal määrab fragmendivarjutaja esmalt kindlaks, millisesse klastrisse ta kuulub. Seejärel kasutab see valgusindekseerimise andmeid, et leida selle klastri jaoks asjakohaste valguste loend ja teostab valgustusarvutused *ainult* selle väikese valguste alamhulga jaoks.

Süvaanalüüs: klastriruudustiku ehitamine

Selle tehnika aluseks on hästi struktureeritud ruudustik. Siin tehtud valikud mõjutavad otseselt nii kärpimise tõhusust kui ka jõudlust.

Ruudustiku mõõtmete määratlemine

Ruudustik on defineeritud selle resolutsiooniga piki X-, Y- ja Z-telge (nt 16x9x24 klastrit). Mõõtmete valik on kompromiss:

• Kõrgem resolutsioon (rohkem klastreid): Tulemuseks on täpsem ja rangem valguse kärpimine. Igale klastrile määratakse vähem tulesid, mis tähendab vähem tööd fragmendivarjutajale. Samas suurendab see valguste määramise etapi koormust CPU-l ja klastri andmestruktuuride mälukasutust.
• Madalam resolutsioon (vähem klastreid): Vähendab CPU-poolset ja mälukoormust, kuid tulemuseks on jämedam kärpimine. Iga klaster on suurem, seega ristub see rohkemate tuledega, mis toob kaasa rohkem tööd fragmendivarjutajas.

Levinud praktika on siduda X- ja Y-mõõtmed ekraani kuvasuhtega, näiteks jagades ekraani 16x9 paaniks. Z-mõõde on sageli kõige kriitilisem häälestamist vajav parameeter.

Logaritmiline Z-lõikamine: kriitiline optimeerimine

Kui jaotame frustumi sügavuse (Z-telje) lineaarseteks lõikudeks, tekib meil perspektiivprojektsiooniga seotud probleem. Suur osa geomeetrilistest detailidest on koondunud kaamera lähedale, samas kui kaugel asuvad objektid hõivavad väga vähe piksleid. Lineaarne Z-jaotus looks suured, ebatäpsed klastrid kaamera lähedal (kus täpsus on kõige vajalikum) ja pisikesed, raiskavad klastrid kauguses.

Lahenduseks on logaritmiline (või eksponentsiaalne) Z-lõikamine. See loob väiksemad ja täpsemad klastrid kaamera lähedal ning järk-järgult suuremad klastrid kaugemal, viies klastrite jaotuse vastavusse perspektiivprojektsiooni toimimisega. See tagab ühtlasema fragmentide arvu klastri kohta ja viib palju tõhusama kärpimiseni.

Valem sügavuse `z` arvutamiseks i-nda lõigu jaoks `N` koguarvust lõikudest, arvestades lähitasandit `n` ja kaugtasandit `f`, võib väljendada järgmiselt:

See valem tagab, et järjestikuste lõikude sügavuste suhe on konstantne, luues soovitud eksponentsiaalse jaotuse.

Asja tuum: valguse kärpimine ja indekseerimine

Siin toimubki maagia. Kui meie ruudustik on defineeritud, peame välja selgitama, millised tuled milliseid klastreid mõjutavad, ja seejärel pakendama selle teabe GPU jaoks. WebGL-is teostatakse see valguse kärpimise loogika tavaliselt CPU-l JavaScripti abil iga kaadri jaoks, kus tuled või kaamera liiguvad.

Valguse-klastri ristumiskatsed

Protsess on kontseptuaalselt lihtne: käiakse tsüklis läbi iga valgus ja testitakse selle ristumist iga klastri piirdekehaga. Klastri piirdekeha on ise frustum. Levinumad testid hõlmavad:

• Punktvalgustid: Käsitletakse sfääridena. Test on sfääri ja frustumi ristumiskatse.
• Kohtvalgustid: Käsitletakse koonustena. Test on koonuse ja frustumi ristumiskatse, mis on keerulisem.
• Suunavalgustid: Neid peetakse sageli kõike mõjutavateks, seega käsitletakse neid tavaliselt eraldi ja ei kaasata kärpimisprotsessi.

Nende testide tõhus teostamine on võtmetähtsusega. Pärast seda sammu on meil vastavus, näiteks JavaScripti massiivide massiivis, nagu: clusterLights[clusterId] = [lightId1, lightId2, ...].

Andmestruktuuri väljakutse: CPU-lt GPU-le

Kuidas me saame selle klastripõhise valgusnimekirja fragmendivarjutajale? Me ei saa lihtsalt edastada muutuva pikkusega massiivi. Varjutaja vajab prognoositavat viisi nende andmete otsimiseks. Siin tulebki mängu globaalse valgusnimekirja ja valgusindeksite nimekirja lähenemine. See on elegantne meetod meie keeruka andmestruktuuri tasandamiseks GPU-sõbralikeks tekstuurideks.

Loome kaks peamist andmestruktuuri:

1. Klastriinfo ruudustiku tekstuur: See on 3D-tekstuur (või 2D-tekstuur, mis emuleerib 3D-d), kus iga tekselelement vastab ühele klastrile meie ruudustikus. Iga tekselelement salvestab kaks olulist teavet:
   • Nihe (offset): See on algusindeks meie teises andmestruktuuris (globaalses valgusnimekirjas), kust algavad selle klastri tuled.
   • Arv (count): See on tulesid arv, mis seda klastrit mõjutavad.
2. Globaalse valgusnimekirja tekstuur: See on lihtne 1D-loend (salvestatud 2D-tekstuuris), mis sisaldab kõigi klastrite kõigi valgusindeksite järjestikust jada.

Andmevoo visualiseerimine

Kujutame ette lihtsat stsenaariumi:

• Klastrit 0 mõjutavad tuled indeksitega [5, 12].
• Klastrit 1 mõjutavad tuled indeksitega [8, 5, 20].
• Klastrit 2 mõjutab tuli indeksiga [7].

Globaalne valgusnimekiri: [5, 12, 8, 5, 20, 7, ...]

Klastriinfo ruudustik:

• Tekselelement klastrile 0: { offset: 0, count: 2 }
• Tekselelement klastrile 1: { offset: 2, count: 3 }
• Tekselelement klastrile 2: { offset: 5, count: 1 }

Selle seadistusega saab iga fragment määrata oma klastri, lugeda ühe tekselelemendi klastriruudustikust, et saada nihe ja arv, ning seejärel teostada lihtsa tsükli, et lugeda oma spetsiifilised tuled globaalsest valgusnimekirjast.

Implementeerimine WebGL-is ja GLSL-is

Nüüd ühendame kontseptsioonid koodiga. Implementatsioon hõlmab JavaScripti osa kärpimiseks ja andmete ettevalmistamiseks ning GLSL-i osa varjutamiseks.

Andmeedastus GPU-le (JavaScript)

Pärast valguse kärpimise teostamist CPU-l on teil olemas klastriruudustiku andmed (nihe/arv paarid) ja globaalne valgusnimekiri. Need tuleb igas kaadris GPU-le üles laadida.

1. Klastriandmete pakkimine ja üleslaadimine: Looge oma klastriandmete jaoks `Float32Array` või `Uint32Array`. Saate pakkida iga klastri nihke ja arvu tekstuuri RG-kanalitesse. Kasutage `gl.texImage2D` tekstuuri loomiseks või `gl.texSubImage2D` selle andmetega uuendamiseks. See on teie klastriinfo ruudustiku tekstuur.
2. Globaalse valgusnimekirja üleslaadimine: Sarnaselt tasandage oma valgusindeksid `Uint32Array`-ks ja laadige see üles teise tekstuuri.
3. Valgusomaduste üleslaadimine: Kõik valgusandmed (asukoht, värv, intensiivsus, raadius jne) tuleks salvestada suurde tekstuuri või ühtsesse puhverobjekti (UBO), et varjutajast saaks teha kiireid, indekseeritud otsinguid.

Fragmendivarjutaja loogika (GLSL)

Fragmendivarjutajas realiseeruvad jõudluse kasumid. Siin on samm-sammuline loogika:

Samm 1: Fragmendi klastriindeksi määramine

Esiteks peame teadma, millisesse klastrisse praegune fragment kuulub. Selleks on vaja selle asukohta vaateruumis.

            
// Ruudustiku infot pakkuvad uniform-muutujad
uniform vec3 u_gridDimensions; // nt vec3(16.0, 9.0, 24.0)
uniform vec2 u_screenDimensions;
uniform float u_nearPlane;
uniform float u_farPlane;

// Funktsioon Z-lõigu indeksi saamiseks vaateruumi sügavusest
float getClusterZIndex(float viewZ) {
  // viewZ on negatiivne, muudame selle positiivseks
  viewZ = -viewZ;
  // CPU-l kasutatud logaritmilise valemi pöördfunktsioon
  float slice = floor(log(viewZ / u_nearPlane) / log(u_farPlane / u_nearPlane) * u_gridDimensions.z);
  return slice;
}

// Peamine loogika 3D klastriindeksi saamiseks
vec3 getClusterIndex() {
  // X ja Y indeksi saamine ekraani koordinaatidest
  float clusterX = floor(gl_FragCoord.x / u_screenDimensions.x * u_gridDimensions.x);
  float clusterY = floor(gl_FragCoord.y / u_screenDimensions.y * u_gridDimensions.y);
  
  // Z indeksi saamine fragmendi vaateruumi Z-positsioonist (v_viewPos.z)
  float clusterZ = getClusterZIndex(v_viewPos.z);

  return vec3(clusterX, clusterY, clusterZ);
}

            

              
                Copy
              
            
          

Samm 2: Klastriandmete hankimine

Kasutades klastriindeksit, loeme oma klastriinfo ruudustiku tekstuurist andmeid, et saada selle fragmendi valgusnimekirja jaoks nihe ja arv.

            
uniform sampler2D u_clusterTexture; // Tekstuur, mis salvestab nihet ja arvu

// ... funktsioonis main() ...
vec3 clusterIndex = getClusterIndex();
// Vajadusel tasandage 3D-indeks 2D-tekstuuri koordinaadiks
vec2 clusterTexCoord = ...; 

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

            

              
                Copy
              
            
          

Samm 3: Tsükkel ja valguse akumuleerimine

See on viimane samm. Me käivitame lühikese, piiratud tsükli. Iga iteratsiooni puhul hangime valgusindeksi globaalsest valgusnimekirjast, seejärel kasutame seda indeksit valguse täielike omaduste saamiseks ja arvutame selle panuse.

            
uniform sampler2D u_globalLightIndexTexture;
uniform sampler2D u_lightPropertiesTexture; // UBO oleks parem

vec3 finalColor = vec3(0.0);

for (int i = 0; i < count; i++) {
  // 1. Hangi töödeldava valguse indeks
  int lightIndex = int(texture2D(u_globalLightIndexTexture, vec2(float(offset + i), 0.0)).r);

  // 2. Hangi valguse omadused selle indeksi abil
  Light currentLight = getLightProperties(lightIndex, u_lightPropertiesTexture);

  // 3. Arvuta selle valguse panus
  finalColor += calculateLight(currentLight, surfaceProperties, viewDir);
}

            

              
                Copy
              
            
          

Ja ongi kõik! Selle asemel, et tsükkel jookseks sadu kordi, on meil nüüd tsükkel, mis võib joosta 5, 10 või 30 korda, sõltuvalt valguse tihedusest konkreetses stseeni osas, mis toob kaasa monumentaalse jõudluse paranemise.

Täpsemad optimeerimised ja tulevikukaalutlused

• CPU vs. arvutusvõimsus (Compute): Selle tehnika peamine kitsaskoht WebGL-is on see, et valguse kärpimine toimub CPU-l JavaScriptis. See on ühelõimeline ja nõuab igas kaadris andmete sünkroonimist GPU-ga. WebGPU tulek on mängumuutja. Selle arvutusvarjutajad (compute shaders) võimaldavad kogu klastrite ehitamise ja valguse kärpimise protsessi üle viia GPU-le, muutes selle paralleelseks ja kordades kiiremaks.
• Mäluhaldus: Olge teadlik oma andmestruktuuride mälukasutusest. 16x9x24 ruudustiku (3,456 klastrit) ja maksimaalselt, näiteks, 64 tulega klastri kohta, võib globaalne valgusnimekiri potentsiaalselt sisaldada 221 184 indeksit. Ruudustiku häälestamine ja realistliku maksimaalse tulede arvu seadmine klastri kohta on hädavajalik.
• Ruudustiku häälestamine: Ruudustiku mõõtmete jaoks pole ühtegi maagilist numbrit. Optimaalne konfiguratsioon sõltub suuresti teie stseeni sisust, kaamera käitumisest ja sihtriistvarast. Profiilimine ja erinevate ruudustiku suurustega katsetamine on tippjõudluse saavutamiseks ülioluline.

Kokkuvõte

Klasterdatud edasisuunaline renderdamine on enamat kui lihtsalt akadeemiline kurioosum; see on praktiline ja võimas lahendus olulisele probleemile reaalajas veebigraafikas. Arukalt vaateruumi jaotades ja teostades kõrgelt optimeeritud valguse kärpimise ja indekseerimise sammu, purustab see otsese seose valguste arvu ja fragmendivarjutaja kulu vahel.

Kuigi see lisab CPU-poolele rohkem keerukust võrreldes traditsioonilise edasisuunalise renderdamisega, on jõudluse kasu tohutu, võimaldades rikkalikumaid, dünaamilisemaid ja visuaalselt köitvamaid kogemusi otse veebilehitsejas. Selle edu tuum peitub tõhusas valgusindekseerimise torus – sillaks, mis muudab keerulise ruumilise probleemi lihtsaks, piiratud tsükliks GPU-l.

Veebiplatvormi arenedes tehnoloogiatega nagu WebGPU, muutuvad tehnikad nagu klasterdatud edasisuunaline renderdamine ainult kättesaadavamaks ja jõudsamaks, hägustades veelgi piire natiivsete ja veebipõhiste 3D-rakenduste vahel.