Three.js: GLTFExporter GLB kompatibel mit Facebook-Viewer

/ping @zellski

Hey! Ja, dieser RGBA-Check sollte in zwei Wochen weg sein. Arbeiten Sie nicht drum herum. :)

Ich versuche, WaltHead.obj in glb zu konvertieren. Ich lade es in https://threejs.org/editor/ und exportiere es von dort nach GLB (das bereits die neuesten Patches enthalten sollte).

Hier ist WaltHead.glb und das bekomme ich im Validator von Facebook:

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

🤔

Es ist syntaktisch gültiges JSON, aber die Nullen in diesem Snippet von WaltHead.gltf entsprechen nicht dem Typschema:

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

Das Khronos glTF-Validator-Tool listet auch etwa 10.000 Instanzen eines anderen Fehlers in der Datei auf, alle in der folgenden Reihenfolge:

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

Es scheint also, dass beim glTF-Export vielleicht ein Accessor generiert wird, der mit Indizes gefüllt wird, aber nie wirklich welche erhält?

UVs sind NaN: 🙃

@mrdoob @donmccurdy behoben! https://github.com/mrdoob/three.js/pull/13400
Obwohl wir dieses Beispiel immer noch nicht zeigen können, weil

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

(zur To-Do-Liste hinzugefügt)

@zellski hast du eine Einschätzung zu dieser Funktion? ;)

@fernandojsg Dieser ist etwas schwieriger. Es wird behoben, aber es kann etwas länger dauern. tl;dr Vielleicht einen Monat?

Längere Erklärung: Das Problem ähnelt der Vertex-Farbe oben, da unsere Client-Implementierungen hinterherhinken und mein Validator im Backend sie nur vor Modellen schützt, die sie noch nicht verarbeiten können.

Natürlich müssen wir nicht indizierte Geometrie unterstützen, je früher, desto besser. Idealerweise auf den Clients, aber auch bis dahin sollte ich meinen Backend-Code bis zur vollen Death Star-Power haben, wo wir alle hochgeladenen .gltf faul/on-demand umwandeln, je nach individuellem Kundenbedarf. An diesem Punkt können wir für unsere Kunden coole Dinge tun, wie zum Beispiel indizierte Geometrie auf dem Server erstellen.

Ich gehe davon aus, dass der obige Fehler auftritt, wenn Three.js versucht, Primitive zu exportieren, die in ihrer Laufzeitdarstellung natürlich nicht indiziert sind?

Ich gehe davon aus, dass der obige Fehler auftritt, wenn Three.js versucht, Primitive zu exportieren, die in ihrer Laufzeitdarstellung natürlich nicht indiziert sind?

@zellski das A-Painter-App einzubinden (weitere Informationen: https://blog.mozvr.com/tag/a-painter/) und wir verwenden dort nicht indizierte Geometrie auch, also wäre es toll, dafür Unterstützung zu haben ;)
Ich wollte nur wissen, ob das auf der Roadmap steht, also zu wissen, dass das so ist und wir es in etwa einem Monat haben könnten, ist mehr als vernünftig ;) Danke für das Teilen dieser Informationen!

Möglicherweise müssen wir in der Zwischenzeit ein dummes Indexattribut hinzufügen (wie in 0, 1, 2, 3, 4, 5, 6, 7, 8, ...) 😕

@mrdoob meinst du eine Methode zum Konvertieren von nicht indizierten in indiziert, wie du möchtest, oder füge den Hack direkt im Exporter hinzu?

Ja, füge einen temporären Hack im Exporter hinzu...

Ich weiß nicht, ich möchte nur, dass das Zeug funktioniert und den Leuten nicht sagen muss: "Oh? Ihr Modell funktioniert nicht auf Facebook? Das liegt daran, dass ... Sie wissen, was indizierte Geometrien sind? Ja, Sie sollten nicht, aber ..."

Ja, ich habe es verstanden! Ok, ich schaue, ob ich einen nicht so schmutzigen Hack hinzufügen könnte :)

@zellski für den Kontext...

Ich habe ein Export GLB in http://threejs.org/editor/ hinzugefügt, das dieses GLTFExporter .

Video: wie man ein Modell als glTF im Three.js Editor exportiert :D

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

Glauben Sie mir, ich verstehe die Zurückhaltung, Hacks hinzuzufügen. Es ist ein ziemlicher Kampf, eine geduldige Einstellung aufrechtzuerhalten, jetzt, da wir...

Könnten Sie den GLTFExporter-Hack in einem Fork machen, der in http://threejs.org/editor/ verwendet wird, aber nicht anderswo? Ich würde hoffen, dass wir diesen Fehler behoben haben, wenn r91 herauskommt, daher erscheint es für euch ein bisschen sinnlos, sorgfältigen, verantwortungsvollen Code dafür zu schreiben.

Könnten Sie den GLTFExporter-Hack in einem Fork machen, der in http://threejs.org/editor/ verwendet wird, aber nicht anderswo?

Ja, keine Sorge!

Ich hoffe, dass wir diesen Fehler behoben haben, wenn r91 herauskommt

Oh, ich möchte am 1. März veröffentlichen. Der Veröffentlichungszyklus wurde auf Anfang des Monats geändert, um die richtigen monatlichen Veröffentlichungen zu haben.

Es scheint, als hätten wir noch weitere Funktionen hinzuzufügen, bevor wir dies sowieso bewerben. Ich glaube nicht, dass wir Rauheits-, Metallic-, Normal- oder Alpha-Maps exportieren.

Neuester Test mit 2 diffusen Karten, von denen eine ein transparentes PNG ist:
https://www.facebook.com/fakemrdoob/posts/950266411809572

Ich bin mir nicht sicher, woher das scheinbare alphaTest: 0.5 kommt...

Verwenden Sie einfach den Workaround für Indizes :)
https://www.facebook.com/fernandojsg/posts/10156405595122044

Los geht's https://github.com/mrdoob/three.js/pull/13410

@mrdoob macht es Ihnen etwas aus, die fehlenden Funktionen hinzuzufügen, die Sie finden und die nicht mit den Facebook-Anforderungen zu diesem Thema zusammenhängen: https://github.com/mrdoob/three.js/issues/11951
Obwohl ich den Status dort aktualisieren muss 😇

Hört sich gut an. Ich teste, indem ich exportiere und zurück in den Editor ziehe.
Sollen wir diesen schließen?

@mrdoob Ich würde es offen lassen, bis das Problem RGB vs RGBA für Scheitelpunktfarben auf der Facebook-Seite gelöst ist. Wenn also Leute hierher kommen, um Hilfe zu suchen, können sie darüber lesen, anstatt ein anderes Problem zu öffnen.

Übrigens habe ich gerade diesen Link mit einigen nützlichen Informationen gefunden: https://developers.facebook.com/docs/sharing/3d-posts/glb-tutorials

Anscheinend müssen Texturen eine Potenz von 2 haben ...
https://twitter.com/drupalati/status/967486854630055936

Konvertiert Three.js nicht automatisch Bilder ohne Zweierpotenz in Zweierpotenzen?

Ja Entschuldigung. Die Größe der mobilen Clients wird noch nicht geändert, daher müssen wir sie während der Validierung für eine Weile ablehnen. Die Größenanpassung werden wir wahrscheinlich auf dem Server vornehmen, da wir die vollständige Kontrolle über die Lieferpipeline haben. Ich hoffe, dass auch diese Einschränkung in 2-3 Wochen aufgehoben wird.

@takahirox Ja, die Größe von Three.js wird im

Die vollständige Liste der glTF-Funktionen, die Facebook noch nicht unterstützt, in grober Reihenfolge der ETA:

• Keine RGB-Scheitelfarben; muss RGBA sein.
• Keine NPOT-Texturen für bestimmte Klemm-/Filterkombinationen
• Nur indizierte Dreiecksgeometrie.
• Keine Animationen (still ignoriert)
• Keine Sparse-Accessoren (fehlgeschlagene Validierung)
• Keine Morph-Ziele (wenn ein Netz eine 'Ziel'-Eigenschaft hat, schlägt die Validierung des Modells fehl)
• Keine Kameras (still ignoriert) (vorerst)

Ebenfalls:

• Maximale Dateigröße 3 MB
• Keine Texturdimension größer als 4096
• Keine anderen Erweiterungen als KHR_material_unlit (vorerst)

Ich denke, das ist es.

Ich habe PR #13424 für Force POT Textur gemacht, weil ich denke, dass es sich nicht nur für FB lohnen würde.

Wenn ich GLTFExporter zum Exportieren eines Netzes aus mehreren Materialien (einem Materialarray) verwende, erhalte ich diesen Fehler:

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

@Ben-Mack Das ist ein bekanntes Problem und ich arbeite gerade daran. (Aber es würde ein bisschen dauern).

@zellski irgendwelche pläne für draco-support auf fb? Ich kann meine Meshes von 40 MB auf 5 MB runterladen, aber die letzten paar MB werden einfach nicht abfallen.

@webprofusion-chrisc (Mann, das ist ein langes @ für eine Telefontastatur) ja, Draco ist definitiv auf der Roadmap. Es erfordert einiges an Entwicklungsarbeit, also ist es mindestens einen Monat her, aber – in vielerlei Hinsicht haben wir unsere Annahmen darauf aufgebaut – wie Sie sagen, ist die Grenze von 3 MB für viele Modelle einfach unhaltbar. (Ich bin mir immer noch nicht sicher, was wir bei Texturen tun können.)

(Ich bin mir immer noch nicht sicher, was wir bei Texturen tun können.)

@donmccurdy macht https://github.com/mrdoob/three.js/pull/12877

Mit der #12877 können wir von GLTFExporter 25-30% kleinere Texturen erwarten.

Längerfristig arbeitet Binomial mit Khronos zusammen, um eine Erweiterung für plattformübergreifende komprimierte Texturen in glTF zu erstellen: https://www.khronos.org/blog/call-for-participation-gltf-creating-a-compressed-texture-extension .

Okay... Nach #12877 und #13451 ist ein GLB-Export, der früher 3,3 MB groß war, jetzt 480 KB

Cool! #13451 bedeutet, dass die Bilddateigröße größer wird, wenn wir jpg in png konvertieren?

Cool! #13451 bedeutet, dass die Bilddateigröße größer wird, wenn wir jpg in png konvertieren?

Jawohl. #13451 ist ein kleiner Workaround, da der Editor das Format einer Textur im Moment nicht ändern lässt. Aber in der Bibliothek machen wir sowieso das Gleiche...

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

Aber ja, GLTFExpoter speichert derzeit als jpg, wenn texture.format === THREE.RGBFormat .

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

Was nicht ideal ist, weil wir ein jpg neu komprimieren... Aber besser als übergroße Exporte, denke ich?

Ich musste FBX2glTF Code hinzufügen, der sogar die Alpha-Werte von RGBA-Bildern überprüft, da die Leute (oder genauer gesagt die Tools der Leute) sie standardmäßig erstellen und es oft völlig unnötig ist, sie als PNGs zu behalten. Selbst nach dem Ausprobieren der brutalsten GPU-fähigen, nicht-linear optimierenden PNG-Crunchers scheint JPEG wirklich die Oberhand zu haben ... der Größenunterschied ist ziemlich unglaublich!

Ich mache mir ein wenig Sorgen über das Inter-Channel-Bleed für Dinge wie die ORM-Textur (Okklusion / Rauheit / Metall), bei der jede Komponente Daten trägt, die völlig unabhängig von den Daten der anderen Komponenten sind ... aber in der Praxis scheint es gut zu funktionieren.

Der Exporter könnte auch die Qualitätsstufe optional machen, wenn man canvas.toDataURL( mimeType ) verwendet - meine Texturen werden zur Laufzeit aus zusammengesetzten Bildern generiert, das würde auch helfen.

@zellski für die Pipeline / den Viewer von fb Ich vermute, Sie könnten Sketchfab mögen und eine Texturversion mit niedriger Auflösung bereitstellen, dann die Texturen mit hoher / voller Auflösung streamen und sie beim Laden im Modell ersetzen. Kein kleines Stück Arbeit aber machbar.

@webprofusion-chrisc Ja, das können wir am Ende tun. Im Moment haben wir alles auf .glb als übertragene Entität gegeben, was schwer mit selektivem LOD-Streaming zu kombinieren ist (da es nur eine einzige sequentielle Datei ohne Direktzugriff gibt). Aber ich gehe davon aus, dass wir Grundannahmen ziemlich oft neu bewerten werden, je nachdem, wie die Dinge laufen. :)

GLTFExporter kann BufferGeometry exportieren und problemlos in Facebook importieren. Aber alle Geometry oder BufferGeometry die mit der Methode fromGeometry konvertiert wurden, funktionieren nicht auf Facebook. Ich erhalte dies immer im FB-Validator:

[msg] => Vertex COLOR_0 Attribute vom Typ RGB werden (vorübergehend) nicht unterstützt. Sie müssen RGBA sein.

Schritt zur Reproduktion:

• Unter Verwendung des misc_exporter_gltf Beispiels zuletzt in der Entwicklung funktioniert Export Sphere oder Walthead gut auf FB, aber das Ergebnis von export Scene1 kann nicht in FB importiert werden.

Ist das ein erwartetes Verhalten und muss FB-Seite warten?

Ich habe erwartet, dass BufferGeometry mit fromGeometry wie normale BufferGeometry funktioniert.

@Ben-Mack das soll laut @zellski in den nächsten Wochen https://github.com/mrdoob/three.js/issues/13397#issuecomment -367534958

Ab Build 161 (aktuelle App Store-Version ist 160) der Haupt-FB-App wird dies kein Absturz mehr sein und wir werden diese Validierungsprüfung entfernen. Ich gehe davon aus, dass dies innerhalb der Woche geschieht.

@zellski das ist toll! Danke :)

Wundert mich aber...

Der "wahre" Grund, warum THREE.GLTFExporter THREE.Geometry nicht exportieren kann, liegt darin, dass wir beim Konvertieren von THREE.Geometry in THREE.BufferGeometry ein color erstellen Attribut, das in den meisten Fällen voller Nullen ist.

Eine "Lösung" (und Optimierung) wäre also, das Attribut color nicht zu exportieren, wenn material.vertexColors auf THREE.NoColors ?

Ops, das wusste ich nicht :D das ist sicher eine Muss-Optimierung :D

@fernandojsg danke für die Aktualisierungen, die Sie vorgenommen haben, sehr geschätzt. Es gibt noch zwei Dinge, die es wert sind, hinzugefügt zu werden:

1. Unterstützung von Multi-Material-Netzen. Diejenigen, die Gruppen in ihren Geometrien und Arrays in Mesh.material , können derzeit nicht richtig exportiert werden;
2. Bessere Kompatibilität zwischen dem einzigen unterstützten MeshStandardMaterial und dem Ergebnis, das wir auf Facebook haben. Bisher sehen metallische und diffuse Oberflächen in Three.js und auf Facebook ganz anders aus. Vielleicht haben wir eines Tages ein spezielles "Facebook"-Material?

Dankeschön

@ov Ich denke, beide werden wahrscheinlich um r91 herum behoben:

1. Multi-Material-Export https://github.com/mrdoob/three.js/pull/13536
2. Metall-/Rauheitskorrekturen https://github.com/mrdoob/three.js/pull/13501

Es ist möglich, dass die Materialien von Facebook auch noch nicht ganz richtig sind, aber glTF ist ziemlich genau, wie die Dinge aussehen sollen, also sollten wir irgendwann zusammenkommen.

Oh, wir sollten auch die Möglichkeit hinzufügen, KHR_materials_unlit zu exportieren...

BEARBEITEN: Geöffnet https://github.com/mrdoob/three.js/pull/13566

Der "echte" Grund, warum THREE.GLTFExporter THREE.Geometry nicht exportieren kann, ist, dass wir beim Konvertieren von THREE.Geometry in THREE.BufferGeometry ein Farbattribut erzeugen, das in den meisten Fällen voller Nullen ist.

Eine "Lösung" (und Optimierung) wäre also, das Farbattribut nicht zu exportieren, wenn material.vertexColors auf THREE.NoColors gesetzt ist?

+1 hoffe das wird bald behoben. Viele Bibliotheken für Three.js funktionieren immer noch basierend auf THREE.Geometry .

( FB hat immer noch Fehler ...must be RGBA mit THREE.Geometry )

@Ben-Mack, welche Bibliotheken verwenden Sie, die noch Geometrie verwenden? Vielleicht könnten wir mit den Eigentümern zusammenarbeiten, um sie auf den neuesten Stand zu bringen.

@looeee Bitte schau dir diese Bibliothek an: https://github.com/a-jie/threejs-geometry-modifiers

Hey Leute - seit heute Morgen lehnt Facebook RGB (VEC3)-Scheitelfarben nicht mehr als "ungültig" ab.

Die Anforderungen an die Zweierpotenz von Texturen bleiben im Moment bestehen, aber ich arbeite auch daran.

@zellski cool! :) Ich bin kurz davor, volle Unterstützung für a-painter zu haben :D Gibt es einen Plan, den Rest der primitiven Modi zu implementieren? Im Moment glaube ich, dass nur TRIANGLE unterstützt werden. Es könnte großartig sein, den Rest zu unterstützen, z. B. in A-painter verwenden wir TRIANGLE_STRIP, um etwas Platz zu sparen 👼

Es wäre verrückt, sie nicht umzusetzen, oder? Idealerweise sollten alle gültigen glTF akzeptiert werden. Ich weiß jedoch nicht, wie diese Arbeit priorisiert wird. Wir sind ein kleines Team mit vielen starken Trieben. :)

Ich denke, dieses Thema kann jetzt geschlossen werden?