Three.js: WebGL2Renderer

Sehr schön. :) Ich war tatsächlich etwas besorgt, wie ich mit der Komplexität von WebGL 2 und 1 umgehen soll.

Es wäre toll, lieber UBO zu verwenden. :) Und ich liebe die Idee, nur BufferGeometry zu unterstützen - das sollte die Dinge enorm vereinfachen.

Es wäre cool, wenn wir hauptsächlich dieselben Shader unterstützen würden, wenn wir beim Vorwärts-Rendering bleiben (was UE4 anscheinend für die Geschwindigkeit für VR tut). Ich denke, wir können das wahrscheinlich ändern? Was denkst du?

Ich denke, ich möchte die Shader-Kompatibilität beibehalten, damit wir, wenn WebGL2 nicht verfügbar ist, auf etwas zurückgreifen können, das ähnlich aussieht, nur langsamer.

@mrdoob Hip hip hurra! Und schön zu hören, dass ausschließlich BufferGeometry verwendet wird. 👍

Ich unterstütze den Vorschlag von @bhouston , UBOs zu bevorzugen.

Wäre es auch möglich, Beleuchtung und Schattenbehandlung vollständiger vom Renderer zu entkoppeln? Die Standardeinstellungen sind wirklich praktisch, aber wenn Sie die vollständige Kontrolle über die Beleuchtungs- und Schattenlogik haben möchten, WebGLRenderer und co. das Gefühl haben, dass sie sich wehren.

Und während ich Artikel vom Typ Wunschliste aufliste, könnten Sortieralgorithmen "steckbar" gemacht werden? Ich habe Sortieranforderungen, die außerhalb des Bereichs von drei liegen, und es scheint unnötig schwierig, die Sortierfunktionen im aktuellen WebGLRenderer zu überschreiben. Vielleicht könnte dies eine optionale Einstellung beim Erstellen des Renderer-Objekts sein?

Ich frage mich fast, ob man WebGLRenderer 1 einfach modifizieren und die Unterstützung für alles andere als BufferGeometry-Objekte entfernen sollte. Das kann ein einfacherer Weg nach vorne sein. Wenn es eine einfache Funktion zum Konvertieren von Geometry in BufferGeometry gibt, die man zum Aufrufen zwingt ...

Ich denke, ich sage das, weil ich mir Sorgen darüber mache, ob ich versuche, die Feature-Parität zwischen WebGLRenderer und WebGLRenderer2 aufrechtzuerhalten. Es ist einfacher, eine einzelne Codebasis zu entwickeln, als zwei parallel zu pflegen.

Ich frage mich fast, ob man WebGLRenderer 1 einfach modifizieren und die Unterstützung für alles andere als BufferGeometry-Objekte entfernen sollte. Das kann ein einfacherer Weg nach vorne sein. Wenn es eine einfache Funktion zum Konvertieren von Geometry in BufferGeometry gibt, die man zum Aufrufen zwingt ...

Eine solche Funktion gibt es bereits. Aber so einfach ist das nicht...

Ich denke, es ist besser, WebGLRenderer2 von Grund auf neu zu erstellen, damit wir die API und die unterstützten Funktionen überdenken können.

Firefox 51 unterstützt jetzt WebGL 2: https://www.mozilla.org/en-US/firefox/51.0/releasenotes/

Ich kann es kaum erwarten!

Chrome 56 mit Unterstützung für WebGL 2.0 wurde veröffentlicht!
https://developers.google.com/web/updates/2017/01/nic56

Guter Zeitpunkt, um WebGLRenderer2 voranzukommen? XD

Sollen wir auch einen WebGLDeferredRenderer2 erstellen?

Ich plane, mich nächste Woche mit all dem zu befassen! ✌️

Hatten Sie vielleicht schon etwas Zeit, sich damit zu beschäftigen! Soooo freue mich darauf! (3D-Texturen)

@mrdoob
Irgendwelche Neuigkeiten?
Wenn Sie Bedenken haben, teilen Sie uns dies bitte mit!
Wir können diskutieren und helfen ;D

Hatte noch keine Zeit. Bald bald! 😇

https://blog.chromium.org/2017/03/faster-3d-rendering-with-webgl-20.html

Irgendwelche Updates? Ich interessiere mich besonders für 3D-Texturen für das Volumen-Rendering einiger medizinischer Bilder. Ich bin auch bereit, dabei zu helfen, dass dieser Pull-Request erfolgreich ist.

Die aktuelle Three.js-Webgl2-Sandbox funktioniert nicht :( https://threejs.org/examples/webgl2_sandbox.html
Könnte ein Problem beim Build der Version three.js sein?

Wenn online <script type="module"> schon implementiert wäre...
https://groups.google.com/a/chromium.org/d/msg/blink-dev/uba6pMr-jec/tXdg6YYPBAAJ

Zumindest arbeitet Mozilla daran https://bugzilla.mozilla.org/show_bug.cgi?id=1240072

@mrdoob , Bedeutet dies, dass wir erwarten können, dass die Three.js-API die Vorteile von <script type="module"> nutzt, wenn sie auf WebGL 2.0 aktualisiert wird? ;)

Übrigens denke ich, dass es in der Zwischenzeit am einfachsten ist, einfach WebGL 2.0-Unterstützung zu WebGLRenderer hinzuzufügen. Ich denke, dass dies eine schrittweise Einführung ermöglichen würde, und wir können eine Funktionserkennung durchführen, um zu sehen, ob wir WebGL 2-Funktionen verwenden können. Ich glaube nicht, dass es das Schwierigste ist. Ich weiß, dass es im Gegensatz zu einem reinen WebGL 2-Renderer zu etwas Komplexität führt, aber es ist kurz- und mittelfristig der einfachste Weg. Und wir entwickeln uns langsam dahin, wo wir WebGL 1 schließlich hinter uns lassen, sobald WebGL 2 eine Verbreitung von über 90 % erreicht hat.

Khronos hatte gerade ein Webinar zu webgl2:
https://docs.google.com/presentation/d/11-mTDNmSJzJnRVGu9Vu6AUzOt34yV3PO7oqw4E5wc2o/edit#slide =id.gd15060520_0_38
Die Medien werden in Kürze veröffentlicht, aber die Präsentation bestand hauptsächlich aus Voice-Over der Folien und zugehörigen Demos in den Folien.

Es ist ziemlich klar, dass dies einen Neuanfang erfordert, nicht eine "Aktualisierung" des bestehenden WebGLRenderer.

In Bezug auf es6-Module denke ich, dass der aktuelle Ansatz, bei dem die Quelle es6-Module sind, dann die Verwendung von Rollup für ein Bundle immer noch der Weg ist, einen "dual Build" zu unterstützen.

Ich mache das jetzt seit etwa einer Woche und teste Module auf Safari Tech Preview und das Bundle auf allen Browsern. Führt wirklich dazu, dass sowohl der Quellbaum als auch das aktuelle Bundle erstellt / vorhanden sind. Einzeiliges Rollup, wie Sie es derzeit haben, und eine Kopie des Quellbaums für die Modulverwendung.

@bhouston verlockend...

Letzter Status?

Ich habe da irgendwie gemischte Gefühle. Anfangs dachte ich über den gleichen Weg nach, den @bhouston vorgeschlagen hatte, und fügte schrittweise webgl2-Funktionen zum aktuellen WebGLRenderer hinzu. Aber das würde den Renderer komplexer und schwieriger zu handhaben machen mit Funktionen, die sich zwischen den beiden Versionen am meisten unterscheiden, was zu einem unordentlichen Code voller Verzweigungen und Bedingungsprüfungen führen würde.
Eine Option könnte darin bestehen, WebGLRenderer als Ausgangspunkt für WebGL2Renderer zu klonen und weiterhin Funktionen zu entfernen/hinzuzufügen, ohne den ursprünglichen Renderer zu verändern.
Wenn wir uns Engines wie Playcanvas ansehen, die wahrscheinlich diejenige mit der frühesten webgl2-Unterstützung ist, können wir sehen, dass sie nicht einmal die Vorteile der neuen webgl2-Funktionen wie UBO oder VAO nutzt, weil es etwas ist, das sich ändern wird viele Teile des Motors.

Ich bin der festen Überzeugung, dass wir, wenn wir versuchen, beide Versionen auf demselben Renderer zu mischen, mit einem schwieriger zu wartenden Code enden werden, und sobald webgl2 volle Unterstützung erhält, müssen wir dies sowieso umgestalten, wie ich denke, wir werden es sein gezwungen, einem Design zu folgen, um diese Kompatibilität beizubehalten, anstatt es mit Blick auf webgl2 von Grund auf neu zu entwerfen.

Meine Stimme ist also, WebGL2Renderer ganz von vorne anzufangen, auch wenn wir langsam vorgehen (wir haben immer noch Raum für Verbesserungen, bis webgl2 nahezu 100% unterstützt wird).

Einige andere Dateien als nur der Renderer selbst müssen modifiziert werden, zum Beispiel Texturen, Programme und so weiter. Sollten wir einen Unterordner renderer\webgl2 erstellen und weiterhin die Dateien hinzufügen, die speziell für diesen Renderer erstellt werden?

Wir könnten ein Problem mit der Liste der Änderungen erstellen, die wir vornehmen sollten, um einen voll kompatiblen Webgl2-Renderer zu haben, um sie beim Schreiben des Renderers im Hinterkopf zu behalten, und auch eine Liste der Funktionen erstellen, die wir für MVP haben möchten, um unsere Bemühungen auf die Diskussion zu konzentrieren diese in diesem Ausgangszustand, um ein tieferes Gespräch über die Umsetzung anzustoßen.

Irgendwelche Updates zu seiner Entwicklung?

Noch nicht. Ich habe WebVR diesen Monat Priorität gegeben.

Ich habe eine Quick'n'dirty-Inplace-Konvertierung in die WebGL2- und ES3-Shader-Sprache versucht, wie oben von @fernandojsg vorgeschlagen. Hier ist das gequetschte Diff: https://github.com/tstanev/three.js/compare/master...tstanev :traian/webgl2 Eigentlich sieht es gar nicht so schlecht aus, wie ich anfangs erwartet hatte. Es sieht fast so aus, als wäre es nicht super hässlich, beides über einige strategisch platzierte ifdefs zu unterstützen.
[Bearbeiten: Link aktualisiert.]

@tstanev Hast du ein funktionierendes Beispiel?

Die gebündelten three.js-Beispiele im verlinkten Zweig funktionieren (wie Sie im Diff sehen können, habe ich diejenigen konvertiert, die zuvor Erweiterungen erforderten). Sie können das Repo/den Zweig klonen und lokal ausführen.

@tstanev Wie wäre es mit einem Leistungsvergleich für webgl2-Änderungen online?) Wäre schön, es zu sehen. (three.js vs. three.js auf webgl2)

Hallo
danke für diese beste idee.
Ich möchte webgl2renderer in meinem Programm verwenden, aber ich konnte es nicht in der vorkompilierten Version (r86) verwenden, also bekomme ich die Quelle und entkommentiere den webgl2rendrer in three.js, importiere und erstelle es dann.
Jetzt laufen mein Code und Ihr Beispiel (webgl2-Sandbox) ohne Fehler, aber sie zeigen nichts

EDIT: Ich hatte sie in Firefox 54 und Chrome 60 getestet
mein Beispiel mit BufferGeometry und ShaderMaterial und wird in webglrenderer korrekt funktionieren

keiner antwortet mir? wo ist jetzt das problem von webgl2renderer?

@ MHA15 vermutlich ist es nicht im Build enthalten, da es noch nicht produktionsreif ist.

Hey Leute, wie läuft die WebGL2Renderer-Entwicklung?
Ich weiß, dass die Entscheidung getroffen wurde, es von Grund auf neu zu erstellen. Aber es ist schon eine Weile her und die Entwicklung zu diesem Thema ist ziemlich langsam, da es meiner Meinung nach eine Menge Arbeit ist, es neu zu erstellen.

Können wir an dieser Stelle überdenken, einen Klon von WebGLRenderer zu erstellen und ihn stattdessen in WebGL2 umzuwandeln, wie es @mattdesl in https://github.com/mrdoob/three.js/issues/8125 getan hat? Wir können dann den Renderer basierend auf einigen neuen Funktionen wie UBO modifizieren, wie @fernandojsg sagte. Irgendwann werden wir all diese alten Webgl-1-Codes entfernen.

Die Erstellung des Renderers von Grund auf erfordert meiner Meinung nach einen enormen Arbeitsaufwand und kann im Idealfall nur mit wenigen Mitwirkenden beginnen. Dieses Gespräch wurde vor einem Jahr begonnen. Und wenn wir nicht an den Punkt kommen, an dem wir einen Retter haben, der ein paar Monate Vollzeit damit verbringen würde, es von Grund auf neu zu bauen, glaube ich, dass wir nächstes Jahr wahrscheinlich auf der gleichen Seite stehen werden.

Die Erstellung des Renderers von Grund auf erfordert meiner Meinung nach einen enormen Arbeitsaufwand und kann im Idealfall nur mit wenigen Mitwirkenden beginnen.

Dass es wahr ist. Aber selbst dann denke ich, dass das einfacher ist, als WebGLRenderer schwieriger zu pflegen zu machen, indem man überall Bedingungen hinzufügt. Ich habe die meisten meiner letzten 5 Jahre damit verbracht, WebGLRenderer lesbarer und pflegeleichter zu machen.

Außerdem denke ich, dass @fernandojsg vorhatte, es in den kommenden Wochen auszuprobieren.

Das ist großartig. Wir freuen uns auf großartige Arbeit von @fernandojsg!!

PS Ich muss sagen... Ich danke allen Mitwirkenden dieses Projekts für die Erweiterung meines Horizonts der Computergrafik. Ich hoffe, dass ich in Zukunft einige Beispiele beisteuern kann.

Ich stimme @mrdoob zu, dass es einfacher ist, einen neuen Renderer von Grund auf neu zu erstellen, als den aktuellen zu ändern.
Wie er sagte, wollte ich es in den folgenden Wochen versuchen. Meine Herangehensweise besteht darin, damit zu beginnen, genau das zu erstellen, was für eine einfache Box auf dem Bildschirm benötigt wird, und Schritt für Schritt Funktionen hinzuzufügen, anstatt das zu nehmen, was bereits vorhanden ist, und zu versuchen, es umzugestalten.
Als Beispiel werfen Sie einen Blick auf den aktuellen Stand von WebGLRenderer , es gab viele Diskussionen darüber, es modularer und anpassbarer zu machen, aber selbst wenn sich der interne Code im Laufe der Zeit immer weiter verbessert, bleibt es draußen nur eine Blackbox.
Sobald etwas funktioniert, eröffne ich eine PR, damit wir dort die nächsten Schritte weiter besprechen können.

Wo wir gerade dabei sind... 5f889ce296aaf447ec5992a6df726691098a9110 8aab6e0382cd6ba8fd3fb943e7f65141bf3a50bc
webgl2_sandbox funktioniert wieder (erfordert jedoch es6-Module).

@mrdoob hast du eine grobe Schätzung, wann es im Master/Release verfügbar sein wird? :) Ich bin froh, dass es passiert! :)

@wdanilo Nicht wirklich ... Welche Funktionen von WebGL2 benötigen Sie?

@mrdoob Die größten Verbesserungen würden von den Uniform Buffer Objects und dem Sampler2DArray kommen. Das Texturarray wäre für mein aktuelles Projekt von großem Vorteil, da wir an Grenzen für Textureinheiten stoßen, da ich einen komplexen Shader verwende, der mehrere durch Alpha-Maps maskierte Materialien überlagert.

@mrdoob Neue Schlüsselwörter wie flat in glsl wären auch sehr hilfreich.

Mein Projekt benötigt 3D-Texturen.

Interessant...
Super hilfreich, um sich der spezifischen Fälle bewusst zu sein, für die die Leute WebGL 2.0 benötigen.
Lass sie kommen!

3D-Texturen sind auch das große Feature für uns. Ich denke, wir verwenden auch einige Shader-Funktionen.

Manchmal möchte ich MRT

+1 auch für mehrere Renderziele

Mehrere Renderziele werden bereits in WebGL1 über eine Erweiterung unterstützt, und es gibt sogar eine PR dafür in ThreeJS: https://github.com/mrdoob/three.js/pull/9358 ( Demo ).

Ich denke, Multisample-Renderziele sind meine Lieblingsfunktion. Die meisten Kunden fordern eine Nachbearbeitung (Bloom, LUTs usw.), sind jedoch enttäuscht über das Fehlen eines angemessenen Anti-Aliasing, sobald die Post-FX implementiert sind. Mit MSAA-Renderzielen können wir endlich eine schön geglättete _und_ nachbearbeitete Szene haben.

Ich stimme zu. Workaround-Shader für Anti-Aliasing in nachbearbeiteten Szenen mit Effects Composer reichen für echtes Anti-Aliasing nicht aus.

+1 für Draw-Feedback. Oder wird es bereits als webgl1-Erweiterung in unterstützt
drei?

Am Donnerstag, den 14. Dezember 2017 um 21:45 Uhr schrieb Kyle [email protected] :

Ich stimme zu. Workaround-Shader für Anti-Aliasing in nachbearbeiteten Szenen
mit Effects Composer reichen für echtes Anti-Aliasing nicht aus.

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/mrdoob/three.js/issues/9965#issuecomment-351815640 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AHTX1RhYdGuTVSpmOy1ka-6gy1eslHQAks5tAXrFgaJpZM4Kj_9l
.

Ich habe hier ein paar Anwendungsfälle:

1. Ich brauche MRT - derzeit rendere ich denselben Shader 4 oder 5 Mal und ändere ein Attribut, nur um unterschiedliche Puffer zu erhalten.
2. Das Rendering in Textur mit Antialiasing ist für uns ein wichtiges Feature - wir machen einen "Knoten-Editor" mit Visualisierungsvorschau. Jede Visualisierung ist nur eine Textur, wir zeichnen auch etwas, und kein richtiges Antialiasing ist hier ein Problem.
3. Das Schlüsselwort "flat" - ich indiziere jetzt Geometrie mit einem Float-Attribut, was offensichtlich suboptimal ist - schlimmer als die Indizierung mit uint one. Ich übergebe dieses Attribut vom Scheitelpunkt an den Fragment-Shader und kann uint jetzt nicht verwenden, da uns die Unterstützung von "flachem" kwrd fehlt.
4. (kleinere) 3D-Texturen eignen sich hervorragend für High-End-Visualisierungen, die wir in naher Zukunft unterstützen möchten.

Der gemeinsame Einsatz von Anti-Aliasing und Post-Processing ist für mich das Wichtigste.

@mrdoob Meine Top 3 WebGL 2 Funktionen/Anwendungsfälle (in der Reihenfolge ihrer Wichtigkeit):

1. Multisampled Render Targets: Für eine korrekte (MS)AA in der Nachbearbeitung.
2. Ganzzahlige Texturen: Zur Durchführung bildbasierter Algorithmen wie Signed Distance Fields sowie zur Verwendung exotischerer texturbasierter Daten wie DEM (Digital Elevation Models).
3. Transformations-Feedback: Zum Ausführen von Partikelsystemen.

@mrdoob weißt du übrigens, warum #9358 PR nicht zusammengeführt wurde? Wie @mattalat geschrieben hat, bringt es Multitarget-Rendering zu threejs. Wurde vor 2 Jahren begangen, mehrmals behoben, um mit anderen Änderungen auf dem Laufenden zu bleiben, und bis jetzt ist es nicht da :(

Ich frage danach, weil ich eine Szene habe, die stark SDF-Formbeschreibungen verwendet. Jede Form gibt 6 verschiedene Ausgaben aus, also berechne ich sie jetzt 6 Mal, indem ich zu den Shader-Nummern von 0 bis 5 übergehe. Es wäre viel schöner, mehrere Ausgaben zu verwenden, und es bringt einfach eine 5-fache Leistungssteigerung.

@wdanilo Es war wahrscheinlich nicht der richtige Zeitpunkt (viele bewegende Dinge im Renderer damals). Außerdem scheint es die Builds enthalten zu haben, die leicht Konflikte verursachen. Jemand Lust auf eine neue PR?

/cc @edankwan

Wir brauchen 3D-Texturen und Multisample-Renderziele.

Ich möchte es verwenden, damit ich DepthTexture.type = THREE.FloatType festlegen kann. Es sei denn, es gibt derzeit eine andere Möglichkeit, so etwas zu tun.

Gibt es eine Hoffnung, dass LineThickness anders als 1 unter Windows und WebGL 2.0 funktioniert? Wenn ja, würde es einige unserer Ergebnisse verbessern.

Und hier antworte ich mir selbst. Beim Lesen von Strichstärken-mit-drei-Zeilen-Basismaterial auf SO habe ich verstanden, dass dicke Linien in Zukunft sowieso eine Geometrie benötigen werden.

@Richard004 Das hat nichts mit WebGL 2 zu tun. Wir haben bereits eine PR für diese Funktionsanfrage, siehe #11349 👍

Hallo @mrdoob und @Mugen87
Ich brauche Bit-Manipulationen innerhalb des Fragment-Shaders sowie eine dynamische Array-Indizierung. Der erste ist wahrscheinlich nicht sehr verbreitet, aber ich brauche ihn trotzdem, weil ich versuche, einen CUDA-Kernel auf WebGL (GLSL) zu portieren, und andere Shader-Sprachen erlauben Bit-Manipulationen, WebGL 1.0 (GLSL) jedoch nicht.

Von der zweiten, denke ich, könnten viele Entwickler profitieren: nämlich der Zugriff auf ein Array-Element mit einer Variablen. Derzeit wird in WebGL 1.0 (GLSL) ein Programm wie dieses fehlschlagen:

int myData[200];
int x = 3; // 'x' might change later based on my lookup needs
int requestedData = myData[x];

In WebGL 2.0 ist dies jedoch möglich. Es wird oft innerhalb einer Schleife benötigt, wo Sie verschiedene Werte aus einem Array erhalten müssen, aber Sie können nicht einfach eine iterative Schleife ausführen (z. B. 0 bis 199 im obigen Beispiel), da Sie dann jeden einzelnen überprüfen müssten Element und das ist wirklich langsam.

Antialiasing im Postprocessing wäre auf jeden Fall von Vorteil.

Unter all dem steht die Frage: Ist es Zeit für eine neue Architektur für Drei?

Ich habe vor kurzem angefangen, D3, Version 4, zu verwenden. Es war ein komplettes Redesign. Es6
Module. Und viel wichtiger, 30 Module, jedes für sich
Repo. Ich empfehle wirklich, sich die D3-Architektur anzusehen.

Ich sage nicht, dass wir das für Three brauchen, aber ich denke, wir könnten eins in Betracht ziehen
Hauptversionsstoß. Teilweise wegen webgl2. Aber auch aus Bedarf
Untermodule.

Ein Beispiel: Es gibt ein D3 „selections“ Repo/Sub-Modul. Es ist deine Basis
jQuery-DOM-Modul, aber mit der ganzen Ausführlichkeit des DOM, das in einem versteckt ist
funktionales, verkettetes Design. Es kann unverändert verwendet werden, ohne den Rest von zu verwenden
D3.

Würden Sie nicht ein drei unabhängiges Modul lieben, das alle Webgl gemacht hat?
Ausführlichkeit verschwinden? Vielleicht sogar mehrere Untermodule für webgl ctx/shader
Verwaltung, Pufferverwaltung und so weiter. Tatsächlich ist die Puffergeometrie a
viel so. Dasselbe gilt für die Shader-Erstellung aus Teilen.

Nur ein Gedanke.

@ fetox74 Ziemlich sicher, dass du AA bereits machen kannst https://threejs.org/examples/?q=fxaa#webgl_postprocessing_fxaa

@elunty der FXAAShader liefert im Vergleich zum ursprünglichen Antialiasing kein ausreichend gutes Ergebnis, ich habe es in freier Wildbahn verwendet.

Ich interessiere mich hauptsächlich für VAOs und das Schreiben in Mipmaps, von denen ich hoffe, dass sie unter dieser Spezifikation möglich sind.

@pailhead Verwandte #8705 :wink:

Wir freuen uns auf die native Unterstützung für EXT_shader_texture_lod .
Es kann die Artefakte auflösen, die bei der Verwendung MeshStandardMaterial und MeshPhysicalMaterial auf den meisten Android-Geräten und MS Edge und Internet Explorer generiert werden

@mrdoob , gibt es Pläne von Ihnen oder Ihrem Team, Threejs auf Webgl 2.0 zu aktualisieren? Dieser Thread dauert buchstäblich Jahre und nichts ändert sich wirklich, während alle anderen Frameworks bereits Fortschritte gemacht haben. Ich stehe bald vor einer schweren Entscheidung, wir müssten wahrscheinlich über Babylon auswandern oder so und ich würde wirklich gerne bei Three bleiben. Ich werde, falls es welche geben würde, einfach irgendwelche Pläne für ihre Modernisierung machen.

@wdanilo Wenn WebGL 2.0 für Ihr Projekt Priorität hat, würde ich Ihnen empfehlen, zu Babylon zu migrieren. Ich weiß, dass einige Mitwirkende an three.js planen, daran zu arbeiten, aber ich persönlich konzentriere mich auf WebVR und Künstler-Workflows (SVG-Unterstützung usw.).

@mrdoob Ich schätze Ihre schnelle Antwort hier sehr. Ich möchte Three.js wirklich nicht aufgeben. Mir gefällt, wie die Lib unter der Haube konstruiert ist und ihre Annahmen als "allgemeines" Framework, nicht "spielorientiert" usw. sind. Wie auch immer, danke für die Informationen und die Klarstellung.

(Nochmals vielen Dank @takahirox , dieser Thread war mir bekannt). Ich habe gerade einen Pull-Request #13692 gestellt. Ich verstehe, dass der Fokus nicht darauf liegt, aber für unsere Zwecke hat es gut funktioniert.

Zugehörige #13702

Ich habe den WebGL2-Basiszweig nach #9965 und #12250 erstellt

Repository: https://github.com/takahirox/three.js/tree/WebGL2Base
Beispiele: https://rawgit.com/takahirox/three.js/WebGL2Base/examples/index.html

Sie können damit WebGL2.0 + Three.js starten.

(Tut mir leid, Konflikte mit der Arbeit von @yoshikiohshima )

@mrdoob Können wir einen Zweig für WebGL2Renderer wie three.js/dev-2.0 haben? Oder können wir es in dev zusammenführen, obwohl es immer noch viele doppelte Codes zwischen für webgl1 und für webgl2 gibt?

Ich bin neu in der vergangenen Entwicklung zu diesem Thema. @takahirox , kannst du die Strategie zusammenfassen, die du verwendest und was von https://github.com/takahirox/three.js/tree/WebGL2Base unterstützt wird? (und noch einmal Entschuldigung für meine Unwissenheit), aber ich sah keine Notwendigkeit für viel duplizierten Code, um WebGL2 zu unterstützen. Was sind die Probleme?

@mrdoob Können wir einen Zweig für WebGL2Renderer wie three.js/dev-2.0 haben? Oder können wir es in dev zusammenführen, obwohl es immer noch viele doppelte Codes zwischen für webgl1 und für webgl2 gibt?

Ich bin mir nicht sicher, warum dies einen neuen Zweig benötigen würde. Warum sollte es doppelten Code geben?

Scheint keine Konflikte zu haben. Es gibt jetzt zwei Anforderungen für WebGL2.0.

1. WebGL2Renderer erstellen, um alle WebGL2.0-Funktionen zu unterstützen und gut zu optimieren
2. Hinzufügen webgl2 Unterstützung zu bestehender WebGLRenderer . Aber wir unterstützen WebGL2.0-Funktionen darauf nicht vollständig und optimieren nicht für WebGL2.0, weil wir den Renderer nicht durcheinander bringen wollen. Also im Grunde nur für den frühen Zugriff auf Three.js + WebGL2.0 + GLSL3.0

Meine ist für 1. Seine Arbeit ist für 2. Wir haben keinen doppelten Code und müssen keinen neuen Zweig für 2 erstellen.

@takahirox Ich denke, es wäre vorerst besser, in der gleichen Branche zu arbeiten.

Wenn du dich verbesserst...

https://github.com/mrdoob/three.js/blob/dev/src/renderers/WebGL2Renderer.js

und die webgl2 Beispiele importieren Klassen direkt (benötigen keine Builds) ...

https://github.com/mrdoob/three.js/blob/dev/examples/webgl2_sandbox.html#L39 -L47

Konflikte sollte es nicht geben.

Sie können mein bisheriges WebGL2Base vergessen, weil es scheint, dass wir die WebGL2.0-Unterstützung in einem WebGLRenderer starten.

Denken wir immer noch darüber nach, einen WebGL2Renderer zu implementieren?
Ich habe in letzter Zeit viel nach WebGL2-Unterstützung gesucht, und ich warte auf Takahirox-Änderungen, um meine neu zu starten. Aber nachdem ich einige Änderungen vorgenommen hatte, begann ich zu denken, dass es eine wirklich gute Idee wäre, den Renderer sowie das WebGLTextures-Objekt neu zu schreiben. Wenn es noch aktuell ist, nehme ich gerne teil.

Ich denke schon. Ich denke, das Hinzufügen von grundlegender Webgl 2.0-Unterstützung zum aktuellen WebGLRenderer dient nur dazu, etwas zu haben, während wir an WebGL2Renderer arbeiten.

Fühlen Sie sich frei, den Renderer neu zu schreiben und PRs zu senden (idealerweise Schritt für Schritt).

Entschuldigung, wenn ich das Offensichtliche frage, aber nachdem ich diese ganze Ausgabe gelesen habe, wobei der letzte Post ein halbes Jahr zurückliegt, und ein paar Verweise auf webgl2 sowohl im Master-Quellcode als auch in den Beispielen gefunden habe, kann ich es immer noch nicht ganz verstehen .

Frage mich, ob webgl2 in seinem aktuellen Zustand in Three.js verwendbar ist? (auch wenn nur einfache Puffergeometrienetze gerendert werden) Würde der EffectComposer mit einem Webgl2-kontextfähigen Renderer funktionieren? Müsste das Renderziel in irgendeiner Weise angepasst werden?

Die größte Frage ist natürlich, ob es derzeit möglich ist, ein angemessenes Antialiasing zu erhalten, wenn Composer mit benutzerdefinierten Passes verwendet wird?

Es scheint, als hätten wir am Ende gerade WebGL 2.0-Funktionen zu WebGLRenderer hinzugefügt.
WebGPU wird jedoch sicher ein WebGPURenderer benötigen.