Three.js: Y aura-t-il un moteur de rendu basé sur WebGPU?

Théoriquement dans un futur lointain, mais comme vous le savez peut-être, le groupe WebGPU est toujours en train de parler / s'aligner activement sur la formation des premières propositions / spécifications / ébauches. Il faudra des années avant que nous ayons une spécification complète et des implémentations normalisées fonctionnelles.

Cela dit, je recommanderais de m'impliquer / suivre dans le développement WebGPU ici: https://github.com/gpuweb/gpuweb/wiki et https://www.w3.org/community/gpu/

Si WebGPU s'avère aussi puissant que nous l'espérons tous, ce sont des bibliothèques comme Three.js qui devront probablement être réécrites à partir de zéro afin d'en tirer pleinement parti.

@TimvanScherpenzeel
Oui je suis d'accord. Je serai le futur lointain.
Est-il impossible d'ajouter un moteur de rendu WebGPU dans three.js sans réécrire le noyau à partir de zéro? Devrions-nous avoir à réécrire tout le moteur (API) en threejs à partir de zéro? Je pense que même si WebGPU sortait, il serait très probable qu'il coexiste ensemble (WebGL / WebGPU) pendant un certain temps. Je ne pense pas que WebGPU tuerait tout l'écosystème WebGL.
Cependant, je suppose que WebGPU serait très puissant s'il prend en charge nativement et directement contrairement à ce que WebGL est une API indirecte de pilote graphique;Et Google et d'autres grands acteurs le souhaitent pour de meilleures performances DeepLearning et une expérience graphique haute performance dans le navigateur.

ThreeJS a déjà de nombreux moteurs de rendu différents - WebGLRenderer, WebGL2Renderer, CSS3DRenderer, SVGRenderer ... WebGPU peut être géré de la même manière, lorsque l'API est prête. Des modifications plus profondes de la bibliothèque sont également possibles avec le temps.

Clôture de ce problème pour le moment, même si je suis ravi que ces API de nouvelle génération soient également disponibles. :)

@donmccurdy
En effet .. Three.js est si flexible qu'il peut même implémenter WebGPU à l'avenir, non?

Selon la proposition WebGPU, ils ont mentionné les développeurs de Three.js comme l'un de leurs principaux publics cibles.

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

Développeurs de framework JavaScript qui créent des bibliothèques GPU, destinées à être utilisées dans le contenu Web, mais fournissant une API de niveau supérieur et cachant une grande partie des graphiques de bas niveau et des détails de calcul à leurs utilisateurs. Par exemple, three.js.

Ma question est qu'ils utilisent un autre langage de shader appelé WHLSL.
https://github.com/gpuweb/WHLSL

Ma question est qu'ils utilisent un autre langage de shader appelé WHLSL.

"Nous traverserons ce pont quand nous y arriverons."

A été annoncé @ Google I / O avec prise en charge expérimentale de Chrome Canary pour OSX disponible maintenant:
https://www.youtube.com/watch?v=K2JzIUIHIhc

Babylon.js a annoncé une prise en charge complète lors de sa sortie. Vérifiez le ici:
https://forum.babylonjs.com/t/webgpu-is-coming-to-babylon-js/3122

J'espère que l'équipe ThreeJS suivra l'exemple.

Je ne sais pas pourquoi fermer cela car il a été mentionné le soutien potentiel. Par logique, nous avons laissé des problèmes ouverts pour le «suivre». Si vous le fermez, vous oubliez simplement ... sauf s'il y a un autre problème pour le suivre.

Je peux vous assurer que nous ne l'oublierons pas ... 😁

Mais je ne suis pas un mainteneur. Personnellement, je suivrai le premier framework qui adopte webgpu. Et ce n'est pas moi. Est-ce que le message que vous donnez ferme ceci. C'est comme "Chose cool, certes, mais je m'en fiche. Ça peut tenir là dans les limbes".

PS. Je l'ai mal lu, je pensais que c'était "Je peux vous assurer que vous ne l'oublierez pas"

@MichelDiz ce numéro a été ouvert pour demander si nous prévoyons de prendre en charge WebGPU. La question a été répondue: nous prévoyons absolument de soutenir WebGPU. Il est probablement trop tôt pour y travailler, mais de nouvelles questions seront ouvertes lorsque nous serons prêts à en discuter.

@TimvanScherpenzeel certaines parties qui sont abstraites des utilisateurs devront être réécrites mais suggérer que le tout devra être "réécrit à partir de zéro" est une exagération massive. Les géométries des tampons auront le même format. Tout comme WebGL, WebGPU est également basé sur des shaders GLSL -> WHLSL. Il semble que le format glTF qui est devenu le standard WebGL sera également le standard WebGPU. Toutes les API Three.js les plus utilisées resteront inchangées à 99% tandis que le nouveau moteur de rendu WebGPU sera sous le capot et, espérons-le, améliorera considérablement les performances et débloquera un potentiel de rendu de grandes scènes à des fps élevés.

Salut à tous,
merci beaucoup pour les mises à jour sur celui-ci!
Je voulais juste partager mon point de vue sur des fonctionnalités comme celle-ci. Dans notre cas, nous n'utilisons pas toujours WebGL pour les applications grand public. Nous avons des expériences WebGL dans lesquelles nous visualisons de très gros ensembles de données où les actifs font ~ 1 Go et sont servis localement sur du matériel fixe où nous pouvons contrôler les navigateurs et ses indicateurs pour activer WebGPU. Donc, même en mode expérimental, nous pourrions certainement aimer avoir du soutien pour cela. Je comprends que nous sommes la minorité, mais je voulais simplement ajouter ce point de vue dans la conversation.

@sinokgr Comment WebGPU aide-t-il à afficher les ressources de 1 Go? Autant que je sache, les structures de données pour les données de géométrie sont les mêmes que WebGL.

merci pour la réponse @mrdoob . Pour être honnête à 100%, je ne prétendrai pas comprendre suffisamment les différences et les informations que je trouve en ligne sont très vagues (d'après mes recherches en tout cas). Le sentiment principal que je ressens vient de ce que j'ai lu comme le dernier message de @DVLP que vous avez aimé,

apportera une grande amélioration des performances et débloquera un potentiel de rendu de grandes scènes à des fps élevés.

cela me fait penser que nous allons voir au moins quelques améliorations. Cela pourrait être, à quelle vitesse, par exemple, ces actifs se chargeront, peut-être de meilleurs fps? Je ne suis pas sûr.

Le chargement initial dans la mémoire normale restera le même mais l'ensemble de l'API GPU sera plus rapide, donc à partir du moment où le GPU est impliqué, il devrait être plus rapide. Voici comment je vois d'où viendra l'augmentation des performances:

1. Charger le fichier de modèle dans le navigateur - même vitesse
2. Analyser le modèle et charger la géométrie dans un tampon de tableau - même vitesse
3. Chargez les programmes GPU - plus rapidement
4. Charger les textures - initialement la même vitesse mais plus rapide lors de la remise au GPU
5. Transférez la géométrie vers le GPU - plus rapidement
6. Faire une série d'appels de dessin pour rendre une image - plus rapidement

Merci beaucoup pour l'explication @DVLP . Les points 5 et 6 me semblent très intéressants car nous avons des milliers d'objets avec beaucoup de matériaux.

Il peut s'écouler longtemps avant que WebGPU soit largement adopté. Jusque-là, vous pouvez accélérer le tout en utilisant l'instanciation de maillage
https://threejs.org/docs/#api/en/objects/InstancedMesh

J'ai peur que nous ne puissions pas utiliser l'instanciation, tous les objets sont uniques @DVLP

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