Ça a l'air vraiment bien!

Au fait, nous prévoyons de supprimer THREE.GLTFLoader et de renommer GLTF2Loader → GLTFLoader bientôt*. Cela pourrait être une bonne idée de renommer l'exportateur en GLTFExporter avant que r87 n'arrive, pour éviter toute confusion et ainsi il n'y aura pas de changement de nom requis entre les versions. Oups, j'ai raté que tu l'aies déjà nommé ainsi.. continue ! ??

* @mrdoob , une préférence quant au moment où cela devrait se produire ? OMI, nous pourrions le faire maintenant, à moins que nous ne voulions conserver GLTFLoader dans r87 avec juste un avertissement de dépréciation, et le supprimer dans r88 ?

Je pense que le plus tôt sera le mieux. Tant que le nouveau GLTFLoader est capable de détecter 1.0 et d'avertir l'utilisateur que nous ne prenons en charge que 2.0+.

IIRC, nous pouvons détecter en voyant asset comme je l'ai mentionné précédemment.

IIRC, nous pouvons détecter en voyant l'actif comme je l'ai mentionné précédemment.

Ouais ! https://github.com/mrdoob/three.js/pull/11864

Frais! Mais j'ai trouvé un bug mineur. Je fais des relations publiques maintenant. Fusionnons avant de renommer.

Pouvons-nous spécifier les éléments sur lesquels quelqu'un travaille dans la liste de contrôle ?

@takahirox bien sûr ! les gens pourraient simplement écrire des commentaires ici et je pourrais mettre à jour la liste et pointer vers un PR s'il se passe déjà quelque chose

La prochaine chose que je vais travailler est sur les textures, pour les convertir en base64 au lieu d'utiliser uniquement l'url

Merci! Je veux aider à faire de l'exportateur glTF. Je cherche ce que je peux aider dans la liste de contrôle...

BTW avez-vous volontairement laissé deux variables WEBGL_CONSTANTS et THREE_TO_WEBGL globales ?

@takahirox cool !
En ce qui concerne les deux variables, c'est quelque chose que je vais aborder dans le PR suivant pour en faire une partie du WebGLUtils et simplement l'importer. Cela n'a pas de sens que chaque personne qui a besoin de ces constantes doive les redéfinir à chaque fois.

@takahirox d' ailleurs n'hésitez pas à proposer de nouveaux articles à la liste bien sûr ! ;)

@fernandojsg Bien sûr ! À propos des variables, je voulais proposer de les déplacer quelque part si elles sont délibérément déclarées comme globales, il est donc bon de savoir que vous le faites.

Je veux travailler sur la vue tampon partagée.

BufferViews : actuellement, je crée un nouveau bufferView pour chaque accesseur, cela devrait être corrigé pour n'en utiliser qu'un pour ces attributs qui partagent le même componentType

La raison pour laquelle un pour les attributs qui partagent le même componentType, pas un pour tous les attributs, est pour l'alignement des données, n'est-ce pas ?

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#data -alignement

Cool je viens de t'ajouter à la liste au même bufferview. Cela pourrait être un bon point de départ ;)

Je voulais dire, la raison pour laquelle nous ne laissons pas la vue de la mémoire tampon être partagée entre différents types de composants (par exemple, float et short) est de conserver un bon alignement des données, n'est-ce pas ?

Je pense que vous pouvez stocker dans la même vue tampon différents types de composants tant qu'ils ont le même target , par exemple normal (Vec3) , position (Vec3) et uv (Vec2) pourrait être dans la même vue tampon mais pas indices . @donmccurdy pouvez-vous le confirmer ?

Oui, d'accord. Et comme le mentionne cette spécification glTF

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#data -alignement

Le décalage d'un accesseur dans un bufferView (c'est-à-dire accessor.byteOffset) et le décalage d'un accesseur dans un tampon (c'est-à-dire accessor.byteOffset + bufferView.byteOffset) doivent être un multiple de la taille du type de composant de l'accesseur.

C'est une bonne idée que nous séparions les vues de tampon entre les différents componentType (= type de données comme float et short, pas vec2 ou vec3) pour plus de simplicité. Si nous les séparons entre différentes longueurs de données componentType, ce serait plus optimisé.

BTW existe-t-il des raisons particulières pour lesquelles l'exportateur actuel ne prend en charge que accessor.componentType float, uint et ushort ? glTF 2.0 peut gérer les caractères char, uchar et short, en plus d'eux.

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#accessorcomponenttype -white_check_mark

@takahirox pas vraiment, je viens de les définir maintenant car ce sont ceux qui sont utilisés pour le type d'attributs que nous prenons en charge actuellement (positions, normales, couleurs, UV, indices..).
La prochaine étape sur laquelle je travaille concerne les textures, nous en aurons donc besoin d'autres comme uchar par exemple

OK, donc je vais d'abord travailler sur les accessor.componentType moins que vous n'ayez déjà commencé à implémenter.

Presque prêt mais mon PR devrait entrer en conflit avec #11978.
J'envoie donc le mien une fois que #11978 est fusionné et je corrige le conflit.

Souhaitez-vous ajouter une animation à la liste ?

@takahirox bien sûr, ça pourrait être génial d'ajouter de l'animation. Je ne l'ai tout simplement pas ajouté car je ne connaissais pas assez l'état actuel des fonctionnalités d'animation sur three.js, mais si vous avez envie de le reprendre, ce serait génial ;)

Prévoyez-vous de prendre en charge les groupes BufferGeometry ?
Les spécifications GLTF couvrent-elles cela ou entraîneraient-elles la création d'un nouveau maillage pour chaque groupe ?
Cela doit également prendre en compte, la propriété matérielle d'un maillage étant un tableau de matériaux.

@marcatec La spécification glTF a une distinction "mesh" vs "primitive" qui vous permettrait de créer des groupes BufferGeometry qui pourraient chacun référencer un matériau différent. Actuellement, THREE.GLTFLoader n'optimise pas les primitives de chargement — il crée des maillages séparés — mais cela pourrait être implémenté.

Super travail, super liste et bon à savoir qu'il y a déjà tellement de soutien sur le format ! Fonctionne également très bien avec l'exportateur de mélangeur gltf. J'attends avec impatience le support des lumières ! Continuez ce bon travail.

Je confirme, beau travail !

Est-il prévu d'ajouter la prise en charge d'autres matériaux en dehors de StandardMaterial ?

Merci!

@homerjam toutes les propriétés de matériau partagées avec MeshStandardMaterial seront préservées - ainsi, par exemple, un MeshPhongMaterial utilisant map et normalMap exportera avec ces textures intactes, mais lorsque vous le réimporterez dans three.js il sera un MeshStandardMaterial. L'exportateur effectue actuellement une conversion naïve en PBR pour cela.

La prise en charge aller-retour (exporter Phong depuis GLTFExporter, charger Phong depuis GLTFLoader) nécessitera un travail en cours sur le format glTF : https://github.com/KhronosGroup/glTF/pull/1150

baseColorTexture : C'est supporté (material.map) mais le texCoord est toujours mis à 0

@fernandojsg pourriez-vous clarifier ce qui manque ici ? Étant donné que .map est toujours le premier jeu d'UV dans three.js, cela semble être la bonne façon de représenter cela dans glTF ?

Aussi un avertissement, j'ai barré trois éléments sur la liste. Raisonnement ci-dessous :

• tangentes
  
  
  
  • three.js ne les calcule que sur le GPU ; l'ajout d'une implémentation juste pour l'exportateur ne semble pas idéal.
  
  
• accesseurs clairsemés
  
  
  
  • Je pense qu'il vaut mieux laisser cela à l'optimisation post-export, comme le script de mattdesl .
  
  
• vérifier si le matériau correspond à la valeur par défaut de glTF et l'omettre
  
  
  
  • se sent comme un cas de bord / encombrement, n'hésitez pas à mettre en œuvre si quelqu'un se sent fortement cependant
  
  

En exportant vers GLB depuis l'éditeur, j'ai remarqué que alphaMap , roughnessMap et metalnessMap ne sont pas exportés.

En #13397, j'ai dit que normalMap ni l'

En exportant vers GLB depuis l'éditeur, j'ai remarqué qu'alphaMap, roughnessMap et metalnessMap ne sont pas exportés.

Je vais travailler dessus aujourd'hui, sauf si quelqu'un a déjà commencé.

@donmccurdy

accesseurs clairsemés
Je pense qu'il vaut mieux laisser cela à l'optimisation post-export, comme le script de mattdesl.

Envie de laisser l'exportateur prendre en charge les accesseurs clairsemés pour le morphing. Je vais essayer plus tard.

@takahirox cool ! vas-y!

Je ne pense pas que alphaMap soit pris en charge dans glTF 2.0.

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#material

Ouais, j'avais peur de ça.... Et les metalnessMap et les roughnessMap ?

Je travaille dessus maintenant !

13415

Concernant les formats d'images. glTF 2.0 ne prend en charge que les fichiers .png et .jpg en tant que fichiers image externes. Je réfléchis à la manière de gérer les fichiers au format d'image non pris en charge (par exemple: .bmp) en mode non embedImages .

1. Convertir en .png ou .jpg et incorporer
2. Ne vous en souciez pas. Exporter en tant que fichiers image originaux
3. Ne pas exporter

Je préfère 1. Des idées ?

Wow, j'apprécie vraiment le travail de vous les gars.

J'espère que Multi-material meshes sera implémenté dès que possible car la plupart des modèles 3D utilisent des multi-matériaux.

1. Convertir en .png ou .jpg et incorporer
2. Ne vous en souciez pas. Exporter en tant que fichiers image originaux
3. Ne pas exporter

Je vote pour 3 et enregistre un avertissement dans la console.

Espérons que les maillages multi-matériaux seront implémentés dès que possible car la plupart des modèles 3D utilisent des multi-matériaux.

D'accord, pour moi, c'est le problème numéro un empêchant l'utilisation de l'exportateur.

Espérons que les maillages multi-matériaux seront implémentés dès que possible car la plupart des modèles 3D utilisent des multi-matériaux.

Comme je l'ai dit dans l'autre fil, j'y travaille.

1. Convertir en .png ou .jpg et incorporer
2. Ne vous en souciez pas. Exporter en tant que fichiers image originaux
3. Ne pas exporter

Je vote pour 3 et enregistre un avertissement dans la console

Oui, j'en suis venu à penser que 3. serait plus simple et ne serait pas déroutant pour les utilisateurs. Obtenir une image intégrée en mode non emedImages serait un peu déroutant.

La raison pour laquelle je préfère 1. était pour la conversion d'autres formats en glTF. Certains (ou beaucoup) d'autres formats n'ont pas de limitation de format d'image.

L'exportateur convertit en mode embedImages . Donc, ajouter "utiliser l'option embedImages si vous voulez convertir" à l'avertissement de la console serait bien, je pense.

J'irais aussi pour 3 aussi. Comme la conversion à partir d'autres formats peut être fastidieuse, vous devrez de toute façon prioriser certains formats par rapport à d'autres. Cela vaut probablement la peine d'en faire 3 maintenant et d'attendre de voir si gltf ajoute la prise en charge de nouveaux formats de texture comme ktx ou autre et nous pourrions revoir l'implémentation.

Comme indiqué dans https://github.com/mrdoob/three.js/pull/13415#issuecomment -369022383, ce serait bien si l'exportateur pouvait composer la texture ambientRoughnessMetalness pour l'utilisateur. Il vaut probablement mieux placer ce code dans ImageUtils .

J'ai mis à jour la liste de contrôle avec les derniers changements. J'ai ajouté @takahirox à l' multimaterial , et je me charge de la tâche de composition d'images.
J'ai également ajouté l'extension material_unlit, bien qu'elle soit encore en projet, je pense qu'elle est assez proche de la sortie et ne changera pas tant que ça (/cc @donmccurdy)

Espérons que les maillages multi-matériaux seront implémentés dès que possible car la plupart des modèles 3D utilisent des multi-matériaux.

Comme je l'ai dit dans l'autre fil, j'y travaille.

WIP... (Miku a du multi-matériaux)

À propos des formats d'image non pris en charge, ok allons-y pour 3.

@takahirox a l' air bien ! ??

BTW, êtes-vous intéressé par la prise en charge des archives zip ? .glTF + .bin et textures externes conviendraient (peut-être) à d'autres outils de création, mais difficile à faire sans archive. Une archive zip serait donc nécessaire. Et nous pouvons réduire la taille du fichier exporté.

Je le veux et j'ai essayé dans ma branche locale avant, je peux partager plus tard si vous êtes intéressé.

N'est-ce pas à peu près la même chose que gzipping un glb?

.glTF + .bin et textures externes conviendraient à d'autres outils de création (peut-être)

J'espère que les outils de création ne nécessiteront pas de fichiers séparés ; nous encourageons tout le monde à utiliser GLB par défaut. Mais il est plus facile de modifier manuellement une image si elle n'est pas intégrée, c'est sûr.

Aucune opinion bien arrêtée quant à savoir si nous voulons mettre cette fonctionnalité dans THREE.GLTFExporter directement... mais je pense presque que nous ne devrions pas avoir trop d'options qui pourraient plutôt être des post-optimisations sur le glTF. Un autre exemple, Draco est en quelque sorte compliqué et nécessite plusieurs fichiers externes, alors peut-être est-il préférable de laisser des outils spécialisés glTF-to-glTF faire cette optimisation ? Et de même, nous pourrions créer un glb-unpacker (en face de http://glb-packer.glitch.me/) pour aider les gens à décompresser les fichiers de GLB vers ZIP si nous découvrons que les gens en ont besoin.

De https://github.com/KhronosGroup/glTF/issues/1256 —

... l'intention originale de gltf-pipeline - et vraiment glTF en général - rend les exportateurs aussi simples que possible et pousse les optimisations vers un outil commun. Cela aidera aussi, bien sûr, à la fragmentation.

cela dit, aucun glb-unpacker n'existe encore à ma connaissance...

@mrdoob

Je voulais que les images de texture soient externes, plutôt que .glTF vs .glb.

@donmccurdy

J'ai suivi la discussion sur https://github.com/KhronosGroup/glTF/issues/1117 et je suis d'accord pour encourager maintenant l'approche des fichiers intégrés et du pipeline .glb +. Un .glb est bon pour la transmission de données, en particulier pour l'approche Web et pipeline, peut garder les exportateurs et les outils simples et réutilisables. (J'aime aussi l'approche du pipeline de commandes UNIX/Linux !)

Je ne pense donc pas que l'exportateur ait besoin de la prise en charge des archives zip maintenant. Et peut-être qu'il n'a pas non plus besoin d'un accessoire clairsemé et d'un support draco pour la même raison.

Concernant glb-unpacker, je vais peut-être le faire pendant mon temps libre. Je pense que certains artistes aiment les fichiers externes .glTF + car ils sont lisibles sans aucun outil spécifique à glTF. Et parfois, les fichiers externes peuvent réduire le temps de chargement en raison du fichier de chargement parallèle afin qu'il puisse être utilisé à des fins d'optimisation.

En ce qui concerne les outils de pipeline/d'optimisation, je tiens à noter que nous ne voulons pas transférer d' énormes données sur le réseau. Les utilisateurs veulent optimiser/compresser avant de ~transformer~ le transfert de données. Ainsi, le service Web d'optimisation glTF ne fonctionne parfois pas bien pour les données volumineuses, car l'utilisateur doit envoyer un fichier volumineux au serveur.

De plus, pour Three.js et d'autres moteurs basés sur un navigateur JavaScript, nous serions heureux si nous disposions d'outils d'optimisation glTF qui s'exécutent sur le navigateur. Nous pouvons optimiser/compresser avant que les données ne soient transmises aux utilisateurs. Sans eux, les utilisateurs doivent télécharger manuellement les données exportées, puis les transmettre aux outils de pipeline en raison des limitations du navigateur.

De ce point de vue, je souhaite qu'un outil puisse s'exécuter n'importe où, sur navigateur, sur serveur, CUI, etc., pour qu'il soit plus commun et réutilisable. Nous ne voulons pas créer deux fois ou plus les mêmes outils pour différentes plates-formes. Donc, un outil basé sur node.js serait bien ? L'équipe glTF (pipeline) a-t-elle des suggestions ? (Peut-être que cette discussion devrait être faite dans glTF, pas ici.)

Juste au cas où, dans GLTFLoader le support binaire est implémenté en tant qu'extension mais .glb est dans la spécification de base de glTF 2.0, n'est-ce pas ?

Juste au cas où, dans GTLTFLoader, le support binaire est implémenté en tant qu'extension, mais .glb est dans la spécification de base de glTF 2.0, n'est-ce pas ?

Oui, c'était une extension dans glTF 1.0 et je n'ai jamais déplacé ou renommé ce code après qu'il soit devenu une partie de la spécification de base de glTF 2.0.

De ce point de vue, je souhaite qu'un [outils d'optimisation] puisse s'exécuter n'importe où, sur navigateur, sur serveur, CUI, etc., pour qu'il soit plus commun et réutilisable. Donc, un outil basé sur node.js serait bien ? L'équipe glTF (pipeline) a-t-elle des suggestions ? (Peut-être que cette discussion devrait être faite dans glTF, pas ici.)

Cela vaudrait la peine de poser des questions sur la feuille de route de glTF-Pipeline ... glTF-Toolkit semble pertinent, mais ne fonctionne (actuellement) que sous Windows. Personnellement, j'aime Node.js mais C++ ou Rust pourraient être des choix raisonnables avec la compilation vers WASM.

Oh, il me manquait la compilation vers WASM. Spécifier certaines plates-formes de développement recommandées serait une bonne chose pour les développeurs d'optimisation. Je proposerais donc à un fil approprié.

Je suis d'accord avec @donmccurdy car je pense que ces optimisations sur le pipeline pourraient vivre dans un référentiel différent de celui de three.js, afin que tout le monde puisse en bénéficier. Je dois encore vérifier les différences entre le pipeline gltf et les outils de la boîte à outils, mais je m'attendrais à ce que ce type de fonctionnalités y soit inclus.
Je suis également d'accord que tant que nous aurons un WASM, la langue source n'aura pas vraiment d'importance, mais il est également vrai que s'il est écrit en node.js, de nombreux membres de la communauté autour des moteurs Web 3D pourraient probablement aider à les améliorer en tant que sont actuellement la cible principale de ce format de fichier de toute façon.

Je ne suis pas sûr de comprendre "l'optimisation avant la transformation" ... il existe plusieurs types de transformations qu'un pipeline peut effectuer sur un modèle, et les optimisations sont probablement le type de transformation le plus courant ?

D'accord au-delà. Il est bon d'avoir des outils ciblés de bas niveau qui peuvent être utilisés pour créer d'autres outils ou connectés à une interface graphique plus conviviale.

Oups, c'est une faute de frappe. Ne pas transformer mais transférer. Je voulais dire, la plupart des utilisateurs veulent optimiser/compresser avant d'envoyer des données sur le réseau. J'ai mis à jour les messages pour qu'ils soient plus clairs.

salut les gars

J'utilise l'exportateur GLTF THREE.js pour exporter une scène aframe entière en tant qu'objet gltf.
Comment puis-je faire en sorte que les balises a-animation définies sur aframe fassent partie des animations de l'objet gltf ?

@donmccurdy @fernandojsg @mrdoob

Salut @siddhartpai — THREE.GLTFExporter ne convertit que les objets THREE.AnimationClip en animations glTF, alors que le système d'animation d'A-Frame utilise TweenJS. Donc actuellement ce n'est pas possible. Vous voudrez peut-être ouvrir un numéro sur A-Frame ou A-Frame Inspector, qui utilisent également GLTFExporter , pour le demander en tant que future fonctionnalité.

Support multi-matériaux #13536

Je viens de remarquer que le validateur renvoie une erreur sur chaque élément normal sur un bufferview qui n'est pas normalisé. par exemple, si j'ai stocké des valeurs non initialisées comme [0,0, 0], cette erreur s'affichera.
Comme il s'agit d'une erreur et non d'un avertissement/d'un avis, je vois qu'il est sensible à la correction. Que pensez-vous de la normalisation des éléments normaux de bufferview ? Même ainsi, pour les valeurs qui ne peuvent pas être normalisées telles que [0,0,0], devrions-nous utiliser un vecteur unitaire valide ? /cc @donmccurdy

On dirait que NORMAL devrait être normalisé.

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#meshes

NORMALE | "VEC3" | 5126 (FLOTTEUR) | Normales de sommet XYZ normalisées

D'accord pour assurer parce que Three.js normal n'a pas une telle limitation.

Oui, mais que faire lorsque vous n'avez pas de normale réelle, comme une valeur inutilisée de [0,0,0], créez-en simplement une valide et c'est bon ? disons [1,0,0]. Nous devons donc modifier le code de bufferview pour détecter que nous analysons un attribut normal et normaliser chacun avant de l'enregistrer dans la vue de données.

que faire lorsque vous n'avez pas de normale réelle, comme une valeur inutilisée de [0,0,0]

Hm... remplacer par un valide et afficher un avertissement ?

Nous devons donc modifier le code de bufferview pour détecter que nous analysons un attribut normal et normaliser chacun avant de l'enregistrer dans la vue de données.

Je préfère faire ça en processMesh() parce que ce serait plus simple, comme

var originalNormal = geometry.attributes.normal;

if ( hasNonNormalizedValues( originalNormal ) ) {

    geometry.attributes.normal = createNormalizedAttribute( originalNormal );

}

processAccessorHere();

geometry.attributes.normal = originalNormal;

Si nous le faisons dans processBufferView() , le code deviendrait un peu complexe car nous devons veiller à ce que les données soient partagées entre différents attributs, par exemple la position et la normale. (Je sais que c'est un cas d'utilisation très rare mais Three.js ne restreint pas.)

Oui, j'aime cette approche, j'avais peur de modifier les normales après l'exportation, mais ça devrait aller si nous sauvegardons une référence les remettre après avoir terminé. :+1: Cela vous dérangerait-il de pousser un PR avec ces changements ? ou tu veux que je le fasse ?

D'accord, je le ferai. (Êtes-vous pressé de résoudre ce problème ?)

@takahirox cool, merci ! mais pas pressé j'étais juste en train de passer en revue l'état de l'exportateur ^_^

OK, alors je ferai ~demain~ cette semaine.

D'accord, glTF ne permet pas d'omettre des normales sur des sommets particuliers mais pas d'autres dans une seule primitive. Nous devrons fournir une sorte de valeur, supprimer ces sommets ou générer une erreur.

Je préférerais rendre les choses plus faciles pour l'utilisateur, donc mon vote est de créer un nouveau tableau de normales en les normalisant et en ajoutant une valeur (0,1,0) pour les vides.

Semble correct. Si c'est lent pour les grands modèles, nous pourrions vouloir une option checkNormals ou quelque chose comme ça, donc les utilisateurs qui n'en ont pas besoin peuvent se retirer, plutôt que de scanner chaque sommet.

Oui, j'étais sur le point d'écrire la même chose ! :RÉ

Si c'est lent pour les grands modèles, nous pourrions vouloir une option checkNormals ou quelque chose comme ça, donc les utilisateurs qui n'en ont pas besoin peuvent se retirer, plutôt que de scanner chaque sommet.

Je vais d'abord faire des relations publiques sans cette option. Ajoutons quand/si nécessaire. Personnellement, je suppose que ce contrôle ne ralentit pas beaucoup.

Je vais d'abord faire des relations publiques sans cette option. Ajoutons quand/si nécessaire. Personnellement, je suppose que ce contrôle ne ralentit pas beaucoup.

Je normalisais l'ensemble des tampons lors du chargement de chaque trait sur a-painter et c'était assez lent

Même s'il ne s'agit que de vérifier s'ils sont normalisés ?

@takahirox, vous devrez de toute façon calculer la longueur, donc je suppose que cela ne changera pas tant que ça

HM OK. Je vais évaluer avec le PR.

C'est la première fonctionnalité de GLTFExporter que nous avons introduite qui effectue n'importe quel calcul avec chaque sommet (à l'exception de la conversion de cible de morphing relative/absolue), donc oui potentiellement plus lent... dans tous les cas.

Bon travail! IMHO devrait être fusionné dans core three.js, plutôt que dans des "exemples".
J'adorerais voir le support de KHR_lights_punctual !

PR https://github.com/mrdoob/three.js/pull/15519 ajoute KHR_lights_punctual. :)

Je pense que ce problème peut probablement être résolu - les éléments restants sont moins pratiques ou optimisés et peuvent être suivis ailleurs :

• [ ] réutiliser les vues tampon
• [ ] fusionne automatiquement les textures métal/rugueux/ao

Hé les gars, est-ce que quelqu'un sait comment exporter un maillage de forme personnalisée en appliquant les changements de morphing et en le supprimant de l'objet final ?
Comme cette question https://stackoverflow.com/questions/57423471/how-to-export-morph-changed-meshes-from-threejs-application
Merci d'avance!

@vini-guerrero Veuillez utiliser les forums (https://discourse.threejs.org/) ou Stack Overflow pour obtenir de l'aide, plutôt que les problèmes GitHub.