Three.js: Moteur de rendu WebGL2

Très agréable. :) J'étais en fait un peu inquiet quant à la façon de gérer la complexité de WebGL 2 et 1.

Ce serait bien de préférer utiliser UBO. :) Et j'adore l'idée de ne supporter que BufferGeometry - cela devrait énormément simplifier les choses.

Ce serait cool de prendre en charge principalement les mêmes shaders si nous nous en tenons au rendu vers l'avant (ce qui semble être ce que fait UE4 pour la vitesse de la VR.) Je pense que nous pouvons probablement faire basculer cela ? Qu'en penses-tu?

Je suppose que je voudrais maintenir la compatibilité des shaders afin que si WebGL2 n'est pas disponible, nous puissions revenir à quelque chose qui ressemble, mais plus lent.

@mrdoob Hip hip hourra ! Et c'est bien d'apprendre que BufferGeometry sera exclusivement utilisé. 👍

J'appuie la suggestion de @bhouston de préférer les UBO.

Serait-il également possible de découpler plus complètement l'éclairage et la gestion des ombres du moteur de rendu ? Les valeurs par défaut sont vraiment pratiques, mais lorsque vous voulez un contrôle complet sur l'éclairage et la logique des ombres, WebGLRenderer et co. l'impression qu'ils se sont battus.

Et pendant que je liste des éléments de type liste de souhaits, les algorithmes de tri pourraient-ils être rendus "enfichables" ? J'ai des besoins de tri qui sortent du cadre de trois, et il semble inutilement difficile de remplacer les fonctions de tri dans le WebGLRenderer actuel. Peut-être que cela pourrait être un paramètre facultatif lors de la création de l'objet de rendu ?

Je me demande presque si l'on devrait simplement modifier WebGLRenderer 1 et supprimer la prise en charge de tout sauf des objets BufferGeometry. C'est peut-être une façon plus facile d'avancer. S'il existe une fonction simple pour convertir la géométrie en BufferGeometry que l'on force les gens à appeler ...

Je suppose que je dis cela parce que je suis inquiet d'essayer de maintenir la parité des fonctionnalités entre WebGLRenderer et WebGLRenderer2. Il est plus facile de faire évoluer une seule base de code plutôt que d'en maintenir deux en parallèle.

Je me demande presque si l'on devrait simplement modifier WebGLRenderer 1 et supprimer la prise en charge de tout sauf des objets BufferGeometry. C'est peut-être une façon plus facile d'avancer. S'il existe une fonction simple pour convertir la géométrie en BufferGeometry que l'on force les gens à appeler ...

Il y a déjà une fonction comme ça. Mais ce n'est pas si simple...

Je pense qu'il est préférable de construire WebGLRenderer2 à partir de zéro afin que nous puissions reconsidérer l'API et les fonctionnalités prises en charge.

Firefox 51 prend désormais en charge WebGL 2 : https://www.mozilla.org/en-US/firefox/51.0/releasenotes/

Je ne peux pas attendre ça !

Chrome 56 prenant en charge WebGL 2.0 est sorti !
https://developers.google.com/web/updates/2017/01/nic56

Le bon moment pour avancer WebGLRenderer2 ? XD

Devrions-nous également créer un WebGLDeferredRenderer2 ?

Prévoyez de commencer à examiner tout cela la semaine prochaine ! ✌️

À tout hasard, vous avez déjà eu le temps de vous y pencher ! Tellement hâte d'y être! (textures 3D)

@mrdoob
Les mises à jour?
Si vous avez des inquiétudes, n'hésitez pas à nous en faire part !
On peut discuter et s'aider ;D

Pas encore eu le temps. Bientôt bientôt! 😇

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

Les mises à jour? Je m'intéresse particulièrement aux textures 3D pour le rendu en volume de certaines images médicales. Je suis également prêt à aider à faire de cette pull request un succès.

Le sandbox webgl2 actuel de three.js ne fonctionne pas :( https://threejs.org/examples/webgl2_sandbox.html
Peut-être un problème de construction de la version three.js ?

Si en ligne <script type="module"> avait déjà été implémenté...
https://groups.google.com/a/chromium.org/d/msg/blink-dev/uba6pMr-jec/tXdg6YYPBAAJ

Au moins Mozilla y travaille https://bugzilla.mozilla.org/show_bug.cgi?id=1240072

@mrdoob , Cela signifie-t-il que nous pouvons nous attendre à ce que l'API Three.js profite de <script type="module"> lors de la mise à jour vers WebGL 2.0 ? ;)

BTW, je pense qu'il est plus simple d'ajouter le support WebGL 2.0 à WebGLRenderer. Je pense que cela permettrait une adoption incrémentielle et nous pouvons faire une détection de fonctionnalités pour voir si nous pouvons utiliser les fonctionnalités WebGL 2. Je ne pense pas que ce soit la chose la plus difficile à faire. Je sais que cela conduit à un peu de complexité par opposition à un moteur de rendu WebGL 2 pur, mais c'est le chemin le plus simple à court et moyen terme. Et nous évoluons lentement là où nous laissons derrière nous WebGL 1 une fois que WebGL 2 a dépassé les 90 % d'adoption.

Khronos vient d'avoir un webinaire sur webgl2 :
https://docs.google.com/presentation/d/11-mTDNmSJzJnRVGu9Vu6AUzOt34yV3PO7oqw4E5wc2o/edit#slide =id.gd15060520_0_38
Les médias seront bientôt disponibles, mais la présentation était principalement une voix off des diapositives et des démos associées dans les diapositives.

Il est assez clair que cela nécessite un nouveau départ, pas une "mise à jour" du WebGLRenderer existant.

En termes de modules es6, je pense que l'approche actuelle de la source étant les modules es6, puis l'utilisation du rollup pour un bundle est toujours le moyen de prendre en charge une "double construction".

Je le fais depuis environ une semaine, en testant des modules sur Safari Tech Preview et le bundle sur tous les navigateurs. Il en résulte vraiment une construction/avoir l'arborescence des sources ainsi que le bundle actuel. Rollup à une ligne comme vous l'avez actuellement, et une copie de l'arborescence source pour l'utilisation du module.

@bhouston tentant...

Dernier statut?

J'ai un sentiment mitigé à ce sujet. Au départ, je pensais au même chemin que celui proposé par @bhouston , en ajoutant progressivement des fonctionnalités webgl2 au WebGLRenderer actuel. Mais cela rendrait le moteur de rendu plus complexe et difficile à gérer avec les fonctionnalités qui diffèrent le plus entre les deux versions, se retrouvant avec un code désordonné plein de branches et de vérifications de condition.
Une option pourrait être de cloner le WebGLRenderer comme point de départ pour WebGL2Renderer et de continuer à supprimer/ajouter des fonctionnalités sans perturber le moteur de rendu d'origine.
Si nous jetons un coup d'œil à des moteurs comme Playcanvas, qui est probablement celui qui prend en charge le plus tôt webgl2, nous pouvons voir qu'il ne profite même pas des nouvelles fonctionnalités webgl2 comme UBO ou VAO car c'est quelque chose qui va modifier de nombreuses pièces du moteur.

Je crois fermement que si nous essayons de mélanger les deux versions sur le même moteur de rendu, nous nous retrouverons avec un code plus difficile à maintenir et dès que webgl2 sera entièrement pris en charge, nous devrons refactoriser cela de toute façon car je suppose que nous le serons obligé de suivre une conception pour conserver cette compatibilité, au lieu de la concevoir à partir de zéro en pensant à webgl2.

Donc, mon vote est de commencer WebGL2Renderer à partir de zéro, même si nous allons ralentir (nous avons encore de la place pour l'amélioration jusqu'à ce que webgl2 obtienne un support proche de 100 %).

Certains fichiers autres que le moteur de rendu lui-même doivent être modifiés, par exemple les textures, les programmes, etc. Devrions-nous créer un sous-dossier renderer\webgl2 et continuer à ajouter les fichiers qui seront spécifiquement créés pour ce moteur de rendu ?

Nous pourrions créer un problème avec la liste des changements que nous devrions faire pour avoir un moteur de rendu entièrement compatible webgl2 pour les avoir à l'esprit lors de l'écriture du moteur de rendu, et également créer une liste de fonctionnalités que nous aimerions avoir pour que MVP concentre nos efforts sur discuter ceux-ci dans cet état initial pour lancer une conversation plus approfondie sur la mise en œuvre.

Des mises à jour sur son développement?

Pas encore. Je donnais la priorité au WebVR ce mois-ci.

J'ai essayé une conversion sur place rapide et sale vers le langage de shader WebGL2 et ES3, comme suggéré par @fernandojsg ci-dessus. Voici le diff écrasé : https://github.com/tstanev/three.js/compare/master...tstanev :traian/webgl2 En fait, ça n'a pas l'air aussi mauvais que ce à quoi je m'attendais initialement. Il semble presque que ce ne serait pas super moche de prendre en charge les deux via des ifdef stratégiquement placés.
[Modifier : lien mis à jour.]

@tstanev Avez-vous un exemple de travail ?

Les exemples groupés de three.js dans la branche liée fonctionnent (comme vous pouvez le voir dans le diff, j'ai converti ceux qui nécessitaient des extensions auparavant). Vous pouvez cloner le dépôt/la branche et les exécuter localement.

@tstanev Que diriez-vous de faire une comparaison des performances pour les modifications de webgl2 en ligne?) Ce serait bien de le voir. (three.js contre three.js sur webgl2)

salut
merci pour cette meilleure idée.
Je veux utiliser webgl2renderer dans mon programme mais je ne pouvais pas l'utiliser dans la version précompilée (r86) donc j'obtiens la source et décommente le webgl2rendrer dans l'importation de three.js, puis le construis.
maintenant mon code et votre exemple (webgl2-sandbox) fonctionneront sans aucune erreur mais ils ne montrent rien

EDIT : je les ai testé sous firefox 54 et chrome 60
mon exemple utilisant bufferGeometry et ShaderMaterial et fonctionnera correctement dans webglrenderer

personne ne me répond ? quel est le problème de webgl2renderer maintenant ?

@ MHA15 , il n'est probablement pas inclus dans la construction car il n'est pas encore prêt pour la production.

Salut les gars, comment se passe le développement de WebGL2Renderer ?
Je sais que la décision a été prise de le recréer à partir de zéro. Mais cela fait un moment et le développement est un peu lent sur ce sujet car il faut beaucoup de travail pour le recréer, je crois.

À ce stade, pouvons-nous reconsidérer la création d'un clone de WebGLRenderer et le transformer en WebGL2 à la place, comme ce que @mattdesl a fait dans https://github.com/mrdoob/three.js/issues/8125 ?? Nous pouvons ensuite modifier le moteur de rendu en fonction de certaines nouvelles fonctionnalités comme UBO comme l'a dit @fernandojsg . Finalement, nous supprimerons tous ces anciens codes webgl 1.

À mon avis, créer le moteur de rendu à partir de zéro nécessite une énorme quantité de travail et, idéalement, cela ne peut commencer qu'avec quelques contributeurs. Cette conversation a commencé il y a un an. Et à moins que nous n'arrivions au point où nous avons un sauveur qui passerait quelques mois à plein temps à le construire à partir de zéro, je pense que nous serons probablement sur la même longueur d'onde l'année prochaine.

À mon avis, créer le moteur de rendu à partir de zéro nécessite une énorme quantité de travail et, idéalement, cela ne peut commencer qu'avec quelques contributeurs.

Que c'est vrai. Mais même dans ce cas, je pense que c'est plus facile que de rendre WebGLRenderer plus difficile à maintenir en ajoutant des conditions partout. J'ai passé la plupart de mes 5 dernières années à essayer de rendre WebGLRenderer plus facile à lire et à maintenir.

De plus, je pense que @fernandojsg prévoyait de tenter le coup dans les semaines à venir.

C'est génial. Dans l'attente de l'excellent travail de @fernandojsg !!

PS je dois dire.. Merci à tous les contributeurs de ce projet d'avoir élargi mon horizon de l'infographie. En espérant pouvoir apporter quelques exemples à l'avenir.

Je suis d'accord avec @mrdoob qu'il sera plus facile de créer un nouveau moteur de rendu à partir de zéro que de modifier l'actuel.
Comme il l'a dit, je voulais essayer dans les semaines suivantes. Mon approche consiste à commencer à créer exactement ce dont vous avez besoin pour une simple boîte à l'écran et à y ajouter des fonctionnalités étape par étape, au lieu de prendre ce qui existe déjà et d'essayer de le refactoriser.
À titre d'exemple, jetez un coup d'œil à l'état actuel du WebGLRenderer , il y a eu beaucoup de discussions pour le rendre plus modulaire et personnalisable, mais même si le code interne ne cesse de s'améliorer au fil du temps, en dehors de là, c'est juste une boîte noire.
Dès que j'aurai quelque chose qui fonctionne, j'ouvrirai un PR afin que nous puissions continuer à discuter des prochaines étapes.

Pendant que nous y sommes...
webgl2_sandbox fonctionne à nouveau (nécessite cependant des modules es6).

@mrdoob avez-vous une estimation approximative quand sera-t-il disponible en master / release ? :) Je suis content que ça arrive ! :)

@wdanilo Pas vraiment... De quelles fonctionnalités de WebGL2 avez-vous besoin ?

@mrdoob, les plus grandes améliorations proviendraient des objets tampon uniformes et du Sampler2DArray. Le tableau de texture serait très bénéfique pour mon projet actuel car nous sommes confrontés aux limites d'unité de texture car j'utilise un shader complexe qui superpose plusieurs matériaux masqués par des cartes alpha.

@mrdoob De nouveaux mots clés comme flat dans glsl seraient également très utiles.

Mon projet a besoin de textures 3D.

Intéressant...
Super utile pour connaître les cas spécifiques pour lesquels les gens ont besoin de WebGL 2.0.
Laissez-les venir!

Les textures 3D sont également la grande fonctionnalité pour nous. Je pense que nous utilisons également certaines fonctionnalités de shader.

Parfois je veux MRT

+1 pour plusieurs cibles de rendu aussi

Plusieurs cibles de rendu sont déjà prises en charge dans WebGL1 via une extension, et il y a même un PR pour cela dans ThreeJS : https://github.com/mrdoob/three.js/pull/9358 ( demo ).

Je pense que les cibles de rendu multi-échantillons sont ma fonctionnalité préférée. La plupart des clients demandent un post-traitement (bloom, LUT, etc.) mais ils sont déçus du manque d'anti-aliasing approprié une fois les post-FX implémentés. Avec les cibles de rendu MSAA, nous pouvons enfin avoir une scène bien anti-aliasée _et_ post-traitée.

Je suis d'accord. Les shaders de contournement pour l'anti-aliasing sur les scènes post-traitées avec compositeur d'effets ne suffisent pas pour un véritable anti-aliasing.

+1 pour les commentaires de tirage. Ou est-il déjà pris en charge en tant qu'extension webgl1 dans
Trois?

Le jeudi 14 décembre 2017 à 21h45, Kyle [email protected] a écrit :

Je suis d'accord. Shaders de contournement pour l'anti-aliasing sur les scènes post-traitées
avec des effets composer ne suffisent pas pour un vrai anti aliasing.

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/mrdoob/three.js/issues/9965#issuecomment-351815640 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AHTX1RhYdGuTVSpmOy1ka-6gy1eslHQAks5tAXrFgaJpZM4Kj_9l
.

J'ai quelques cas d'utilisation ici:

1. J'ai besoin de MRT - actuellement, je rends le même shader 4 ou 5 fois, en changeant un attribut juste pour obtenir des tampons différents.
2. Le rendu de la texture avec anticrénelage est une fonctionnalité importante pour nous - nous créons un "éditeur de nœuds" avec un aperçu de la visualisation. Chaque visualisation n'est qu'une texture, nous dessinons quelque chose aussi et aucun anticrénelage approprié n'est une douleur ici.
3. Le mot clé "flat" - j'indexe maintenant la géométrie avec un attribut float, qui est évidemment sous-optimal - pire que l'indexation avec uint one. Je passe cet attribut de vertex à fragment shader et je ne peux pas utiliser uint maintenant, car nous n'avons pas le support de kwrd "plat".
4. Les textures 3D (plus petites) sont idéales pour les visualisations haut de gamme que nous aimerions prendre en charge dans un avenir proche.

L'utilisation conjointe de l'anticrénelage et du post-traitement est la plus importante pour moi.

@mrdoob Mes 3 meilleures fonctionnalités/cas d'utilisation de WebGL 2 (par ordre d'importance) :

1. Cibles de rendu multi-échantillonnées : pour un (MS)AA approprié en post-traitement.
2. Textures entières : pour créer des algorithmes basés sur des images tels que les champs de distance signés, ainsi que pour utiliser des données basées sur des textures plus exotiques telles que DEM (Digital Elevation Models).
3. Transform Feedback : Pour créer des systèmes de particules.

@mrdoob au fait, savez-vous pourquoi #9358 PR n'a pas été fusionné ? Comme @mattalat l' a écrit, il apporte le rendu multicible à threejs. A été commis il y a 2 ans, corrigé plusieurs fois pour se tenir au courant des autres changements et jusqu'à présent ce n'est pas là :(

Je pose la question parce que j'ai une scène qui utilise beaucoup les descriptions de forme SDF. Chaque forme produit 6 sorties différentes, donc maintenant je la calcule 6 fois en passant aux numéros de shader de 0 à 5. Il serait beaucoup plus agréable d'utiliser plusieurs sorties et cela apportera simplement une amélioration des performances 5x.

@wdanilo Ce n'était probablement pas le bon moment (beaucoup de choses en mouvement dans le moteur de rendu à l'époque). En outre, il semble qu'il inclue les versions qui provoquent facilement des conflits. Quelqu'un est-il prêt à faire un nouveau PR ?

/cc @edankwan

Nous avons besoin de textures 3D et de cibles de rendu multi-échantillons.

Je cherche à l'utiliser pour pouvoir définir depthTexture.type = THREE.FloatType .. à moins qu'il n'y ait un autre moyen de faire actuellement une telle chose.

Y a-t-il un espoir que LineThickness autre que 1 fonctionne sous Windows et WebGL 2.0 ? Si oui, cela améliorerait certains de nos résultats.

Et là, je me réponds. En lisant l' épaisseur des lignes à l'aide de matériel de base à trois lignes sur SO, j'ai compris que les lignes épaisses auront de toute façon besoin d'une géométrie à l'avenir.

@Richard004 Cela n'a rien à voir avec WebGL 2. Nous avons déjà un PR pour cette demande de fonctionnalité, voir #11349 👍

Bonjour @mrdoob et @Mugen87
J'ai besoin de manipulations de bits à l'intérieur du fragment shader ainsi que d'une indexation de tableau dynamique. Le premier n'est probablement pas très courant, mais j'en ai besoin malgré tout car j'essaie de porter un noyau CUDA sur WebGL (GLSL) et d'autres langages de shader autorisent les manipulations de bits, mais WebGL 1.0 (GLSL) ne le fait pas.

Le second, je pense que beaucoup de développeurs pourraient en bénéficier : c'est-à-dire accéder à un élément de tableau avec une variable. Actuellement dans WebGL 1.0 (GLSL), un programme comme celui-ci échouera :

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

Cependant, dans WebGL 2.0, vous pouvez le faire. Il est souvent nécessaire à l'intérieur d'une boucle, où vous devez obtenir différentes valeurs d'un tableau, mais vous ne pouvez pas simplement faire une boucle itérative (0 à 199 dans l'exemple ci-dessus par exemple), car vous auriez alors besoin de vérifier chaque élément et c'est vraiment lent.

L'anticrénelage dans le post-traitement serait certainement bénéfique.

Sous tout cela se trouve la question : est-il temps d'avoir une nouvelle architecture pour Three ?

J'ai récemment commencé à utiliser D3, version 4. C'était une refonte complète . Es6
modules. Et bien plus important, 30 modules, dont chacun était le sien
dépôt. Je recommande vraiment de regarder l'architecture D3.

Je ne dis pas que nous en avons besoin pour Trois, mais je pense que nous pourrions envisager une
bosse de version majeure. En partie à cause de webgl2. Mais aussi en raison du besoin de
sous-modules.

Un exemple : Il existe un repo/sous-module D3 "selections". C'est ta base
module jQuery DOM mais avec toute la verbosité du DOM cachée dans un
design fonctionnel et enchaînant. Il peut être utilisé tel quel sans utiliser le reste de
D3.

N'aimeriez-vous pas un module indépendant à trois qui a fait tout le webgl
la verbosité disparaît ? Peut-être même plusieurs sous-modules pour webgl ctx/shader
gestion, gestion des tampons, etc. En effet, la géométrie du tampon est une
beaucoup comme ça. Idem pour la création de shader à partir de parts.

Juste une pensée.

@fetox74 Je suis presque sûr que vous pouvez déjà faire AA https://threejs.org/examples/?q=fxaa#webgl_postprocessing_fxaa

@elunty le FXAAShader ne produit pas un résultat assez bon par rapport à l'anticrénelage d'origine, je l'ai utilisé dans la nature.

Je suis surtout intéressé par les VAO et l'écriture sur les mipmaps, ce qui, je l'espère, est possible sous cette spécification.

@pailhead Connexe #8705 :wink:

Dans l'attente du support natif pour EXT_shader_texture_lod .
Il peut résoudre les artefacts générés lors de l'utilisation MeshStandardMaterial et MeshPhysicalMaterial sur la plupart des appareils Android et MS Edge et Internet Explorer

@mrdoob avez-vous ou votre équipe prévu de mettre à jour Threejs vers Webgl 2.0 ? Ce fil prend littéralement des années et rien ne change vraiment alors que tous les autres frameworks ont déjà avancé. J'aurai bientôt une décision difficile à prendre, nous devrons probablement migrer vers Babylone ou quelque chose comme ça et j'aimerais vraiment rester avec Three. Je vais, s'il y en avait, n'importe quels plans pour sa modernisation.

@wdanilo si WebGL 2.0 est une priorité pour votre projet, je vous recommande de migrer vers Babylon. Je sais que certains contributeurs de three.js prévoient d'y travailler, mais je me concentre personnellement sur le WebVR et les flux de travail des artistes (support svg, etc.).

@mrdoob J'apprécie vraiment votre réponse rapide ici. J'aimerais vraiment ne pas abandonner three.js. J'aime la façon dont la bibliothèque est construite sous le capot et ses hypothèses comme étant un cadre "général", et non "axé sur le jeu", etc. Quoi qu'il en soit, merci pour les informations et de garder cela clair.

(Merci encore @takahirox , j'étais au courant de ce fil). Je viens de faire une pull request #13692. Je comprends que l'accent n'est pas mis là-dessus, mais pour nos besoins, cela a bien fonctionné.

Associé #13702

J'ai créé la branche de base WebGL2 après #9965 et #12250

Dépôt : https://github.com/takahirox/three.js/tree/WebGL2Base
Exemples : https://rawgit.com/takahirox/three.js/WebGL2Base/examples/index.html

Vous pouvez démarrer WebGL2.0 + Three.js avec.

(Désolé en conflit avec le travail de @yoshikiohshima )

@mrdoob Pouvons-nous avoir une branche pour WebGL2Renderer comme three.js/dev-2.0 ? Ou pouvons-nous le fusionner dans dev alors qu'il y a encore beaucoup de codes en double entre pour webgl1 et pour webgl2 ?

Je suis nouveau dans le développement passé sur cette question. @takahirox , pouvez-vous résumer la stratégie que vous adoptez et ce qui est pris en charge par https://github.com/takahirox/three.js/tree/WebGL2Base ? (et encore désolé pour mon ignorance) mais je n'ai pas vu la nécessité d'avoir beaucoup de code dupliqué pour supporter WebGL2. Quels sont les problèmes ?

@mrdoob Pouvons-nous avoir une branche pour WebGL2Renderer comme three.js/dev-2.0 ? Ou pouvons-nous le fusionner dans dev alors qu'il y a encore beaucoup de codes en double entre pour webgl1 et pour webgl2 ?

Je ne sais pas pourquoi cela nécessiterait une nouvelle branche. Pourquoi y aurait-il du code dupliqué ?

Il ne semble pas y avoir de conflits. Il y a maintenant deux demandes pour WebGL2.0.

1. Faire WebGL2Renderer pour prendre en charge toutes les fonctionnalités WebGL2.0 et bien optimiser
2. Ajout de la prise en charge webgl2 aux WebGLRenderer existants. Mais nous ne prenons pas entièrement en charge les fonctionnalités WebGL2.0 et n'optimisons pas pour WebGL2.0 car nous ne voulons pas que le moteur de rendu soit gâché. Donc, fondamentalement, c'est juste pour un accès anticipé à Three.js + WebGL2.0 + GLSL3.0

Le mien est pour 1. Son travail est pour 2. Nous n'avons pas de code dupliqué et n'avons pas besoin de créer une nouvelle branche pour 2.

@takahirox Je pense qu'il serait préférable de travailler dans la même branche pour le moment.

Si vous vous améliorez...

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

et les exemples webgl2 importent directement les classes (sans avoir besoin de builds)...

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

il ne devrait pas y avoir de conflits.

Vous pouvez oublier mon WebGL2Base jusqu'à présent car il semble que nous démarrons le support WebGL2.0 en un WebGLRenderer .

Pensons-nous toujours à implémenter un WebGL2Renderer ?
J'ai beaucoup cherché ces derniers temps pour ajouter le support WebGL2, et j'attends les changements de takahirox pour rebaser le mien. Mais après avoir fait quelques changements, j'ai commencé à penser que réécrire le moteur de rendu serait une très bonne idée, ainsi que l'objet WebGLTextures. Si c'est toujours d'actualité, je serais ravie d'y participer.

Je pense que oui. Je pense que l'ajout du support de base de webgl 2.0 au WebGLRenderer actuel est juste pour avoir quelque chose pendant que nous travaillons sur WebGL2Renderer .

N'hésitez pas à commencer à réécrire le moteur de rendu et à envoyer des PR (idéalement étape par étape).

Toutes mes excuses si je demande l'évidence, mais après avoir lu tout ce numéro, le dernier message datant d'il y a six mois, et trouvé quelques références à webgl2 à la fois dans le code source principal et dans les exemples, je n'arrive toujours pas à comprendre .

Vous vous demandez si webgl2 est utilisable dans son état actuel dans Three.js ? (même s'il ne s'agit que de rendre de simples maillages de géométrie tampon) EffectComposer fonctionnerait-il avec un moteur de rendu compatible avec le contexte webgl2 ? La cible de rendu devrait-elle être ajustée de quelque manière que ce soit ?

La plus grande question, bien sûr, est de savoir s'il est actuellement possible d'obtenir un anticrénelage approprié lors de l'utilisation de composer avec des passes personnalisées.

On dirait qu'en fin de compte, nous venons d'ajouter des fonctionnalités WebGL 2.0 à WebGLRenderer .
WebGPU aura certainement besoin d'un WebGPURenderer .