Three.js: Utils: Exporter einstellen (Blender, 3DS Max und Maya)

+1 dafür - die Existenz schlecht gewarteter und veralteter Exporteure im Repo ist ein unnötiger Verwirrungspunkt für Neulinge, zumal es, wie @Mugen87 betont , jetzt viel bessere Optionen gibt.

Hinweis: Der offizielle GLTF Blender-Exporter (https://github.com/KhronosGroup/glTF-Blender-Exporter) erlaubt derzeit keinen ordnungsgemäßen Animationsexport (derzeit wird nur 1 Animation pro Objekt unterstützt).
https://github.com/KhronosGroup/glTF-Blender-Exporter/issues/112

@Usnul wie ist das im Vergleich zum Blender JSON-Exporter in diesem Repository?

@looeee
Blender JSON Exporter exportiert Animationen problemlos. Es gibt einige seltsame Störungen mit UVs oder Vertex-Normalen unter bestimmten Bedingungen, die im GLTF-Exporter nicht vorhanden sind, aber das ist eine andere Geschichte.

OK, ich benutze Blender nicht, also werde ich das nicht weiter kommentieren.

Aus Erfahrung kann ich jedoch sagen, dass der Versuch, den 3DS Max-Exporter zu verwenden, der seit mehreren Jahren nicht aktualisiert wurde, endlose Kopfschmerzen bereitet und ich würde es nachdrücklich unterstützen, ihn zugunsten des FBX-Formats aus dem Repository zu entfernen.
Fast alles, was vom 3DS Max FBX-Exporter exportiert wird, wird jetzt vom FBXLoader unterstützt und da dieser Exporter von AutoDesk verwaltet wird, können wir uns darauf verlassen, dass er auf dem neuesten Stand bleibt.

Ähnlich beim Maya FBX-Exporter, obwohl der FBXLoader noch aktualisiert werden muss, um Pivot-Punkte dort richtig zu unterstützen.

Wenn ich mich richtig erinnere, exportiert Blender keine Animationen, wenn Sie BufferGeometry auswählen. Es gibt definitiv ein Problem mit Morph-Zielen, siehe #10932. Außerdem verwendet der Exporter das "alte" Animationshierarchieformat und nicht das des aktuellen Animationssystems.

Ich denke, wir sollten auch die README-Datei des Revit-Exporters entfernen - sie verlinkt nur auf ein separates Repo, das in den letzten Jahren kaum angerührt wurde.

Es gibt wahrscheinlich Hunderte von Three.js-Tools, auf die wir so verlinken könnten, aber wenn wir nicht bereit sind, sicherzustellen, dass sie aktiv gewartet werden und ordnungsgemäß funktionieren, müssen wir hier keine Links zu ihnen einfügen.

Wenn Sie nach "three.js revit exporter" googeln, wird das Repository sowieso in Ordnung.

Ich denke, wir sollten auch die README-Datei des Revit-Exporters entfernen - sie verlinkt nur auf ein separates Repo, das in den letzten Jahren kaum angerührt wurde.

👍

die Existenz schlecht gewarteter und veralteter Exporteure im Repo ist ein unnötiger Verwirrungspunkt für Neuankömmlinge

Ich möchte diese Aussage nur hervorheben, weil ich denke, dass sie für three.js sehr wichtig ist. Wenn Benutzer auf diese Exporteure stoßen, erwarten sie Tools, die einfach funktionieren. Aber in den meisten Fällen sind sie verwirrt und haben vielleicht einen schlechten Eindruck vom gesamten Projekt. Das ist nicht gut. 😢

Darf ich als unschuldiger Benutzer einen Kommentar wagen ...

Bezüglich Mixer:
Wenn Three.js einen nativen Importer für das .blend-Format hätte ,
ein Exporteur wäre offensichtlich nicht erforderlich.

Kein Installationsaufwand auf Blenderseite,
keine Kompilierung von Blender-API/-Strukturen zu Javascript durch Python-Code ...

Es gab enorme Anstrengungen, den JSON-Exporter in Python zu schreiben,
Ich frage mich, warum Sie Mitarbeiter nicht diesen Weg gewählt haben ... ?

@wolfgangvonludwigsburg
Es ist eine ziemlich einfach zu beantwortende Frage. Das Blend-Format kommt der internen Darstellung von Three.js nicht sehr nahe, daher ist eine gewisse Konvertierung erforderlich. Das JSON-Format von Three.js ist der internen Repräsentation sehr ähnlich, daher ist die Konvertierung von der Blender-Repräsentation in Three.js in jedem Fall möglich, egal ob Sie es Exporter oder Loader nennen. Abgesehen davon ist .blend kein gängiges Übertragungsformat, nichts außer Blender unterstützt es wirklich, daher würde ein Loader dafür ein relativ kleines Publikum zufriedenstellen, da selbst Leute, die Blender häufig verwenden, dazu neigen, auch andere Software und .blend . zu verwenden ist kein Format der Wahl als Austauschformat. Normalerweise ist es obj, fbx oder ein offener Standard wie gltf oder collada.

@wolfgangvonludwigsburg Wenn Sie _würden_, einen .blend-Dateilader zu erstellen, wäre dies wahrscheinlich ein guter Anfang:

https://raginggazebo.com/parsing-blender-3d-files-blend-1-of-3/

Viele THX für Ihre Kommentare!

Aber warum ist der Blender JSON Exporter so fehleranfällig ...
=> Es hängt von der Blender-API ab, ist in Python geschrieben, soll die Blender-Datenstrukturen verstehen,
und kompiliert in ein JSON-Format, das Three.js wieder in seine Interna umwandelt ...

Sehr viele Aufgaben, die alle fehlschlagen können (und wirklich tun!), hauptsächlich bei Blender-Versionsänderungen.
Nun, ich würde den Weg der "direkten Datenerstellung" bevorzugen ...

Nun, ich würde den Weg der "direkten Datenerstellung" bevorzugen.

Das ist kein guter Ansatz. Das Laden von blend Dateien direkt in Apps ist eine Art Missbrauch. Stattdessen sollten Sie ein Dateiformat verwenden, das für die Datenübertragung und Bereitstellung von Assets vorgesehen ist. glTF ist das erste standardisierte Format, das diesen Aspekt aus Sicht der Anwendung in den Mittelpunkt stellt. Das ist einer der Gründe, warum ich so oft für glTF werbe 😇 . Es sollte der Standard für alle kommenden 3D-Apps sein.

Nun, ich würde den Weg der "direkten Datenerstellung" bevorzugen ...

Leider gibt es tiefere Probleme bei der Verwendung von .blend diese Weise. Es speichert Dinge wie den Bearbeitungsverlauf, den aktuellen Status der Blender-Benutzeroberfläche, Blender-Add-On-Daten. Das Format ändert sich, wenn neue Blender-Versionen herauskommen. Und die Dateigrößen können sehr groß sein, sodass es für hochwertige 3D-Anwendungen nie eine gute Wahl wäre. Der beste Weg, um Daten direkt aus Blender zu erhalten, besteht darin, die APIs von Blender zu verwenden (wie es die FBX- und glTF-Exporter tun), anstatt zu versuchen, das interne .blend Format von Blender zurückzuentwickeln.

Zur ursprünglichen Frage überspringe ich das Hinzufügen einer Ja/Nein-Stimme, da ich mit 3D-Authoring-Workflows nicht sehr vertraut bin.

Aber als Betreuer und in erster Linie ein JS-Entwickler scheint es wahrscheinlicher, zuverlässigere Ergebnisse zu liefern, wenn man sich auf das Laden und die Unterstützung von Formaten wie FBX und glTF konzentrieren kann, die Autorentools von Drittanbietern aktiv gewartet haben.

Abgesehen davon, wenn es Probleme mit dem aktuellen glTF-Ökosystem gibt, die verhindern, dass es ein ausreichend guter Workflow ist, um diese Art von Bedarf zu lösen, ist dies ebenfalls hilfreiches Feedback. 🙂

Ich habe nicht argumentiert, das Blender-.blend-Format als allgemeines Austauschformat zu verwenden .
aber es könnte die Zusammenarbeit zwischen Blender und Three.js vereinfachen ...

Ich kann den Aufwand nicht abschätzen, einen Python-Exporter + GUI unter dem Blender-Framework zu pflegen,
aber ich schätze, das kann leicht zum Horror werden... ;-)

@donmccurdy
Übrigens, Wavefront .obj, 3D Studio .3ds sind auch native Formate, die weit verbreitet sind ...

Übrigens, Wavefront .obj, 3D Studio .3ds sind auch native Formate, die weit verbreitet sind ...

Ja, ich denke, OBJ wird hier nicht erwähnt, weil das Format einige beliebte Funktionen wie Animation nicht unterstützt, aber Three.js wird OBJ sicherlich noch sehr lange unterstützen – es ist ein klassisches und zuverlässiges Format.

.3ds 3DS Max ist in der gleichen Kategorie wie .blend Blender oder .mlt Maya oder .c4d Cinema4D. Jeder Editor hat sein eigenes internes Format, und diese Formate ändern sich mit der Software. Die Wartung von Ladeprogrammen für das private interne Format jedes Modellierungswerkzeugs ist weitaus schwieriger und fehleranfälliger als die Verwendung der Exportformate, die die eigenen Entwickler des Editors bereitgestellt haben. Erwähnenswert ist, dass sowohl 3DS als auch Blender über einen integrierten FBX-Export verfügen – der von ihren Autoren gepflegt wird – und dass Blender in einer zukünftigen Version auch über einen integrierten glTF-Export verfügen wird.

Ein letzter Einwurf...

Wir haben bereits ein Modellierungswerkzeug unabhängig vom/Importeur: Collada,
aber aus irgendwelchen Gründen scheint dies nicht so sehr akzeptiert zu sein.

Vorzugsweise hatte ich diese Implementierungsart im Hinterkopf:
eine Ladelösung, basierend auf Google Protocol Buffer

https://developers.google.com/protocol-buffers/

Es ist ein

... sprachneutraler, plattformneutraler, erweiterbarer Mechanismus zur Serialisierung strukturierter Daten – denken Sie an XML, aber kleiner, schneller und einfacher.

Da die 2D/3D-Vektordaten, mit denen wir zu tun haben, nicht so komplex sind, sollte die Entwicklung eines Blender-Datendateischemas einfach machbar sein ...

Es gibt tatsächlich einen Blend-Datei-Parser in Javascript 😁
https://github.com/Galactrax/js.blend

ähh, ich bekomme Unterstützung... - danke mrdoob ;-))

DIE (im Hinblick auf Terrabyte) größte 3D-Modellanwendung (Google Maps 3D) verwendet diese effiziente Art (Protobufs) der Implementierung ...

Den Pfad des Ladens von .blend zu beschreiten, ist möglicherweise nicht sehr vernünftig. Aber ist nicht wirklich anders als das Laden von .dae und .fbx...

Jedenfalls stimme ich der Idee zu, die Exporteure abzuwerten.
Ich würde jedoch warten, bis gltf ein bisschen ausgereifter und getestet ist. Sommer 2018?

Ich bin damit einverstanden, auch diese Exporteure zu entfernen. Du könntest sie sogar in ein anderes Repo verschieben, wo sie RIPen können :)

Ich würde jedoch warten, bis gltf ein bisschen ausgereifter und getestet ist. Sommer 2018?

Warten erscheint mir sinnvoll. Insbesondere für glTF wäre es gut, zuerst ein paar Dinge zu haben:

• [ ] Blender-Versand mit integriertem glTF-Export und Unterstützung für mehrere Animationen.
• [x] Verbesserter Workflow von Maya und 3DS Max zu glTF oder einfach mehr Tests von FBX2GLTF .
• [x] Updates des offiziellen COLLADA2GLTF-Konverters für glTF 2.0.

Die Frage im Sommer 2018 noch einmal zu beantworten, klingt richtig.

Ich würde jedoch warten, bis gltf ein bisschen ausgereifter und getestet ist. Sommer 2018?

Für den Blender-Exporter stimme ich eher zu. Ich empfehle jedoch, zumindest den 3DS Max-Exporter sofort zu entfernen, da es in FBX bereits eine ausgereifte und viel bessere Alternative gibt.

Ich empfehle jedoch, zumindest den 3DS Max-Exporter sofort zu entfernen, da es in FBX bereits eine ausgereifte und viel bessere Alternative gibt.

Klingt gut für mich 👌

Okay, der 3DS Max-Exporter ist weg. Kommen wir in einigen Monaten noch einmal zu den anderen Exporteuren (Blender und Maya).

Ich glaube nicht, dass sich in dieser Zeit viel bezüglich des Maya-Exporteurs ändern wird.

Das sollten wir wohl jetzt auswerten. Ich werde es in den nächsten Tagen testen und sehen, ob es sich lohnt, es aufzubewahren.

Guter Vorschlag 👍 .

Solange wir hier sind, wie ist der Status von https://github.com/mrdoob/three.js/tree/dev/utils/converters/fbx ? Scheint, als könnte das durch ein node.js-Skript wie den obj2three-Konverter ersetzt werden, indem einfach THREE.FBXLoader verwendet und am Ende serialisiert wird. Derzeit hat der Konverter viele offene Probleme:

No animation support
Only Lambert and Phong materials are supported
Some camera properties are not converted correctly
Some light properties are not converted correctly
Some material properties are not converted correctly
Textures must be put in asset's folder, and use relative path in the material

Auch die msgPack-, UTF8- und CTM-Konverter - sie wurden seit Jahren nicht mehr angerührt.

Sind sie noch nützlich für irgendjemanden?

@donmccurdy Ich fürchte, Sie können FBXLoader in einem node.js-Skript verwenden, da Sie keinen Zugriff auf das DOM haben. Alle Lader, die TextureLoader haben eine Abhängigkeit von ImageLoader und damit von document . Wir erhalten Laufzeitfehler wie ReferenceError: document is not defined . Das gleiche Problem für das window Objekt, auf das von FileLoader zugegriffen wird.

Als temporäre Problemumgehung könnten wir vielleicht ImageLoader und FileLoader in der Datei fbx2three.js ?

Vielleicht könnten wir ImageLoader und FileLoader in der Datei fbx2three.js neu definieren?

Ich denke, das wäre einfach genug und erfordert immer noch viel weniger Code als der Python-Konverter dort jetzt ... Ich werde das versuchen.

Vielleicht könnten wir ImageLoader und FileLoader in der Datei fbx2three.js neu definieren?

Gute Idee :rot:

.3ds von 3DS Max ist in der gleichen Kategorie wie .blend von Blender oder .mlt von Maya oder .c4d von Cinema4D.

Dies ist möglicherweise nicht ganz richtig, .max entspricht eher der gleichen Kategorie, .3ds ist ziemlich abgespeckt.

Ich mochte es, den 3ds max-Exporter als Beispiel dafür zu haben, wie man einen Exporter schreibt, und auch auf Maxscript. Ich glaube nicht, dass ich jemals den richtigen Tangentenraum von 3ds max über fbx exportieren konnte.

Lohnt es sich, ein neues Repo mit entsprechenden Haftungsausschlüssen einzurichten? Alle Beispiele für das Schreiben eines Exporters, aber wenn er nicht gewartet wird und FBXLoader jetzt zuverlässiger ist, möchten wir nicht, dass die Leute davon ausgehen, dass dies die empfohlene Methode ist, Assets aus 3DS Max in Three.js zu übertragen.

Ja, wenn überhaupt, dann stimme ich für ein neues Repo.

Wollte nur hinzufügen, bevor wir das Json-Format komplett aufgeben: Wir verwenden den Blender-Exporter für den Szenenexport, dh das Einrichten einer Kamera- und Szenenhierarchie mit Animationen und benutzerdefinierten Eigenschaften sowie Platzhalterobjekten, die dann zur Laufzeit dynamisch durch echte Meshes ersetzt werden (geladen auf andere Weise). Da dies 'nur' Json ist, ist es sehr einfach, sich in js zu besinnen und zu modifizieren und solche Dinge zu tun. Ich bin mir nicht sicher, ob zB glTF (zumindest in seiner aktuellen Form) als Szenenformat gut geeignet ist, also hoffe ich, dass der Blender-Exporter und das Json-Format noch etwas länger bestehen bleiben

@pjoe Ich Zukunft eher bestehen bleiben als andere in diesem Thread erwähnte Dinge (z. B. 3DS Max + Maya-Exporter).

Trotzdem wäre es schön, Ihr Feedback zu glTF und dem Blender-Exporter zu erhalten . Alles, was Sie erwähnt haben, wird unterstützt:

• Kamera einrichten
• Szenenhierarchie
• Animationen (für mehrere Blender-Aktionen benötigen Sie einen anderen Exporter )
• benutzerdefinierte Eigenschaften (wählen Sie "Extras exportieren" in den Optionen)
• "nur JSON" für die Materialien, Metadaten usw. Mesh-Daten werden als separate binäre Nutzlast optimiert

@donmccurdy muss zugeben, dass ich (zumindest noch) nicht viel Erfahrung mit glTF habe - obwohl ich versucht habe, die Spezifikation zu lesen :)

Ich denke, mein Hauptproblem bei glTF (was meiner Meinung nach ein großartiges Transportformat ist und auch großartig, um 'die Bytes' so schnell und direkt wie möglich in GPU-Puffer zu bekommen) ist, dass alle Refs indexbasiert sind, was nicht gut ist fit für ein veränderliches Szenenformat. Wenn Sie also zB Einträge löschen oder in der Mitte Sachen hinzufügen möchten, müssen Sie alle Refs auf Indizes hinter dieser Stelle aktualisieren. Diese 'Indexverwaltung' zu machen, wird imo schnell ziemlich chaotisch.

Von der kurzen Zeit, die ich mit dem Blender glTF Exporter verbracht habe, schien er damals (vor etwa zwei Monaten) auch ziemlich unausgereift. Das kann natürlich behoben werden, indem man bei der Verbesserung hilft :)

... alle Refs sind indexbasiert, was nicht gut zu einem veränderlichen Szenenformat passt. Wenn Sie also zB Einträge löschen oder in der Mitte Sachen hinzufügen möchten, müssen Sie alle Refs auf Indizes hinter dieser Stelle aktualisieren.

Ja, es ist in diesem Sinne nicht für manuelle Bearbeitungen ausgelegt und wird es als Laufzeit-/Übertragungsformat wahrscheinlich nie sein. Es gibt verschiedene Bibliotheken für die Arbeit damit, die helfen könnten.

Im Allgemeinen habe ich festgestellt, dass der glTF Blender-Exporter bessere Ergebnisse liefert als jede andere Blender-Ausgabe, aber bitte melden Sie Fehler, wenn Sie bestimmte Probleme gefunden haben. :)

@donmccurdy stimmte zu, dass glTF dem Transport/Laufzeit treu bleibt ... eines der großartigen Dinge daran ist, dass es nicht versucht, ein für alle Formate geeignetes Format zu sein (wie collada - lass mich nicht anfangen).

Wir versuchen, zusätzliche Bibliotheken oder Konvertierungs-Overhead zu vermeiden, da wir eine Webanwendung erstellen, die winzig und schnell sein muss - und bisher hat sich das Three.js-JSON-Format als Szenenformat für diesen Anwendungsfall gut bewährt. Die ganze Szene im Blender einrichten zu können, zB mit Kameraanimation, einfach Modelle exportieren, laden und zur Laufzeit dynamisch ersetzen (wofür wir wahrscheinlich bald glTF verwenden werden) - das alles sorgt für eine einigermaßen reibungslose Pipeline für uns :)

Als Randnotiz verwenden wir auch den Webpack-Json-Loader, um die Szenendatei in unser Hauptpaket aufzunehmen - macht es noch einfacher, damit umzugehen.

Ich glaube nicht, dass sich in dieser Zeit viel bezüglich des Maya-Exporteurs ändern wird. Das sollten wir wohl jetzt auswerten. Ich werde es in den nächsten Tagen testen und sehen, ob es sich lohnt, es aufzubewahren.

@looeee Ich bin gespannt, habt ihr Neuigkeiten dazu 😊 ? Glaubst du, wir können den Exporteur jetzt entfernen und stattdessen auf FBX verweisen?

Glaubst du, wir können den Exporter jetzt entfernen und stattdessen auf FBX verweisen?

Ich habe nur eine kleine Menge an Tests gemacht, hatte geplant, mehr zu tun, aber ich hatte keine Zeit. Aber ich würde sagen, ja, wir sollten es entfernen und daran arbeiten, dass der FBXLoader Maya vollständig unterstützt.

Hier als Benutzer des Blender-Exporters einstimmen: Ein Vorteil von JSON ist, dass es nach dem Export extrem einfach zu ändern ist. Blender ist nur ein Teil unserer automatisierten Toolchain, und wir verarbeiten viel am exportierten JSON, bevor es für unseren Webviewer bereit ist. Ein Transferformat, das dem internen Threejs-Format so nahe kommt, ist für uns ein großer Vorteil.

Wir haben auch einige Tests mit anderen Exportformaten durchgeführt und festgestellt, dass das JSON-Format in Bezug auf die Übertragungsgröße nicht so schlecht ist, wenn es einmal anständig komprimiert ist, viel besser als beispielsweise Collada oder FBX. Wir haben einen schnellen Protopuffer-basierten Versuch durchgeführt und könnten auf diese Weise etwas kleiner werden, aber nichts, was uns den Aufwand wert war.

Bei großen Szenen und langsamen Clients wird auch die Geschwindigkeit beim Parsen und Konvertieren in das interne ThreeJS-Modell wichtig. Da das JSON-Parsing in den Browsern stark optimiert ist und die Modellstruktur so ähnlich ist, sind wir davon ausgegangen, dass das JSON-Format diesbezüglich recht gut abschneiden würde. Habe das nicht wirklich getestet.

Soft8Soft hat gerade einen glTF-basierten Exporter für 3ds Max veröffentlicht . Es könnte also eine gute Alternative zum entfernten JSON-Exporter sein.

Danke @alexkowel , diesem Thread einen Link hinzufügen könnten, werden wir ihn mit anderen glTF-Ressourcen auflisten. 🙂

@dherben gute Punkte, danke —

Was die Parsing-Geschwindigkeit angeht, erwarte ich, dass glTF noch schneller ist. Der Unterschied besteht im Wesentlichen darin, dass Metadaten immer noch "nur JSON" sind, während sich die großen Teile der Nutzlast (Vertexpositionen, Animationsdaten) in einem ArrayBuffer-Block befinden, der verwendet werden kann, um ein typisiertes Array für THREE.BufferAttribute Konstruktoren zu erstellen. In einem vollständig optimierten Loader (ich weiß nicht, ob THREE.GLTFLoader noch da ist) müssen Sie diese Daten in JS nie lesen oder kopieren.

Aber für Änderungen an den Daten als Teil einer Pipeline stimme ich zu, dass einfaches JSON einfacher zu handhaben ist, wie Sie sagten. Es gibt Bibliotheken in verschiedenen Sprachen für die Arbeit mit glTF, aber die Tools sind noch nicht sehr ausgereift.

Aktueller Stand zu diesem Thema:

Exporteure:

• [X] Maya-Exporteur
• [X] 3DS Max-Exporteur
• [X] Blender-Exporter
  
  
  
  • Ich gehe gerade nirgendwo hin, kann es in Zukunft erneut besuchen.
  
  
  • Mai 2018 entfernt.
  
  

Konverter:

• [ ] FBX
  
  
  
  • vereinfachter Ersatz vorgeschlagen als https://github.com/mrdoob/three.js/pull/13013; muss getestet werden
  
  
• [ ] GM (nicht diskutiert)
• [ ] utf8 (nicht besprochen)
• [ ] obj2three (nicht besprochen)

EDIT: Aktualisiert im Mai 2018.

@donmccurdy Ich wollte nur zurückkommen, nachdem ich mehr mit dem glTF Blender-Exporter und dem Three.js-Loader experimentiert hatte. Es stellte sich heraus, dass es als Szenenformat für unseren bisherigen Anwendungsfall recht gut funktioniert. Was ich jetzt tue, ist, die exportierte glTF-Datei in eine Three.js-Szene zu laden und dann die Three.js-Szenenhierarchie zu manipulieren (Platzhalter mit dynamisch geladenem Material auszutauschen), bevor ich das erste Rendern mache.

Es gibt wahrscheinlich noch einige Funktionen, die ich gerne im glTF-Exporter sehen würde, werde versuchen, dort zu kommentieren oder PRs zu machen :)

Es gibt wahrscheinlich noch einige Funktionen, die ich gerne im glTF-Exporter sehen würde, werde versuchen, dort zu kommentieren oder PRs zu machen :)

Super, bitte! 🙂

Der Blender-Exporter geht im Moment nirgendwo hin, wird möglicherweise in Zukunft erneut besucht.

Wird also irgendjemand an den aktuellen Bugs des Blender-Exporters arbeiten? Ich gehe davon aus, dass die Antwort nein ist. In diesem Fall sollten wir das sagen.

Wenn es niemand vor mir tut... würde ich zumindest versuchen, die Rotationsprobleme zu lösen. #13130

Wird also irgendjemand an den aktuellen Bugs des Blender-Exporters arbeiten? Ich gehe davon aus, dass die Antwort nein ist.

Ich habe nicht die ganze Diskussion gelesen, sondern meine zwei Cent.

Letzte Woche wurde ich gebeten, einem Unternehmen zu helfen, das eine Lösung hat, die Three.js bei der Bereitstellung von Inhalten innerhalb einer Dauerausstellung verwendet. Beschilderungen mit 3D-Modellen, die Benutzer erkunden und mit denen sie interagieren können. Die ursprünglichen Entwickler, die schon lange nicht mehr existieren, haben das Three.js-JSON-Format verwendet . Die Vorbereitung und Einführung neuer Modelle (mit der Bedingung, dass das Ändern des Laufzeitcodes nogo ist) ist ein echter Albtraum.

IMHO Three.js sollte sich auf die Unterstützung etablierter und schnell wachsender Formate wie FBX und glTF konzentrieren . Priorität bei Formaten, die mehrere UV-Datenfächer aufnehmen können (daher sollte das beliebte OBJ NICHT gefördert werden). Dann Animation. Ich weiß, dass das Blender-Export-Addon angeblich beides unterstützt, aber auch FBX.

Stellen Sie sich einen Arbeitsablauf vor, in den Blender'ed Zeug hinausgeht

1) WebGL
Three.js offensichtlich

2) OpenGL 3.3+
roh / Asche

3) OpenGL ES 2.0 auf RISC
Vom Smartphone zum RaspberryPi

4) Spiel-Engines

5) Echtzeit-Grafik-Apps, die in Medienserver integriert sind (Hippo, D3-Verkleidung)
Diejenigen, die VFX-Leute verwenden.

Anstatt viele verschiedene Exporter für verschiedene Ausgaben verwenden zu müssen, wäre das Ziel, 1, max. 2 Formate zu verwenden. Beim Schreiben von OGL in den ersten 3 Fällen ... sollte das gleiche Modellformat verwendet werden, das war's. Für die letzten beiden Punkte ist FBX der König (verschiedene Implementierungen für COLLADA über Pakete hinweg erschweren die Arbeit) und dort wird das Modell tatsächlich nicht "exponiert".
Ich schlage nicht das Three.js JSON-Format oder das Blender-Addon ( @mrdoob 🙇 🙏 ), es hat (hatte?) seinen Nutzen und wurde wahrscheinlich erfunden, um Probleme zu lösen, die andere Formate zu der Zeit nicht konnten (und ich tue es) auch ein NIHS-Syndrom haben).
Ich möchte nur teilen, dass aus der Perspektive, dass man ständig an verschiedene Ausgaben innerhalb der Branche liefern muss, das Three.js-JSON-Format nicht in die Landschaft passt, es ist überflüssig.

@kroko stimme definitiv zu 👍

Ich denke, die Formatlandschaft wird immer klarer. Das JSON-Format Three.js wurde erstellt, da es zu dieser Zeit noch kein JSON-Format gab. Ein Dateiformat zu definieren war das Letzte, was ich tun wollte, als ich bereits eine Rendering-Engine und eine API erstellte 😩

Als Neuling war der Three.js-JSON-Exporter sehr lehrreich, da ich damit die Rohdaten und die zugrunde liegende Struktur der Ausgabegeometrien sehen konnte. Andere Exportprogramme, so effizient sie auch sind, lassen Sie die Daten nicht sehen, da sie meistens im Binärformat vorliegen.

Ich stimme zu, dass es heute die beste Option wäre, es aus diesem Repo zu entfernen, aber wie @hccampos sagte, könnte es vielleicht in einem eigenen Repo platziert werden, um zu Bildungszwecken zu bleiben.

Ich stimme zu, dass es heute die beste Option wäre, es aus diesem Repo zu entfernen, aber wie @hccampos sagte, könnte es vielleicht in einem eigenen Repo platziert werden, um zu Bildungszwecken zu bleiben.

Es besteht immer die Möglichkeit, als JSON von http://threejs.org/editor/ zu exportieren.

Geschlossen in https://github.com/mrdoob/three.js/pull/14117.

Ich schlage vor, dass wir jetzt alle offenen Probleme schließen, die mit dem Blender-Exporter zusammenhängen. Einverstanden?

Ich denke, jemand kann eine "offizielle" Dokumentation / Pipeline für den Export/Import von 3D-Modellen (für grundlegende und spezielle Funktionen), allgemeine Fehlerbehebung und das Entfernen oder Aktualisieren aller veralteten Dokumente und Beispiele schreiben. ZB das Knight-Beispiel ist sehr verwirrend, da Sie keinen Blender-Json-Exporter mehr haben. Vielleicht sollte JSONLoader für 3D-Modelle nur aus Gründen der Retrokompatibilität beibehalten werden, aber das müssen wir lesen usw.

@stmaccarelli hier gibt es einige neue Dokumentationen: https://threejs.org/docs/#manual/introduction/Loading -3D-models, aber ja bitte lass uns wissen, was sonst noch hilfreich wäre!

@donmccurdy Ich denke, dass Papier schlecht ist.
Im Moment ist das gesamte 3D-Import-/Animationssystem angesichts der Mischung aus Dokumentationen, Beispielen und im Internet gefundenen Dingen aus verschiedenen Epochen verwirrend.

Das Master-Animationssystem-Dokument wäre in Ordnung, wenn die Refs der einzelnen Objekte korrekt wären.
Nehmen wir die AnimationClip-Referenz. Ich bin mir nicht sicher, ob ich morphTargets richtig exportiere, aber hier lese ich:

_.CreateClipsFromMorphTargetSequences ( name : String, morphTargetSequence : Array, fps : Number, noLoop : Boolean ) : Array
Gibt ein Array von neuen AnimationClips zurück, die aus den Morph-Zielsequenzen einer Geometrie erstellt wurden und versucht, Morph-Zielnamen in animationsgruppenbasierte Muster wie "Walk_001, Walk_002, Run_001, Run_002 ..." zu sortieren.

Das Problem ist, dass, wenn ich eine glTF-Datei importiere, kein morphTargetSequence-Array vorhanden ist ... hier und da einige morphTargetSequence-Objekte gespeichert sind, aber ich weiß nicht, was und wie ich es verwenden soll.

Ich denke, wir sollten einige Dokumente haben, die die Verwaltung von 3D-Modellen / Arbeitsabläufe mit sehr einfachen Beispielen beschreiben.
UND die 3D-Loader-Referenzen sollten alle dieselbe Vorlage berücksichtigen.
Sagen wir
1- einfacher 3D-Modellimport
2- Materialimport (mit allem drum und dran wie die verschiedenen Karten, Kartenparameter, Multimaterial-Management, etc)
3- Import der gesamten Szene (wie zum Durchlaufen / Verwalten importierter Szenen wie die von glTF)
4- Skelettanimation(en) importieren und verwalten
5- Import und Verwaltung von Morph-Animationen

Wir sollten auch überprüfen, ob alle Beispiele, die das Laden von 3D-Modellen beinhalten, dasselbe Muster berücksichtigen.

Wir sollten Beispiele aktualisieren, und obwohl es nicht möglich ist, sollten wir klar schreiben, dass einige Teile veraltet sind und was (wie im Ritterbeispiel ...)

_EG- Wenn wir entscheiden, dass das JSON-Dateiformat für das 3D-Modell zugunsten von – sagen wir – glTF eingestellt werden soll, macht es keinen Sinn, dass das einzige Animationsbeispiel, das sowohl Skelett-Animationen als auch Morphtargets enthält, das alte Ritter-Beispiel ist, das a . verwendet JSON-Modell von vor 10 Versionen, das eine Datenstruktur speichert, die nicht mehr verwendet wird._

@stmaccarelli Es gibt keinen einzigen empfohlenen End-to-End-Workflow; Ich denke, wir würden uns schwer tun, dies angesichts unterschiedlicher Fähigkeiten, Vorlieben für kostenlose und kostenpflichtige Modellierungstools und besonderen Anforderungen zu bieten.

Ich glaube nicht, dass Sie diese CreateClipsFromMorphTargetSequences Methode normalerweise brauchen würden. Das obige Dokument geht nicht auf die Details der Verwendung eines bestimmten Loaders ein (wie Sie bereits erwähnt haben, sind sie inkonsistent), aber die GLTFLoader-Dokumente tun -

loader.load('foo.glb', function(gltf) {
  const clips = gltf.clips;  // Array<THREE.AnimationClip>
  const model = gltf.scene; // THREE.Scene
  ...
});

In diesem Fall spielt es keine Rolle, ob es sich bei den Clips um TRS-, Skinned- oder Morph-Ziele handelt – Sie können die Animationen alle gleich abspielen. Ich habe einen möglichen Workflow mit Mixamo und Blender geschrieben . Hier ist eine weitere Verwendung von Maya .

Wir sollten auch überprüfen, ob alle Beispiele, die das Laden von 3D-Modellen beinhalten, dasselbe Muster berücksichtigen.

UND die 3D-Loader-Referenzen sollten alle dieselbe Vorlage berücksichtigen.

Dies ist ein fairer Punkt, und wir haben hier einiges Verbesserungspotential.

Es macht keinen Sinn, dass das einzige Animationsbeispiel, das sowohl Skelett-Animationen als auch Morphtargets enthält, das alte Ritter-Beispiel ist, das ein JSON-Modell von vor 10 Versionen verwendet, das eine Datenstruktur speichert, die nicht mehr verwendet wird.

Streng genommen sind das JSON-Format und die Datenstruktur nicht veraltet, und es ist immer noch eine völlig vernünftige Möglichkeit, eine Szene zu [de]serialisieren, aber es ist klar. @mrdoob was halten Sie davon, dass wir einige der Animationsbeispiele ersetzen? Wie zum Beispiel:

animation / keyframes / json
animation / scene
animation / skinning / blending
animation / skinning / morph

Was halten Sie davon, dass wir einige der Animationsbeispiele ersetzen?

+1 dafür. Ich stimme dafür, zumindest den Soldaten von animation / skinning / blending a durch ein moderneres Modell von Mixamo wie dieses zu ersetzen:

Wir könnten zwischen Leerlauf / Gehen / Laufen wechseln, und es wäre wahrscheinlich möglich, das Modell in glTF umzuwandeln, wenn dies bevorzugt wird.

Die Modellgröße würde etwa 9 MB betragen, während das aktuelle Modell zusammen mit allen zugehörigen Dateien 71 MB groß ist!

Für animation / skinning / morph könnten wir das Modell verwenden, mit dem ich FBX-Morph-Ziele getestet habe:

Es hat ungefähr die gleiche Größe wie das aktuelle Rittermodell, aber da Morph-Ziele häufiger für Gesichtsausdrücke verwendet werden, würde ich sagen, dass dieses hier sinnvoller ist. Auch hier liegt es derzeit im FBX-Format vor, könnte aber in glTF konvertiert werden, wenn dies bevorzugt wird.

Hier sind einige Beispiele, die Sie berücksichtigen sollten:

| Screenshot | Link | Größe |
|---|---|--|
| | Link | 6 MB |
| | Link | 3 MB |
| | Link | 5 MB |
| | Link | 12 MB |

Sie sind alle animiert, funktionieren in Three.js korrekt und könnten wahrscheinlich etwas stärker komprimiert oder optimiert werden als die Sketchfab-Download-Version. Ich habe keinen manipulierten Charakter mit schönen Lauf- / Gehzyklen , aber der