Three.js: Wird es einen WebGPU-basierten Renderer geben?

Theoretisch in ferner Zukunft, aber wie Sie vielleicht wissen, spricht die WebGPU-Gruppe immer noch aktiv über die Bildung erster Vorschläge / Spezifikationen / Entwürfe. Es wird Jahre dauern, bis wir eine vollständige Spezifikation haben und standardisierte Implementierungen durchführen.

Trotzdem würde ich empfehlen, sich hier an der WebGPU-Entwicklung zu beteiligen: https://github.com/gpuweb/gpuweb/wiki und https://www.w3.org/community/gpu/

Wenn sich WebGPU als so leistungsfähig herausstellt, wie wir alle hoffen, müssen Bibliotheken wie Three.js wahrscheinlich von Grund auf neu geschrieben werden, um alle Vorteile nutzen zu können.

@ TimvanScherpenzeel
Ja, ich stimme zu. Ich werde die ferne Zukunft sein.
Ist es unmöglich, WebGPU-Renderer in three.js hinzuzufügen, ohne den Kern von Grund auf neu zu schreiben? Müssen wir die gesamte Engine (API) in drei Sekunden von Grund auf neu schreiben? Ich denke, selbst wenn WebGPU herauskommt, ist es sehr wahrscheinlich, dass es für eine Weile zusammen existiert (WebGL / WebGPU). Ich glaube nicht, dass WebGPU das gesamte WebGL-Ökosystem zerstören würde.
Ich gehe jedoch davon aus, dass WebGPU sehr leistungsfähig wäre, wenn es nativ und direkt unterstützt, im Gegensatz dazu, dass WebGL eine indirekte API des Grafiktreibers ist.Google und andere große Unternehmen möchten dies für eine bessere DeepLearning-Leistung und eine leistungsstarke Grafikerfahrung im Browser

ThreeJS hat bereits viele verschiedene Renderer - WebGLRenderer, WebGL2Renderer, CSS3DRenderer, SVGRenderer ... WebGPU kann ähnlich behandelt werden, wenn die API bereit ist. Mit der Zeit sind auch tiefere Änderungen an der Bibliothek möglich.

Schließen Sie dieses Problem vorerst, obwohl ich gespannt bin, dass diese APIs der nächsten Generation ebenfalls verfügbar sind. :) :)

@donmccurdy
In der Tat .. Three.js ist so flexibel, dass es in Zukunft sogar WebGPU implementieren kann, oder?

Laut dem WebGPU-Vorschlag erwähnten sie Three.js Deverlopers als eine ihrer Hauptzielgruppen.

https://gpuweb.github.io/admin/cg-charter.html

JavaScript-Framework-Entwickler, die GPU-Bibliotheken erstellen, die für die Verwendung in Webinhalten vorgesehen sind, jedoch eine übergeordnete API bereitstellen und einen Großteil der Grafiken auf niedriger Ebene verbergen und Details vor ihren Benutzern berechnen. Zum Beispiel three.js.

Meine Frage ist, dass sie eine andere Shader-Sprache namens WHLSL verwenden.
https://github.com/gpuweb/WHLSL

Meine Frage ist, dass sie eine andere Shader-Sprache namens WHLSL verwenden.

"Wir werden diese Brücke überqueren, wenn wir dazu kommen."

Wurde bei Google I / O mit experimenteller Unterstützung in Chrome Canary für OSX angekündigt und ist ab sofort verfügbar:
https://www.youtube.com/watch?v=K2JzIUIHIhc

Babylon.js hat volle Unterstützung dafür angekündigt, wenn es herauskommt. Schau es dir hier an:
https://forum.babylonjs.com/t/webgpu-is-coming-to-babylon-js/3122

Ich hoffe, dass das ThreeJS-Team der Führung folgt.

Ich bin mir nicht sicher, warum ich dies schließen sollte, da die potenzielle Unterstützung erwähnt wurde. Aus logischen Gründen haben wir Probleme offen gelassen, um sie zu "verfolgen". Wenn Sie es schließen, vergessen Sie einfach ... es sei denn, es gibt ein anderes Problem, um es zu verfolgen.

Ich kann Ihnen versichern, dass wir es nicht vergessen werden ... 😁

Aber ich bin kein Betreuer. Persönlich werde ich dem ersten Framework folgen, das webgpu übernimmt. Und der Punkt ist nicht ich. Ist die Botschaft, die ihr gibt, dies zu schließen? Es ist wie "Coole Sache, sicher, aber es ist mir egal. Es kann dort in der Schwebe halten".

PS. Ich habe es falsch gelesen und dachte, es sei "Ich kann Ihnen versichern, dass Sie es nicht vergessen werden".

@MichelDiz Dieses Problem wurde geöffnet, um zu fragen, ob wir WebGPU unterstützen möchten. Die Frage wurde beantwortet: Wir planen unbedingt, WebGPU zu unterstützen. Es ist wahrscheinlich zu früh, um daran zu arbeiten, aber neue Themen werden eröffnet, wenn wir bereit sind, darüber zu diskutieren.

@TimvanScherpenzeel Bestimmte Teile, die von den Benutzern abstrahiert werden, müssen neu geschrieben werden, aber es ist eine massive Übertreibung, dass das Ganze "von Grund auf neu geschrieben" werden muss. Puffergeometrien haben das gleiche Format. Genau wie WebGL basiert auch WebGPU auf den Shadern GLSL -> WHLSL. Es scheint, dass das glTF-Format, das zum WebGL-Standard geworden ist, auch der WebGPU-Standard sein wird. Alle am häufigsten verwendeten Three.js-APIs bleiben zu 99% unverändert, während sich der neue WebGPU-Renderer unter der Haube befindet und hoffentlich einen großen Leistungsschub bringt und das Potenzial für das Rendern großer Szenen mit hohen Bildern pro Sekunde freisetzt.

Hallo zusammen,
Vielen Dank für die Updates zu diesem!
Ich wollte nur meine Sicht auf solche Funktionen teilen. In unserem Fall verwenden wir WebGL nicht immer für Verbraucheranwendungen. Wir haben WebGL-Erfahrungen damit, dass wir sehr große Datenmengen visualisieren, bei denen die Assets ~ 1 GB groß sind und lokal auf fester Hardware bereitgestellt werden, wo wir die Browser und ihre Flags steuern können, um WebGPU zu aktivieren. Selbst wenn wir uns im experimentellen Modus befinden, könnten wir definitiv gerne Unterstützung dafür haben. Ich verstehe, dass wir die Minderheit sind, aber ich wollte diese Ansicht nur in das Gespräch aufnehmen.

@sinokgr Wie hilft WebGPU bei der Anzeige von 1 GB Assets? Soweit ich weiß, sind die Datenstrukturen für Geometriedaten dieselben wie für WebGL.

danke für die antwort @mrdoob . Um 100% ehrlich zu sein, werde ich nicht behaupten, dass ich die Unterschiede genug verstehe und die Informationen, die ich online finde, sehr vage sind (nach meinen Recherchen sowieso). Das Hauptgefühl, das ich bekomme, ist von Sachen, die ich gelesen habe, wie die letzte Nachricht von @DVLP , die dir gefallen hat.

wird einen großen Leistungsschub bringen und das Potenzial freisetzen, große Szenen mit hohen Bildern pro Sekunde zu rendern.

das lässt mich denken, dass wir zumindest einige Verbesserungen sehen werden. Dies könnte sein, wie schnell zum Beispiel diese Assets geladen werden, vielleicht bessere fps? Ich bin mir nicht sicher.

Das anfängliche Laden in den regulären Speicher bleibt gleich, aber die gesamte GPU-API ist schneller. Ab dem Moment, an dem die GPU beteiligt ist, sollte sie schneller sein. So sehe ich, woher der Leistungsschub kommt:

1. Laden Sie die Modelldatei in den Browser - mit der gleichen Geschwindigkeit
2. Analysieren Sie das Modell und laden Sie die Geometrie in einen Array-Puffer - gleiche Geschwindigkeit
3. Laden Sie GPU-Programme - schneller
4. Laden Sie Texturen - zunächst mit der gleichen Geschwindigkeit, aber schneller bei der Übergabe an die GPU
5. Übertragen Sie die Geometrie auf die GPU - schneller
6. Führen Sie eine Reihe von Zeichenaufrufen aus, um einen Frame schneller zu rendern

Vielen Dank für die Erklärung @DVLP . Die Punkte 5 und 6 klingen für mich sehr interessant, da wir Tausende von Objekten mit vielen Materialien haben.

Es kann lange dauern, bis WebGPU weit verbreitet ist. Bis dahin können Sie das Ganze mithilfe von Mesh-Instanzen beschleunigen
https://threejs.org/docs/#api/en/objects/InstancedMesh

Ich fürchte, wir können keine Instanz verwenden, alle Objekte sind eindeutig @DVLP

https://github.com/mrdoob/three.js/pull/20254