Što najnoviji 3D web projekti 2026. otkrivaju o realnim granicama WebGL‑a na mobilnim preglednicima

WebGL na mobitelima 2026.: gdje točno puca sustav

Najnoviji 3D web showcase projekti iz 2026. godine jasno pokazuju da se granice WebGL‑a na mobilnim preglednicima više ne mjere samo u „snazi GPU‑a”. Performanse ovise o kombinaciji faktora: ograničenja pregledničkog sandboxa, energetskog budžeta baterije, throttlinga CPU‑a i GPU‑a, te načina na koji engine organizira rendering pipeline. U praksi to znači da dva projekta, oba na WebGL‑u, mogu imati radikalno različit FPS na istom telefonu – ovisno o tome kako su posloženi draw pozivi, shaderi i memorija.

U zadnjim tjednima pojavili su se konkretni primjeri koji to potvrđuju: usporedbe PlayCanvas i Three.js projekata na mobilnim preglednicima, rasprave o milijunskim sustavima čestica i showcaseovi koji istovremeno nude WebGL i WebGPU verziju iste scene. Rezultat je jasniji uvid u to gdje WebGL još drži korak, a gdje ga WebGPU na mobilnim uređajima počinje sustizati i prestizati.

PlayCanvas vs Three.js: zašto engine često odlučuje pobjednika

Usporedbe PlayCanvasa i Three.js‑a na istim mobitelima pokazuju da se razlike u performansama WebGL‑a često ne svode na sam API, nego na to kako engine upravlja cijelim rendering pipelineom. WebGL je samo sloj prema GPU‑u; sve između scene i draw poziva je odgovornost enginea.

PlayCanvas se u zadnjim verzijama profilira kao engine posebno agresivan prema mobilnoj optimizaciji. Fokus je na:

• smanjenju broja draw poziva kroz batching i instancing,
• automatskom spajanju materijala i tekstura gdje je moguće,
• pametnim fallbackovima za slabije GPU‑ove i starije uređaje,
• dosljednoj upotrebi WebGL2 značajki za širu kompatibilnost.

Three.js, s druge strane, ostaje fleksibilniji i više „toolkit” nego strogo optimiziran engine. Nudi ogroman ekosustav i slobodu, ali ostavlja više posla razvojnom timu: ručno spajanje materijala, prilagodbu geometrije, ručno upravljanje LOD‑ovima i custom shaderima. Na desktopu to često nije kritično, no na mobitelu razlika u FPS‑u postaje mjerljiva već kod srednje složenih scena.

Tipičan primjer iz 2026.: ista arhitektonska scena s desetak objekata, PBR materijalima i nekoliko svjetala. Na istom Android telefonu PlayCanvas verzija drži 50–60 FPS, dok Three.js implementacija bez agresivnog batchinga pada na 25–30 FPS. API je isti (WebGL2), ali način na koji engine pakira draw pozive i resurse čini razliku između glatke i granične interakcije.

Zašto je WebGL2 i dalje ključan za masovno tržište

Unatoč eksploziji interesa za WebGPU, vodeći enginei poput PlayCanvasa i dalje vrlo jasno komuniciraju da je WebGL2 primarni cilj za masovnu publiku. Razlog je jednostavan: pokrivenost uređaja i preglednika. Velik dio Android i iOS ekosustava u 2026. još uvijek nema stabilnu, jednako implementiranu podršku za WebGPU, dok je WebGL2 praktički standard.

To u praksi znači da većina produkcijskih 3D web aplikacija mora biti dizajnirana tako da:

• zadovoljava performanse i stabilnost na WebGL2 putanji,
• koristi WebGPU samo kao dodatni „boost” na jačim uređajima,
• održava jedinstveni UX, bez dramatičnih razlika između fallback i high‑end verzije.

Za timove koji ciljaju globalno tržište, WebGL2 ostaje „najniži zajednički nazivnik”. Ako WebGL verzija ne radi dovoljno dobro, WebGPU implementacija ne spašava projekt jer će većina mobilnih korisnika i dalje završiti na WebGL fallbacku.

WebGPU showcaseovi: milijuni čestica i Gaussian splatting

Istovremeno, WebGPU showcase projekti iz 2026. jasno pokazuju koliko daleko se može ići kada scena više ne opterećuje WebGL. Demoi s milijunskim sustavima čestica, volumetrijskom rasvjetom i naprednim post‑procesom postižu stabilan FPS upravo zato što WebGPU otvara compute shadere, bolji pristup memoriji i moderniji pipeline.

Primjer je novi PlayCanvas 2.18 fokusiran na Gaussian splatting preko WebGPU compute shadera. U toj arhitekturi WebGPU renderer preuzima težak dio posla: rekonstrukciju 3D scene iz tisuća ili milijuna „splatova”, filtriranje i reprojekciju. WebGL renderer ostaje fallback sloj – dovoljan za osnovnu interakciju i pregled, ali vidljivo ograničen čim broj splatova ili čestica postane masivan.

Tipičan scenarij:

• WebGPU verzija: 2–3 milijuna čestica, real‑time fizika, dinamično osvjetljenje, stabilnih 60 FPS na novijim flagship telefonima i desktopu.
• WebGL fallback: 200–300 tisuća čestica, reducirani post‑proces, pojednostavljeni shaderi, ciljanih 30 FPS na srednjem rangu mobitela.

Granica između „wow efekta” i „osnovne funkcionalnosti” prolazi upravo kroz mogućnosti WebGPU compute shadera i modernog resource managementa, koje WebGL ne može u potpunosti pratiti.

Hibridne arhitekture: dvostruki rendering pipeline kao novi standard

Najvažniji trend koji se izdvaja iz novih projekata jest planiranje dvostrukog rendering pipelinea od prvog dana. Umjesto jedne monolitne implementacije, timovi definiraju hardverske i pregledničke „tierove”:

• Tier 1 – WebGL2 baseline: većina Android i iOS uređaja, fokus na stabilnosti, manjem broju draw poziva i konzervativnim shaderima.
• Tier 2 – WebGPU high‑end: noviji flagship telefoni i moderni desktop preglednici, s uključenim naprednim efektima, većom rezolucijom i stabilnijim frame pacingom.

Ovaj pristup uvodi nekoliko tehničkih posljedica za arhitekturu:

• Shader dvojnici: kritična logika u shaderima mora biti dizajnirana tako da se može prevesti i u GLSL (za WebGL) i u WGSL (za WebGPU). To potiče modularni dizajn shadera i izbjegavanje egzotičnih konstrukcija.
• Asset pipeline s više razina detalja: LOD modeli, lightmap bake, impostori i atlasirane teksture planiraju se tako da WebGL verzija scene može biti agresivno pojednostavljena, bez rušenja UX‑a.
• Uvjetno učitavanje: gateway logika u frontendu odlučuje na temelju preglednika, GPU‑a i dostupne memorije koji se pipeline aktivira, dok se drugi drži u standbyu ili se uopće ne učitava.

Posljedica je da WebGL više nije samo „stari API” koji se drži iz navike. On postaje strateški sloj za mobilne korisnike, koji i dalje čine većinu prometa u 3D web aplikacijama, dok WebGPU služi kao nadogradnja za korisnike s jačim uređajima.

Ograničenja mobilnih preglednika: sandbox, energija i throttling

Najnoviji showcase projekti također otkrivaju da se glavna ograničenja na mobilnim uređajima ne nalaze samo u GPU‑u, nego i u samim preglednicima. WebGL radi unutar strogo kontroliranog sandboxa, s ograničenim pristupom resursima i sigurnosnim mehanizmima koji mogu iznenada usporiti rendering.

Tipični problemi koje timovi prijavljuju:

• Energetski budžet: dugotrajni rendering na visokom opterećenju aktivira zaštitne mehanizme. CPU i GPU se spuštaju na niže frekvencije, FPS pada, a frame pacing postaje nestabilan.
• Ograničenja memorije: prevelike teksture i previše buffer objekata dovode do izbacivanja resursa iz GPU memorije, što uzrokuje „stutter” i nagle padove FPS‑a.
• Sigurnosni sandbox: neke kombinacije ekstenzija, framebuffer konfiguracija ili intenzivnih shader petlji mogu aktivirati zaštitu preglednika i dovesti do resetiranja WebGL konteksta.

Usporedno, WebGPU nudi moderniji, eksplicitniji pristup resursima, ali i on radi unutar istog energetskog i sigurnosnog okvira. Razlika je u tome što WebGPU daje veću kontrolu nad pipelineom i omogućava učinkovitije korištenje dostupnog budžeta, posebno kroz compute shadere i bolje planiranje memorijskog layouta.

Praktične lekcije za timove koji ciljaju mobilne korisnike

Za arhitekte 3D web rješenja glavna lekcija iz ovih najnovijih projekata je pragmatična: ako ciljate mobilne preglednike u 2026., WebGL putanja mora biti prva stvar koju profilirate i optimizirate. Tek kada je WebGL dovoljno lagan, WebGPU se isplati uvoditi kao dodatni sloj kvalitete.

Nekoliko konkretnih preporuka koje se ponavljaju kroz recentne showcaseove:

• Ograničite draw pozive: agresivno koristite batching, instancing i spajanje materijala. Cilj je držati broj draw poziva po frameu što nižim, posebno na WebGL pipelineu.
• Pojednostavite materijale: izbjegavajte kompleksne PBR shader kombinacije na mobilnom WebGL‑u. Koristite lightmap bake, precomputed lighting i jednostavnije BRDF modele gdje je moguće.
• Kontrolirajte teksture: koristite komprimirane formate, razuman broj mip razina i ograničite rezolucije za mobilne tierove. Prevelike teksture direktno udaraju na memoriju i bandwidth.
• Planirajte LOD strategiju: za WebGL verziju scene unaprijed definirajte više razina detalja i impostore za udaljene objekte, kako biste izbjegli nepotrebnu geometrijsku kompleksnost.
• Profilirajte na stvarnim uređajima: testiranje samo na desktopu ili jednom flagship telefonu vodi u lažnu sigurnost. Razlike između mid‑range i high‑end mobitela su ogromne.

Tek kada WebGL fallback održivo drži ciljani FPS i stabilan frame pacing, ima smisla dodavati WebGPU značajke poput naprednih post‑proces efekata, većih rezolucija render targeta ili compute‑bazirane fizike. U suprotnom, riskirate scenarij u kojem mali dio desktop publike vidi puni potencijal projekta, dok većina mobilnih korisnika dobiva preopterećen WebGL s lošim iskustvom.

Zaključak: WebGL kao temelj, WebGPU kao nadogradnja

Novi 3D web projekti iz 2026. jasno pokazuju da WebGL na mobilnim preglednicima još nije zastario, ali je njegova uloga redefinirana. On je temeljni, „sigurni” sloj za masovno tržište. WebGPU dolazi kao nadogradnja koja otključava napredne efekte, veće scene i stabilniji FPS na jačim uređajima.

Realne granice WebGL‑a danas se ne mjere samo kroz broj poligona koje GPU može progutati, već kroz cijeli ekosustav: engine, sandbox, energetski budžet, protokole i ograničenja preglednika. Timovi koji to razumiju planiraju dvostruki pipeline, optimiziraju WebGL kao prioritet i tretiraju WebGPU kao strateški „boost”, a ne kao jedino rješenje.

U takvom okruženju, uspješan 3D web projekt u 2026. nije onaj koji maksimalno iskorištava WebGPU na malom broju uređaja, nego onaj koji isporučuje konzistentan UX preko WebGL‑a većini korisnika, uz pametno korištenje WebGPU‑a tamo gdje to hardver i preglednik doista mogu podržati.