Intéressant!

@sunag Nous sommes très intéressés par quelque chose comme ça. Comment puis-je aider? Je peux au moins ajouter la prise en charge de Standard.

Je suis intéressé par la création de graphiques assez arbitraires, afin que les nœuds intermédiaires prennent également des entrées. Vous pouvez donc avoir un graphique qui ressemble à ceci :

Une texture (tex1, uv1)
Texture B (tex2, uv2)
C Mélange (A, B, mode)
D Bruit(param1, param2)
E Mélange (C, D, mode)

Et puis utilisez ce nœud final E, comme entrée d'un matériau.

C'est donc très arbitraire, pas limité aux seules textures.

Mon objectif serait d'aider à créer ceci au cours des prochaines semaines, en espérant collaborer avec vous au cours de la semaine prochaine si possible. Je cherchais à le faire via la bibliothèque shadergraph ici: https://github.com/mrdoob/three.js/issues/7339 Mais je trouve que je le crée directement dans ThreeJS. Vraiment, toute solution est bonne tant qu'elle est flexible et qu'elle fonctionne.

Je lis votre code, il est assez bien conçu. J'ai quelques premiers retours. Puis-je démarrer un PR en utilisant votre code comme base pour commencer à collaborer dessus ?

(1) Je voudrais que le matériel résolve les références. Fondamentalement, les références auraient des noms qu'ils demanderaient à leur matériel de résoudre, et le matériel renverrait un extrait de code sur la façon d'accéder à ces données. Cela permettrait également au matériel de savoir quelles variables (uniformes/variantes) sont utilisées par les nœuds, afin qu'il puisse optimiser de manière appropriée. Cela permet également à différents matériaux de résoudre les références différemment, rendant ainsi les nœuds plus portables, plutôt que d'avoir à savoir comment les matériaux implémentent les choses, en particulier lorsqu'il existe des différences entre les implémentations de fragments et de sommets.

(2) J'essaie d'utiliser l'objet GeometryContext que j'ai créé dans le refactor de lumières, il donne un accès cohérent à de nombreuses variables locales requises. Mais bien sûr, cela peut être résolu par le matériel lui-même.

(3) J'ai UV juste être une autre référence, qui est résolue par le matériau. Et je voudrais que NodeTexture prenne en fait une entrée de nœud, permettant ainsi des UV générés de manière procédurale.

(4) J'appellerais NodeCube, NodeTextureCube pour être cohérent avec le reste de Three.JS. Et je supprimerais la logique sur la façon d'en tirer les jets de rayons. Mais j'aime l'idée des cartes de cube standard, donc je ne mettrais pas la requête d'environnement pour spéculaire ou diffuse dans les nœuds, mais l'aurais dans le matériau de base phong, et vous ne pouvez contrôler que la normale utilisée pour la requête, ou le cubemap lui-même (lui permettant ainsi d'être une couleur déterminée de manière procédurale.) Cela a-t-il du sens? J'aurais donc le pluggable normal dans le matériau et la texture du cube pluggable (interrogeable par une direction et un biais/lod, et renvoie une couleur). Ainsi on peut fournir une texture cubique à la carte d'irradiance et une autre à la carte spéculaire. Nous pouvons échanger le vrai sampleCube avec la fonction cubeToUV2 de @tschw comme un simple échange de nœuds.

(5) J'essaierais d'ajouter une NodeFunction qui permet d'appeler des fonctions arbitraires avec des paramètres en plus de votre NodeOp (ou peut-être qu'elles pourraient être fusionnées d'une manière ou d'une autre.)

(6) Je me débarrasserais de toutes les classes individuelles verbeuses NodeNormal, NodeTransform, NormalMap, etc. NodeReference pourrait résoudre les uniformes, les variations ainsi que les valeurs calculées dans le shader.

(7) Je ne comprends pas la différence entre NodeEnvironment et NodeCube. Je pense que NodeEnvironment est peut-être incomplet ?

(8) Il est déroutant que NodePhong ne soit pas dérivé de NodeMaterial. Bien que je voie que NodeMaterial est dérivé de ShaderMaterial. Je me demande si vous avez appelé le dérivé direct de ShaderMaterial, GraphMaterial (ou NodeGraphMaterial) qui aurait plus de sens - car tous ensemble, les nœuds forment un graphique, et c'est le graphique qui devient le matériau, pas un nœud individuel.

(9) Je suggérerais peut-être une terminologie plus variée. J'appellerais le nœud racine, MaterialNode, et on pourrait en dériver PhongMaterialNode. J'ai Vector3Node, FloatNode, etc. dérivé de ValueNode -- pas nécessairement constant, mais juste une valeur. Ainsi, on pourrait diriger trois FloatNodes vers un Vector3Node. Je pense que vous pouvez avoir une aide qui ferait déclarer chacune de ces lignes environ plutôt que les 10 environ actuellement.

(10) Je déplacerais le nom "Node" du début des noms de classe vers l'arrière car c'est comme ça dans le reste du projet ThreeJS.

(11) Je créerais la nouvelle classe MaterialNode et elle serait initialisée avec une liste d'uniformes et de variantes. Il serait par défaut de pouvoir résoudre ce problème et également de suivre ce qu'il a résolu afin que l'on puisse suivre les fonctionnalités nécessaires. On pourrait ainsi avoir une résolution limitée dans le PhongMaterialNode dérivé qui résoudrait les cas spéciaux et s'appuierait sur la classe sous-jacente pour faire les plus simples (variants, uniformes.)

(12) Je suis en quelque sorte confus entre la différence entre NodePhong et NodePhongMaterial. Je ne savais pas qu'il y avait les deux jusqu'à maintenant.

(13) il y a un code comme celui-ci :

THREE.NodeGLPosition.prototype = Object.create( THREE.Node.prototype );
THREE.NodeGLPosition.prototype.constructor = THREE.NodeGLPosition;

THREE.NodeGL.prototype.generate = function( material, shader ) {

Mais au-dessus de cet extrait, vous avez déjà défini generate pour NodeGL et vous n'en avez pas défini pour NodeGLPosition -- donc je pense que c'est une erreur de copier-coller-édition.

(14) Je me débarrasserais de NodeReflectUVW et NodeRefractVector et ferais plutôt de cela quelque chose que l'on peut demander au matériel via une résolution de référence. Le calcul d'un vecteur de réflexion est simple. Je l'ai ajouté à GeometryContext dans mes branches expérimentales ThreeJS non fusionnées.

(15) La façon dont j'implémenterais la réflexion et la réfraction serait de les avoir comme entrées de couleur sur le matériau. On résoudrait Refect, ReflectLOD et Refract, RefractLOD de la même manière que vous résoudriez n'importe quelle variable, puis les passeriez dans son équivalent de cube de texture (procédural ou basé sur samplerCube), puis passerait la couleur résultante dans Material. C'est comme ça que tu faisais ?

(16) Je suis confus au sujet de l'entrée de lumière - généralement, les lumières ne sont pas enfichables, mais les paramètres de lumière sont entièrement définis dans la classe de lumière. Je suppose que vous avez besoin de cette flexibilité supplémentaire? Comment l'envisagez-vous.

@bhouston wow, merci beaucoup pour vos commentaires.
J'aurai besoin de plusieurs messages pour répondre :)

Je suis intéressé par la création de graphiques assez arbitraires, afin que les nœuds intermédiaires prennent également des entrées. Vous pouvez donc avoir un graphique qui ressemble à ceci :
Une texture (tex1, uv1)
Texture B (tex2, uv2)
C Mélange (A, B, mode)
D Bruit(param1, param2)
E Mélange (C, D, mode)

Actuellement, la syntaxe comme celle-ci. Exemple d'animation de décalage Uv1 :
Je pense que NodeMaterial à MaterialNode et THREE.PhongMaterialNode Ce serait mieux aussi.

var uv2 = false;
var uv_offset = new THREE.NodeFloat(0);     
var uv = new THREE.NodeOperator( '+', new THREE.NodeUV( uv2 ), uv_offset);
var texture = new THREE.NodeTexture( imgTexture, uv );

nodematerial.color = t;

// onUpdate
uv_offset.number += .01;

Je pense inverser l'ordre avec votre suggestion pour vous améliorer (mode,A,B) en (A,B,mode). Je suis en train de créer les reflex maps, cubemap et autres...

L'environnement et la Cubemap sont incomplets.

Actuellement les bugs ça peut arriver plus à cause du convertisseur de format encore inachevé. Ceci est responsable par conversion vectorielle. vec3 à vec4 ou vec4 par exemple.

https://github.com/sunag/sea3d/blob/gh-pages/Labs/Three.JS-NodeMaterial/index.html#L365

Une "texture" Blend par exemple : ( je n'ai pas testé ce code )
Il peut être implémenté dans le même d'un THREE.NodeOperator

https://github.com/sunag/sea3d/blob/gh-pages/Labs/Three.JS-NodeMaterial/index.html#L1105

THREE.NodeBlend = function( a, b, mode ) {

    THREE.NodeInput.call( this, 'blend' );

    this.mode = mode;
    this.a = a;
    this.b = b;

};

THREE.NodeBlend.prototype = Object.create( THREE.NodeInput.prototype );
THREE.NodeBlend.prototype.constructor = THREE.NodeBlend;

THREE.NodeBlend.prototype.generate = function( material, shader, output ) {

    var a = this.a.build( material, shader, output );
    var b = this.b.build( material, shader, output );

    switch(this.mode)
    {
        case 'multiply':

            return this.format( '(' + a + '*' + b + ')', this.a.type, output);

            break;
    }

    return a;

};

.generate() est le responsable du générateur de code. Les codes de calcul sont stockés dans un cache si vous souhaitez les utiliser dans plus d'une entrée sans perte de performances.

Je ne mets toujours pas en place de pointeurs ou de constantes pour l'optimisation...

La compilation se fait par propagation dans build() pour le code vertex et fragment.

Je peux te mettre comme collaborateur ? Si vous souhaitez modifier le code de quelque manière que ce soit, je travaillerai également dessus.

Je peux te mettre comme collaborateur ? Si vous souhaitez modifier le code de quelque manière que ce soit, je travaillerai également dessus.

Merci! Je ferai des relations publiques pour vous afin que vous puissiez approuver les modifications.

Je vous ai ajouté (ainsi que @mrdoob , @WestLangley et @tschw) à un de mes projets parallèles qui tente de définir un ensemble de nœuds réutilisables et de définitions de matériaux qui peuvent être transférables entre différents rendus. Il peut être mappé sur ce système de graphique de shader que vous avez créé.

Je ne pense pas que vous deviez faire attention au repo auquel je viens de vous donner accès si vous ne le souhaitez pas. C'est ce que je suis intéressé à mettre en œuvre en plus de cela.

(2) J'essaie d'utiliser l'objet GeometryContext que j'ai créé dans le refactor de lumières, il donne un accès cohérent à de nombreuses variables locales requises. Mais bien sûr, cela peut être résolu par le matériel lui-même.

Je souhaite que les lumières soient un LightNode. Mon souci est d'exploiter le code déjà développé pour Three.JS.

(3) J'ai UV juste être une autre référence, qui est résolue par le matériau. Et je voudrais que NodeTexture prenne en fait une entrée de nœud, permettant ainsi des UV générés de manière procédurale.

Vous pouvez remplacer les UV par un vec2, serait-ce cela ?

(5) J'essaierais d'ajouter une NodeFunction qui permet d'appeler des fonctions arbitraires avec des paramètres en plus de votre NodeOp (ou peut-être qu'elles pourraient être fusionnées d'une manière ou d'une autre.)

ce serait super. principalement pour un BlendNode.

(6) Je me débarrasserais de toutes les classes individuelles verbeuses NodeNormal, NodeTransform, NormalMap, etc. NodeReference pourrait résoudre les uniformes, les variations ainsi que les valeurs calculées dans le shader.

Dans cette ligne de pensée, je pense que le MaterialNode pourrait être une base de matériel Phong et de matériel physique.

(7) Je ne comprends pas la différence entre NodeEnvironment et NodeCube. Je pense que NodeEnvironment est peut-être incomplet ?

Je ne peux toujours pas terminer ces nœuds.

(8) Il est déroutant que NodePhong ne soit pas dérivé de NodeMaterial. Bien que je voie que NodeMaterial est dérivé de ShaderMaterial. Je me demande si vous avez appelé le dérivé direct de ShaderMaterial, GraphMaterial (ou NodeGraphMaterial) qui aurait plus de sens - car tous ensemble, les nœuds forment un graphique, et c'est le graphique qui devient le matériau, pas un nœud individuel.

NodeMaterial serait le matériau du nœud racine, il est nécessaire d'utiliser un nœud pour le sommet et le fragment. NodePhong est hibrid et NodePhongMaterial n'est qu'une classe proxy. Celui-ci peut ensuite être fusionné.

(9) Je suggérerais peut-être une terminologie plus variée. J'appellerais le nœud racine, MaterialNode, et on pourrait en dériver PhongMaterialNode. J'ai Vector3Node, FloatNode, etc. dérivé de ValueNode -- pas nécessairement constant, mais juste une valeur. Ainsi, on pourrait diriger trois FloatNodes vers un Vector3Node. Je pense que vous pouvez avoir une aide qui ferait déclarer chacune de ces lignes environ plutôt que les 10 environ actuellement.

Ça a l'air bien.

(16) Je suis confus au sujet de l'entrée de lumière - généralement, les lumières ne sont pas enfichables, mais les paramètres de lumière sont entièrement définis dans la classe de lumière. Je suppose que vous avez besoin de cette flexibilité supplémentaire? Comment l'envisagez-vous.

Ce serait pour la lightmap ou un éventuel LightNode.

Ce serait pour la lightmap ou un éventuel LightNode.

J'aime l'idée d'une lightmap enfichable car on pourrait définir explicitement les UV pour cela. :)

@bhouston Corrige plusieurs corrections aujourd'hui dans ce dossier : Mais a encore beaucoup à faire.
https://github.com/sunag/sea3d/blob/gh-pages/Labs/Three.JS-NodeMaterial/three.node.js

C'est le terrain de jeu que je crée :art: Les textures et les boutons sont un glisser-déposer, ne fonctionnent qu'en chrome

http://sea3d.poonya.com/flow/

Incroyable, des trucs ! Putain de merde ! C'est beau.

Serait-il possible de partager le code d'une manière que je puisse également contribuer ? En tant que RP public ou quelque chose comme ça ?

Vous travaillez avec le projet Sea3D ici, n'est-ce pas ?

https://github.com/sunag/sea3d/tree/gh-pages/Labs/Three.JS-NodeMaterial

Donc je peux juste le fork et commencer à contribuer ? Accepteriez-vous les PR ? Comment pouvons-nous collaborer efficacement.

Je n'ai pas demandé, mais @mrdoob aimerait probablement (?) L'avoir dans le projet ThreeJS lui-même.

Absolument!

Donc je peux juste le fork et commencer à contribuer ? Accepteriez-vous les PR ? Comment pouvons-nous collaborer efficacement.

Bien sûr, je pense que votre aide serait incroyable. Je dois également apporter d'autres types de nœuds, comme la saturation, le bruit comme vous l'avez suggéré.

Vous travaillez avec le projet Sea3D ici, n'est-ce pas ?

Je pense qu'en faisant un PR pour Three.JS avec des exemples, tout cela est défini.

@mrdoob Que

C'est un type de matériau, il devrait donc être THREE.NodeMaterial .

En haut. Je pense que je suis proche d'un PR?
https://github.com/sunag/sea3d/commit/55cf70aea38b2b72110abf96f7b96924dad81c54

Faites glisser ce cubemap vers le terrain de jeu et toute autre texture pour les tests
https://raw.githubusercontent.com/mrdoob/three.js/master/examples/textures/skyboxsun25degtest.png

http://sea3d.poonya.com/flow/

un exemple de shader de jante

exemple de réflexion de zone

C'est tellement génial @sunag!

@bhouston merci ! vous pensez qu'il sera difficile de convertir en R74?

C'est un travail très impressionnant ! Cela me rappelle

Très bon travail jusqu'à présent!

@sunag Ce sera un peu de travail, mais j'aimerais aider et la plupart des grands changements structurels dans le code du shader R74 sont de ma faute. :)

@GGAlanSmithee c'est aussi très similaire à ce que l'UE4 a : https://docs.unrealengine.com/latest/INT/Engine/Rendering/Materials/ExpressionReference/index.html

semble bel homme et amusant de jouer avec: puis-je offrir comme source d'inspiration l'éditeur de nœuds Blender3D. Je le trouve super efficace, il y a même de superbes vidéos sur PBR via le système de nœuds de Blender et quels nœuds seraient les plus utiles pour créer du PBR à partir de zéro :

https://www.youtube.com/playlist?list=PLlH00768JwqG4__RRtKACofTztc0Owys8

Ce sera un peu de travail, mais j'aimerais aider et la plupart des grands changements structurels dans le code du shader R74 sont de ma faute. :)

@bhouston Ouah. C'était beaucoup plus propre avec les nouveaux changements r74. J'ai terminé la première partie manquant toujours StandardMaterial. Tout problème que je poste ici : ) Merci
https://github.com/sunag/sea3d/commit/d544ad7993272348f8bbea2337cdceb52159a6a8

Une autre chose qui nous manque encore est la réfraction. J'aime vraiment utiliser le tampon de rendu à la place d'un Cubemap RTT par défaut. Ce serait beaucoup plus efficace.

@GGAlanSmithee J'ai quelques références de ShaderFX dont je suis un grand fan. Shader Forge et UE4 principalement sont aussi de très bonnes références. Merci !

@richardanaya Des vidéos incroyables. Merci !

@mrdoob Dans quel dossier recommandez-vous de mettre ces fichiers ? racine de three.js ( src/materials/node ) ou dans des exemples ?
https://github.com/sunag/sea3d/tree/gh-pages/Labs/Three.JS-NodeMaterial/node

Je recommanderais toujours d'appeler cela un "GraphMaterial" ou, dans le style ThreeJS inversé, un "GraphMaterial". Ou si vous insistez pour utiliser le terme "Node", je l'appellerais "NodeBasedMaterial". Ces deux noms indiquent clairement que le matériau contient des nœuds, plutôt que d'être un nœud lui-même.

Je recommanderais toujours d'appeler cela un "GraphMaterial" ou, dans le style ThreeJS inversé, un "GraphMaterial". Ou si vous insistez pour utiliser le terme "Node", je l'appellerais "NodeBasedMaterial". Ces deux noms indiquent clairement que le matériau contient des nœuds, plutôt que d'être un nœud lui-même.

Pour moi les deux ont l'air bien. Je laisse la décision à @mrdoob qu'en pensez-vous ?

BTW @sunag, je m'en tiendrais aux cubesmaps pour les réfractions si possible, c'est plus facile et plus précis. Je pense que c'est ainsi que presque tout le monde le fait et nous avons également besoin du matériel RTT pour des réflexions précises. Je pense que cela doit juste être un rendu rapide à 128^2 ou 256^2.

BTW @sunag, je m'en tiendrais aux cubesmaps pour les réfractions si possible, c'est plus facile et plus précis. Je pense que c'est ainsi que presque tout le monde le fait et nous avons également besoin du matériel RTT pour des réflexions précises. Je pense que cela doit juste être un rendu rapide à 128^2 ou 256^2.

Oui, nous pouvons laisser les deux. serait une discussion entre performance x précision. Toujours pour la réfraction plane (verre, eau) je recommande le tampon à la place d'un CubeMap (pour la plupart des cas).

NodeStandard pour analyser il est nécessaire de faire glisser le CubeMap.
https://raw.githubusercontent.com/mrdoob/three.js/master/examples/textures/skyboxsun25degtest.png
http://sea3d.poonya.com/flow/

La source:
https://github.com/sunag/sea3d/blob/gh-pages/Labs/Three.JS-NodeMaterial/node/NodeStandard.js

@mrdoob Dans quel dossier recommandez-vous de mettre ces fichiers ? racine de three.js ( src/materials/node ) ou dans des exemples ?

Je le mettrais dans des exemples pour commencer. Une fois qu'il est bien défini, nous pouvons le déplacer plus tard vers src 😊

Je recommanderais toujours d'appeler cela un "GraphMaterial" ou, dans le style ThreeJS inversé, un "GraphMaterial". Ou si vous insistez pour utiliser le terme "Node", je l'appellerais "NodeBasedMaterial".

Pour moi les deux ont l'air bien. Je laisse la décision à @mrdoob qu'en pensez-vous ?

J'aime déjà NodeMaterial ... Peut-être NodesMaterial ? NodeGraphMaterial ? @WestLangley des suggestions ?

Je renommerais cependant les nœuds actuels... NodeColor , NodeFloat , NodeTexture , ... en ColorNode , FloatNode , TextureNode

http://sea3d.poonya.dev/flow/

Je n'arrive pas à charger ça 😐

Je le mettrais dans des exemples pour commencer. Une fois qu'il est bien défini, nous pouvons plus tard le déplacer vers src :blush:

@mrdoob ce sera génial.

Je renommerais cependant les nœuds actuels ... NodeColor, NodeFloat, NodeTexture, ... en ColorNode, FloatNode, TextureNode

Je vais le transmettre alors.

c'est l'url locale :blush: , essayez ceci :
http://sea3d.poonya.com/flow/

@WestLangley des suggestions ?

Je suggère THREE.FlowMaterial .

Mon deuxième choix serait THREE.CustomMaterial .

En tant que spectateur complètement aléatoire. NodeMaterial me semble très intuitif, car c'est ainsi qu'ils s'appellent dans Blender3D

Si @mrdoob aime NodeMaterial, nous pouvons nous y tenir. :)

NodeMaterial c'est alors 😁

Ce projet est génial ! Je viens de voir la démo sur Twitter et c'est très impressionnant.

Je me demande si les nœuds devraient être quelque chose qui entrent dans Three core. Ils sont très spécifiques à la mise en œuvre. Je construis moi aussi un éditeur de graphique shader Three.js (pas encore publié) pour ShaderFrog.com, et la solution que j'ai est de simplement exporter le code GLSL et toutes les métadonnées nécessaires comme les noms uniformes, dans un petit fichier JSON, et de le charger avec une bibliothèque d'exécution externe

Cet éditeur de graphiques peut fonctionner avec des shaders complets en analysant leur code source, ce qui signifie qu'aucun type de nœud de shader spécifique n'est requis. Ce type NodeMaterial pourrait-il également être géré entièrement en dehors du noyau de Three ? Tout ce que vous avez vraiment à produire est un RawShaderMaterial pour que quelqu'un l'utilise dans son propre projet.

Ce type NodeMaterial pourrait-il également être géré entièrement en dehors du noyau de Three ? Tout ce que vous avez vraiment à produire est un RawShaderMaterial pour que quelqu'un l'utilise dans son propre projet.

@DelvarWorld Salut. Oui en théorie, mais il est très tôt pour faire un bon shader à partir de raw. Du coup c'est mieux avec une interface initiale. Il aide également à rester compatible avec Skin / Morph et d'autres composants natifs de Three.JS.

J'ai pensé à noter un petit problème :
Dans "Flow", les connecteurs ne sautent pas au niveau supérieur lorsque vous faites glisser les nœuds les uns sur les autres.
Peut-être que ce problème attend des couches ou quelque chose d'encore.

Je me demande s'il existe un moyen d'unifier les deux approches? Je suis intéressé par un shader multicouche et pour cela, vous devez avoir plusieurs BSDF qui contribuent à un résultat final. Cela signifie qu'il faut séparer davantage le modèle d'ombrage - pour le moment, il est assez étroitement couplé dans la conception actuelle de @sunag . Je pense que nous devrions nous diriger dans une direction où il n'est pas nécessaire d'avoir un matériau Standard ou Phong spécifié, il pourrait être brut comme ce que @DelvarWorld a. Je pense que nous pouvons y aller progressivement, donc ce que @sunag a est un bon début.

Ce n'est pas une réponse étoffée, mais il y a quelque temps, j'ai créé une proposition approximative pour un format de shader portable qui inclut des métadonnées, telles que des noms uniformes, leurs types, leur type dans Three.js, etc. https://github.com /DelvarWorld/ShaderFrog-Runtime/blob/master/THREE_SHADER_FORMAT.md

Tout ce dont un shader a vraiment besoin pour fonctionner dans un environnement réel est le code source brut du shader (puisque le GPU le compile) et, pour plus de commodité, quels uniformes l'utilisateur peut définir avec quelles valeurs. Cette proposition approximative n'inclut aucune notion de construction d'un shader par programmation, c'est juste une simple livraison pour GLSL et les métadonnées. Il est compatible avec Three.js car il suffit de le mettre dans un RawShaderMaterial au final.

Actuellement, il n'y a aucun moyen de rendre les shaders portables dans Three.js ou de les exporter depuis n'importe quelle application, c'est ce qui m'a donné l'idée de proposer un standard, et je pense que cela pourrait résoudre nos deux problèmes, puisque nous construisons des applications externes qu'à la fin crachent une matière prédéterminée. Cela signifie également que les détails d'implémentation de la compilation de combinaisons spécifiques d'un graphique sont laissés aux applications, et non à Three.js.

Cette norme de shader proposée a-t-elle sa place dans Three ? Je n'ai aucune idée. Pour le moment, c'est probablement plus utile pour moi que pour le noyau de Three, puisque Three construit ses propres shaders à sa manière.

@DelvarWorld J'ai commencé ce projet sur un moyen de créer un ensemble standardisé de nœuds de graphe de shader :

https://github.com/OpenMaterialGraph/OpenMaterialGraph

Spécifications du nœud ici :

https://github.com/OpenMaterialGraph/OpenMaterialGraph/tree/master/spec/nodes

Spécifications BSDF minimalistes ici :

https://github.com/OpenMaterialGraph/OpenMaterialGraph/tree/master/spec/bsdfs

Ceci est cependant orienté vers le rendu basé sur la physique.

Mon sentiment est qu'il faut avoir un shell de shader pour ThreeJS qui est de niveau supérieur à un shader brut mais de niveau inférieur à celui de Phong shader. Fondamentalement, le shader par défaut serait capable de faire des cibles de morphing, des os, etc. Et puis tous ces shaders de schéma d'éclairage spécifiques (Basic, Lambert, Phong, Standard) utiliseraient ce modèle. À l'heure actuelle, il existe un modèle de shader implicite (nous incluons les mêmes éléments dans chaque shader) - mais je pense que nous pourrions préciser où brancher les éléments. Vous pouvez brancher des schémas d'éclairage (phong, lambert, basique ou multicouche) et vous pouvez connecter des propriétés à ces schémas d'éclairage qui sont vos nœuds généraux.

@bhouston oh sympa, on dirait que nous avons beaucoup d'exigences qui se chevauchent, alias valeur par défaut, nom d'affichage, descriptions lisibles par l'homme, etc. Je ne sais pas ce que l'avenir nous réserve, mais ce serait un changement modérément facile pour moi d'utiliser un format plus proche de ce que vous proposez.

Un format de shader formel a beaucoup de sens. Il devrait cependant vivre avec la bibliothèque, afin qu'il puisse évoluer plus facilement avec elle. Pour quelqu'un qui est plutôt nouveau sur three.js, y a-t-il une raison spécifique pour laquelle une telle chose n'existe pas déjà ? Devrait être intéressant pour l'éditeur si rien d'autre.

* EDIT Peut-être que le fait d'avoir la spécification dans three.js irait à l'encontre de son objectif s'il est destiné à être consommé par d'autres tuyaux de rendu.

Pour le moment, c'est probablement plus utile pour moi que pour le noyau de Three, puisque Three construit ses propres shaders à sa manière.

Vous pouvez générer le même matériel dans un autre langage si vous apportez des modifications à l'intérieur de THREE.NodeGL.prototype.generate une fois qu'un NodeMaterial(*Flow) est un langage visuel. Le NodeBuilder peut en être la porte. Actuellement est l'intermédiaire des données entre les nœuds.

J'ai nettoyé un exemple de NodeMaterial "raw": Il peut encore générer plusieurs bugs.
https://github.com/sunag/sea3d/blob/gh-pages/Labs/Three.JS-NodeMaterial/index.html#L179
https://github.com/sunag/sea3d/blob/gh-pages/Labs/Three.JS-NodeMaterial/node/NodeMaterial.js#L9

Je pense faire avancer cela avec des nœuds racines créés par des particules. NodePass pour Multi-Pass et NodeMaterialD après le PR que dois-je faire dans quelques jours.

J'ai suggéré un THREE.ShaderFrogLoader au lieu d'un shader d'exécution.

Dans "Flow", les connecteurs ne sautent pas au niveau supérieur lorsque vous faites glisser les nœuds les uns sur les autres.

@MasterJames Merci ! Je vais le regarder.

:+1:

J'ai commencé à créer les exemples. J'espère finir cette semaine. :sweat_smile:
http://sunag.github.io/sea3d/Labs/Three.JS-NodeMaterial/webgl_materials_nodes.html

Les pensées?

@sunag +1 :- )

+1 !

C'est tellement génial. Je choisirais par défaut la texture plantes + mur plutôt que le déplacement nuageux. :) C'est tout simplement magnifique.

Je choisirais par défaut la texture plantes + mur plutôt que le déplacement nuageux.

Vous vous référez à l'exemple des « couches » ? Pourtant je posterai d'autres exemples pour nous

gpu soft-body

A titre de comparaison avec une approche différente, l'éditeur de graphiques Shader Frog est maintenant en ligne, et il est dans la phase « kick the tires ». Je tiens à souligner que cela ne nécessite aucune modification du noyau Three.js.

ShaderFrog a actuellement plus de puissance que les éditeurs de nœuds traditionnels. Il a des types de nœuds n'importe quel shader . Par exemple, pour appliquer une réflexion uniquement sur les bords d'un objet, vous pouvez simplement prendre un shader de lueur , qui est un shader entièrement autonome avec un fragment et un vertex shader :

...et le multiplier par un shader de réflexion ...

...à l'aide du graphe de shader...

Et ta-da ! Un shader de jante de réflexion .

Vous pouvez également, par exemple, masquer deux shaders à l'aide de n'importe quel autre shader , et ainsi de suite :

Notez que le seul « type de nœud » requis par ce processus est un nœud multiplié (il y en a d'autres dans ShaderFrog), qui est presque entièrement indépendant de GLSL. ShaderFrog peut fonctionner avec n'importe quel shader, c'est pourquoi il a des types de nœuds infinis. Cette approche technologique avancée permet cette manipulation indépendamment des modifications de Three.js.

ShaderFrog a un support d'exportation de première classe vers Three.js, gratuitement. Le tout sans modifier le code source de Three.js. Sea3D est un produit tiers, comme ShaderFrog. Mettre des mécanismes de produits tiers dans le noyau de Three semble être un avantage injuste et je ne le comprends pas politiquement.

@DelvarWorld Je ne vois vraiment pas une abstraction de construction de shader basée sur des nœuds comme une technologie spécifique à un tiers. En tout cas, cela permet à plus de concurrents de s'impliquer dans la technologie de shader basée sur les nœuds et de bénéficier tous de l'avantage supplémentaire du travail de chacun (plus de nœuds, construction optimisée, etc.).

En tant que programmeur graphique comme moi qui comprend les shaders à un niveau élevé (à partir d'outils comme Blender 3D), mais pas à un niveau bas, l'abstraction basée sur les nœuds semble être un excellent moyen pour moi d'interagir par programmation avec les shaders en utilisant mes connaissances en modélisation 3D. Je comprends la configuration des nœuds pour PBR par exemple, mais que Dieu m'aide si jamais je voulais l'écrire en GLSL.

@DelvarWorld Incroyable. J'adore le nouvel éditeur.

@DelvarWorld +1 Très bien ! : - )

Merci! :)

Je ne vois vraiment pas une abstraction de construction de shader basée sur des nœuds comme une technologie spécifique à un tiers.

Je comprends la configuration du nœud pour PBR par exemple

Une partie de mon contre-exemple ici est que vous pouvez obtenir ces deux éléments gratuitement indépendamment de Three.js. Tous les shaders ShaderFrog sont open source, de sorte que tous les nœuds qui font partie d'une implémentation PBR peuvent également être appris, modifiés et améliorés au fil du temps (ainsi que composés avec d'autres shaders, pas seulement un sous-ensemble du noyau Three.js). Pour moi, le fait que tout cela puisse être accompli sans trois changements signifie que ce n'est pas nécessaire et brouille la frontière entre Three.js étant une API wrapper webgl et maintenant des fonctionnalités spécifiques à l'implémentation. Le stockage des données de nœud de shader est très spécifique à l'application et, à ma connaissance, il n'existe actuellement aucun format standard d'éditeur de nœud commun pour aucun logiciel ? L'application d'un pourrait être préjudiciable à d'autres implémentations.

@DelvarWorld Si je comprends bien ce changement, ShaderFrog pourra toujours fonctionner et continuera d'aller au-delà de GraphMaterial s'il le souhaite. J'ai regardé l'exemple de code source de GraphMaterial et j'ai pu comprendre la simplicité de son fonctionnement sans même avoir à penser à une solution/éditeur tiers. En tant que développeur graphique, je suis préoccupé par la façon de créer par programme des matériaux qui impressionnent rapidement, je pense que c'est une préoccupation appropriée de ThreeJS.

Je pense que NodeMaterial et Flow ont deux objectifs différents. Flow et ShaderFrog sont tous deux des solutions tierces d'éditeurs visuels actuellement en code source fermé (je pense principalement aux artistes pour cela). Je suis d'accord avec @richardanaya dans le sens où ShaderFrog peut aller au-delà de NodeMaterial si vous le souhaitez. Tout comme je pense que Flow n'a pas besoin d'être juste un éditeur de matériel. J'espère vraiment que de grandes améliorations de ShaderFrog à l'avenir, comme d'habitude.

wip: caustique-voronoi
http://sunag.github.io/sea3d/Labs/Three.JS-NodeMaterial/webgl_materials_nodes.html

@sunag Je parcourais votre code source ce soir. Je l'aime vraiment. Quelques retours rapides de mes lectures de ce soir :

• J'aimerais voir un PR le plus tôt possible. Je peux aider. :)
• Il peut être intéressant d'autoriser des attributs arbitraires plutôt que des attributs standard (uv, uv2, normal, position, etc.). Je sais que de nombreux shaders peuvent bénéficier des vec4 tangents, plus que 2 uv et aussi plusieurs couleurs les attributs. Ainsi, je généraliserais le needPosition dans un tableau demandéAttributes ou quelque chose.
• Je suggérerais une organisation des nœuds dans le NodeMaterial principal, les BRDF (Phong, Standard, etc.), les nœuds de texture (NodeCubeTexture, NodeTexture), les nœuds accesseurs (?) (NodePosition, NodeNormal), les nœuds mathématiques (NodeOperator, etc. ), des nœuds utilitaires (NodeSwitch, ...) et des extra (?) (NodeVelocity, ...) Je pense que cela aiderait beaucoup.
• Ce serait bien d'avoir des accesseurs de matrice pour les matrices Projection, View et World.
• Il vous manque certains opérateurs : % ^ & << >> ~ |
• Je ne suis pas sûr de voir la valeur dans NodePhongMaterial lorsque la classe est si petite, je demanderais simplement aux utilisateurs de la créer en utilisant le nœud NodePhong combiné avec un NodeMaterial (bien que je n'aime toujours pas ce nom, GraphMaterial se sent beaucoup plus de nature pour moi, mais je peux vivre avec.)
• J'appellerais NodeTimer -> NodeTime... mais encore une fois une préférence personnelle.
• Je me demande s'il existe un moyen de combiner de nombreux nœuds variables en un seul comme vous l'avez fait avec NodeMath#, NodeOperator. Ceux-ci semblent si similaires : NodeViewPosition, NodeWorldPosition, NodeViewNormal, NodeTransformedNormal, NodeTransformedPosition, NodeProjectPosition...
• J'aimerais voir l'ensemble d'arguments facultatifs pour NodeMath#, NodeOperator sous une forme qui peut être une liste, afin que l'on puisse facilement remplir une liste déroulante avec. En ce moment parce qu'ils sont des membres juste capitalisés sur les classes, il est un peu plus difficile de les identifier. Je ne suis pas sûr d'une bonne solution qui soit toujours pratique pour le codage. Peut-être simplement les rassembler dans une liste après leurs définitions en tant que membres de la classe, alors ajoutez simplement ces listes ?
• NodeTransformedNormal, NodeTransformedPosition sont difficiles pour moi de comprendre ce qu'ils sont sans regarder le code. Sont-ils dans l'espace monde, l'espace vue, l'espace objet ? "Transformé" est un terme très générique, qui signifie simplement multiplié par une matrice. Je vais regarder le code pour eux maintenant...
• Je permettrait à NodeUV et NodeColor de prendre un index plutôt que d'être limités respectivement à 2 et 1 canal. Encore une fois, j'aimerais voir ceux-ci rendus génériques, vraiment vous passez une chaîne ou l'un d'un certain nombre de préréglages plutôt que de le coder en dur sur un ensemble de canaux spécifiques. Vous pouvez toujours avoir des chemins de code dédiés pour certaines variables, mais cela reviendrait à quelque chose de générique pour les noms qu'il ne reconnaît pas pour la gestion des cas particuliers.

Plus de commentaires :

• J'aimerais avoir un graphique avec plus d'un BRDF, essentiellement deux BRDF standard, puis faire la préservation de l'énergie entre eux. Une fois que vous obtenez le PR, je voudrais ajouter cette fonctionnalité. Cela rendra le système plus générique et plus puissant.

@bhouston Ouah ! Merci!

Les attributs de la requête, l'organisation des dossiers, NodeTime, NodePosition, NodeNormal, NodeView ont été révisés. Ajout de +3 exemples également.

dans les opérateurs et la matrice, nous devons ajouter la compatibilité avec les conversions integer et matrix . Pour que cela se fasse de manière automatique comme dans float / vectors#. Nous avons assez de travail pour les prochaines mises à jour.. :sweat_smile:

Demain je ferai le PR. Je dois revoir certaines choses encore.

@sunag :

Je crois que c'est un bug :

addGui( 'metalnessA', roughnessA.number, function( val ) {

                        roughnessA.number = val;

                    }, false, 0, 1 );

Je crois que c'est un bug :

Merci!

J'ai juste eu le vertige en allant sur la page d'exemple et en voyant un graphique de nœud PBR <3

<3
Modifications de la dernière révision
https://github.com/sunag/sea3d/commit/a2e3813b53902331e91dbc0f6bae0136a384ad0c

NodeMaterial rev 4 + NodePass

http://sunag.github.io/sea3d/Labs/Three.JS-NodeMaterial/webgl_postprocessing_nodes.html

Nice !

J'allais suggérer d'utiliser les nœuds pour le post-traitement mais j'attendais que la première partie soit faite. Putain, c'est beau !

NodeMaterial rev 5 + LightNode

http://sunag.github.io/sea3d/Labs/Three.JS-NodeMaterial/webgl_materials_nodes.html

Peau

Ombrage de dessin animé

++ Exemples de color-adjustment et plush .

Génial !

subsurface scattering :sweat_smile:

C'est une sorte de shader qui peut fonctionner dans les futures mises à jour.

http://sunag.github.io/sea3d/Labs/Three.JS-NodeMaterial/webgl_materials_nodes.html

!

Merci pour NodeMaterial génial !

J'ai plusieurs commentaires/bugs :

• Les espaces de fin interrompent le nœud de fonction

var n1 = new THREE.FunctionNode(" float mul_2_float(float x) { return x*2.0; }"); // problem
var n2 = new THREE.FunctionNode("float mul_2_float(float x) { return x*2.0; }"); // ok

• problème avec le paramètre int dans le nœud de fonction

exemple de travail avec le paramètre float :

var floatFuncNode= new THREE.FunctionNode("float mul_2_float(float x) { return x*2.0; }");

var funcCallNode = new THREE.FunctionCallNode(floatFuncNode);
funcCallNode.inputs.x = new THREE.FloatNode(0.2);

var colorResNode = new THREE.OperatorNode(new THREE.ColorNode(0x00ff00),
    funcCallNode, THREE.OperatorNode.MUL);

var mat = new THREE.PhongNodeMaterial();
mat.color = colorResNode;

exemple cassé avec le paramètre int :

var intFuncNode= new THREE.FunctionNode("float mul_2_int(int x) { return float(x)*2.0; }");

var funcCallNode = new THREE.FunctionCallNode(intFuncNode);
funcCallNode.inputs.x = new THREE.IntNode(1);

var colorResNode = new THREE.OperatorNode(new THREE.ColorNode(0x00ff00),
    funcCallNode, THREE.OperatorNode.MUL);

var mat = new THREE.PhongNodeMaterial();
mat.color = colorResNode;

• suggestion : passez les paramètres de la fonction dans le constructeur FunctionCallNode

//current:
var funcCallNode = new THREE.FunctionCallNode(floatFuncNode);
funcCallNode.inputs.param1 = new THREE.FloatNode(1);
funcCallNode.inputs.param2 = new THREE.ColorNode(0x0f0f0f);

// proposed:
var funcCallNode = new THREE.FunctionCallNode(floatFuncNode, 
    { param1: new THREE.FloatNode(1), param2: new THREE.ColorNode(0x0f0f0f) } );

// and, i think suitable in some cases: 
var funcCallNode = new THREE.FunctionCallNode(floatFuncNode, 
    [ new THREE.FloatNode(1), new THREE.ColorNode(0x0f0f0f) ] );

• est-ce que PhongNodeMaterial est compatible avec le bump map ?

quelques remarques supplémentaires :

• problème avec PositionNode.LOCAL dans le shader de fragment dans NodeMaterial "brut":

var material = new THREE.NodeMaterial(
        new THREE.RawNode( new THREE.PositionNode( THREE.PositionNode.PROJECTION ) ),
        new THREE.RawNode( new THREE.PositionNode( THREE.PositionNode.LOCAL ) )
    );

shaders résultants :

varying vec3 vPosition;
void main(){
gl_Position = (projectionMatrix * modelViewMatrix * vec4( position, 1.0 ));
vPosition = transformed;
}

varying vec3 vPosition;
void main(){
gl_FragColor = vec4(vPosition,0.0);
}

La fonctionnalité probablement "transformée" devrait être déplacée des matériaux de nœud Phong/Standart vers NodeMaterial

• Utilisation de ConstNode

    var material = new THREE.NodeMaterial(
        new THREE.RawNode( 
            new THREE.OperatorNode(
                new THREE.PositionNode( THREE.PositionNode.PROJECTION ),
                new THREE.ConstNode("float TWO = 2.0;"),
                THREE.OperatorNode.MUL)
            ),
        new THREE.RawNode( new THREE.ColorNode( 0xff0000 ) )
    );

Dans ce cas, le shader de résultat contient
gl_Position = ((projectionMatrix * modelViewMatrix * vec4( position, 1.0 ))*TWO);
mais la constante DEUX n'est pas déclarée. Est-ce mon erreur ou un bug ?
De plus, ConstNode est sensible au point-virgule, donc "float TWO = 2.0" n'est pas analysé.

Merci @dimarudol ! Si vous voulez vous sentir libre avec les notes dès que possible, vous ferez la nouvelle révision.

mais la constante DEUX n'est pas déclarée. Est-ce mon erreur ou un bug ?

Je considérerai ce mode d'utilisation et en matière par exemple material.include( node )

Essayez alors une constante globale :

var TWO = new THREE.ConstNode("float TWO = 2.0;");
THREE.NodeLib.add( TWO ); // global

 var material = new THREE.NodeMaterial(
        new THREE.RawNode( 
            new THREE.OperatorNode(
                new THREE.PositionNode( THREE.PositionNode.PROJECTION ),
                TWO,
                THREE.OperatorNode.MUL)
            ),
        new THREE.RawNode( new THREE.ColorNode( 0xff0000 ) )
    );

Salut @sunag , j'ai joué avec Sea3d Flow et ça a l'air plutôt cool. Je voulais juste demander s'il existe un dépôt officiel quelque part pour cela.
Salutations.

Salut @rraallvv , pas encore, c'est déjà prêt. Dès que possible, je poste les nouvelles.

Merci @sunag , c'est très apprécié.

Salut @sunag ! Vous avez vraiment fait du bon travail !
J'ai une question : pour mon projet, ce serait bien d'utiliser la structure de vos nœuds, mais j'ai besoin d'une couleur par sommet (et de valeurs flottantes personnalisées par sommet), mais dans votre système de nœuds, vous n'avez que colorNode et floatNode appliqués à l'ensemble du maillage .. Pensez-vous qu'il existe un moyen d'implémenter facilement quelque chose comme un bufferColorNode (en utilisant THREE.BufferAttribute) ?

Par exemple j'ai cette scène :

Chaque sommet a sa propre couleur. C'est possible avec THREE.BufferAttribute et un THREE.ShaderMaterial mais il n'y a pas d'équivalent dans votre code.

J'aurais besoin de quelque chose comme :
`let material = new THREE.StandardNodeMaterial();
let texColorMap = new THREE.TextureNode( new THREE.TextureLoader().load("colorMap.jpg"));
let customData = new THREE.BufferFloatNode(new Float32Array(...), "data"); // Le deuxième paramètre est le nom de l'attribut

let colorMap = new THREE.FunctionNode([
"vec3 colorMap(sampler2D texColorMap, données flottantes){",
" return vec3(texture2D(texColorMap, customFunc(data)));", // customFunc renvoie un vec2 en fonction des données
"}"
].join("n"));

let colorMapCall = new THREE.FunctionCallNode(colorMap);
colorMapCall.inputs.texColorMap = texColorMap;

material.color = colorMapCall;
matériel.build();`

Au fait, il semble que je ne puisse pas utiliser les paramètres sampler2D pour le FunctionNode...

Est-ce que j'ai raté quelque chose ?
Je pense que je pourrais aider si besoin :)

@martinRenou Merci ! Hmm, peut-être quelque chose comme pour l'instant :

bufferGeometry.addAttribute( 'color', new THREE.BufferAttribute( colors, 4 ) );
...
colorMapCall.inputs.data = new THREE.ColorsNode(); // send color.x to float slot

Je n'avais pas encore pensé à affecter un attribut de géométrie dynamique avec node. Mais je pense que c'est une bonne idée... peut-être quelque chose comme THREE.BufferAttributeNode ...

@sunag merci pour ta réponse :)
Je vais essayer ça. Si cela vous convient, je commencerai à travailler sur un THREE.BufferAttributeNode, pour l'instant je lis toujours votre code et j'essaie de comprendre la structure.

1. Concernant THREE.FunctionNode, comme je l'ai dit, j'ai vraiment besoin de définir un sampler2D dans mes paramètres car il est utilisé comme colorMap.. La couleur du pixel est calculée avec texture2D() et le deuxième paramètre de texture2D() est calculé en utilisant mes données personnalisées (qui est par exemple une température).
   Je comprends que l'idée d'utiliser les paramètres vec3 était pour être conviviale avec les utilisateurs, mais FunctionNode pourrait également prendre en charge les paramètres sampler2D, vous ne pensez pas ?
2. De plus, THREE.FunctionNode n'écrit que dans le shader de fragment, mais ne serait-il pas agréable de pouvoir aussi écrire dans le shader de vertex ?

Ce serait mon cas d'utilisation, ça s'appelle IsoColor, car la couleur correspond à une donnée (température, pression...) rouge ->haute température, bleu ->basse température :

1. Je pense écrire un THREE.IsoColorNode (qui remplacerait le FunctionNode de mon diagramme), et d'autres nœuds qui seraient très intéressants pour les visualisations scientifiques. Cela vous intéresse ? @mrdoob serais-tu aussi intéressé ?

Concernant THREE.FunctionNode, comme je l'ai dit, j'ai vraiment besoin de définir un sampler2D dans mes paramètres car il est utilisé comme colorMap.. La couleur du pixel est calculée avec texture2D() et le deuxième paramètre de texture2D() est calculé en utilisant mes données personnalisées (qui est par exemple une température). Je comprends que l'idée d'utiliser les paramètres vec3 était pour être conviviale avec les utilisateurs, mais FunctionNode pourrait également prendre en charge les paramètres sampler2D, vous ne pensez pas ?

Je comprends ton besoin maintenant ! Je vais créer un PR pour cela et d'autres notes du @dimarudol ...

De plus, THREE.FunctionNode n'écrit que dans le shader de fragment, mais ne serait-il pas agréable de pouvoir aussi écrire dans le shader de vertex ?

Je n'ai pas testé cela mais je suppose que oui.

J'ai ajouté deux autres exemples :

• sampler2D sont dans l'exemple triangle-blur
• BufferAttribute sont dans l'exemple custom-attribute

Cela fonctionne mais je vais quand même donner un code poli...

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

Wow ! Tu as vraiment fait du bon travail, ça marche pour moi aussi :sourire:

Merci encore pour votre travail !

Salut @sunag ,

Pour l'instant, nous ne pouvons pas avoir de FunctionNode de type "void" car nous devons l'envoyer au matériau en tant que paramètre (couleur, alpha...). Par exemple, si je veux implémenter un plan de clip FunctionNode, tout ce que je veux faire est de créer une partie de shader comme celle-ci :

void clipPlane(vec4 plane){
 if(dot(position, plane.xyz) > plane.w) discard;
}

Mais ce n'est pas possible de le donner au matériel... Une solution serait de retourner un flotteur qui soit canal alpha, mais ce n'est pas propre et optimisé. Ne pensez-vous pas que ce serait cool d'ajouter des fonctions vides à un matériau comme celui-ci :

var clipPlane = new FunctionNode([
"void clipPlane(vec 4 plane){",
" if (dot(position, plane.xyz) > plane.w) discard;",
"}"].join("\n"));
var clipPlaneCall = new FunctionCallNode(clipPlane);
clipPlaneCall.inputs.plane = myVec4Node;

var threshold = new FunctionNode([
"void threshold(float upperBound, float lowerBound, float data){",
" if(data < lowerBound) discard;",
" if(data > upperBound) discard;",
"}"].join("\n"));
var thresholdCall = new FunctionCallNode(threshold);
thresholdCall.inputs.upperBound = myFloatNode1;
thresholdCall.inputs.lowerBound = myFloatNode2;
thresholdCall.inputs.data = myAttributeNode;

var myMaterial = new StandardNodeMaterial();
myMaterial.color = ...
myMaterial.alpha = ...

// voidFunctions is not a good name I'm not inspired...
myMaterial.voidFunctions = [clipPlaneCall, thresholdCall];

Pour un exemple plus "design", si je veux faire des trous sur ma théière avec cette texture :

J'aimerais faire quelque chose comme ça :

var holes = new FunctionNode([
"void holes(vec3 texColor){",
" if (/*texColor too much dark*/) discard;",
"}"].join("\n"));
var holesCall = new FunctionCallNode(holes);
holesCall.inputs.texColor = new TextureNode(LoadTexture("holes-text.jpg"));

var myMaterial = new StandardNodeMaterial();
myMaterial.voidFunctions = [holesCall];
myMaterial.side = THREE.DoubleSide;

Une autre chose est que nous n'avons pas de contrôle sur l'ordre des fonctions dans les shaders. Si j'ai des fonctions qui ne sont pas commutatives, je n'ai pas de contrôle sur le résultat...

voyons cet exemple :

var transparencyPlane = new FunctionNode([
"float transparencyPlane(vec 4 plane){",
" if (dot(position, plane.xyz) > plane.w) return 0.5.;",
" return 1.;",
"}"].join("\n"));
var transparencyPlaneCall = new FunctionCallNode(transparencyPlane);
transparencyPlaneCall.inputs.plane = myVec4Node;

var displacement = new FunctionNode([
"vec3 displacement(vec3 vector){",
" return position + vector;",
"}"].join("\n"));
var displacementCall = new FunctionCallNode(displacement);
displacementCall.inputs.vector = myVec3Node;

var myMaterial = new StandardNodeMaterial();
myMaterial.transform = displacementCall;
myMaterial.alpha = transparencyPlaneCall;

Si un point est en arrière du plan de transparence et dépasse du fait du déplacement, dans le cas où "transparencyPlaneCall" est appelé avant "displacementCall" alpha = 1., et dans le cas où il est appelé après alpha = 0.5.
J'aimerais donc définir l'ordre des appels de fonction... Vous voyez ce que je veux dire ?

Salut @martinRenou

Hmm, environ void fonctionne peut-être un ProxyNode à utiliser dans le slot car cela doit suivre un ordre ou s'initialiser au début ou à la fin du code, peut-être functionsStart ou functionsEnd emplacements...

L'utilisation du slot alpha si alpha est 0 est automatiquement supprimée.
https://github.com/mrdoob/three.js/blob/dev/examples/js/nodes/materials/PhongNode.js#L180

Je voudrais donc définir l'ordre des appels de fonction...

Existe une séquence voir ici :
https://github.com/mrdoob/three.js/blob/dev/examples/js/nodes/materials/PhongNode.js#L122

L'ordre des fonctions se fait automatiquement en utilisant un simple algorithme dependencies , devrait mettre le FunctionCall dans un emplacement précédent, color est le premier specular est le deuxième par exemple.

Cet exemple est composé de deux codes shader différents : fragment à transparencyPlaneCall et vertex à displacementCall .

Cela me fait penser qu'utiliser des variables ( varying et locals) pour étendre pas les entrées et const seulement sera très intéressant. Peut-être un VarNode ...

Terminé r6 - https://github.com/mrdoob/three.js/pull/9636

L'utilisation de l'emplacement alpha si alpha est égal à 0 est automatiquement supprimée.

Désolé pour ça, je ne l'avais pas vu.

L'ordre des fonctions se fait automatiquement à l'aide d'un algorithme de dépendances simple, devrait mettre le FunctionCall dans un emplacement précédent, la couleur est la première spéculaire est la seconde par exemple.

Je comprends, en fait, je voulais juste être sûr que la fonction qui supprime les pixels était appelée en premier. Cela me semble bien d'utiliser alpha si vous le jetez juste après mes fonctions :smiley:

Cet exemple est composé de deux codes de shader différents : fragment en transparencePlaneCall et vertex en déplacementCall.

Droit ! Ce n'était donc pas un bon exemple. Mon erreur.

Terminé r6 - #9636

Frais ! Merci pour vos réponses.

Cela me fait penser que l'utilisation de variables (variantes et locales) pour développer non les entrées et const seulement sera très intéressante. Peut-être un VarNode...

Ça sonne bien aussi, il pourrait être intéressant de pouvoir écrire explicitement une fonction dans le vertex shader, d'utiliser un varNode et de l'utiliser avec une fonction dans le fragment shader. Ne pensez-vous pas?

@sunag
Je pense qu'il y a un problème avec l'utilisation de AttributeNode avec FunctionNode dans le vertex shader.

Si j'ai un code comme celui-ci :

var customData = new THREE.AttributeNode("data", "float");

var myFunc = new THREE.FunctionNode([
 "vec3 myFunc(float data){",
 " return vec3(data, 0., 0.);"
 "}"].join("\n"));
var myFuncCall = new THREE.FunctionCallNode(myFunc);
myFuncCall.inputs.data = customData;

material.transform = myFuncCall;

Le shader s'écrit dans cet ordre :

...
varying float nVdata;
attribute float data;
...
float myFunc(float data){
 return return vec3(data, 0., 0.);
}

void main(){
...
transformed = myFunc(nVdata); // We use nVdata but it is not initialized
...
nVdata = data;
...
}

Une solution simple serait d'initialiser nVdata aux données ?

Ça sonne bien aussi, il pourrait être intéressant de pouvoir écrire explicitement une fonction dans le vertex shader, d'utiliser un varNode et de l'utiliser avec une fonction dans le fragment shader. Ne pensez-vous pas?

Oui! L'idée est une meilleure communication avec les vertex/fragment shaders en utilisant varying comme VarNode . Cela convient parfaitement maintenant avec la fonctionnalité keywords .

Je crée un exemple minimal de varying mais il n'y a pas encore de solution à void function .

Je pense qu'il y a un problème avec l'utilisation de AttributeNode avec FunctionNode dans le vertex shader.

Corrigé - https://github.com/mrdoob/three.js/pull/9681

Salut @sunag , j'ai vu votre exemple de variation, et cela me semble bizarre de mettre la variation dans mtl.transform comme vous l'avez fait... Peut-être que vous changerez cela quand il sera possible de créer des fonctions vides ?
Cependant, cela semble une bonne idée que les mots-clés comportent :smiley:

En fait, je pense que ce serait une bonne idée de mettre ces variables dans mtl.varyings (mtl.varyings est un tableau) comme ça : mtl.varyings.push(myVar) . En utilisant la même idée, nous pourrions mettre des fonctions dans des shaders de vertex et de fragments comme ceci : mtl.vertexFunctions.push(myVertexFunctionCall) , de la même manière avec mtl.fragmentFunctions .

De cette façon, nous pourrions faire beaucoup de calculs sur ces variables, puis les utiliser pour les effets. Ces fonctions seraient des fonctions vides.

NodeMaterialLoader https://github.com/mrdoob/three.js/pull/13070

Comme dans les captures d'écran ci-dessus où les nœuds sont connectés visuellement, comment recréer cela mentalement avec cette API ? Je vois que les constructeurs acceptent d'autres nœuds. Est-ce ainsi que la sortie d'un nœud (passée dans un constructeur) est entrée pour un autre nœud (il reçoit les nœuds dans son constructeur) ? Un nœud a-t-il au plus une sortie ? Combien de nœuds peuvent être entrés dans un autre nœud via le constructeur, ou est-ce limité ?

@trusktr Est bien sûr limité combien de nœuds supplémentaires cela consomme plus de CPU au moment de la construction et du GPU au moment de l'exécution. Les nœuds sont ajustés en fonction des valeurs d'entrées et de sorties, la conversion de float en vec2 ou vec3 par exemple est automatique, et stocké dans le cache si utilisé plus d'une fois pour l'optimisation (voir TempNode ).

Dans les captures d'écran, chaque nœud est une classe, par exemple : PositionNode affiché est :
https://github.com/mrdoob/three.js/blob/789efa65bafe022e178c7e93e0985a7607a54403/examples/js/nodes/accessors/PositionNode.js#L5

@mrdoob @sunag seriez-vous prêt à commenter l'état actuel du code NodeMaterial et comment il correspond à la feuille de route three.js ?

En théorie, nous pourrions utiliser des nœuds pour plusieurs choses maintenant, comme :

• Implémentez les matériaux glTF spec/gloss PBR en tant que NodeStandardSGMaterial.
• Prise en charge des ensembles et des transformations UV par carte
• Simplifiez l'utilisation des matériaux intégrés avec l'instanciation

Mais il est difficile de justifier l'ajout d'une dépendance dans GLTLFoader pour tous les fichiers de nœuds. Et il est probablement difficile de justifier la mise de nœuds dans src/* sans une utilisation plus active. Œuf de poule. ??

Il serait utile de connaître le plan à long terme pour NodeMaterial, de deviner quelles fonctionnalités sont (ou ne sont pas) liées… cela nécessite-t-il plus de développement ? Y a-t-il des choses que d'autres contributeurs pourraient faire pour aider ?

@sunag ouais, je serais curieux de savoir aussi si vous avez d'autres projets à ce stade.

En théorie, nous pourrions utiliser des nœuds pour plusieurs choses maintenant, comme :

• Implémentez les matériaux glTF spec/gloss PBR en tant que NodeStandardSGMaterial.
• Prise en charge des ensembles et des transformations UV par carte
• Simplifiez l'utilisation des matériaux intégrés avec l'instanciation

Ces problèmes particuliers ont maintenant des exemples de résolution avec les API existantes, sans qu'il soit nécessaire de modifier le noyau :

Instanciation :
https://github.com/mrdoob/three.js/pull/10750 (complètement soufflé, touche le noyau, mais pourrait être patché par un singe)
https://github.com/mrdoob/three.js/pull/14166 (extensions matérielles simples via onBeforeCompile)
https://github.com/mrdoob/three.js/pull/14012 (simple, extension de bibliothèque via mokey-patching)

ensembles par carte-uv
https://github.com/mrdoob/three.js/pull/14174

spec-gloss comme sa propre classe
https://github.com/mrdoob/three.js/pull/14099

Peut-être que cela peut servir à soulager le sentiment d'urgence d'avoir NodeMaterial dans le noyau :).

Pour ceux qui suivent ce sujet, des discussions sont en cours sur https://github.com/mrdoob/three.js/pull/14149.

Rejoindre les fils de #14149 :

tl;dr — NodeMaterial me semble être une prochaine étape très prometteuse pour le système matériel. Je soupçonne que l'adoption de NodeMaterial est actuellement limitée par quelques éléments :

• friction d'inclure de nombreux fichiers individuels
• manque d'éditeur visuel
• relativement peu d'exemples, docs

Je laisserais la question de savoir quand/si NodeMaterial devrait être dans src/ à @mrdoob et @sunag , mais je pense que nous devrions aller de l'avant en abordant (au moins) les trois problèmes ci-dessus. Il serait également utile de savoir si d'autres voient NodeMaterial comme une alternative au système de matériaux actuel ou un remplacement complet.

La masse critique semble se former par les parties prenantes de GTLTFLoader, et mon observation (subjective) est que le besoin est survenu en raison de onBeforeRender mal documenté (quelques exemples) et encore moins documenté onBeforeCompile (un exemple).

@pailhead J'ai commencé à maintenir GTLTFLoader pour résoudre les problèmes de flux de travail dans A-Frame, dont je suis également développeur. Je suis d'accord qu'un système matériel plus utile est l'objectif, pas le chargement d'un format particulier. Décider comment intégrer (ou ne pas intégrer) les matériaux de nœud doit être basé sur les mérites des utilisateurs finaux de la bibliothèque three.js - fonctionnalités, flexibilité, une API compréhensible.

Vous avez raison de dire que les crochets onBeforeCompile et onBeforeRender sont infiniment flexibles ; il n'y a pas de limite pratique à la mesure dans laquelle vous pouvez manipuler ou remplacer les shaders sous-jacents. Mais les deux sont également défectueux en tant qu'API de matériau principal :

1. Force la syntaxe WebGL dans l'API matérielle même pour des fonctionnalités relativement simples
2. Dépend de la manipulation des cordes des shaders de matériaux de base, ce qui rend les modifications des matériaux de base plus difficiles au fil du temps et plus fragiles
3. Moins accessible aux artistes
4. Pratiquement non sérialisable

Les décorateurs (par exemple #14206) améliorent certainement cela du point de vue de l'utilisateur - mais si le développement futur des fonctionnalités des matériaux sera basé sur des décorateurs de plus en plus compliqués au-dessus des shaders de matériaux existants, c'est un danger pour la maintenabilité à mon avis.

Les matériaux des nœuds ne sont pas parfaits, mais ils sont largement adoptés dans d'autres outils graphiques et présentent des avantages clés :

1. Flexible et composable
2. Préserve une couche d'abstraction des shaders WebGL internes de la bibliothèque sans supprimer l'accès aux shaders simples si nécessaire
3. Représentation matérielle très populaire pour les artistes et les développeurs de jeux
4. Au moins quelque peu sérialisable (bien que la conversion vers d'autres formats soit toujours difficile)

Cela ressemble probablement à ce que je dis que onBeforeCompile devrait être déprécié, et je ne veux pas dire - je serais heureux de le voir rester, et les exemples sont les bienvenus. Mais ce n'est pas une API vers laquelle je veux pointer les utilisateurs d'A-Frame ou de three.js pour plus de cas que nécessaire ; Je ne pense pas que cela se compare bien avec les systèmes de matériaux dans d'autres outils 3D.

• friction d'inclure de nombreux fichiers individuels

Cela ne devrait pas être une friction. Je pense qu'il serait utile de faire une sorte d'enquête ou quelque chose du genre, pour voir combien de personnes utilisent des bundlers et construisent des outils. L'importation manuelle de fichiers js dans un fichier html ne devrait pas vraiment être une approche en 2018. C'est le seul nombre que je peux trouver , et je pense qu'on pourrait supposer que tous ces utilisateurs l'utilisent avec quelque chose qui fonctionne avec node.

Je ferais plus d'efforts, pour secouer les arbres et pouvoir correctement import/export , que de m'inquiéter de la façon dont cela fonctionnerait lors de l'inclusion manuelle des fichiers de script.

• manque d'éditeur visuel
• relativement peu d'exemples, docs

Je pense que cela devrait se produire avant que cela ne devienne le noyau. Le matériau brillant spéculaire doit être un exemple qui n'est pas associé à GLTFLoader . Le fait que ce soit en /src ou en /examples ne devrait pas être pertinent ?

@donmccurdy

Vous avez raison de dire que les hooks onBeforeCompile et onBeforeRender sont infiniment flexibles ; il n'y a pas de limite pratique à la mesure dans laquelle vous pouvez manipuler ou remplacer les shaders sous-jacents.

Je ne prétends pas réellement cela, je prétends qu'un crochet comme onBeforeRender permet une approche différente de la structuration du code, mais qu'il ne devrait pas être utilisé comme il est utilisé maintenant dans le GLTFLoader (d'où #14099).

onBeforeCompile certainement des limites et peut être mal nommé. Une bonne chose à souligner dans ce contexte est un récent PR # 14214. Dès que j'ai vu ce qui s'était passé ( build() en faveur de needsUpdate ) j'ai su que j'allais y voir onBeforeCompile . Je l'ai utilisé comme onBeforeParse car si je ne remplace aucune instruction #include <foo> , elles sont toujours analysées après cette fonction et avant la compilation réelle. Dans ce PR, il est utilisé comme onWillRefreshMaterial .

La philosophie que j'essaie de faire passer est qu'il devrait probablement y avoir plus de granularité avec ce genre de rappels. Il devrait y en avoir plus et il faut faire très attention au moment de les nommer.

#14214 est un excellent exemple de la raison NodeMaterial laquelle Au moins pas couplé avec quoi que ce soit dans /renderer , et non fourni avec.

1. Force la syntaxe WebGL dans l'API matérielle même pour des fonctionnalités relativement simples

J'ai déjà entendu ce problème mais il n'a pas été développé. Pourquoi c'est un problème? Qu'est-ce que la « API matérielle » de toute façon ? Je l'ai toujours vu comme "voici quelques matériaux d'ombrage de surface courants".

Si vous voulez une carte dynamique, je ne vois aucune raison pour laquelle material.map , ou 'material.color' ne pourrait pas prendre NodeTexture , GLSLTexture , TextureTexture .

myMaterial.color = new SomeNodeGraph() //outputs vec4 in the end

myMaterial.color = new GLSLInput() // inputs various documented variables, outputs some vec4

myMaterial.color = new THREE.Color()

myMaterial.color = new CustomColorGradientTopBottom() // dunno if its Node, GLSL, regular color whatever, i just know it's compatible with the slot

1. Dépend de la manipulation des cordes des shaders de matériaux de base, ce qui rend les modifications des matériaux de base plus difficiles au fil du temps et plus fragiles

Mon point est que cela est déjà quelque peu possible avec onBeforeCompile mais rend ces changements encore plus difficiles et plus fragiles que ce que vous décrivez. J'ai déjà tendu la main pour cela dans ma vie professionnelle et j'ai un code qui en dépend. Comme il est fragile, cause beaucoup de stress :(

Les décorateurs que vous avez signalés #14206 sont au point mort depuis plus d'un an à cause de ce PR, qui lui-même est au point mort depuis 3 ans. Mon sentiment subjectif est que #14206 rendrait l'écriture de ces décorateurs possible, moins fastidieuse et moins fragile. Ce sont 30 lignes de code qui n'ont absolument aucun impact, à moins que ces propriétés fantômes ne soient définies. Si on nous donne déjà une corde pour nous pendre sous la forme de onBeforeCompile pourquoi ne pas la rendre un peu plus humaine ? :le sourire:

En fin de compte, j'aimerais décider moi-même ce qui est un niveau acceptable de fragile et ce qui ne l'est pas.

1. Moins accessible aux artistes

C'est pourquoi les artistes devraient avoir un outil visuel et une sorte de format pour enregistrer les graphiques. Les consommer en tant que GLSL « cuit » ou quelque chose qui construit le NodeMaterial au moment de l'exécution devrait être un choix laissé à l'utilisateur.

Un artiste pourrait créer un shader, un ingénieur pourrait demander qu'il soit "compilé" afin d'optimiser le processus de chargement. Un artiste travaillant seul pourrait simplement charger le graphique, en supposant que ce soit pour une raison quelconque ("compilé" demande plus d'efforts).

Aussi, pourquoi et comment les artistes sont-ils considérés ici ? Existe-t-il des statistiques, à quoi ressemble un utilisateur "artiste" moyen, pourquoi travaille-t-il avec three.js et non avec l'unité, c'est-à-dire. de quel type de pipeline s'agit-il. Y a-t-il des ingénieurs impliqués, pourquoi pas un outil autonome qui communique avec three.js d'une manière ou d'une autre qu'un répertoire technique adopte, etc. Je suppose que les 40 000 téléchargements npm par semaine ne sont pas des artistes. L'hypothèse est que ce type d'installation est utilisé par certains outils de construction et qu'il est très peu probable qu'il soit importé manuellement.

À la fois sur ce point et sur le point 2, mon cas d'utilisation n'implique aucun artiste, et généralement aucun autre utilisateur. Je développe un système de matériaux, construit sur des matériaux intégrés. J'utilise mon propre déballage normal avec des attributs tangents, un peeling en profondeur, différents découpages, etc. Tout ce qui m'importe, c'est de structurer ce code en interne et d'exposer aussi peu d'éléments internes aux classes ci-dessus.

1. Pratiquement non sérialisable

Je n'y connais pas grand chose et j'ai déjà entendu cet argument. Je serais plus qu'heureux de regarder du code si quelqu'un pouvait m'indiquer les zones problématiques. Avec ma compréhension très limitée (presque nulle) du problème, je ne comprends pas pourquoi il ne suffit tout simplement pas d'écrire

"materialFoo": {
  "color":"#ff0000",
  "specularMap": "some_path.jpg",
  "glossiness": "0.5"
}

Supposons que vous ayez un matériau de brillance de spécification construit avec NodeMaterial , vous ne voudriez pas sérialiser l'intégralité du graphique, uniquement les entrées ? Quelle que soit la sérialisation d'un matériau SpecGloss , elle devrait avoir la même apparence ? Il me manque probablement beaucoup de choses ici, j'apprécierais quelques pointeurs.

Re : sérialisation

Serait-il suffisant d'ajouter :

https://github.com/mrdoob/three.js/blob/dev/src/materials/Material.js#L160

customSerializer( data )

Et puis quelque chose comme

SpecularGlossMaterial.prototype.toJSON = ()=>{
  Material.prototype.call(this, undefined, data =>{
    if ( this.roughness !== undefined ) data.roughness = this.roughness;
  })
}

specularMap serait en fait sérialisé car il est codé en dur :
https://github.com/mrdoob/three.js/blob/dev/src/materials/Material.js#L213

Mais cela semble un peu bizarre, la classe Material est consciente des éléments internes de tous les matériaux intégrés, semble-t-il?

@donmccurdy si vous voulez avoir cette discussion, il serait peut-être préférable de le faire dans le PR du décorateur, #14206. Hors ligne, je suis disponible pour une session de travail autour d'une bière ou d'un café n'importe où dans la région de la baie :slightly_smiliing_face:

Convenu que plusieurs fichiers _ne devraient pas_ être des frictions, et que ce n'est pas un argument en soi pour mettre NodeMaterial dans src/ . C'est simplement l'une des nombreuses raisons pour lesquelles NodeMaterial n'est pas encore très utilisé, et il existe d'autres moyens de résoudre ce problème. Et je suis certainement d'accord pour dire que plus de documents seraient une condition préalable pour mettre NodeMaterial dans src/ , ou même pour pousser l'adoption dans examples/js ou une sortie de build séparée.

Je suis optimiste quant NodeMaterial la direction générale de src/ . Je suis très inquiet à l'idée d'utiliser onBeforeCompile et la manipulation de chaînes comme chemin pour mettre de nouvelles fonctionnalités dans le système matériel, comme décrit ci-dessus, et surtout à mesure que nous nous dirigeons vers la prise en charge de WebGL2 et (éventuellement) de WebGPU . Cela ne veut pas dire que ces deux choix sont les seules options, mais (des deux) ce sont mes pensées.

Sur les autres points, il semble que nous comprenions les préoccupations et les préférences des uns et des autres, mais que nous ne soyons toujours pas d'accord. J'ai écrit tout ce que j'ai le temps d'écrire à ce stade, et je vais attendre un moment et laisser les autres peser. Merci pour cette discussion approfondie et polie à ce sujet. ??

J'aimerais mettre une texture d'occlusion ambiante avec Multiply sur une texture diffuse, alors j'essaye ceci :

const aoNode = new OperatorNode(
        new Math1Node( aoTexture, Math1Node.INVERT ),
        aoScale,
        OperatorNode.MUL
    );
material.ao = aoNode;

C'est ma texture AO

Malheureusement, j'ai vu une occlusion ambiante sur mon modèle.

Avez-vous une idée pour faire ça ?
J'espère que c'est le bon endroit pour poster ma question.

Merci!

J'aimerais pouvoir penser dans le sens d'un mappage des outils existants basés sur des nœuds vers des matériaux dans threejs. Par conséquent, j'aimerais voir NodeMaterial dans src/ avec une documentation appropriée.

@IARI

Pouvez-vous s'il vous plaît énumérer les outils basés sur les nœuds existants ?

@donmccurdy

Merci pour la réponse :)

Malheureusement, je pense que nous ne nous comprenons toujours pas. Si vous avez le temps de lire ce post, ce truc :

Je suis très inquiet à l'idée d'utiliser onBeforeCompile et la manipulation de chaînes comme chemin pour mettre de nouvelles fonctionnalités dans le système matériel,

onBeforeCompile est horrible, je suis d'accord, la seule raison pour laquelle je suis impliqué dans l'un de ces threads est que je veux #13198 que je considère comme supérieur à la manipulation de chaîne de onBeforeCompile .

Cela ne devrait pas être un modèle pour ajouter de nouvelles fonctionnalités à three.js. Il devrait permettre aux utilisateurs d'ajouter de nouvelles fonctionnalités à leurs applications. Je suis triste que @bhouston n'ait partagé aucune conclusion sur le maintien d'un fork pour faire certaines de ces choses. Je serais curieux de savoir s'ils ont fait un meilleur cadre pour changer les shaders, ou s'ils ont réellement piraté le noyau de cette fonctionnalité.

Dans le cas des transformations uv par canal, j'en ferais un exemple ou un module npm. Si 3 personnes le téléchargent chaque semaine, c'est probablement quelque chose qui n'est pas censé être dans le noyau. Si 20 000 personnes le téléchargent, c'est probablement ainsi que three.js aurait dû être conçu en premier lieu.

onBeforeCompile semble être crucial pour les matériaux de nœud, https://github.com/mrdoob/three.js/pull/14214 , il n'est donc pas seulement utilisé pour la manipulation de chaînes .

J'ai onBeforeCompile et NodeMaterial pour faire ça, je demande une troisième option. Beaucoup plus pratique que onBeforeCompile et beaucoup plus petit que NodeMaterial .

Avec des exemples récents :
https://github.com/mrdoob/three.js/pull/14206

Ancienne discussion :
https://github.com/mrdoob/three.js/pull/13198

@pailhead Pour commencer, je penserais à quelques nœuds de base de Blender Cycles.
Je trouverais aussi intéressant de jouer avec Unitys Shadergraph.

@claudioviola Vous pouvez ajouter material.shadow ou multiplier avec diffuse material.color = diffuse * oclusion . Occlusion dépendante de la lumière indirecte, AmbientLight , HemisphereLight ...

@IARI

Je télécharge 7,5 Go de Unity pour vérifier le ShaderGraph :slightly_smiling_face: : Je ne sais pas si cela sera considéré comme un outil pour créer des graphiques de shader, je pense que c'est un outil pour créer des graphiques de shader pour l'unité. Existe-t-il des outils autonomes pour la création de graphiques ? Je veux voir quel type de fichier cela enregistre également le graphique et comment sera-t-il transféré vers three.js et NodeMaterial dans /src .

Je pense que @pailhead est isolé contre ce déplacement de NodeMaterials dans le noyau à ce stade. Je ne pense pas qu'il soit utile que tout le monde se dispute avec @pailhead pendant des jours. Je pense que le projet ne doit pas appartenir à un seul individu.

Cela n'a pas été précipité et cela n'a pas été forcé. Sunag a ajouté cela il y a des années. Il y a actuellement un besoin pour cela et d'autres alternatives n'ont pas fonctionné (par exemple, fusionnées), alors essayons ce chemin.

Chaque outil majeur, 3DS Max, UE4, Blender, Unity, Maya, Sketchfab utilise des graphiques de shader. Affirmer que three.js devrait être en permanence désavantagé à cet égard semble injuste pour three.js.

Je ne sais pas si ce système de shader basé sur des graphes est parfait pour le moment, mais une fois qu'il est dans le noyau, nous pouvons tous continuer à travailler avec.

J'insiste pour que nous continuions à prendre en charge l'API de PhoneMaterial, StandardMaterial, etc. d'une manière ou d'une autre afin de ne pas casser 95% des projets three.js, ce serait irresponsable. Il est également agréable de travailler avec de telles interfaces simples et simplifiées.

Je n'ai ni la capacité ni le désir d'empêcher cela de pénétrer dans le noyau. J'espère juste que cela pourrait débloquer des PR sans rapport, car il a été référencé comme un bloqueur. @bhouston , j'étais juste curieux de connaître votre fourchette et vos expériences avec elle.

Quand j'ai réussi à joindre les deux bouts en tant qu'artiste 3D affamé, j'aime tout ce qui est basé sur les nœuds. Nuke était mon compositeur préféré, et j'aimerais apprendre à créer des outils comme ça. Je souhaite juste que cela débloque ceci en particulier #14231. Je l'utilise comme plate-forme d'apprentissage pour moi-même, mais si cela perturbe, je cesserai de publier, merci.

@pailhead Je n'ai jamais travaillé avec, mais vous avez probablement entendu parler de substance designer ? Pour autant que je sache, cet outil va également au-delà de la création de graphiques / shaders - mais il se concentre principalement sur la conception procédurale des matériaux - c'est peut-être un indice intéressant ?

A part ça, je ne connais pas les outils autonomes du haut de ma tête, mais une recherche rapide sur google a donné ces deux:

• https://victhorlopez.github.io/editor/
• http://www.shaderplay.com/products/nodeflex/overview/overview.html
  semble intéressant.

Cependant, il existe également cet outil pour les nœuds threejs, que j'ai trouvé dans un article twitter de @mrdoob de 2015 - bien qu'il semble n'avoir jamais été mis à jour, je me demande pourquoi ....

Cet outil semble avoir été référencé ici, mais je ne vois aucun moyen d'exporter quoi que ce soit. Le premier lien a l'air incroyable, mais la sortie est assez noueuse, pas très lisible par rapport à GLSL. Je me demande si cela peut déjà être utilisé pour réassembler le NodeMeterial , ou même un ShaderMaterial .

J'ai jeté un coup d'œil à l'unité mais je n'ai pas pu trouver l'outil graphique de shader,

Au fait, si j'ai bloqué cela d'une manière ou d'une autre, laissez-le être débloqué. Le PR date de 2015, j'ai répondu pour la première fois il y a 8 jours.

(Désolé, c'est un peu hors sujet..)
@pailhead For Unity shadergraph : vous devez démarrer un projet Unity avec le modèle de pipeline de rendu léger. Assurez-vous d'ouvrir le gestionnaire de packages Unity et vérifiez que vous utilisez la dernière version du package Render-pipelines.light.
Voici un tutoriel pour le configurer en commençant par un nouveau projet en cours de configuration : https://youtu.be/Ar9eIn4z6XE?t=98

Cet éditeur de nœuds de matériaux Sea3D Flow (http://sea3d.poonya.com/flow/) est de @sunag , le même gars qui a écrit NodeMaterial.

Merci beaucoup @sunag
Comment puis-je obtenir la lumière indirecte? Est-ce une valeur dans le moteur de rendu ou comment puis-je la calculer ?

Je voudrais appliquer un effet de post-traitement à une sélection d'objets uniquement (c'est-à-dire changer la saturation).
Cependant, je ne trouve rien concernant le masquage (s'il n'y a pas d'autre moyen) avec des nœuds.
Actuellement, je lis le OutlinePass (sans nœud) qui écrit un tas de trucs dans un tas de tampons, que je peux voir comme une méthode réalisable pour réaliser ce que je veux - mais je n'ai pas la moindre idée de la façon d'aborder ceci avec des nœuds.

L'éditeur de nœuds de matériaux Sea3D Flow sera autonome comme l'éditeur three.js, ou en fera-t-il partie ? S'appellera-t-il toujours Sea3D ou quelque chose d'autre lié à three.js ? Merci @sunag d' avoir publié cet éditeur visuel dans la communauté three.js.

mais je n'ai pas la moindre idée de la façon d'aborder cela avec des nœuds.

@IARI

Il semble que vous connaissiez GLSL puisque vous êtes capable de lire le OutlinePass et de comprendre ce qu'il fait. Vous semblez également le comprendre suffisamment pour voir que vous ne pouvez pas y parvenir avec des nœuds. Je pensais que si vous saviez comment le coder, vous saurez comment le nouer. De plus, si vous ne savez pas comment le coder, vous savez peut-être comment le nouer. Où est la déconnexion ?

Je n'ai pas du tout vu ces messages de 2016. Intéressant de voir Shader Frog. Je me demande si cela peut être vu comme vim vs emacs ou quelque chose comme ça. J'aime utiliser Sublime Text, vous aimez utiliser autre chose. L'un aime utiliser shader frog, un autre aime utiliser l'éditeur Sea3D de three.js.

J'aime la façon dont Shader Frog produit juste un shader, mais ce n'est pas open source comme Sea3D.

Ensuite, il y a ceci.

Mettre des mécanismes de produits tiers dans le noyau de Three semble être un avantage injuste et je ne le comprends pas politiquement.

Pour moi, le fait que tout cela puisse être accompli sans trois changements signifie que ce n'est pas nécessaire et brouille la frontière entre Three.js étant une API wrapper webgl et maintenant des fonctionnalités spécifiques à l'implémentation. Le stockage des données de nœud de shader est très spécifique à l'application et, à ma connaissance, il n'existe actuellement aucun format standard d'éditeur de nœud commun pour aucun logiciel ? L'application d'un pourrait être préjudiciable à d'autres implémentations.

@bhouston
J'ai hâte que NodeMaterial atterrisse, car cela pourrait débloquer d'autres PR et la vie pourrait reprendre son cours normal. Il semble que d'autres voix aient essayé de bloquer cela dans le passé.

Je pense que @pailhead est isolé contre ce déplacement de NodeMaterials dans le noyau à ce stade.
Je pense que le projet ne doit pas appartenir à un seul individu.

Merci.

Je ne vois aucune raison pour laquelle cela ne pourrait pas être réalisé avec des nœuds exactement de la même manière que outlinepass le fait - mais d'une manière lisible, compréhensible et modulaire de sorte que les pièces puissent être réutilisées.
Pourquoi n'y aurait-il pas, par exemple, des nœuds de sortie qui écrivent dans les tampons et autres.

Et je ne connais vraiment pas très bien glsl, et aussi je trouve - pardonnez mon libellé - une super douleur dans le cul pour lire et écrire du code shader. Et en plus de cela, c'est très douloureux s'il est enveloppé dans un tableau stupide de chaînes en code javascript.

Utilisez-vous webpack ou autre ?

tableau stupide

C'est seulement stupide si vous devez l'importer dans un fichier .html. Lorsque vous travaillez avec webpack et que vous disposez de la syntaxe JS moderne, vous pouvez conserver votre GLSL dans des fichiers .glsl, .vs, .fs et disposer d'une coloration syntaxique, etc.

shader.fs :

void main(){
  gl_FragColor = vec4(1.);
} 

javascript (regarde maman, pas de tableaux stupides)

import mShader from './shader.fs'

Mon souci est que je ne vois pas beaucoup de valeur dans votre besoin puisque vous demandez spécifiquement comment créer un effet, pas comment coder quelque chose. Est-ce que NodeMaterial ouvrira la porte à des milliers de questions "comment puis-je ombrer cet effet", qui n'auront qu'une réponse générique :

Utilise les nœuds, Luke !

Non, devoir lire (et encore moins écrire) du code dans deux langues différentes dans le même fichier est toujours une douleur à voir pour moi. De plus, webpack n'aide en rien, lorsque vous essayez d'étudier un exemple de code de shader threejs qui est entièrement enveloppé dans des stringarrays laids joints par des sauts de ligne.
Quoi qu'il en soit, ce numéro concerne le système de nœuds, et j'ai posé une question simple sur les nœuds - pas pour une discussion sur les préférences de codage personnelles - qui ne mène nulle part.

@IARI

Désolé, je n'ai pas vu de points d'interrogation dans votre message, donc j'ai raté votre question.

Cela ne devrait certainement pas être une discussion sur les préférences de codage personnelles, mais le fait qu'il y en ait différentes devrait être pris en compte. Je suis également un peu préoccupé par la vague de questions "Comment puis-je créer ce shader".

Avant, cette barre était assez haute, les gens abandonnent juste avec i don't know glsl ou quand ils voient "un tableau stupide dans les chaînes". Mais s'il est inférieur, alors tout le monde essaiera d'écrire des shaders.

Je n'ai pas trouvé votre question, mais je suis curieux de savoir ce que c'est. Est-ce :

Comment créer un ToonShader avec NodeMaterial ?

Dans ce cas, je suis curieux de savoir quelle est la réponse.

Vous ne pouvez pas car NodeMaterial ne prend pas en charge certaines abstractions.
Vous pouvez, simplement utiliser NodeMaterial, pour connecter des nœuds

Peut-être que cette discussion gagnerait à être éclatée ? C'est un nombre élevé de messages, qui remontent très loin (2015). NodeMaterial est dans /examples, vous pouvez donc probablement créer votre shader de toon à partir de celui-ci. Peut-être pourriez-vous ouvrir un autre problème ou publier sur le débordement de la pile pour cela spécifiquement, et le reste de la conversation pourrait passer à un nouveau problème ?

Nous pouvons volontiers emmener cette discussion ailleurs, comme une chaîne slack ou autre - j'ai vraiment le sentiment que cela n'a pas sa place ici, mais cela ennuiera surtout les gens.

Le forum pourrait être mieux que mou pour ce cas particulier.

@pailhead , toute cette discussion a déraillé d'être productive. Autant clore ce problème et en faire un nouveau centré sur le problème actuel.

@bhouston

D'accord, sauf que je pense que c'est plusieurs problèmes.

• comment implémenter nodematerial
• si d'autres PR liés et non liés doivent être bloqués
• comment permettre aux personnes qui ne savent pas écrire des shaders d'implémenter certains effets de shader

Comment créer un ToonShader avec NodeMaterial ?
Dans ce cas, je suis curieux de savoir quelle est la réponse.
Vous ne pouvez pas car NodeMaterial ne prend pas en charge certaines abstractions.
Vous pouvez, simplement utiliser NodeMaterial, pour connecter des nœuds

MDR. Je suis d'accord avec @bhouston... cela ne peut être qu'une blague. Vous auriez pu voir l'exemple webgl_materials_nodes avant de le dire ?

Et si vous voulez utiliser du code, voir expression using FunctionNode .

@sunag je pense que tu m'as mal compris. J'étais curieux de savoir pourquoi, s'il s'agit actuellement de /examples et non de /src cela devient-il un citoyen de première classe. Ce problème semble avoir été soulevé par @AndrewRayCode en 2015.

Je viens de dire que cette question est surchargée, s'étendant loin en 2015 et discutant de divers sujets différents. Si quelqu'un demandait "comment puis-je faire un whatever ", il serait renvoyé au débordement de la pile.

S'il s'agit d'une refonte massive de three.js _(le fait que l'unité doive être configurée spécifiquement pour cela me fait un peu peur)_ alors je pense qu'il devrait y avoir un problème en cours dédié ici sur github pour de telles questions - usage of NodeMaterial . En l'état, les personnes qui demandent des choses au hasard (#14232) sont référées à ce fil, cela rend la communication désordonnée :)

J'ai récemment dû écrire un shader de toon mais il était basé sur des lignes, et plus précisément sur les lignes grasses de NodeMaterial ce qui pourrait prendre qui sait combien de temps. Ce sont tous des sujets divers qui sont alambiqués ici.

Et si vous souhaitez utiliser du code, voir expression using FunctionNode.

Si je code, j'utiliserai du texte sublime, ShaderMaterial me convient, pas besoin de FunctionNode . Si je crée des effets visuels, je me tournerai probablement vers un éditeur visuel, mais c'est ma propre préférence. Je ne suis ici que parce que cela a bloqué d'autres PR :) J'ai réalisé il n'y a pas si longtemps qu'il est en fait dans l'intérêt de trois que cela atterrisse le plus rapidement possible. Démêler cette conversation aiderait probablement à accélérer les choses. En cela, je suis d'accord avec @bhouston, cela devrait être yolod dès que possible !

Merci.

Pour info : je ne suis pas intéressé par un shader de toon ou quelque chose comme ça.
J'implémente un système qui permet aux personnes qui n'écrivent pas de code de brancher des effets prédéfinis simples dans certaines positions.

Malheureusement, je crains de ne pas avoir le temps d'étudier comment écrire des nœuds pour le moment, et je dois de toute façon rattraper mon retard sur le codage glsl de base, donc pour l'instant je vais implémenter des choses sans nœuds : ce ne sera pas extensible , il utilisera plusieurs passes de rendu où une seule serait probablement suffisante avec une bonne implémentation des nœuds, elle sera moins lisible, ...

Dans l'ensemble, malheureusement, je suis juste novice dans le domaine général et j'ai besoin d'acquérir une compréhension beaucoup plus élémentaire, mais à en juger par ce que je sais, les nœuds seraient le meilleur moyen de le faire de manière vraiment élégante et extensible.
J'aimerais beaucoup avoir des informations sur la mise en œuvre des nœuds comme un article de blog ou un tutoriel.

Avis de non-responsabilité : je n'exige rien, j'espère juste clarifier ma vague demande d'en haut.
Merci à vous tous pour tout le travail accompli ici - c'est absolument incroyable.

On m'a demandé dans le fil https://github.com/mrdoob/three.js/issues/14232 de commenter l'implémentation du shader basé sur les nœuds. Je pense que c'est très pauvre. J'aime l'idée, mais la mise en œuvre est tout à fait inadéquate à mon avis, donc, puisque je suis si négatif, je vais donner quelques raisons concrètes pour lesquelles.

Compréhensibilité

Après avoir lu une partie du code pour les nœuds et diverses classes d'utilitaires, je peux dire que c'est un énorme défi à comprendre.

• les noms de variables ne sont pas descriptifs
• pas de commentaires du tout
• les noms de méthode sont obscurs ou carrément trompeurs. (par exemple, que pensez-vous que la méthode "build" fait? - faire une supposition)

La structure du code est carrément bizarre. Considérez cet extrait :
https://github.com/mrdoob/three.js/blob/e2b49c017b2d1f37ab34317033a27df7b5a71d4d/examples/js/nodes/FunctionNode.js#L39 -L50

Vous pourriez obtenir la même chose avec :

return this.inputs.find(input => input.name === name);

"Architecture émergente"

Qu'est-ce qu'un « nœud » ? Je demande une définition de la structure des données, car il semble que ce ne soit qu'un concept nébuleux car il y a peu de points communs entre les différents "nœuds", cela ressemble à du ducktyping, s'il cancane comme un nœud - c'est un nœud.

Séparation des préoccupations

Comment passer de Node à un ShaderMaterial ? À l'heure actuelle, c'est un mélange de responsabilités entre divers éléments de logique de chaque nœud, certains constructeurs, certains caches, analyseurs, etc. Il n'y a pas de responsabilité claire pour ce processus. Le nœud utilise NodeBuilder ? Qu'est-ce que le ...? D'après le nom que j'aurais, NodeBuilder est une usine qui produit ou construit des nœuds, car il s'avère qu'il s'agit en fait d'une structure auxiliaire. Pour autant que je sache, il y a des tâches assez distinctes à faire ici :

• Construire un graphique
• Valider
• Construire une représentation intermédiaire
• optimiser
• compiler en GLSL

Ce n'est pas du tout ce que vous trouverez dans le code actuel.

Conclusion

Sans une bonne documentation et des commentaires, je considère cette implémentation comme totalement inadéquate. Avec ces choses en place, c'est une question de code spaghetti et de manque de design. Cela étant dit, je reconnais que c'est un outil puissant et une mise en œuvre fonctionnelle d'un concept très utile.

@Usnul, nous ne

La raison en est que le "=>" crée une fonction qui doit être appelée sur chaque entrée. Les appels de fonction sont très lents en JavaScript par rapport à une boucle for ou while. Ainsi, nous faisons toujours des boucles explicites au lieu de code orienté rappel. Je sais que c'est plus verbeux mais c'est nécessaire. All of Three..JS est comme ça et exprès.

@Usnul , vos préoccupations en matière de conception sont très utiles, pourriez-vous alors aider à la refactorisation ? Je pense que tout le monde apprécierait votre contribution et vos contributions à la conception. :)

La raison en est que le "=>" crée une fonction qui doit être appelée sur chaque entrée. Les appels de fonction sont très lents en JavaScript par rapport à une boucle for ou while. Ainsi, nous faisons toujours des boucles explicites au lieu de code orienté rappel. Je sais que c'est plus verbeux mais c'est nécessaire. All of Three..JS est comme ça et exprès.

c'est un bon point. Personnellement, je pense que les performances et la lisibilité doivent être sur une échelle et non sur l'une ou l'autre, mais la cohérence est bonne. Mon principal problème avec cet exemple spécifique est que ce n'est pas une façon courante d'itérer sur un tableau. Voici une manière idiomatique :

for(var i=0, count=array.length; i<count; i++){
    var element = array[i];
    ...
}

ou disons que vous avez un morceau de code de 50 lignes de la forme :

function complex(a){
  if(a){
      //do a ton of stuff
      ...
      return result;
  }
}

ce n'est pas aussi lisible que :

function complex(a){
  if(!a){
      //omg! not A?!11 
      return;
  }
  //do a ton of stuff
  ...
  return result;
}

@Usnul pourriez-vous aider à refactoriser le code pour en tenir compte ? Je pense que la refactorisation devrait être facile, non? Je suis un grand partisan de Code Complete, ce livre m'a beaucoup influencé.

@usnul si vous n'aimez pas cela, vous serez libre de le remanier ? Peu importe que cela ressemble à ceci ou non, il est juste important qu'il soit construit par-dessus, c'est ce que je comprends.
Je ne sais pas si les réfracteurs devraient se produire pendant que cela se trouve dans des exemples (ou peut-être un autre référentiel) ou devraient-ils être déplacés immédiatement vers src comme le suggère @bhouston .

@IARI

Je ne connais vraiment pas très bien glsl , et je trouve aussi - pardonnez ma formulation - une super douleur dans le cul pour lire et écrire du code shader .

mais à en juger par ce que je sais , les nœuds seraient le meilleur moyen de le faire de manière vraiment élégante et extensible.

Je ne peux pas non plus affirmer que je connais très bien GLSL, mais je le connais suffisamment pour résoudre mes problèmes. D'après ce que je sais, je suis principalement d'accord avec ce que @usnul a écrit ici et ce que @AndrewRayCode a écrit auparavant. Je trouve que le nœud est verbeux par rapport à GLSL.

Si vous ne connaissez pas GLSL, je pense qu'il serait très difficile de le comparer avec autre chose. Comme vous l'avez écrit vous-même, si nous judge on what you know , et que vous l'avez dit vous-même you don't know glsl je pense que votre contribution doit être prise avec un avertissement :)

C'est comme si je disais :

Le Japon est le pire endroit sur cette planète... mais je ne suis jamais allé au Japon".

Merci.

les noms de méthode sont obscurs ou carrément trompeurs. (par exemple, que pensez-vous que la méthode "build" fait? - faire une supposition)

Wow, je n'avais même pas réalisé qu'il s'agissait d'un ShaderMaterial dessous. Je suppose que cela fait tout ce que THREE.WebGLRenderer fait avec les modèles de shader.

Je ne connais vraiment pas très bien glsl, et aussi je trouve - pardonnez mon libellé - une super douleur dans le cul pour lire et écrire du code shader.
mais à en juger par ce que je sais, les nœuds seraient le meilleur moyen de le faire de manière vraiment élégante et extensible.

@pailhead Ce qu'il veut dire, c'est qu'il existe des niveaux intermédiaires entre les choses.

Je ne comprends pas pourquoi cette alarme. @mrdoob ne fusionnera jamais autre chose qu'une excellente solution. Toutes les bonnes relations publiques, les améliorations de n'importe qui dans NodeMaterial ou non sont très utiles pour la communauté. Si cela n'a toujours pas été une fusion dans le noyau, c'est parce que nous devons nous améliorer avec plus de travail.

@sunag y a-t-il quelque chose de particulier que d'autres puissent faire pour vous aider dans ce projet ? Je serais prêt à rédiger de la documentation, si vous êtes prêt pour les documents et que vous pouvez les consulter.

@sunag y a-t-il quelque chose de particulier que d'autres puissent faire pour vous aider dans ce projet ? Je serais prêt à rédiger de la documentation, si vous êtes prêt pour les documents et que vous pouvez les consulter.

Ce sera génial. Sans doute aide-t-il beaucoup.

Le système de matériaux basé sur les nœuds semble incroyable, il augmenterait le pouvoir d'expression.

Comment passerons-nous du système matériel existant au système matériel basé sur les nœuds dans le noyau ? Allons-nous tous les deux remplacer les deux systèmes ou remplacer celui existant par celui du nœud ?

Désolé, peut-être que je ne pense pas avoir rattrapé ce fil parce que ce fil est trop gros...

Allons-nous tous les deux remplacer les deux systèmes ou remplacer celui existant par celui du nœud ?

Je vois le remplacement comme l'objectif ultime, c'est mieux à la fois pour les performances et la maintenance. L'étape suivante consiste à créer un MeshStandardNodeMaterial et d'autres matériaux de nœud dans le noyau exactement comme le noyau en termes de visuel, de syntaxe et de performances.

WIP https://github.com/mrdoob/three.js/pull/14333

Je dois afficher shadowMap dans mon projet.

J'ai une scène avec une lumière directionnelle et 2 géométries utilisant MeshStandardNodeMaterial.

j'ai allumé
castShadow = vrai pour la lumière
castShadow et receiveShadow pour les deux objets.
shadowEnabled = true pour le rendu

Pourquoi ça ne marche pas ?
Dois-je utiliser la propriété shadow du MeshStandardNodeMaterial ? Est-ce le but ?

Est-ce que quelqu'un peut m'aider?
Merci!

@claudioviola
les questions d'assistance vont sur le forum de stackoverflow.

@sunag Pensez-vous que NodeMaterial est suffisamment stable pour que nous puissions commencer par fournir des fichiers de déclaration TypeScript ? Si vous ne prévoyez pas de modifications majeures de l'API dans un avenir proche, je commencerais par cette tâche car NodeMaterial est le dernier groupe de modules sans prise en charge de TS.

@sunag Pensez-vous que NodeMaterial est suffisamment stable pour que nous puissions commencer à fournir des fichiers de déclaration TypeScript ? Si vous ne prévoyez pas de modifications majeures de l'API dans un avenir proche, je commencerais par cette tâche, car NodeMaterial est le dernier groupe de modules sans prise en charge de TS.

@ Mugen87 Oui, il doit y avoir plus d'ajouts que de modifications. Ajouter le support TS sera génial. ??

D'accord, le support TS est prêt avec la prochaine version R017 🙌