# Performance-Analyse: WebGL- vs. WebGPU-Frameworks für Millionen-Polygone-Szenen

## Performance auf verschiedenen Plattformen (Desktop & WebGL vs. WebGPU)

**Skalierung auf millionen Polygone:** Moderne WebGL-Frameworks können *grundsätzlich* Szenen mit über einer Million Polygonen handhaben, allerdings nur mit entsprechenden Optimierungen. Auf Desktop-GPUs sind **1 Mio. Dreiecke** heutzutage machbar, während High-End-Systeme sogar *mehrere* Millionen bei 60 FPS schaffen können ([Three.js: What's the upper limit for holding 60 FPS on an average desktop? - Stack Overflow](https://stackoverflow.com/questions/41525579/three-js-whats-the-upper-limit-for-holding-60-fps-on-an-average-desktop#:~:text=,points%2Fvertices%20on%20an%20average%20GPU)) ([Optimizing of many models, what path to take - Help & Support - PlayCanvas Discussion](https://forum.playcanvas.com/t/optimizing-of-many-models-what-path-to-take/14636#:~:text=1,a%20lot%20on%20some%20devices)). Ein Entwickler berichtet z.B., dass **~500.000 Dreiecke** in Three.js bei 1080p problemlos mit 60 FPS liefen (2017) – auf aktuellen High-End-GPUs ließe sich diese Zahl „verzehnfachen“ ([Three.js: What's the upper limit for holding 60 FPS on an average desktop? - Stack Overflow](https://stackoverflow.com/questions/41525579/three-js-whats-the-upper-limit-for-holding-60-fps-on-an-average-desktop#:~:text=,points%2Fvertices%20on%20an%20average%20GPU)). Babylon.js erzielt ähnlich hohe Polygonzahlen: Mittels Instancing konnte ein Entwickler **1.000.000 Würfel** (entspricht ~12 Millionen Dreiecken) flüssig darstellen ([Performance compared to for example unity native (not unity webgl) - Questions - Babylon.js](https://forum.babylonjs.com/t/performance-compared-to-for-example-unity-native-not-unity-webgl/16325#:~:text=One%20thing%20that%20should%20help,million%20cubes%20without%20a%20problem)). Auch auf einer *Oculus Quest 2* (Mobile-VR mit Smartphone-GPU) seien „ein paar Millionen Vertices kein Problem, solange die Draw-Calls minimal bleiben“ ([Performance compared to for example unity native (not unity webgl) - Questions - Babylon.js](https://forum.babylonjs.com/t/performance-compared-to-for-example-unity-native-not-unity-webgl/16325#:~:text=Deltakosh%20%20December%205%2C%202020%2C,4%3A33pm%20%203)). Kurz: **Die GPU-Leistung, nicht das Framework**, bestimmt primär die Polygon-Obergrenze – *keines* der genannten Frameworks setzt hier ein hartes Limit ([Main reasons for performance differences between WebGL frameworks. - Questions - three.js forum](https://discourse.threejs.org/t/main-reasons-for-performance-differences-between-webgl-frameworks/40729#:~:text=I%20think%20it%E2%80%99s%20fair%20to,things%20require%20time%20and%20work)). Allerdings erfordert das Ausreizen hoher Polygonzahlen optimierte Szenen (siehe unten).

**FPS-Grenze und Optimierungsbedarf:** Eine **stabile Framerate ≥30 FPS** bei millionenschweren Szenen verlangt drastische Reduktion von CPU-Overhead. Der Engpass sind oft **Draw Calls** und Datenverkehr, weniger die reine Polygonanzahl ([Three.js: What's the upper limit for holding 60 FPS on an average desktop? - Stack Overflow](https://stackoverflow.com/questions/41525579/three-js-whats-the-upper-limit-for-holding-60-fps-on-an-average-desktop#:~:text=,colors%20and%20things%20like%20that)) ([Optimizing of many models, what path to take - Help & Support - PlayCanvas Discussion](https://forum.playcanvas.com/t/optimizing-of-many-models-what-path-to-take/14636#:~:text=1,a%20lot%20on%20some%20devices)). Alle Frameworks empfehlen deshalb, *so viel Geometrie wie möglich pro Draw Call* zu rendern – etwa durch Merging oder Instancing. Beispiel: Statt 1.000 Objekte mit je 1.000 Polygonen separat zu zeichnen (1000 Draw Calls), fasst man sie in **einem Mesh mit 1 Mio. Polygonen** zusammen – so bleibt es *ein* Draw Call. Dies verbessert die Auslastung der GPU und verhindert, dass die JavaScript→WebGL-Bindung zum Flaschenhals wird ([Three.js: What's the upper limit for holding 60 FPS on an average desktop? - Stack Overflow](https://stackoverflow.com/questions/41525579/three-js-whats-the-upper-limit-for-holding-60-fps-on-an-average-desktop#:~:text=,colors%20and%20things%20like%20that)). Three.js etwa kann mit einer einzigen *BufferGeometry* zigtausende Polygone in einem Rutsch senden. Babylon.js bietet ähnliche Wege (z.B. **Thin Instances**), die Tausende identischer Objekte ohne nennenswerte JS-Overhead zeichnen – Entwickler berichten, dass Thin Instances merklich effizienter sind als tausende Einzel-Meshes oder normale Instanzen ([Performance Difference between Clone, Instance, and Containers](https://forum.babylonjs.com/t/performance-difference-between-clone-instance-and-containers/45639#:~:text=Performance%20Difference%20between%20Clone%2C%20Instance%2C,a%20performance%20penalty%20on)) ([Performance compared to for example unity native (not unity webgl) - Questions - Babylon.js](https://forum.babylonjs.com/t/performance-compared-to-for-example-unity-native-not-unity-webgl/16325#:~:text=One%20thing%20that%20should%20help,million%20cubes%20without%20a%20problem)). **Statische Objekte** lassen sich außerdem vorab zu größeren Meshes zusammenfassen (Static Batching), was alle Frameworks unterstützen (Unity batcht z.B. statische Meshes beim Build automatisch) ([Unity - Manual: Web performance considerations](https://docs.unity3d.com/Manual/webgl-performance.html#:~:text=,you%20can%20use%20to%20achieve)). Hingegen erfordern **dynamische Objekte** (Animation, Bewegung) separate Draw Calls oder komplexere Lösungen (z.B. GPU-Skinning), was die Belastung erhöht. Hier punkten Frameworks mit spezialisierter Pipeline: Unity und Babylon nutzen GPU-Skinning für animierte Charaktere, um die CPU zu entlasten, Three.js ebenso für SkinnedMesh. Trotzdem bleibt: Viele *gleichzeitig* animierte Meshes kosten Performance – das gilt in allen Engines. Wo möglich, ersetzt man daher *zahlreiche* bewegliche Einzelteile durch *wenige* komplexere Objekte oder nutzt Instancing (sofern die Animation synchronisiert oder simpel ist). Unterm Strich sind **WebGL-Engines auf Desktops** in der Lage, im richtigen Setup *Millionen* Polygone >30 FPS zu halten. Beispielsweise zeigt ein Benchmark **1,8 Millionen Dreiecke (150.000 Würfel)** mit GPU-Animation stabil bei **120 FPS** – allerdings in WebGPU statt WebGL ([Scene performance (heavy meshes, faces, instancing, picking) - Questions - Babylon.js](https://forum.babylonjs.com/t/scene-performance-heavy-meshes-faces-instancing-picking/11449#:~:text=PeterS%20%20January%2031%2C%202024%2C,10%3A42am%20%203)).

**WebGL vs. WebGPU – Leistungsunterschiede:** WebGPU verspricht erhebliche Geschwindigkeitsvorteile gegenüber WebGL, insbesondere bei *vielen Objekten* und komplexen Szenen. Da WebGPU näher an modernen Low-Level-APIs wie Vulkan/DirectX 12 arbeitet, fallen CPU-Bottlenecks durch Draw-Call-Overhead deutlich geringer aus. **Intel** attestiert WebGPU bereits einen „signifikanten Performance-Boost“ gegenüber WebGL ([Unlock the Potential of AI and Immersive Web Applications with WebGPU](https://www.intel.com/content/www/us/en/developer/articles/technical/unlock-potential-ai-immersive-web-apps-with-webgpu.html#:~:text=WebGPU%20is%20a%20new%20API,and)). Erste Studien untermauern dies: In Tests mit der Godot-Engine lieferte WebGPU durchweg höhere Framerates als WebGL – sowohl in Game-Szenen als auch synthetischen Benchmarks ([Performance comparison of WebGPU and WebGL in the Godot ...](https://www.diva-portal.org/smash/record.jsf?pid=diva2:1762429#:~:text=portal,games%20tests%20and%20the)). Praktische Web-Demos zeigen, dass WebGPU selbst mit millionenschweren Szenen hervorragend skaliert: Die oben genannten **150.000 animierten Würfel** liefen über WebGPU mit **120 FPS** auf einer RTX 3070 ([Scene performance (heavy meshes, faces, instancing, picking) - Questions - Babylon.js](https://forum.babylonjs.com/t/scene-performance-heavy-meshes-faces-instancing-picking/11449#:~:text=PeterS%20%20January%2031%2C%202024%2C,10%3A42am%20%203)). Mit klassischem WebGL wäre diese Szene vermutlich CPU-limitiert und deutlich langsamer (das Original-WebGL-Demo kam ~60 FPS). **Aber:** Der Performancegewinn von WebGPU entfaltet sich nur, wenn man die API *idiomatisch* nutzt. Ohne Optimierungen kann WebGPU anfänglich auch *langsamer* erscheinen, da z.B. Caching und Pipeline-Setup hier in Entwicklerhand liegen ([Render performance - #2 by sebavan - Questions - Babylon.js](https://forum.babylonjs.com/t/render-performance/28644/2#:~:text=About%20WebGPU%20you%20should%20look,Babylon.js%20Documentation)) ([Mobile is where WebGPU has the most extreme performance difference to WebGL / We... | Hacker News](https://news.ycombinator.com/item?id=41166396#:~:text=You%27re%20totally%20right%20that%20it%27s,still%20affect%20performance%20pretty%20drastically)). Die Babylon.js-Entwickler stellten fest, dass ein nicht-optimierter WebGPU-Renderpfad zunächst etwas langsamer war, bis gezieltes Caching und Ressource-Management implementiert wurden ([Render performance - #2 by sebavan - Questions - Babylon.js](https://forum.babylonjs.com/t/render-performance/28644/2#:~:text=About%20WebGPU%20you%20should%20look,Babylon.js%20Documentation)). Insgesamt gilt: **Langfristig** übertrumpft WebGPU WebGL in Sachen Durchsatz, besonders bei aufwendigen Szenen, aber aktuell (Anfang 2025) steckt die WebGPU-Unterstützung noch in den Anfängen.

**Render-Pipelines (statisch vs. dynamisch):** Für **statische Geometrie** bieten alle Engines effiziente Pipelines. Three.js erlaubt z.B. das Verschmelzen mehrerer BufferGeometries zu einem großen Mesh, was die Draw Calls minimiert ([Three.js: What's the upper limit for holding 60 FPS on an average desktop? - Stack Overflow](https://stackoverflow.com/questions/41525579/three-js-whats-the-upper-limit-for-holding-60-fps-on-an-average-desktop#:~:text=,colors%20and%20things%20like%20that)). Babylon.js verfügt über **Mesh Merger/Batching** und **Thin Instancing**, womit hunderte Kopien eines Meshes *ohne* spürbaren CPU-Overhead gerendert werden (keine neuen JS-Objekte pro Instanz) ([Performance Difference between Clone, Instance, and Containers](https://forum.babylonjs.com/t/performance-difference-between-clone-instance-and-containers/45639#:~:text=Performance%20Difference%20between%20Clone%2C%20Instance%2C,a%20performance%20penalty%20on)). PlayCanvas hat einen automatischen **Batcher**, der statische Meshes mit gleichem Material zu größeren Batches zusammenfügt (auch das spart Draw Calls). Unity nutzt **Static Batching** beim Build: Statische Objekte mit identischem Material werden zusammengefasst, sodass sie zur Laufzeit als ein Chunk gerendert werden ([Unity - Manual: Web performance considerations](https://docs.unity3d.com/Manual/webgl-performance.html#:~:text=,are%20used%20in%20your%20shaders)). Diese Mechanismen stellen sicher, dass **riesige** Szenen mit vielen Teilen hauptsächlich von der GPU-Leistung abhängen und nicht an JavaScript/CPU gebunden sind. Bei **dynamischen Objekten** (charaktere, bewegliche Teile) ist das Prinzip ähnlich – allerdings greifen hier Instancing/Batching nur begrenzt, da sich Transformationen ändern. Engines wie Babylon.js und Three.js unterstützen **InstancedMesh** (bzw. Instanzen), was auch für *bewegte* Objekte funktionieren kann, wenn alle Instanzen das *gleiche* Mesh nutzen (z.B. viele animierte Figuren mit identischem Rig und Animation). Dennoch bleibt jede unabhängige Animation ein eigener Zeichenbefehl. Daher sind Szenen mit vielen unterschiedlichen animierten Modellen anspruchsvoller. Einige Engines bieten zusätzliche Tricks: Babylon.js hat einen **Solid Particle System (SPS)**, das viele bewegliche Teilchen/Ojekte in einem einzigen Mesh vereint und ihre Bewegung auf GPU/CPU effizient berechnet – nützlich für Schwärme o.ä. Unity setzt bei animierten Meshes auf GPU-Skinning und kann mittels **GPU Instancing** viele gleichartige Objekte (z.B. Gras, Partikel) in einem Draw Call bewegen. **Fazit:** Statische Geometrie lässt sich weitgehend *zusammenfassen* und damit effizient rendern, während dynamische Objekte mehr Planung erfordern. Alle Frameworks stellen aber Tools bereit, um auch dynamischen Content performant zu halten (Instancing, Particle-Systems, etc.). Kein Framework zwingt per se zu schlechter Performance – die richtigen Patterns vorausgesetzt ([Main reasons for performance differences between WebGL frameworks. - Questions - three.js forum](https://discourse.threejs.org/t/main-reasons-for-performance-differences-between-webgl-frameworks/40729#:~:text=I%20think%20it%E2%80%99s%20fair%20to,things%20require%20time%20and%20work)) ([Main reasons for performance differences between WebGL frameworks. - Questions - three.js forum](https://discourse.threejs.org/t/main-reasons-for-performance-differences-between-webgl-frameworks/40729#:~:text=Whether%20it%20takes%20more%20time%2Fwork,lot%20on%20what%20you%E2%80%99re%20doing)).

## Mobile Performance & Optimierungen

**Performance auf iOS/Android (WebGL):** Auf Mobilgeräten schrumpft das Polygon-Budget drastisch. Eine Faustregel: Mobile GPUs verkraften **ca. 200.000–300.000 Polygone** bevor die Framerate unter ~30 FPS fällt ([Optimizing of many models, what path to take - Help & Support - PlayCanvas Discussion](https://forum.playcanvas.com/t/optimizing-of-many-models-what-path-to-take/14636#:~:text=1,a%20lot%20on%20some%20devices)). In Foren wird oft genannt, dass ~100k Dreiecke eine Szene für ein *Galaxy S7* ausreizen, während ein Desktop mit Core i9 + RTX 3080 problemlos **10 Millionen** stemmen könnte ([Hello - newbie questions - Help & Support - PlayCanvas Discussion](https://forum.playcanvas.com/t/hello-newbie-questions/17187#:~:text=1,never%20know%20until%20you%20try)). Ein PlayCanvas-Entwickler berichtet gar, sein *altes Galaxy S6* schaffe “mindestens eine halbe Million Polygone” flüssig ([Hello - newbie questions - Help & Support - PlayCanvas Discussion](https://forum.playcanvas.com/t/hello-newbie-questions/17187#:~:text=Generally%2C%20the%20walls%20are%20pretty,least%20half%20a%20million%20polygons)) – allerdings vermutlich in einem optimalen Szenario (einfaches Shading, wenige Draw Calls). Generell sind Mobile-GPUs heute zwar leistungsfähig, aber **WebGL auf mobilen Browsern** hat zusätzliche Limitierungen: Safari auf iOS unterstützt z.B. lange nur WebGL 1 (mit geringerem Feature-Set und Performance) und WebGL 2 erst experimentell, was einige Optimierungen einschränkte. Außerdem laufen mobile Browser-JavaScript-Threads langsamer, was bei vielen Draw Calls bremst. Die Praxis zeigt daher: **Über ~0,5 Mio. sichtbare Polygone** wird es auf Mobilgeräten kritisch – die Framerate kann dann unter 30 FPS rutschen ([Optimizing of many models, what path to take - Help & Support - PlayCanvas Discussion](https://forum.playcanvas.com/t/optimizing-of-many-models-what-path-to-take/14636#:~:text=1,a%20lot%20on%20some%20devices)). Um dennoch detailreiche Szenen darzustellen, *müssen* Entwickler aggressiv optimieren (LOD, Culling, etc., siehe unten). Besonders iOS-Geräte mit WebGL 1 zwangen oft zu noch weniger Polys und kleineren Texturen. Moderne iPhones/iPads (A14 Bionic und höher) sind zwar deutlich flotter und mit iOS 17 ist WebGL2 weitgehend verfügbar, aber selbst High-End-Handys erreichen nicht die Desktop-FPS bei millionenschweren Szenen. Im Endeffekt gilt: **Mobile = wenig Polygone, wenige Draw Calls, kleine Texturen.**

**Optimierungstechniken für mobile Szenen:** Um auf Smartphone-Browsern große 3D-Szenen stabil zu halten, kommen klassiche Grafik-Tricks zum Einsatz: **Level of Detail (LOD)** reduziert die Polygone ferne Objekte. Alle genannten Frameworks unterstützen LOD-Systeme (Three.js bietet z.B. `THREE.LOD` für verschiedene Detailstufen, Babylon.js hat integriertes LOD-Handling mit Distanzschwellen ([Levels of Detail (LOD) - Babylon.js Documentation](https://doc.babylonjs.com/features/featuresDeepDive/mesh/LOD#:~:text=Babylon,by%20default%29%2C))). So kann ein Modell mit 1 Mio. Polygonen nahe der Kamera angezeigt werden, aber in der Ferne automatisch auf z.B. 100k oder 10k Polygone runtergeschaltet werden. Dies erhält die Illusion von Detail, ohne permanent alle Polys zu rasterisieren. – **Instancing und Batching** sind auf Mobile *essenziell*, da hier Draw Calls besonders teuer sind ([Hello - newbie questions - Help & Support - PlayCanvas Discussion](https://forum.playcanvas.com/t/hello-newbie-questions/17187#:~:text=1,never%20know%20until%20you%20try)). Statt 1000 Bäumen als einzelne Meshes (1000 Draw Calls) zu rendern, instanziert man einen Baum 1000× – das ergibt *einen* Draw Call für alle, was die CPU enorm entlastet. Babylon.js’ Thin Instances etwa verursachen **keinen zusätzlichen JS-Overhead** pro Instanz, wodurch tausende Objekte praktisch „gratis“ mitlaufen ([Performance Difference between Clone, Instance, and Containers](https://forum.babylonjs.com/t/performance-difference-between-clone-instance-and-containers/45639#:~:text=Performance%20Difference%20between%20Clone%2C%20Instance%2C,a%20performance%20penalty%20on)). PlayCanvas verfügt über **automatisches Batching**, das zur Laufzeit viele kleine Meshes in größere zusammenlegt ([Optimizing of many models, what path to take - Help & Support - PlayCanvas Discussion](https://forum.playcanvas.com/t/optimizing-of-many-models-what-path-to-take/14636#:~:text=1,you%20can%20mitigate%20that)) ([Optimizing of many models, what path to take - Help & Support - PlayCanvas Discussion](https://forum.playcanvas.com/t/optimizing-of-many-models-what-path-to-take/14636#:~:text=will%20have%20a%20mesh%20instance,you%20can%20mitigate%20that)). Unity nutzt *Dynamic Batching* für kleine Objekte und GPU Instancing für mehrere gleichartige Meshes – beides hilft, die Draw Calls in Grenzen zu halten ([Unity - Manual: Web performance considerations](https://docs.unity3d.com/Manual/webgl-performance.html#:~:text=,are%20used%20in%20your%20shaders)). – **Mesh-Partitionierung und Culling:** Bei extrem großen Umgebungen (Stadt, riesiges Gebäude) partitioniert man die Szene in Sektoren oder Octrees, sodass jeweils nur der sichtbare Abschnitt gerendert wird. Anstatt ein *einziges* 2-Millionen-Poly-Mesh zu haben, teilt man es in z.B. 20 Teile à 100k Polys. Die Engine kann dann per **Frustum Culling** (automatisch in Three.js, Babylon.js etc.) alle Teile außerhalb des Kamera-Sichtkegels überspringen. Das reduziert die *gleichzeitig* gerenderten Polygone enorm. Solches Spacial Culling ist auf Mobile entscheidend, damit nicht unnötig Polygone rasterisiert werden, die man eh nicht sieht. – **Weitere Tricks:** **Occlusion Culling** (Verdeckenserkennung) kann ebenfalls genutzt werden: dabei werden Objekte, die komplett hinter anderen liegen, gar nicht erst gezeichnet. In WebGL ist das meist manuell umzusetzen oder über simplere Ansätze (z.B. Portals in Architektur-Modellen). **Billboards/Sprites**: Entfernte oder sehr kleine Details werden als 2D-Sprites dargestellt statt als 3D-Modelle (spart Polygone). **Vertex-Kompression & Meshopt**: Tools wie gltfpack (Meshoptimizer) reduzieren die Größe und Anzahl von Vertices, die die GPU verarbeiten muss, ohne visuell viel einzubüßen – was direkt die Performance verbessert. **Texture-Atlas**: Auf Mobile sind zudem Texturen und Materialwechsel ein Performance-Thema. Das Zusammenfassen vieler kleiner Texturen in eine große Atlas-Textur (und entsprechende UV-Anpassungen) verhindert ständige Materialwechsel, was die Draw Calls weiter senkt ([Hello - newbie questions - Help & Support - PlayCanvas Discussion](https://forum.playcanvas.com/t/hello-newbie-questions/17187#:~:text=You%20want%20larger%20objects%2C%20merging,you%20with%20some%20additional%20advanced)) ([Hello - newbie questions - Help & Support - PlayCanvas Discussion](https://forum.playcanvas.com/t/hello-newbie-questions/17187#:~:text=Often%2C%20the%20performance%20on%20mobile,chair%20in%20the%203D%20world)). Schließlich sollte man gerade mobil **überzeichnete Pixel vermeiden** (Overdraw): Viele halbtransparente Ebenen übereinander reduzieren die fillrate. Deshalb hält man die Zahl transparenter Objekte gering und nutzt ggf. *Alpha-Test* statt echter Transparenz, wo möglich. In Summe ermöglichen diese Techniken auch auf iOS/Android ansehnliche 3D-Szenen. Ein Beispiel aus der Praxis: Ein Entwickler von IFC.js (Architektur-Viewer) kombinierte **Instancing + LOD + Occlusion Culling**, um Gebäudemodelle mit tausenden Objekten performant im Browser anzuzeigen ([The most efficient way to display heavy environments - Discussion - three.js forum](https://discourse.threejs.org/t/the-most-efficient-way-to-display-heavy-environments/39362#:~:text=Image%3A%20%3Arabbit2%3AImage%3A%20%3Awhite_check_mark%3A%20This%20reduces,It%20works%20and%20it%E2%80%99s%20fast)) ([The most efficient way to display heavy environments - Discussion - three.js forum](https://discourse.threejs.org/t/the-most-efficient-way-to-display-heavy-environments/39362#:~:text=Use%20InstancedMesh)). **Best Practice für Mobile** ist also, high-poly-Modelle *nur dort* in voller Auflösung zu zeigen, wo nötig, und ansonsten alles einzusparen, was das Auge nicht deutlich merkt.

**WebGL vs. WebGPU auf Mobile:** Interessanterweise könnte **WebGPU gerade auf Mobilgeräten** den größten Performance-Schub bringen. Denn hier ist die CPU-Budget pro Frame sehr klein – ineffiziente WebGL-Calls wie `drawArrays` mit viel overhead fallen auf langsamen mobilen CPUs besonders ins Gewicht. Ein Vorteil von WebGPU ist die Möglichkeit, *viele* Draw Calls in Command-Buffers zusammenzufassen und mit einem Mal zu senden, was den CPU-Aufwand verteilt. Ein Kommentar bringt es auf den Punkt: *„Mobile ist der Bereich, wo WebGPU den krassesten Performance-Unterschied zu WebGL hat.“* ([Mobile is where WebGPU has the most extreme performance difference to WebGL / We... | Hacker News](https://news.ycombinator.com/item?id=41166396#:~:text=Mobile%20is%20where%20WebGPU%20has,difference%20to%20WebGL%20%2F%20WebGL2)). In der Theorie kann WebGPU also z.B. bei 120 kleinen Draw Calls pro Frame deutlich flüssiger sein als WebGL, das evtl. bei gleicher Last ins Stocken gerät. **In der Praxis 2024/2025** gibt es aber noch Hürden: WebGPU ist auf Mobile teils noch instabil oder nicht voll verfügbar. Safari auf iOS unterstützt WebGPU noch nicht offiziell (Stand iOS 17, nur experimentell), so dass iPhones vorerst sowieso auf WebGL beschränkt sind. Android-Chrome hat WebGPU seit Chrome 113+ verfügbar, aber noch nicht breit ausgerollt. Erste Tests zeigen gemischte Ergebnisse: Entwickler berichten, dass WebGPU in einfachen Fällen auf Android bereits *höhere* FPS liefert als WebGL, aber in komplexen Szenen mit vielen Effekten teils noch **Stottern und niedrigere FPS** auftreten ([Subpar WebGPU performance on mobile devices (Issues with text, particles, transparency...) · Issue #7874 · Scirra/Construct-bugs · GitHub](https://github.com/Scirra/Construct-bugs/issues/7874#:~:text=Problem%20description)). Gründe sind unausgereifte Treiber und der Fakt, dass man WebGPU-Code erst an die Mobile-GPU-Architektur anpassen muss (z.B. sind manche WebGPU-Shader zu anspruchsvoll und verursachen Überlast auf Mobil-GPUs). Es wurden Fälle dokumentiert, in denen z.B. Text-Rendering und Partikel über WebGPU auf einem Pixel 7 Pro zu Frame-Drops führten, obwohl WebGL flüssig lief ([Subpar WebGPU performance on mobile devices (Issues with text, particles, transparency...) · Issue #7874 · Scirra/Construct-bugs · GitHub](https://github.com/Scirra/Construct-bugs/issues/7874#:~:text=Problem%20description)). Solche Kinderkrankheiten werden allerdings aktiv behoben. Langfristig ist man sich einig, dass **WebGPU besonders auf Mobilgeräten** WebGL übertreffen wird – durch niedrigere CPU-Last, besseres Multithreading-Potential und Zugriff auf neuere GPU-Features (Compute, etc.). Kurzfristig müssen Entwickler aber vorsichtig testen, ob ein WebGPU-Backend auf Mobile *wirklich* schneller ist. In empfindlichen Fällen kann es sinnvoll sein, auf Mobile (noch) bei WebGL zu bleiben und WebGPU erst auf Desktop zu nutzen, bis die Mobil-Browser aufgeholt haben.

## GLB-Dateien & Ladezeiten großer Szenen

**Handling großer GLB-Dateien:** GLB (Binary glTF) hat sich als Standard für 3D-Modelle im Web etabliert. Modelle mit **hunderttausenden Polygonen** bringen jedoch auch große Dateigrößen (oft zweistellige MB) und viele Texturen mit sich. Alle betrachteten Frameworks unterstützen glTF/GLB nativ und können große Dateien laden – die Performance beim **Laden und Parsen** variiert aber. Three.js z.B. nutzt `GLTFLoader`, der das .glb zunächst vollständig lädt, dann parsed (Binär->JSON-Datenstrukturen) und schließlich Meshes/Texturen erzeugt. Babylon.js hat einen eigenen glTF-Loader mit ähnlichem Ablauf. **Unity WebGL** geht einen anderen Weg: Hier packt man das Modell entweder ebenfalls als glTF ins Projekt oder – häufiger – baut es direkt ins Unity-Szenenformat ein. Dann wird es Teil des großen Asset-Bundles, das Unity beim Start lädt. Das bedeutet, Unity kann sehr große Szenen initial laden, aber der Download kann entsprechend lange dauern (Unity-Ladezeiten von 10–30 Sekunden sind bei hochdetaillierten WebGL-Builds nicht ungewöhnlich). Three.js und Babylon.js laden Modelle meist on-demand während der App läuft, was interaktive *Loading-Screens* ermöglicht. In Bezug auf **Ladegeschwindigkeit** zeigen Vergleiche zwischen Three.js und Babylon.js interessante Unterschiede: In einem Test lud ein identisches GLB-Modell über Three.js **“fast instantan”**, während Babylon.js ~5–6 Sekunden benötigte ([Slow loading of GLB files with textures compared to Threejs - Questions - Babylon.js](https://forum.babylonjs.com/t/slow-loading-of-glb-files-with-textures-compared-to-threejs/40730#:~:text=I%20am%20currently%20trying%20to,6%20seconds)) ([Slow loading of GLB files with textures compared to Threejs - Questions - Babylon.js](https://forum.babylonjs.com/t/slow-loading-of-glb-files-with-textures-compared-to-threejs/40730#:~:text=file%20loads%20much%20faster%20with,6%20seconds)). Der Flaschenhals war hier wohl die Verarbeitung der **Texturen** in Babylon – ohne Texturen lud das Modell auch dort sehr schnell ([Slow loading of GLB files with textures compared to Threejs - Questions - Babylon.js](https://forum.babylonjs.com/t/slow-loading-of-glb-files-with-textures-compared-to-threejs/40730#:~:text=https%3A%2F%2Fsandbox)). Babylon.js’ PBR-Materialsystem könnte beim Laden mehr vorbereitende Schritte ausführen (Erstellen von Mipmaps, konvertieren von Texturformaten usw.), was Zeit kostet. Three.js scheint beim reinen Laden etwas weniger Overhead zu haben, wodurch es bei gleichem Modell zunächst flinker wirkte ([Slow loading of GLB files with textures compared to Threejs - Questions - Babylon.js](https://forum.babylonjs.com/t/slow-loading-of-glb-files-with-textures-compared-to-threejs/40730#:~:text=I%20am%20currently%20trying%20to,6%20seconds)). Allerdings wurde dieser konkrete Fall von den Babylon-Entwicklern als **Bug** bzw. ungewöhnlich bezeichnet ([Slow loading of GLB files with textures compared to Threejs - Questions - Babylon.js](https://forum.babylonjs.com/t/slow-loading-of-glb-files-with-textures-compared-to-threejs/40730#:~:text=sebavan%20%20May%2012%2C%202023%2C,8%3A41am%20%202)) – in internen Tests lud dasselbe GLB auf beiden Engines in ~1–3 Sekunden ([Slow loading of GLB files with textures compared to Threejs - Questions - Babylon.js](https://forum.babylonjs.com/t/slow-loading-of-glb-files-with-textures-compared-to-threejs/40730#:~:text=Evgeni_Popov%20%20May%2012%2C%202023%2C,9%3A44am%20%203)). Generell gilt: *größere GLBs können ein paar Sekunden zum Laden brauchen*, abhängig von Dateigröße, Kompression und Gerät. Drei Faktoren spielen rein: **Download-Größe**, **Parse-Zeit** und **GPU-Upload**. Erst muss die Datei ankommen (Netzwerk), dann wird sie vom Loader in Datenstrukturen umgewandelt (CPU), dann müssen Modelle und Texturen zur GPU übertragen werden (CPU→GPU). Unterschiede zwischen Frameworks entstehen vor allem in Phase 2 (Parsing/Processing). Three.js ist als schlanker Rahmen oft etwas schneller beim reinen Parsen und hat einen kleineren **Footprint** – die Library selbst ist nur ein paar hundert KB groß, während Babylon.js als umfassendes Engine-Paket ein paar MB mitbringt, was initiale Ladezeit erhöht ([Why We Use Babylon.js Instead Of Three.js in 2022](https://www.spotvirtual.com/blog/why-we-use-babylonjs-instead-of-threejs-in-2022#:~:text=As%203D%20is%20a%20core,build%20was%20off%20the%20table)). Babylon.js bietet dafür mehr Funktionen out-of-the-box (z.B. ein eingebautes GUI, Inspector etc.), was den **Memory Footprint** leicht erhöhen kann. Bei reinen GLB-Ladezeiten nehmen sich die Engines aber nicht viel, wenn kein spezieller Bug vorliegt. **Filament** (als WebAssembly) kann GLB ebenfalls laden – es ist für glTF sogar optimiert, da Filament Googles Standard-PBR verwendet. Die Parse-Performance von Filament (C++ in WASM) ist potentiell sehr hoch, allerdings muss zuerst die Filament-WASM (~was einige MB sein kann) selbst geladen werden. Filament eignet sich besonders, wenn man viele Modelle hintereinander laden will, da sein C++-Code effizient darin ist, glTF zu verarbeiten und Materialien zu erstellen. **PlayCanvas** nutzt auch glTF und hat ähnlich Three.js einen schlanken Loader; zudem kann ihr Editor GLBs vorbereiten.

**Speicherauslastung:** Große Szenen bedeuten auch hohe **Speicherlast** (RAM und GPU VRAM). Auf Desktop ist das selten ein Limit, da ein Browser-Tab durchaus mehrere GB allokieren kann, aber auf Mobile ist es kritisch. Insbesondere ältere iPhones (z.B. iPhone 6 mit 1 GB RAM) können bei speicherhungrigen WebGL-Szenen abstürzen, weil iOS Tabs schließt, die zu viel RAM ziehen ([Optimizing of many models, what path to take - Help & Support - PlayCanvas Discussion](https://forum.playcanvas.com/t/optimizing-of-many-models-what-path-to-take/14636#:~:text=On%20mobile%20though%20memory%20is,memory%20and%20kill%20the%20tab)) ([Optimizing of many models, what path to take - Help & Support - PlayCanvas Discussion](https://forum.playcanvas.com/t/optimizing-of-many-models-what-path-to-take/14636#:~:text=On%20iPhone%205%2F6%20which%20feature,planning%20in%20supporting%20those%20devices)). Ein Entwickler berichtet, dass man auf 1 GB-Geräten teils nur **50–100 MB** Gesamtbudget hat, damit Safari den Tab nicht killt ([Optimizing of many models, what path to take - Help & Support - PlayCanvas Discussion](https://forum.playcanvas.com/t/optimizing-of-many-models-what-path-to-take/14636#:~:text=The%20OS%20can%20potentially%20decide,memory%20and%20kill%20the%20tab)). Daher ist *Speicheroptimierung Teil des Lade-Designs*: Texturen sollten komprimiert werden (GPU-Kompression wie ETC/ASTC/KTX2), ungenutzte Ressourcen werden aus dem GPU-Speicher entladen, sobald sie nicht mehr sichtbar sind ([Optimizing of many models, what path to take - Help & Support - PlayCanvas Discussion](https://forum.playcanvas.com/t/optimizing-of-many-models-what-path-to-take/14636#:~:text=Your%20best%20friend%20here%20is%3A)). PlayCanvas bspw. stellt ein **Resource Management** bereit, bei dem nicht benötigte Texturen/Meshes entladen werden, um Platz zu schaffen ([Optimizing of many models, what path to take - Help & Support - PlayCanvas Discussion](https://forum.playcanvas.com/t/optimizing-of-many-models-what-path-to-take/14636#:~:text=Your%20best%20friend%20here%20is%3A)). Three.js/Babylon erfordern hier eher manuelles Handling (z.B. `dispose()` auf Geometrien/Materialien, wenn diese entladen werden sollen). **Große GLBs** bringen oft viele hochauflösende Texturen mit – Entwickler sollten daher **mipmaps und Kompression** nutzen, damit nicht zig 4K-Texturen unkomprimiert im Speicher liegen. Auch **Draco-Kompression** für Meshes (glTF-Extension) hilft: Die Downloadgröße sinkt um ~50%, und obwohl das Decodieren Rechenzeit kostet, verringert es die *Spitzenbelastung* an Daten.

**Progressives Laden & Streaming:** Für wirklich *riesige* 3D-Welten (GLBs mit >100 MB) reicht einfaches Vorabladen nicht aus – hier kommt **Streaming** ins Spiel. Einige Frameworks (insb. Babylon.js) unterstützen bereits **progressives Laden** von glTF: Dabei enthält das GLB-Modell mehrere LOD-Stufen durch die Extension `MSFT_lod`, und der Loader lädt zuerst ein grobes LOD, zeigt es an, und lädt dann im Hintergrund schrittweise höhere Detailstufen nach ([GLTFLoader: HTTP Range Requests support · Issue #24506 · mrdoob/three.js · GitHub](https://github.com/mrdoob/three.js/issues/24506#:~:text=,vertex%20streams%20for%20each%20LOD)) ([GLTFLoader: HTTP Range Requests support · Issue #24506 · mrdoob/three.js · GitHub](https://github.com/mrdoob/three.js/issues/24506#:~:text=I%20think%20it%20is%20good,loading%20even%20for%20bundled%20glb)). Babylon.js kann hierfür sogar **HTTP Range Requests** nutzen, um nur bestimmte Bytebereiche des .glb nachzuladen (anstatt immer die gesamte Datei) ([GLTFLoader: HTTP Range Requests support · Issue #24506 · mrdoob/three.js · GitHub](https://github.com/mrdoob/three.js/issues/24506#:~:text=I%20think%20it%20is%20good,loading%20even%20for%20bundled%20glb)). So erscheint ein grober Umriss der Szene sehr schnell, und Details kommen nach und nach – der Nutzer sieht also früh etwas und die vollständige Qualität baut sich progressiv auf. Three.js zieht hier nach: Es gibt Diskussionen und PRs, um ähnliche **GLB-Streaming**-Features einzubauen ([GLTFLoader: HTTP Range Requests support · Issue #24506 · mrdoob/three.js · GitHub](https://github.com/mrdoob/three.js/issues/24506#:~:text=loading%20even%20for%20bundled%20glb)). Eine Herausforderung ist, dass glTF intern oft eine monolithische Binärdatei für alle Vertices hat – ohne LOD-aufteilung müsste man diese komplett laden. Die Lösung sind entweder LOD-Partitionen (separate .bin-Chunks pro LOD) oder Range Requests. Babylon.js hat dieses Problem schon gelöst und erlaubt **große GLBs stückweise** zu laden ([GLTFLoader: HTTP Range Requests support · Issue #24506 · mrdoob/three.js · GitHub](https://github.com/mrdoob/three.js/issues/24506#:~:text=I%20think%20it%20is%20good,loading%20even%20for%20bundled%20glb)). – **Beispiel:** Eine 300 MB Stadt-Modell-GLB kann so erst die Gebäude als simple Boxen laden (sofort 1 FPS), dann mittlere LODs (etwa 10% Detail, nach ein paar Sekunden), schließlich volles Detail (nach Dutzenden Sekunden). Unity-WebGL bietet ähnliches **nur manuell**: Entwickler könnten sogenannte AssetBundles oder adressierbare Assets nutzen, um Teile der Szene nachzuladen. Allerdings ist das nicht trivial und erfordert eigenes Loading-Code. Out-of-the-box lädt Unity seine Szenen **nicht** progressiv – meist wartet man bis alles komplett im Speicher ist, bevor etwas angezeigt wird. Das führt bei großen Unity-WebGL-Szenen zu langen weißen Bildschirmen, während Three/Babylon ggf. schon eine Ladeanzeige mit Scene-Vorschau zeigen können. – **Streaming-Texturen:** Neben Mesh-LOD kann auch Textur-Streaming helfen: Erst niedrig aufgelöste Platzhalter laden, dann schärfere Versionen nachladen (glTF hat zwar Mipmaps, aber die sind eingebettet; ein echtes Streaming erfordert separate downloads). Manche Engines erlauben es, Texturen on-the-fly nachzuladen oder mit Delays zu versehen. In WebGL muss man das als Entwickler steuern, es gibt aber Libraries/Extensions (z.B. THREE.ProgressiveLightMap oder eigene Loader-Queues). – Zusammengefasst **bieten Babylon.js und Three.js zunehmend Unterstützung** für das Laden großer Szenen in Häppchen ([GLTFLoader: HTTP Range Requests support · Issue #24506 · mrdoob/three.js · GitHub](https://github.com/mrdoob/three.js/issues/24506#:~:text=loading%20even%20for%20bundled%20glb)). Babylon hat hier aktuell die Nase vorn mit fertig implementiertem **Progressive Loader** für GLB. PlayCanvas kann sehr große Szenen ebenfalls laden, aber es lädt standardmäßig alles upfront (bzw. was als “preload” markiert ist). Man kann jedoch auch dort eigene Lade-Sequenzen bauen (z.B. erst wichtige Models, dann unwichtige). **Filament** selbst hat keine eingebaute progressive Load-Funktion (es verlässt sich auf vollständige GLBs), aber Filament integriert gut mit äußeren Asset-Management-Strategien, da man einzelne glTF-Assets nacheinander einlesen könnte. – **Praxis-Tipp:** Bei *hochpolygonigen Welten* sollte man **Modelle bereits in Segmente/LOD splitten**, bevor man sie zu GLB exportiert. So kann man im Web stückweise laden. Ein Monolith-GLB mit Millionen Polys wird sonst auch monolithisch geladen und könnte während des Ladevorgangs den Browser blockieren ([Browser becomes unresponsive when loading the attached model](https://discourse.threejs.org/t/browser-becomes-unresponsive-when-loading-the-attached-model/63749#:~:text=Browser%20becomes%20unresponsive%20when%20loading,any%20way%20to%20load%20it)). Besser ist eine *sequenzielle Ladepipeline*: erst grobe Umgebung, dann Details, evtl. in separaten files. Tools und Standards entwickeln sich hier weiter, um Streaming im Web so komfortabel wie in nativen Engines zu machen.

## API-Design & Handhabbarkeit der Frameworks

**Einfachheit für Entwickler:** In puncto API gilt Three.js traditionell als sehr einsteigerfreundlich – ein simples Setup (Scene, Camera, Renderer) erfordert nur wenige Zeilen. Babylon.js ist umfassender, aber gut dokumentiert und seit v6 komplett in TypeScript, was Entwicklern in größeren Projekten zugutekommt ([Why We Use Babylon.js Instead Of Three.js in 2022](https://www.spotvirtual.com/blog/why-we-use-babylonjs-instead-of-threejs-in-2022#:~:text=TypeScript)). **Three.js**’ API ist eher minimalistisch gehalten: Man baut sich aus Bausteinen (Geometries, Materials, Meshes) die Szene zusammen. Das ergibt viel Freiheit, aber erfordert manchmal, dass man tiefer eintaucht (z.B. selber Shader-Code schreiben für Spezialeffekte). **Babylon.js** verfolgt ein etwas *höher abstrahiertes* Design: Es liefert viele vorgefertigte Systeme (Material-Library, Postprocessing, GUI, Animation-System). Dadurch können Entwickler schneller fortgeschrittene Features nutzen, ohne alles von Grund auf neu zu coden. Die Kehrseite ist eine etwas größere Bibliothek (größerer Download) und potenziell etwas mehr initiales “Boilerplate”, da man eine Engine und Scene aufsetzen muss (Three.js kann z.B. direkt auf dem Canvas loszeichnen). Insgesamt sind aber beide APIs gut handhabbar – viele Konzepte (Scene Graph, Cameras, Meshes) sind ähnlich. **PlayCanvas** richtet sich vor allem an Game-Entwickler, die eine komplette Editor-Umgebung wünschen. Dessen API ist deshalb eng mit dem Editor verzahnt – viele nutzen einfach die Editor-Oberfläche statt direkt im Code alle Entitäten zu erzeugen. Der *Engine-Code* von PlayCanvas selbst ist aber ebenso offen und strukturiert; er fühlt sich ähnlich an wie Babylon (z.B. `pc.Entity`, `pc.Material` etc.). **Filament** unterscheidet sich stärker: Als C++-Engine, die nach JavaScript gebindet ist, hat sie ein etwas ungewöhnlicheres API-Design auf Webseite. Man arbeitet viel über die Filament-Klassen (z.B. `Filament.Engine`, `Filament.Scene`, `Filament.MaterialInstance`). Filament abstrahiert Dinge wie Lighting und Materials auf hohem Niveau (physically-based), aber es verlangt, dass man seine Materialien in einer bestimmten Sprache vordefiniert. Für Webentwickler ohne C++-Erfahrung ist Filament etwas steiler in der Lernkurve, aber es ist *trotzdem* beherrschbar – Google stellt gute Doku und Beispiele zur Verfügung. **Unity WebGL** hat die speziellste Handhabung: Hier programmiert man ja primär in C# innerhalb von Unity Editor. Die “API” für den Webentwickler besteht dann nur darin, das Unity-WebGL-Build in eine Webseite einzubinden und ggf. über JavaScript mit dem Unity-Skript zu kommunizieren. Das heißt, in Sachen *Coding im Browser* hat Unity wenig zu bieten – der Großteil passiert in der Unity-Engine. Das kann von Vorteil sein (bekannte Unity-Workflows), aber für reine Web-Entwickler wirkt es wie eine Black Box, die man nur starten und stoppen kann. Insgesamt ermöglichen **Three, Babylon, PlayCanvas** deutlich nahtlosere Integration ins Web-Ökosystem (DOM, JS frameworks, etc.), während Unity eher isoliert läuft (Canvas mit WebAssembly).

**Boilerplate für Performance-Optimierungen:** Eine wichtige Frage ist, wie viel **zusätzlichen Code** ein Entwickler schreiben muss, um Höchstleistung zu erzielen. Hier nehmen sich Three.js und Babylon.js nicht viel – beide stellen die nötigen *Haken* bereit, aber der Entwickler muss sie nutzen. Beispielsweise ist **Frustum Culling** für Einzel-Meshes standardmäßig aktiv (Objekte außerhalb der Kamera werden automatisch nicht gerendert). **LOD**-Wechsel erfordern in Three.js ein manuelles Einrichten (`THREE.LOD` Objekt mit addLevel()) und in Babylon.js das Hinzufügen von LOD-Meshes per Code oder schon im glTF. **Instancing:** Three.js bietet seit r118 den `InstancedMesh`, d.h. man schreibt etwas Code, um Matrix-Transformationen zu füllen, aber es ist relativ simpel zu verwenden. Babylon.js hat mit `mesh.createInstance()` (für clones) und **ThinInstance**-APIs zwei Wege – letzteres erfordert, Matrizen in einen Buffer zu packen, ähnlich wie Three’s InstancedMesh. **PlayCanvas** macht es einem leicht: Hier kann man im Editor einfach Batch Groups definieren oder via Code `entity.batchGroupId` setzen, und das Engine übernimmt das Batching automatisch. Die Boilerplate hält sich also in Grenzen – vieles lässt sich anklicken oder mit wenigen Aufrufen erledigen. **Unity** nimmt Entwicklern manchen Aufwand ab (Batching, LOD Group Komponenten in Editor), aber es *versteckt* die WebGL-spezifischen Tuningmöglichkeiten. So muss man sich darauf verlassen, dass Unitys interner Batch optimal ist; direkten Einfluss auf WebGL-States hat man wenig. Dafür kann man z.B. eine **LOD Group** Komponente an ein GameObject hängen, mehrere Detailstufen zuweisen – Unity kümmert sich um den Rest. **Filament** wiederum erfordert eher Vorarbeit außerhalb des Code: Man muss Materialien und ggf. Meshes so aufbereiten, dass sie optimal sind (z.B. kleinere Normals/Textures). Boilerplate in Code hält Filament klein, aber es setzt auf *Konzepte* wie Vertex Buffer, Index Buffer, MaterialInstance, die man verstehen und richtig einsetzen muss. Insgesamt sind **Babylon.js und Three.js** auf Augenhöhe: Beide brauchen ein gewisses Maß an zusätzlichem Code für maximale Performance (z.B. Geometrien zusammenführen, Instancing vorbereiten, etc.) ([Main reasons for performance differences between WebGL frameworks. - Questions - three.js forum](https://discourse.threejs.org/t/main-reasons-for-performance-differences-between-webgl-frameworks/40729#:~:text=Whether%20it%20takes%20more%20time%2Fwork,lot%20on%20what%20you%E2%80%99re%20doing)). Babylon hat leichte Vorteile durch eingebaute Hilfen wie dem **Optimizer**-Guide und Tools wie dem Inspector, der Draw Calls zählt – so sieht man schneller, wo man ansetzen muss. Three.js verlangt manchmal mehr manuelle Analyse (z.B. via `Renderer.info` oder externen Profilern). Nichtsdestotrotz: keine Magie – große Performancegewinne erfordern immer etwas extra Implementierung.

**Shader-Programmierung (GLSL vs. Node-basiert):** Bei hochdetaillierten Szenen spielt auch das Material/Shading eine Rolle für Performance **und** Entwicklerfreundlichkeit. *Shader-Code* kann komplex werden, daher bieten einige Frameworks **node-basierte** Materialeditoren, um visuell oder mit Hochsprachennähe Effekte zu erstellen. **Three.js** historically setzt auf GLSL: Die Standard-Materials (MeshStandardMaterial etc.) sind vordefinierte Shader, die man parametrisieren kann. Möchte man etwas Ausgefallenes (z.B. eigenes Beleuchtungsmodell), schreibt man entweder ein eigenes GLSL-ShaderMaterial oder hackt den bestehenden Shader via onBeforeCompile. Neuerdings existiert jedoch Three.js’ **NodeMaterial-System** (und NodeEditor in den Beispielen), mit dem Entwickler Materialien aus Nodes zusammenklicken können – das generiert dann GLSL unter der Haube. Dieses System ist noch im Wachstum, aber zeigt, dass Three.js sich in Richtung *Shader-Graph* bewegt. **Babylon.js** hat bereits seit einiger Zeit einen **Node Material Editor** (NME) als Web-Tool. Entwickler können dort per Drag&Drop Shader-Netzwerke bauen (ähnlich Unity’s ShaderGraph) und diese als `.json` speichern oder direkt im Code verwenden. Intern erzeugt Babylon dann GLSL oder WGSL Shader. Für viele Anwendungsfälle (PBR, Unlit, simple effects) bringen Babylon und Three auch ohne Custom-Shader alles mit, aber wenn benötigt, ist Babylon’s Node-Editor ein großer Pluspunkt für Produktivität. Natürlich kann man in Babylon.js ebenfalls per `ShaderMaterial` direkt GLSL schreiben – beide Ansätze stehen offen. **PlayCanvas** bietet in seinem Editor *kein* komplettes Shader-Graph-Tool out of the box (Stand 2023), aber es gibt ein Materialsystem, das einen Großteil der Unity-Standard-Shader Funktionen als Einstellungen bereitstellt (glossiness, normal maps, etc.). PlayCanvas generiert intern den GLSL aus diesen Material-Einstellungen, d.h. der Entwickler muss selten selbst GLSL schreiben, außer für sehr spezielle Effekte (wofür Hooks ins Shader-Chunksystem bestehen). **Filament** verfolgt einen eigenen Weg: Man definiert Materialien entweder in einem hohen Shading-Language-Format (Filament Material Definition Language, ähnlich GLSL) und kompiliert sie ins `.filamat` Format, oder man nutzt die mitgelieferten PBR-Shader. Ein Node-Graph gibt es nicht, aber Filament strebt an, physikalisch korrekte Materialien ohne viel Anpassung zu liefern – man kommt oft mit den Standard-Parameter (BaseColor, Metallic, Roughness, etc.) aus. Möchte man Sonderlocken, muss man einen neuen Materialshader schreiben und vorab mit Filament-Tools kompilieren (im Web nicht dynamisch möglich). **Unity** schließlich hat wahrscheinlich den ausgereiftesten Ansatz: Neben händischem HLSL (den 99% der Web-Entwickler eher meiden werden) gibt es den **Shader Graph**, mit dem visuell Materialien erstellt werden können – diese funktionieren dann auch in WebGL-Builds, da Unity sie zu GLSL transpiliert. Unitys Standardshader sind zudem sehr optimiert (aber teilweise heavy). Der Entwickler hat hier komfortabel viele fertige Materialien zur Auswahl. – Zusammengefasst: **Babylon.js und Unity** glänzen mit fertigen *node-basierten Shader-Tools*, was die Handhabbarkeit für Entwickler (vor allem ohne tiefes GLSL-Wissen) verbessert. **Three.js** holt auf, hat aber historisch mehr Low-Level-GLSL erfordert, was versiertere Entwickler schätzen, Anfänger aber abschrecken kann. **PlayCanvas** liegt dazwischen – viel geht ohne Shader-Code, aber es fehlt ein öffentliches Node-Tool. In allen Fällen gilt: Für maximale Performance der Shader sollte man unnötig komplizierte Shader meiden – z.B. keinen überladenen Uber-Shader nutzen, wenn ein einfacher unlit reicht, da komplexe Shader auf Mobile wiederum die FPS drücken können (Fillrate). Hier hat Three.js den Vorteil, dass man genau steuern kann, was im Shader passiert; Babylon tendiert dazu, sehr umfassende Standardshader zu haben, die zwar flexibel aber evtl. etwas schwerer sind (man kann aber Feature Flags nutzen, um z.B. unnötige Teile abzuschalten).

## Zukunftssicherheit & Weiterentwicklung

**WebGPU-Perspektiven:** Alle Zeichen deuten darauf hin, dass **WebGPU** die Zukunft der 3D-Grafik im Browser ist. Browser-Hersteller und große Unternehmen investieren stark: 2023 erschien die erste stabile WebGPU-Version in Chrome 113, Unterstützung für Firefox und Safari ist in Arbeit ([Unlock the Potential of AI and Immersive Web Applications with WebGPU](https://www.intel.com/content/www/us/en/developer/articles/technical/unlock-potential-ai-immersive-web-apps-with-webgpu.html#:~:text=Major%20companies%2C%20including%20Google%2C%20Microsoft%2C,for%20future%20updates%20and%20enhancements)) ([Unlock the Potential of AI and Immersive Web Applications with WebGPU](https://www.intel.com/content/www/us/en/developer/articles/technical/unlock-potential-ai-immersive-web-apps-with-webgpu.html#:~:text=implementation%20is%20available%20in%20Chrome,for%20future%20updates%20and%20enhancements)). Für Entwickler bedeutet das, dass *jetzt* die Frameworks der nächsten Generation entstehen. **Babylon.js** war hier Vorreiter – das Team arbeitete eng mit dem WebGPU-Standard mit und Babylon hatte früh eine experimentelle WebGPU-Engine. Inzwischen (Babylon v6) kann man Babylon.js mit WebGPU-Backend laufen lassen; noch opt-in, aber die Ergebnisse sind vielversprechend. **Three.js** zieht nach: Ein WebGPURenderer befindet sich im dev-Branch und zeigt bereits teils beeindruckende Performance auf Desktop ([The new WebGL vs. WebGPU performance comparison example - Discussion - three.js forum](https://discourse.threejs.org/t/the-new-webgl-vs-webgpu-performance-comparison-example/69097#:~:text=The%20below%20is%20how%20profiling,is%20impressive%20comapred%20to%20WebGL)). Three.js wird vermutlich 2025 offiziell WebGPU unterstützen (wenn die Browser-Verbreitung gegeben ist). **PlayCanvas** und **Unity** haben WebGPU ebenfalls im Visier. Laut Intel arbeiten *führende Game-Engines wie Unity, Cocos und PlayCanvas an WebGPU-Ports* ([Unlock the Potential of AI and Immersive Web Applications with WebGPU](https://www.intel.com/content/www/us/en/developer/articles/technical/unlock-potential-ai-immersive-web-apps-with-webgpu.html#:~:text=WebGPU%20delivers%20a%20significant%20performance,are%20moving%20towards%20using%20WebGPU)). Unity selbst hat angekündigt, künftig neue Grafik-Backends (inkl. WebGPU) zu prüfen, sobald verfügbar – es gibt noch keine stabile Unity-WebGPU, aber es ist wahrscheinlich, dass Unity in einigen Jahren WebGPU nutzt, um z.B. von Vulkan-ähnlichen Pfaden zu profitieren. **Filament** könnte aufgrund seiner Ausrichtung auf moderne APIs ggf. auch WebGPU unterstützen, jedoch war Filament ursprünglich nicht für Web gedacht (WebGL wurde „nur zum Prototyping“ benutzt) ([Filament: Physically-based rendering engine - Hacker News](https://news.ycombinator.com/item?id=17684286#:~:text=Filament%3A%20Physically,quickly%20prototype%20the%20lighting%20system)). Wenn Google Filament weiter für Web einsetzen will (z.B. im `<model-viewer>`), ist ein WebGPU-Port denkbar, aber bisher nicht bestätigt. Für Entwickler bedeutet Zukunftssicherheit: **Frameworks, die WebGPU aktiv adaptieren, bieten langfristig die beste Performance.** Drei.js und Babylon.js kann man hier beruhigt verwenden – sie werden sich weiterentwickeln, anstatt obsolet zu werden. Unity-WebGL wird ebenfalls weiter gepflegt; Unity ist zwar proprietär, aber die Firma investiert in Web (z.B. besserer Wasm-Support, Multithreading). Allerdings hängt Unitys Web-Zukunft davon ab, wie gut sie ihre sehr mächtige Engine an Weblimits anpassen können.

**Langfristige Performance-Prognosen:** Mit dem Aufkommen von WebGPU und stetig leistungsfähigeren Geräten dürfte die Grenze des im Browser Darstellbaren weiter verschoben werden. In einigen Jahren könnten **mehrere Millionen Polygone** auch auf High-End-Smartphones darstellbar sein, da Mobil-GPUs jedes Jahr zulegen und WebGPU die CPU-Overheads reduziert. Zudem ermöglichen WebGPU’s Features neue Optimierungsarten: **Compute Shader** könnten z.B. genutzt werden, um *GPU-basierte culling* zu betreiben – d.h. anstatt Tausende Objekte auf der CPU zu filtern, könnte ein Compute-Job auf der GPU berechnen, welche Instanzen sichtbar sind, und direkt einen optimierten Draw-Call auslösen. Solche Techniken (im Stil von *Clustered Rendering* oder *Mesh Shaders* auf nativen APIs) stehen dann offen. Wir sehen vielleicht auch die Web-Adaption von Konzepten wie **Nanite** (aus Unreal Engine), das auf Mikropolygon-Rendering basiert – WebGPU hätte zumindest die nötigen Schnittstellen (z.B. Unterstützung für indirekte Zeichnen, bessere Buffer-Handhabung), um experimentell so etwas umzusetzen. Benchmarks werden sich entsprechend ändern: War bisher ~1–2 Mio. Tris eine Hausnummer, könnten in Zukunft **10+ Mio. Polys** im Browser erreicht werden, wie es heute nur native Anwendungen schaffen. Ein Indiz: In einem experimentellen Three.js-WebGPU-Setup mit instanzierten Objekten konnte man bereits **120 FPS mit 1,8 Mio. Dreiecken** messen ([Scene performance (heavy meshes, faces, instancing, picking) - Questions - Babylon.js](https://forum.babylonjs.com/t/scene-performance-heavy-meshes-faces-instancing-picking/11449#:~:text=PeterS%20%20January%2031%2C%202024%2C,10%3A42am%20%203)) – zukünftige GPUs und Optimierungen könnten das vervielfachen. Wichtig wird auch die **Parallelisierung**: WebAssembly unterstützt inzwischen Threads (mit SharedArrayBuffer), was Unity 2022+ bereits nutzt, um z.B. Physik in separaten Threads laufen zu lassen. Künftige JS-Frameworks könnten vermehrt **Web Workers** einsetzen, um Teile der 3D-Berechnung abzukoppeln (Babylon.js experimentierte bspw. mit OffscreenCanvas + WebGL in Worker). Die Browser werden hier ebenfalls besser: Neben dem Rendering-Thread könnten Asset-Parser in Worker ausgelagert werden, sodass selbst Riesen-GLBs das UI nicht blockieren ([Browser becomes unresponsive when loading the attached model](https://discourse.threejs.org/t/browser-becomes-unresponsive-when-loading-the-attached-model/63749#:~:text=Browser%20becomes%20unresponsive%20when%20loading,any%20way%20to%20load%20it)). Kurz: Die *Prognose* ist sehr positiv – die Lücke zwischen WebGL und nativer Grafikleistung wird kleiner.

**Aktive Weiterentwicklung der Frameworks:** Alle genannten Frameworks sind *aktiv in Entwicklung*, was für ihre Zukunftssicherheit spricht. **Three.js** veröffentlicht fortlaufend (monatlich) Updates, fügt Features hinzu und hat eine riesige Community. **Babylon.js** wird federführend von Microsoft/Mozilla-Mitarbeitern betreut, mit regelmäßigen Major Releases (die GitHub-Community ist rege). **PlayCanvas** Engine ist open-source und wird kontinuierlich verbessert, v.a. mit Fokus auf WebGL2/WebGPU und Editor-Features – auch Unternehmen wie Snap nutzen es für WebAR, was die Entwicklung antreibt. **Filament** als Google-Projekt erhält ebenfalls Updates, insbesondere um es für AR (Android) und Web besser zu machen; da es aber eher ein spezialisiertes Rendering-Toolkit ist, sind die Release-Zyklen länger. **Unity**: die WebGL-Unterstützung profitiert von allgemeinen Engine-Verbesserungen – z.B. die Umstellung auf .NET Core (IL2CPP) hat Performance erhöht, WebAssembly-Threads steigern physikberechnungen, etc. Unity hat aber auch Schwächen: Web ist nur *eine* von vielen Plattformen, sodass Web-spezifische Features manchmal langsam kommen (z.B. dauerte es, bis Unity WebGL WebGL 2 voll unterstützte, und WebGPU steht noch aus). Dennoch pflegt Unity Dokumentation und Best Practices fürs Web regelmäßig ([Unity - Manual: Web performance considerations](https://docs.unity3d.com/Manual/webgl-performance.html#:~:text=,you%20can%20use%20to%20achieve)). – Für Entwickler, die jetzt ein Projekt starten, lohnt es sich, auf die **Community-Größe** zu achten: Three.js hat mit Abstand die meisten Nutzer, Tutorials und StackOverflow-Beiträge, was Hilfe bei Problemen erleichtert. Babylon.js Community ist kleiner, aber sehr engagiert (Forum mit core devs, Beispielprojekte). Beide werden mit WebGPU neue Schub bekommen, sobald mehr Entwickler darauf umsteigen. Unity hat seine eigene große Community, aber spezifisch für WebGL-Optimierung muss man oft in Nischen suchen, da viele Unity-User primär für PC/Konsole entwickeln.

Abschließend lässt sich sagen, dass **hochdetaillierte 3D-Szenen im Browser** heute kein utopisches Ziel mehr sind. Mit Three.js, Babylon.js, PlayCanvas, Filament und Unity stehen leistungsfähige Frameworks bereit, um Millionen von Polygonen darzustellen – *unter der Bedingung*, dass man die jeweiligen Stärken ausnutzt (Instancing, LOD, etc.) und die Inhalte klug vorbereitet. Auf dem Desktop wurden bereits beeindruckende FPS-Werte bei riesigen Szenen gemessen (120 FPS bei ~2 Mio. Polys) ([Scene performance (heavy meshes, faces, instancing, picking) - Questions - Babylon.js](https://forum.babylonjs.com/t/scene-performance-heavy-meshes-faces-instancing-picking/11449#:~:text=PeterS%20%20January%2031%2C%202024%2C,10%3A42am%20%203)), und mobile Geräte holen mit Optimierung ~200–500k Polys zuverlässig in den spielbaren Bereich ([Optimizing of many models, what path to take - Help & Support - PlayCanvas Discussion](https://forum.playcanvas.com/t/optimizing-of-many-models-what-path-to-take/14636#:~:text=1,a%20lot%20on%20some%20devices)). WebGPU wird diesen Trend weiter beschleunigen und in naher Zukunft für nochmal deutlich höhere Performance sorgen ([Unlock the Potential of AI and Immersive Web Applications with WebGPU](https://www.intel.com/content/www/us/en/developer/articles/technical/unlock-potential-ai-immersive-web-apps-with-webgpu.html#:~:text=WebGPU%20is%20a%20new%20API,and)). Entwickler sollten sich jetzt mit den Best Practices vertraut machen – von **Draw-Call-Optimierung** bis **Streaming-Assets** – um das Maximum aus WebGL und dem kommenden WebGPU herauszuholen. Dann sind stabile >30 FPS selbst in detailverliebten Millionen-Polygon-Welten erreichbar, sogar auf Tablets und Phones. **Best Practices:** Wenige Draw Calls, sinnvoller LOD-Einsatz, Instancing wo immer möglich, und Vorsorge beim Laden (komprimierte, gestreamte Assets). Damit wird die immersive 3D-Web-Experience Wirklichkeit – *jetzt* und erst recht in Zukunft. ([Optimizing of many models, what path to take - Help & Support - PlayCanvas Discussion](https://forum.playcanvas.com/t/optimizing-of-many-models-what-path-to-take/14636#:~:text=1,a%20lot%20on%20some%20devices)) ([Scene performance (heavy meshes, faces, instancing, picking) - Questions - Babylon.js](https://forum.babylonjs.com/t/scene-performance-heavy-meshes-faces-instancing-picking/11449#:~:text=PeterS%20%20January%2031%2C%202024%2C,10%3A42am%20%203))