Einführung und einfache Anwendung von WebGL und wasm

Einführung

Im Folgenden werden hauptsächlich WebGL und WASM vorgestellt, die neben HTML, CSS und JS die beiden anderen Hauptkomponenten sind, die von Webstandards unterstützt werden.

Ersteres implementiert eine komplexe Grafikverarbeitung und letzteres bietet eine effiziente Codemigration und Codeausführungseffizienz.

WebGL

Einführung

Wie erreicht das Spiel im Browser zunächst diese Art der Interaktion und zeigt verschiedene Bildschirme an?

Stellen Sie sich vor, Sie verwenden unser dreiteiliges Front-End-Set, um es zu implementieren. Es scheint, dass es mit Canvas implementiert werden kann, aber der Implementierungsprozess wird sehr kompliziert und die Codemenge groß sein.

Diese Art der Grafikwiedergabe wird also tatsächlich an die Grafikwiedergabe-Engine übergeben.

Wir können unseren Rendering-Prozess über die von der Engine bereitgestellte js-Schnittstelle ausführen

Die Essenz von WebGL, die wir vorstellen werden, ist die js-Schnittstelle von OpenGL

Was ist also OpenGL? Es scheint, je mehr Fragen es gibt, desto mehr Fragen gibt es. Machen Sie sich keine Sorgen, lassen Sie uns zunächst die Prinzipien der Grafikwiedergabe verstehen.

In der tatsächlichen Entwicklung werden wir WebGL nicht direkt verwenden, sondern nur die Prinzipien verstehen.

Merkmale

Durch die Einbettung in den Browser ist die Nutzung ohne Installation von Plug-Ins und Bibliotheken möglich.

Nutzen Sie Ihre Systemgrafiken, um 3D-Szenen und -Modelle flüssiger im Browser darzustellen und komplexe Navigations- und Datenvisualisierungen zu erstellen

Kann zum Erstellen von Website-Seiten mit komplexen 3D-Strukturen verwendet werden, wie zum Beispiel:

Google Earth
3D-Modellanzeige
Web-Spiele
digitaler Zwilling

Prinzip

Programmierebene

Dies ist das Grafik-Rendering-Hierarchie-Architekturdiagramm von Flutter (einem von Google gestarteten Anwendungsentwicklungs-Framework).
Hinweis: WebGL und OpenGL befinden sich auf derselben Ebene, nur der Unterschied zwischen B/S- und C/S-Architektur, daher sind sie äquivalent OpenGL in der Abbildung unten

Der Kern von WebGL besteht also darin, die vom Browser zu verarbeitenden Grafiken zu übersetzen und sie zur Ausführung an unsere GPU zu übergeben.

Im Wesentlichen wird es über die Sprache GLSL (OpenGL Shading Language) implementiert, die mit JS identisch ist, jedoch unterschiedliche Funktionen aufweist.

Grafikebene

Anders als wenn wir das gesamte Bild erstellen müssen, müssen wir ihm bei der Verwendung von WebGL nur die Beziehung zwischen einigen Punkten, Linien und Flächen mitteilen, und die Grafiken können automatisch verarbeitet und gerendert werden.

Der spezifische Prozess ist wie folgt. Wir nennen diesen Prozess „Rendering-Pipeline“.

Der Vertex-Shader verarbeitet Vertices: Verarbeitet die eingehenden Vertex-Informationen, wie z. B. Clip-Space-Transformation, Übersetzung, Skalierung, Rotation und andere Vorgänge.
Primitive Assemblierung: Der Prozess des Zusammensetzens von Scheitelpunkten zu Basisgrafiken, das heißt, OpenGL wird mitgeteilt, wie diese Punkte in welcher Form kombiniert werden sollen (welche Punkte eine Gruppe bilden).
Rasterung: Bestimmen Sie nacheinander, ob sich die Pixel innerhalb der Grafik befinden, und interpolieren Sie die Nicht-Scheitelpunktpositionen, um jedem Pixel andere Informationen zu geben. Da ein Pixel mehr als nur Farbinformationen hat, nennen wir es ein „Fragment“.
Fragment-Shader-Färbung: Die Schattierung der gerasterten Fragmente, Beleuchtung, Materialien usw. erfolgt grundsätzlich im Fragment-Shader.
Testen und Mischen: Einschließlich Tiefentests (verdeckte Teile des Objekts werden nicht angezeigt), Vorlagentests, Mischen (Mischen von Transparenzwerten)

erreichen

Sie können den Vergleich zwischen den beiden sehen

Tradition

HTML

<body>
    <canvas id="canvas"></canvas>
    <script>
        var canvas = document.getElementById('canvas');
        var ctx = canvas.getContext('2d');
        ctx.fillStyle = '#00F';
        ctx.fillRect(0, 0, 600, 600);
    </script>
</body>

WebGL

html

<body>
    <canvas id="canvas" width="600" height="600"></canvas>
    <script src="webgl.js"></script>
</body>

webgl.js

function main(){
    
    
    var canvas = document.getElementById('canvas');
    var gl = canvas.getContext('webgl');
    gl.clearColor(0, 0, 255/255, 1.0);
    gl.clear(gl.COLOR_BUFFER_BIT);
}
main();

Anwendung

WebGL-Kapselung: Um die WebGL-Entwicklung zu vereinfachen, besteht die größte Funktion darin, dass Sie GLSL selbst schreiben müssen, um es verwenden zu können.
Rendering-Engine: Sie ist als Anzeige dreidimensionaler Objekte und Szenen positioniert und abstrahiert im Allgemeinen Konzepte wie Szenen, Kameras, Lichter usw. Die Schwelle für den Einstieg ist niedrig und es ist nicht erforderlich, GLSL selbst zu schreiben.
Spiel-Engine: Für die Spieleentwicklung konzipiert, basierend auf der vorherigen Rendering-Engine, bietet sie außerdem Skelettanimationen, eine Physik-Engine, KI, GUI und andere Funktionen sowie einen visuellen Editor zum Entwerfen von Levels und zur Unterstützung der Entwicklung umfangreicher Spiele. (Tatsächlich verfügen die beiden oben genannten Rendering-Engines auch über
die Funktionen vieler Game-Engines und werden daher häufig in der mittleren und leichten Entwicklung verwendet), beispielsweise Unity (U3D), Unreal Engine (WE4).

Zukunft

Im Jahr 2017 veröffentlichte OpenGL seine endgültige Version 4.6, und im selben Jahr kündigte Khronos an, keine neuen OpenGL-Versionen mehr zu veröffentlichen und sich auf die Entwicklung von Vulkan (auch bekannt als glNext) und anderen Technologien zu konzentrieren. Da OpenGL keine Updates mehr anbietet, Grafik-APIs der neuen Generation wie Vulkan, Metal, D3D12 usw. wurden nacheinander veröffentlicht, und die neue Webgrafik-API WebGPU steht kurz vor der Veröffentlichung. In diesem Prozess wird sich WebGL zweifellos aus der Phase der Geschichte zurückziehen.

OpenGL ist für moderne GPU-Architekturen nicht mehr geeignet

Frühe GPUs waren ein fester Satz Hardware mit nur Grundfunktionen und geringer Programmierbarkeit. Da Anwendungsentwickler die Funktionsgrenzen dieser nicht programmierbaren Systeme immer weiter ausreizen, haben GPU-Hersteller auch technologische Durchbrüche erzielt. Moderne GPUs haben sich weiterentwickelt und sind zu einer Leistung geworden. Monster“, das große Datenmengen verarbeiten kann und asynchrones Parallelrechnen unterstützt.

Da OpenGL in den Anfängen der Computergrafik veröffentlicht wurde, hat sein globales Zustandsmaschinen-ähnliches Design keinen Bezug zur modernen GPU-Architektur und kann die optimalen Fähigkeiten der GPU nicht vollständig nutzen. Das Design von WebGL ist vom OpenGL-Subset-Standard abgeleitet , also steht es auch vor dem gleichen Problem.

WebGL wird noch lange bestehen bleiben

Obwohl WebGPU immer näher an uns heranrückt, ist aus den veröffentlichten Demonstrationen ersichtlich, dass es in vielen Aspekten deutlich besser als WebGL ist. Es ist jedoch absehbar, dass WebGL noch lange in der Zukunft für Front entwickelt wird -End-Grafikanwendungen. Hauptoptionen:

Die Weiterentwicklung der Frontend-Standards verlief relativ langsam und es gibt Unterschiede zwischen den großen Browserherstellern hinsichtlich der Unterstützung neuer Standards.
Frontend-Entwickler müssen Kompatibilität und Stabilität priorisieren. Die Einführung neuer Technologien hat häufig negative Auswirkungen, insbesondere bei Anwendungen, die weit verbreitet sind.
WebGL ist stabil genug und seine Version 2.0 wird erst 2022 von allen gängigen Browsern unterstützt (hauptsächlich, weil Safari es immer als experimentelle Funktion verwendet hat). Um den normalen Betrieb bestehender Websites sicherzustellen, wird dieser Standard nicht unterstützt in absehbarer Zeit. Wird voraussichtlich aus dem Browser entfernt.

wasm

Einführung

Das heißt, WebAssembly ist ein Low-Level-Bytecode-Format, das zur Ausführung in Webbrowsern verwendet wird. Ziel ist es, eine leistungsstarke, portable Ausführungsumgebung bereitzustellen, damit verschiedene Sprachen in Browsern ausgeführt werden können, ohne von den Einschränkungen der JavaScript-Engine betroffen zu sein.

Merkmale

Die viertgrößte Websprache nach W3C-zertifiziertem HTML, JS, CSS
Da es sich um eine Binärdatei handelt, ist sie kleiner und schneller als js und bietet ergänzende Vorteile mit js.
Sprachen wie C/C++/C#/ts/Rust können direkt in wasm konvertiert werden, um Entwicklern die Migration bestehender Projekte ins Web zu erleichtern.

Anwendung

generieren

Wie zum Beispiel CPP-Code

#include <emscripten.h>
extern "C" {
    
    
    EMSCRIPTEN_KEEPALIVE
        int add(int a, int b) {
    
    
        return a + b;
    }
}

Emscripten ist eine Toolkette, die asm.js und WebAssembly-Bytecode über LLVM kompiliert und generiert. Der Zweck besteht darin, Ihnen die Ausführung von C und C++ in Webseiten mit nahezu höchster Geschwindigkeit ohne Plug-Ins zu ermöglichen.

Nach der Installation von Emscripten können wir dieses C++-Programm mit dem folgenden Befehl in ein WASM-Programm kompilieren:

emcc add.cpp -s WASM=1 -O3 --no-entry -o add.wasm

Bytecode abrufen

00 61 73 6D 01 00 00 00 01 17 05 60 00 01 7F 60
00 00 60 01 7F 00 60 01 7F 01 7F 60 02 7F 7F 01
7F 03 07 06 01 04 00 02 03 00 04 05 01 70 01 02
02 05 06 01 01 80 02 80 02 06 0F 02 7F 01 41 90
88 C0 02 0B 7F 00 41 84 08 0B 07 82 01 09 06 6D
65 6D 6F 72 79 02 00 19 5F 5F 69 6E 64 69 72 65
63 74 5F 66 75 6E 63 74 69 6F 6E 5F 74 61 62 6C
65 01 00 03 61 64 64 00 01 0B 5F 69 6E 69 74 69
61 6C 69 7A 65 00 00 10 5F 5F 65 72 72 6E 6F 5F
6C 6F 63 61 74 69 6F 6E 00 05 09 73 74 61 63 6B
53 61 76 65 00 02 0C 73 74 61 63 6B 52 65 73 74
6F 72 65 00 03 0A 73 74 61 63 6B 41 6C 6C 6F 63
00 04 0A 5F 5F 64 61 74 61 5F 65 6E 64 03 01 09
07 01 00 41 01 0B 01 00 0A 30 06 03 00 01 0B 07
00 20 00 20 01 6A 0B 04 00 23 00 0B 06 00 20 00
24 00 0B 10 00 23 00 20 00 6B 41 70 71 22 00 24
00 20 00 0B 05 00 41 80 08 0B

verwenden

Führen Sie den folgenden js-Code direkt in vscode aus

a = 2;
b = 4;
WebAssembly.instantiate(new Uint8Array(`
00 61 73 6D 01 00 00 00 01 17 05 60 00 01 7F 60
00 00 60 01 7F 00 60 01 7F 01 7F 60 02 7F 7F 01
7F 03 07 06 01 04 00 02 03 00 04 05 01 70 01 02
02 05 06 01 01 80 02 80 02 06 0F 02 7F 01 41 90
88 C0 02 0B 7F 00 41 84 08 0B 07 82 01 09 06 6D
65 6D 6F 72 79 02 00 19 5F 5F 69 6E 64 69 72 65
63 74 5F 66 75 6E 63 74 69 6F 6E 5F 74 61 62 6C
65 01 00 03 61 64 64 00 01 0B 5F 69 6E 69 74 69
61 6C 69 7A 65 00 00 10 5F 5F 65 72 72 6E 6F 5F
6C 6F 63 61 74 69 6F 6E 00 05 09 73 74 61 63 6B
53 61 76 65 00 02 0C 73 74 61 63 6B 52 65 73 74
6F 72 65 00 03 0A 73 74 61 63 6B 41 6C 6C 6F 63
00 04 0A 5F 5F 64 61 74 61 5F 65 6E 64 03 01 09
07 01 00 41 01 0B 01 00 0A 30 06 03 00 01 0B 07
00 20 00 20 01 6A 0B 04 00 23 00 0B 06 00 20 00
24 00 0B 10 00 23 00 20 00 6B 41 70 71 22 00 24
00 20 00 0B 05 00 41 80 08 0B
`.trim().split(/[\s\r\n]+/g).map(str => parseInt(str, 16))
)).then(({
     
     instance}) => {
    
    
const {
    
     add } = instance.exports
console.log('a + b =', add(a, b))
})

erhalten werden kann

a + b = 6

In Einheit

Tatsächlich exportiert Unity beim Erstellen von WedGL Wasm, um eine hohe Leistung aufrechtzuerhalten.

Sie können die Exportschritte unten sehen und es selbst ausprobieren, oder Sie können sich die WASM-Datei im Exportverzeichnis ansehen.

Schritte exportieren

Öffnen Sie das Unity-Projekt, klicken Sie in der Navigationsleiste auf „Datei“ und wählen Sie im Dropdown-Menü „Build-Einstellungen“ aus.
Wechseln Sie im sich öffnenden Dialogfeld die Plattform zu WebGL, klicken Sie links auf „WebGL“ und wählen Sie dann in der unteren rechten Ecke „Plattform wechseln“. Wenn Sie WebGL zum ersten Mal exportieren, fordert Unity möglicherweise zum Herunterladen auf entsprechendes Komponentenpaket. Stellen Sie sicher, dass die Option „Alle Szenen, die exportiert werden müssen“ aktiviert ist.
Klicken Sie unten links auf „Player-Einstellungen“, um die plattformspezifischen WebGL-Exporteinstellungen zu ändern.
Ändern Sie im Untermenü „Andere Einstellungen“ die folgenden Einstellungen:
- API-Kompatibilitätsgrad: Wechseln Sie zu .NET Standard 2.0 oder .NET Standard 2.1.
- Engine-Code entfernen: Deaktivieren. Wenn diese Option aktiviert ist, entfernt Unity Komponenten, die standardmäßig nicht im Projekt verwendet werden, um die Paketgröße zu reduzieren. Um API-Fehler zu vermeiden, ist es am besten, die Option zu deaktivieren.
Ändern Sie im Untermenü „Veröffentlichungseinstellungen“ die folgenden Einstellungen:
- Komprimierungsformat: Auf „Deaktiviert“ ändern. Andernfalls kann der Browser die gepackten und heruntergeladenen Datendateien möglicherweise nicht direkt lesen und es ist eine weitere Dekomprimierungskonfiguration erforderlich. Da das Projekt klein ist, treten ohne Komprimierung keine Leistungsprobleme auf.
- Dekomprimierungs-Fallback: Wenn Brotli oder Gzip im „Komprimierungsformat“ zum Komprimieren der Paketgröße ausgewählt ist, müssen Sie diese Option aktivieren. Auf diese Weise kann der Browser automatisch dekomprimieren, wenn keine benutzerdefinierte Dekomprimierungsmethode vorhanden ist, um zu vermeiden, dass br- oder gz-Dateien nicht erkannt werden. Zustand.
Tipp: Die Größe der mit der Brotli-Komprimierung gepackten Dateien ist besser als die mit Gzip gepackte Dateigröße, der Preis ist jedoch eine längere Wartezeit beim Packen.
Stellen Sie sicher, dass der Projektpfad keine chinesischen Zeichen enthält (unter bestimmten Bedingungen ist die Verwendung chinesischer Zeichen in Ordnung. Dies kann Probleme mit der Unity-Version verursachen. Es wird empfohlen, ihn zu ändern, wenn ein Fehler auftritt).
Klicken Sie auf „Erstellen und ausführen“ und warten Sie (länger). Der Unterschied besteht darin, dass „Erstellen und Ausführen“ einen lokalen Server startet und Sie eine Vorschau der Wirkung der eingebetteten WebGL-Seite anzeigen können, es jedoch keinen wesentlichen Unterschied bei der Verpackung gibt Beim Debuggen wird in dieser Phase die Verwendung von „Build and Run“ empfohlen. Bei der Portierung auf die Website verwenden Sie einfach „Build“ und greifen dann auf die Kerndateien zu.

Exportierte Verzeichnisstruktur

Kerndateien:
- ProjectName.framework.js: JavaScript-Laufzeit und Plugins.
- ProjectName.loader.js: JavaScript-Code erforderlich, damit Webseiten Unity-Inhalte laden können.
- ProjectName.wasm: WebAssembly-Binärdatei.
- ProjectName.data: Ressourcendaten und Szenen.
- ProjectName.mem (optional): Binäre Bilddatei, die zum Initialisieren des Player-Heapspeichers verwendet wird. Diese Datei wird nur für Multithread-WebAssembly-Builds generiert.
- ProjectName.symbols.json (optional): Debug-Symbolnamen, die zum Debuggen von Fehler-Stack-Traces erforderlich sind. Diese Datei wird nur für Release-Builds generiert, wenn die Option Debug-Symbole aktiviert ist (Datei > Build-Einstellungen > Player-Einstellungen).
- ProjectName.jpg (optional): Das Hintergrundbild, das beim Laden des Builds angezeigt wird. Diese Datei wird nur generiert, wenn in den Player-Einstellungen ein Hintergrundbild bereitgestellt wird (Datei > Build-Einstellungen > Player-Einstellungen > Splash-Bild). Wenn Sie „Für jedes“ auswählen Bei der Komprimierungsmethode wird an den Dateinamen das entsprechende Komprimierungssuffix (.br, .gz) angehängt. Wenn Dekomprimierungs-Fallback weiter aktiviert ist, hängt Unity auch die Erweiterung .unityweb an das Dateinamensuffix an.
StreamingAssets: Wird zum Speichern statischer Ressourcen verwendet. Alle Dateien im Ordner mit demselben Namen im Unity-Projekt werden in diesen Ordner gepackt. Der Hauptzweck besteht darin, große statische Kunstressourcen zu entfernen, damit sie im CDN und an anderen Orten gespeichert werden können und asynchron geladen werden, wodurch die Ladegeschwindigkeit der Kernpakete gespart wird. Bei der Implementierung im Browser sind Benennung und Speicherort des Ordners frei.
TemplateData: Bilder, die in WebGL-Vorlagen verwendet werden, bei denen es sich nicht um Kerndateien handelt.
index.html: Webseitentext, keine Kerndatei.