Three.js: GLTFExporter GLB compatible avec la visionneuse Facebook

/ping @zellski

Hey! Oui, ce contrôle RGBA devrait disparaître dans deux semaines. Ne travaillez pas autour de ça. :)

J'essaie de convertir WaltHead.obj en glb. Je le charge dans https://threejs.org/editor/ et je l'exporte vers GLB à partir de là (qui devrait déjà avoir les derniers correctifs).

Voici WaltHead.glb et voici ce que

Your GLB File has the following errors: The 3D model could not be posted: The JSON portion of this model file is invalid.

??

C'est du JSON syntaxiquement valide, mais les valeurs NULL dans cet extrait de WaltHead.gltf ne sont pas conformes au schéma de type :

    {
      "bufferView": 2,
      "componentType": 5126,
      "count": 48480,
      "max": [
        null,
        null
      ],
      "min": [
        null,
        null
      ],
      "type": "VEC2"
    }

L'outil de validation Khronos glTF répertorie également environ 10 000 instances d'autres erreurs dans le fichier, toutes de l'ordre de :

        /accessors/2: Accessor element at index 28922 is NaN or Infinity.

Il semble donc qu'un accesseur soit généré lors de l'exportation glTF, pour être rempli d'indices, mais n'en reçoive jamais réellement ?

Les UV sont NaN : 🙃

@mrdoob @donmccurdy corrigé ! https://github.com/mrdoob/three.js/pull/13400
Bien que nous ne puissions toujours pas montrer cet exemple en raison de

[msg] => Mesh primitives without indices are (temporary) unsupported.

(ajouté à la liste de choses à faire)

@zellski avez-vous une estimation de cette fonctionnalité ? ;)

@fernandojsg Celui-ci est un peu plus délicat. Ça va être réparé, mais ça peut prendre un peu plus de temps. tl;dr Peut-être un mois ?

Explication plus longue : le problème est similaire à celui de la couleur du sommet ci-dessus, en ce sens que ce sont nos implémentations clientes qui sont à la traîne, et mon validateur sur le backend les protège simplement des modèles qu'ils ne peuvent pas encore gérer.

Évidemment, nous devons prendre en charge la géométrie non indexée, le plus tôt sera le mieux. Idéalement sur les clients, mais aussi d'ici là, je devrais avoir mon code backend jusqu'à la pleine puissance de Death Star, où nous transformons tous les fichiers .gltf téléchargés paresseusement/à la demande, en fonction des besoins individuels des clients. À ce stade, nous pouvons faire des choses intéressantes comme créer une géométrie indexée sur le serveur pour la commodité de nos clients.

Je suppose que l'erreur ci-dessus survient lorsque three.js essaie d'exporter des primitives qui sont naturellement non indexées dans sa représentation d'exécution ?

Je suppose que l'erreur ci-dessus survient lorsque three.js essaie d'exporter des primitives qui sont naturellement non indexées dans sa représentation d'exécution ?

@zellski c'est tout ! Certaines primitives ou objets chargés sur trois sont non indexés. Le premier cas d'utilisation que j'ai pensé pour le chargeur facebook glb était d'inclure des dessins de notre application A-Painter (plus d'informations : https://blog.mozvr.com/tag/a-painter/) et nous y utilisons une géométrie non indexée aussi, donc ce serait super d'avoir du soutien pour ça ;)
Je voulais juste savoir si c'était sur la feuille de route, donc savoir que c'est ça et que nous pourrions l'avoir dans environ un mois, c'est plus que raisonnable ;) merci d'avoir partagé cette information !

Nous devrons peut-être ajouter un attribut d'index stupide en attendant (comme dans 0, 1, 2, 3, 4, 5, 6, 7, 8, ...) 😕

@mrdoob voulez-vous dire avoir une méthode pour convertir les non indexés en indexés comme vous le souhaitez, ou ajouter le hack directement sur l'exportateur ?

Ouais, ajoutez un hack temporel dans l'exportateur...

Je ne sais pas, je veux juste que les choses fonctionnent et ne pas avoir à dire aux gens : " oh ? Votre modèle ne fonctionne pas sur Facebook ? C'est parce que... vous savez ce que sont les géométries indexées ? Ouais, vous ne devriez pas, mais ..."

Oui, j'ai compris! Ok je vais jeter un oeil pour voir si je peux ajouter un hack pas si sale :)

@zellski pour le contexte...

J'ai ajouté un Export GLB dans http://threejs.org/editor/ qui utilise ce GLTFExporter .

Vidéo : comment exporter le modèle au format glTF sur l'éditeur Three.js :D

https://twitter.com/superhoge/status/966689549803053056

Croyez-moi, je comprends la réticence à ajouter des hacks. C'est tout un combat de maintenir une attitude patiente maintenant que nous avons lancé...

Pourriez-vous faire le hack GLTFExporter dans un fork qui est utilisé dans http://threejs.org/editor/ mais pas ailleurs ? J'espère que nous aurons corrigé cette faille d'ici la sortie de r91, il semble donc un peu inutile que vous écriviez un code prudent et responsable pour cela.

Pourriez-vous faire le hack GLTFExporter dans un fork qui est utilisé dans http://threejs.org/editor/ mais pas ailleurs ?

Ouais, pas de soucis !

J'espère que nous aurons corrigé cette faille d'ici la sortie de r91

Oh, j'ai l'intention de sortir le ~ 1er mars. Changement du cycle de publication au début du mois pour avoir des versions mensuelles appropriées.

On dirait que nous avons encore plus de fonctionnalités à ajouter avant de promouvoir cela de toute façon. Je ne pense pas que nous exportions des textures de rugosité, métalliques, normales ou alpha.

Dernier test, utilisant 2 cartes diffuses, l'une des nuages ​​étant un png transparent :
https://www.facebook.com/fakemrdoob/posts/950266411809572

Je ne sais pas d'où vient le alphaTest: 0.5 apparent...

En utilisant simplement la solution de contournement pour les indices :)
https://www.facebook.com/fernandojsg/posts/10156405595122044

Et voilà https://github.com/mrdoob/three.js/pull/13410

@mrdoob, cela vous dérange- https://github.com/mrdoob/three.js/issues/11951
Bien que j'ai besoin de mettre à jour le statut là-bas 😇

Ça a l'air bien. Je vais tester en exportant et en faisant glisser vers l'éditeur.
Doit-on fermer celui-ci ?

@mrdoob Je le laisserais ouvert jusqu'à ce que le problème RVB vs RGBA pour les couleurs de vertex soit résolu du côté de Facebook, donc si les gens viennent ici pour chercher de l'aide, ils pourraient lire à ce sujet au lieu d'ouvrir un autre problème.

Au fait, je viens de trouver ce lien avec des informations utiles : https://developers.facebook.com/docs/sharing/3d-posts/glb-tutorials

Apparemment, les textures doivent avoir une puissance de 2...
https://twitter.com/drupalati/status/967486854630055936

Est-ce que Three.js ne convertit pas automatiquement l'image de non-puissance-de-deux en puissance-de-deux à la volée ?

Oui désolé. Les clients mobiles ne se redimensionnent pas encore, nous devons donc le rejeter pendant la validation pendant un certain temps. Nous ferons probablement le redimensionnement sur le serveur, car nous avons un contrôle total sur le pipeline de livraison. J'espère que cette restriction sera également levée dans 2-3 semaines.

@takahirox Oui, three.js sera redimensionné à la volée. Mais les clients natifs de Facebook n'utilisent pas three.js.

La liste complète des fonctionnalités glTF que Facebook ne prend pas encore en charge, dans l'ordre approximatif de l'ETA :

• Pas de couleurs de vertex RVB ; doit être RGBA.
• Pas de textures NPOT pour certaines combinaisons serrage/filtre
• Géométrie triangulaire indexée uniquement.
• Aucune animation (ignorée en silence)
• Pas d'accesseurs clairsemés (échec de la validation)
• Aucune cible de morphing (si un maillage a une propriété 'target', la validation du modèle échoue)
• Pas de caméras (ignorées en silence) (pour l'instant)

Aussi:

• Taille de fichier maximale 3 Mo
• Aucune dimension de texture supérieure à 4096
• Aucune extension autre que KHR_material_unlit (pour l'instant)

Je pense que c'est ça.

J'ai fait PR #13424 pour forcer la texture POT parce que je pense que cela ne vaudrait pas la peine que pour FB.

Lors de l'utilisation de GLTFExporter pour exporter un maillage multi-matériaux (un tableau de matériaux), j'ai eu cette erreur :

GLTFExporter.js:623 Uncaught TypeError: Cannot read property 'toArray' of undefined
    at processMaterial (GLTFExporter.js:623)

@Ben-Mack C'est un problème connu et j'y travaille maintenant. (Mais ça prendrait un peu de temps).

@zellski des plans pour le support de draco sur fb ? Je peux réduire mes mailles de 40 Mo à 5 Mo, mais ces derniers Mo ne baisseront tout simplement pas.

@webprofusion-chrisc (c'est un @ long pour un clavier de téléphone) oui, Draco est très certainement sur la feuille de route. Cela nécessite pas mal de travail d'ingénierie, donc c'est au moins un mois, mais – à bien des égards, nous avons construit nos hypothèses autour de cela – comme vous le dites, pour de nombreux modèles, la limite de 3 Mo est tout simplement intenable. (Je ne sais toujours pas ce que nous pouvons faire pour aider avec les textures.)

(Je ne sais toujours pas ce que nous pouvons faire pour aider avec les textures.)

@donmccurdy progresse sur ce front : https://github.com/mrdoob/three.js/pull/12877 😀

Nous pouvons nous attendre à des textures 25 à 30% plus petites de GLTFExporter avec le #12877.

À plus long terme, Binomial travaille avec Khronos pour créer une extension pour les textures compressées multiplateformes dans glTF : https://www.khronos.org/blog/call-for-participation-gltf-creating-a-compressed-texture-extension .

D'accord... Après #12877 et #13451, une exportation GLB qui était de 3,3 Mo est maintenant de 480 Ko 😊

Frais! #13451 signifiait que la taille du fichier image serait plus importante si nous convertissions jpg en png ?

Frais! #13451 signifiait que la taille du fichier image serait plus importante si nous convertissions jpg en png ?

Oui. #13451 est un peu une solution de contournement car l'éditeur ne permet pas de changer le format d'une texture pour le moment. Mais on fait quand même la même chose à la bibliothèque...

https://github.com/mrdoob/three.js/blob/dev/src/loaders/TextureLoader.js#L34

Mais oui, GLTFExpoter actuellement enregistré au format jpg lorsque texture.format === THREE.RGBFormat .

https://github.com/mrdoob/three.js/blob/dev/examples/js/exporters/GLTFExporter.js#L493

Ce qui n'est pas idéal, car on recompresse un jpg... Mais mieux que des exports surdimensionnés je suppose ?

J'ai dû ajouter du code à FBX2glTF qui inspecte en fait les valeurs alpha de même les images RGBA, car les gens (ou, plus précisément, les outils des gens) les créent par défaut, et bien souvent il est tout à fait inutile de les conserver au format PNG. Même après avoir essayé les plus brutaux processeurs PNG à optimisation non linéaire et compatibles GPU, il semble que JPEG règne vraiment sur le perchoir... la différence de taille est assez incroyable !

Je suis un peu inquiet au sujet du saignement intercanal pour des choses comme la texture ORM (occlusion/rugosité/métal) où chaque composant transporte des données totalement indépendantes des données des autres composants... mais en pratique, cela semble bien fonctionner.

L'exportateur pourrait également rendre le niveau de qualité facultatif lors de l'utilisation de canvas.toDataURL( mimeType ) - mes textures sont générées lors de l'exécution à partir d'images composites, ce qui serait également utile.

@zellski pour le pipeline/viewer de fb Je suppose que vous pourriez faire comme sketchfab et servir une version de texture basse résolution, puis diffuser les textures haute/pleine résolution et les remplacer dans le modèle au fur et à mesure qu'elles se chargent. Pas un petit travail mais faisable.

@webprofusion-chrisc Oui, nous pourrions finir par le faire. Pour le moment, nous avons opté pour le .glb comme entité transmise, ce qui est difficile à combiner avec un streaming de type LOD sélectif (car il n'y a qu'un seul fichier séquentiel sans accès aléatoire). Mais je pense que nous réévaluerons assez souvent les hypothèses de base, en fonction de la façon dont les choses se passent. :)

GLTFExporter peut exporter BufferGeometry et importer sur Facebook très bien. Mais les Geometry ou BufferGeometry convertis à l'aide de la méthode fromGeometry ne fonctionnent pas sur Facebook. Je reçois toujours ceci dans le validateur FB :

[msg] => Les attributs Vertex COLOR_0 de type RVB ne sont (temporairement) pas supportés. Ils doivent être RGBA.

Étape à reproduire :

• En utilisant l'exemple de misc_exporter_gltf plus récent dans le dev, Export Sphere ou Walthead fonctionne bien sur FB, mais le résultat export Scene1 ne peut pas être importé dans FB.

S'agit-il d'un comportement attendu et devez-vous attendre côté FB ?

Je m'attendais à ce que BufferGeometry utilisant fromGeometry fonctionne de manière extraite comme BufferGeometry normal, veuillez me guider quelques correctifs rapides pour surmonter ce problème.

@Ben-Mack c'est quelque chose qui devrait être corrigé dans les prochaines semaines selon @zellski -> https://github.com/mrdoob/three.js/issues/13397#issuecomment -367534958

À partir de la version 161 et ultérieure (la version actuelle de l'App Store est 160) de l'application FB principale, ce ne sera plus un crash et nous supprimerons ce contrôle de validation. Je m'attends à ce que cela se produise dans la semaine.

@zellski c'est génial ! Merci :)

Je me demande quand même...

La "vraie" raison THREE.GLTFExporter laquelle THREE.Geometry est que lorsque nous convertissons THREE.Geometry en THREE.BufferGeometry nous créons un color attribut qui est, dans la plupart des cas, plein de zéros.

Ainsi, une "solution" (et optimisation) serait de ne pas exporter l'attribut color si material.vertexColors est défini sur THREE.NoColors ?

Ops je ne le savais pas :D c'est certainement une optimisation incontournable :D

@fernandojsg merci pour les mises à jour que vous avez faites, très appréciées. Il y a encore deux choses à ajouter :

1. Prise en charge des mailles multi-matériaux. Ceux qui ont des groupes dans leurs géométries et un tableau dans Mesh.material - ils ne peuvent actuellement pas être exportés correctement ;
2. Meilleure compatibilité entre le seul MeshStandardMaterial pris en charge et le résultat que nous avons sur Facebook. Jusqu'à présent, les surfaces métalliques et diffuses sont assez différentes dans three.js et sur Facebook. Peut-être aurons-nous un jour un matériel spécial "Facebook" ?

Merci

@ov Je pense que les deux sont susceptibles d'être corrigés autour de r91 :

1. exportation multi-matériaux https://github.com/mrdoob/three.js/pull/13536
2. corrections de métal/rugosité https://github.com/mrdoob/three.js/pull/13501

Il est possible que les documents de Facebook ne soient pas encore tout à fait corrects non plus, mais glTF est assez précis sur la façon dont les choses devraient apparaître, donc nous devrions finalement converger.

Oh, nous devrions également ajouter la possibilité d'exporter KHR_materials_unlit ...

EDIT : ouvert https://github.com/mrdoob/three.js/pull/13566

La « vraie » raison pour laquelle THREE.GLTFExporter ne peut pas exporter THREE.Geometry est que lorsque nous convertissons THREE.Geometry en THREE.BufferGeometry, nous créons un attribut de couleur qui est, dans la plupart des cas, plein de zéros.

Ainsi, une « solution » (et une optimisation) serait de ne pas exporter l'attribut de couleur si material.vertexColors est défini sur THREE.NoColors ?

+1 j'espère que ce sera bientôt corrigé. Beaucoup de bibliothèques pour Three.js fonctionnent toujours sur la base de THREE.Geometry .

( FB a toujours l'erreur ...must be RGBA avec THREE.Geometry )

@Ben-Mack, quelles bibliothèques utilisez-vous qui utilisent encore la géométrie ? Peut-être pourrions-nous travailler avec les propriétaires pour les mettre à jour.

@looeee Veuillez jeter un œil à cette bibliothèque : https://github.com/a-jie/threejs-geometry-modifiers

Salut les amis, depuis ce matin, Facebook ne rejette plus les couleurs de vertex RVB (VEC3) comme « invalides ».

Les exigences relatives aux textures au pouvoir de deux restent pour le moment, mais j'y travaille aussi.

@zellski cool ! :) Je suis très proche d'avoir un support complet pour a-painter :D Y a-t-il un plan pour implémenter le reste des modes primitifs ? Pour le moment, je pense que seuls TRIANGLE sont pris en charge, cela pourrait être formidable de prendre en charge le reste, par exemple dans A-painter, nous utilisons TRIANGLE_STRIP pour économiser de l'espace 👼

Ce serait fou de ne pas les mettre en œuvre, non ? Idéalement, tous les glTF valides devraient être acceptés. Je ne sais pas comment ce travail sera priorisé, cependant. Nous sommes une petite équipe avec beaucoup de fortes envies. :)

Je pense que ce problème peut maintenant être fermé?