Three.js: WebGPUベースのレンダラーはありますか？

理論的には遠い将来ですが、ご存知かもしれませんが、WebGPUグループは、最初の提案/仕様/ドラフトの作成について、まだ活発に話し合っています。 完全な仕様と実用的な標準化された実装ができるまでには何年もかかるでしょう。

それは私がここでWebGPU開発に参加/フォローすることをお勧めします： https ： https://www.w3.org/community/gpu/

WebGPUが私たち全員が望むほど強力であることが判明した場合、Three.jsのようなライブラリを最大限に活用するには、最初から書き直す必要があります。

@TimvanScherpenzeel
はい私は同意する。 私は遠い未来になります。
コアを最初から書き直さずにthree.jsにWebGPUレンダラーを追加することは不可能ですか？ エンジン（API）全体をthreejsで最初から書き直す必要がありますか？ WebGPUが出ても、しばらくは共存（WebGL / WebGPU）する可能性が高いと思います。 WebGPUがすべてのWebGLエコシステムを殺すとは思いません。
ただし、WebGLがグラフィックドライバの間接APIであるのとは異なり、WebGPUがネイティブに直接サポートされている場合、WebGPUは非常に強力であると思います。そして、Googleや他の大手企業は、ブラウザでのディープラーニングのパフォーマンスと高性能のグラフィックエクスペリエンスを向上させるためにそれを望んでいます

ThreeJSには、すでに多くの異なるレンダラーがあります– WebGLRenderer、WebGL2Renderer、CSS3DRenderer、SVGRenderer ... APIの準備ができたら、WebGPUも同様に処理できます。 ライブラリへのより深い変更も時間の経過とともに可能です。

これらの次世代APIも利用できるようになることを楽しみにしていますが、今のところこの問題を閉じます。 :)

@donmccurdy
確かに..Three.jsは非常に柔軟性が高いので、将来的にはWebGPUも実装できますよね？

WebGPUの提案によると、彼らは主なターゲットオーディエンスの1つとしてThree.jsデバーロッパーについて言及しました。

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

GPUライブラリを構築しているJavaScriptフレームワーク開発者。Webコンテンツでの使用を目的としていますが、高レベルのAPIを提供し、低レベルのグラフィックスの多くを非表示にして、ユーザーから詳細を計算します。 たとえば、three.jsです。

私の質問は、WHLSLと呼ばれる別のシェーダー言語を使用しているということです。
https://github.com/gpuweb/WHLSL

私の質問は、WHLSLと呼ばれる別のシェーダー言語を使用しているということです。

「その橋にたどり着いたら、その橋を渡ります。」

@ Google I / Oで発表され、Chrome Canary forOSXで実験的なサポートが利用可能になりました。
https://www.youtube.com/watch?v=K2JzIUIHIhc

Babylon.jsは、リリース時に完全なサポートを発表しました。 ここでそれをチェックしてください：
https://forum.babylonjs.com/t/webgpu-is-coming-to-babylon-js/3122

ThreeJSチームが先導してくれることを願っています。

潜在的なサポートについて言及されたため、なぜこれを閉じるのかわかりません。 論理的には、問題を「追跡」するためにオープンのままにしました。 あなたがそれを閉じるならば、あなたはただそれを追跡する他の問題がない限り...忘れます。

私たちはそれを忘れないことを保証することができます...😁

しかし、私はメンテナーではありません。 個人的には、webgpuを採用した最初のフレームワークに従います。 そして、要点は私ではありません。 これを締めくくるメッセージです。 それは「かっこいいこと、確かなことですが、私は気にしません。それはそこにとどまることができます」のようなものです。

PS。 読み間違えたので「忘れないこと間違いなし」だと思いました

@MichelDizこの問題は、WebGPUをサポートする予定があるかどうかを尋ねるために開かれました。 質問は答えられました：私たちは絶対にWebGPUをサポートする予定です。 おそらく今は時期尚早ですが、これについて話し合う準備ができたら、新しい問題が開かれるでしょう。

@TimvanScherpenzeelユーザーから抽象化された特定の部分は書き直す必要がありますが、全体を「最初から書き直す」必要があることを示唆することは、大げさな誇張です。 バッファジオメトリは同じ形式になります。 WebGLと同様に、WebGPUもシェーダーGLSL-> WHLSLに基づいています。 WebGL標準となったglTFフォーマットもWebGPU標準になるようです。 最もよく使用されるすべてのThree.jsAPIは99％変更されませんが、新しいWebGPUレンダラーは内部で機能し、パフォーマンスが大幅に向上し、大きなシーンを高fpsでレンダリングする可能性が広がります。

こんにちは、みんな、
これの更新に感謝します！
このような機能についての私の見解を共有したかっただけです。 私たちの場合、コンシューマーアプリケーションに常にWebGLを使用するとは限りません。 アセットが最大1GBで、ブラウザとそのフラグを制御してWebGPUを有効にできる固定ハードウェアでローカルに提供される、非常に大きなデータセットを視覚化するWebGLエクスペリエンスがあります。 したがって、実験モードであっても、それをサポートしたいと思うことは間違いありません。 私たちは少数派であることを理解していますが、会話にこのビューを追加したかっただけです。

@sinokgr WebGPUは1GBのアセットの表示にどのように役立ちますか？ 私が理解している限り、ジオメトリデータのデータ構造はWebGLと同じです。

返信@mrdoobをありがとう。 100％正直に言うと、違いを十分に理解しているとは言えません。オンラインで見つけた情報は非常にあいまいです（とにかく私の調査によると）。 私が得ている主な感覚は、あなたが好きだった@DVLPからの最後のメッセージのように私が読んだものからです、

パフォーマンスが大幅に向上し、大きなシーンを高fpsでレンダリングする可能性が広がります。

少なくともいくつかの改善が見られると思います。 これは、たとえばこれらのアセットの読み込み速度、おそらくより良いfpsでしょうか？ よく分かりません。

通常のメモリへの初期ロードは同じままですが、GPU API全体が高速になるため、GPUが関与した瞬間から高速になるはずです。 パフォーマンスの向上がどこから来るのかを確認する方法は次のとおりです。

1. モデルファイルをブラウザにロードします-同じ速度
2. モデルを解析し、ジオメトリを配列バッファにロードします-同じ速度
3. GPUプログラムのロード-より高速
4. テクスチャをロードする-最初は同じ速度ですが、GPUに渡すとより速くなります
5. ジオメトリをGPUに転送-より高速
6. 一連の描画呼び出しを行ってフレームをレンダリングします-より高速

@DVLPの説明に感謝します。 ポイント5と6は、たくさんの素材を使った何千ものオブジェクトがあるので、私には非常に興味深いと思います。

WebGPUが広く採用されるまでには長い時間がかかるかもしれません。 それまでは、メッシュインスタンス化を使用して全体をスピードアップできます
https://threejs.org/docs/#api/en/objects/InstancedMesh

インスタンス化を使用できないのではないかと思います。すべてのオブジェクトは一意です@DVLP

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