Das sieht richtig gut aus!

Übrigens, wir planen, THREE.GLTFLoader zu entfernen und GLTF2Loader → GLTFLoader Kürze umzubenennen*. Es könnte eine gute Idee sein, den Exporter in GLTFExporter umzubenennen, bevor r87 landet, um Verwechslungen zu vermeiden und damit keine Namensänderung zwischen den Releases erforderlich ist. Ups, ich habe übersehen, dass du es schon so genannt hast... weiter so! 😆

* @mrdoob , haben Sie eine Präferenz, wann das passieren soll? IMO könnten wir dies jetzt tun, es sei denn, wir wollen GLTFLoader in r87 mit nur einer veralteten Warnung behalten und es in r88 entfernen?

Ich denke je früher desto besser. Solange das neue GLTFLoader 1.0 erkennt und den Benutzer warnt, dass wir nur 2.0+ unterstützen.

IIRC können wir erkennen, indem wir asset wie ich bereits erwähnt habe.

IIRC können wir erkennen, indem wir Assets sehen, wie ich bereits erwähnt habe.

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

Cool! Aber ich habe einen kleinen Fehler gefunden. Ich mache jetzt PR. Lassen Sie uns zusammenführen, bevor wir umbenennen.

Können wir die Punkte, an denen jemand arbeitet, in der Checkliste angeben?

@takahirox sicher! Leute könnten hier einfach Kommentare schreiben und ich könnte die Liste aktualisieren und auf eine PR verweisen, wenn schon etwas los ist

Als nächstes werde ich an den Texturen arbeiten, um sie in base64 zu konvertieren, anstatt nur die URL zu verwenden

Vielen Dank! Ich möchte helfen, den glTF-Exporter zu erstellen. Ich überlege, was ich in der Checkliste helfen kann...

Übrigens, hast du absichtlich zwei Variablen WEBGL_CONSTANTS und THREE_TO_WEBGL global gelassen?

@takahirox cool!
In Bezug auf die beiden Variablen werde ich dies in der folgenden PR ansprechen, um sie zu einem Teil von WebGLUtils und sie einfach zu importieren. Es macht keinen Sinn, dass jeder, der diese Konstanten benötigt, sie jedes Mal neu definieren muss.

@takahirox btw natürlich können Sie der Liste gerne neue Elemente vorschlagen! ;)

@fernandojsg Klar! Was die Variablen betrifft, ich wollte vorschlagen, sie irgendwohin zu verschieben, wenn sie absichtlich als global deklariert wurden, also ist es schön zu wissen, dass Sie dies tun.

Ich möchte an der geteilten Pufferansicht arbeiten.

BufferViews: Derzeit erstelle ich eine neue bufferView für jeden Accessor, dies sollte behoben werden, um nur eine für diese Attribute zu verwenden, die denselben Komponententyp verwenden

Der Grund, warum einer für die Attribute mit demselben Komponententyp und nicht einer für alle Attribute der Datenabgleich ist, richtig?

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

Cool, ich habe dich gerade zur Liste hinzugefügt 👍 Ja, im Grunde willst du die gleiche Pufferansicht für eine Komponente mit demselben Typ teilen, zum Beispiel wenn du position und normal hast, hast du zwei VEC3-Zugriffsmethoden, die aber zeigen zur gleichen Pufferansicht. Das könnte ein guter Ausgangspunkt sein ;)

Ich meinte, der Grund, warum die Pufferansicht nicht von verschiedenen Komponententypen (z. B. Float und Short) geteilt wird, besteht darin, eine gute Datenausrichtung beizubehalten, richtig?

Ich glaube, Sie können verschiedene Komponententypen in derselben Pufferansicht speichern, solange sie die gleichen target , zum Beispiel normal (Vec3) , position (Vec3) und uv (Vec2) könnte sich in derselben Pufferansicht befinden, aber indices nicht. @donmccurdy kannst du das bestätigen?

Ja, zugestimmt. Und wie diese glTF-Spezifikation erwähnt

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

Der Offset eines Accessors in eine bufferView (dh accessor.byteOffset) und der Offset eines Accessors in einen Puffer (dh accessor.byteOffset + bufferView.byteOffset) müssen ein Vielfaches der Größe des Komponententyps des Accessors sein.

Es ist eine gute Idee, der Einfachheit halber Pufferansichten zwischen den verschiedenen ComponentType(=Datentypen wie float und short, nicht vec2 oder vec3) zu trennen. Wenn wir sie zwischen Komponententyp mit unterschiedlicher Datenlänge trennen, wäre es optimierter.

Gibt es übrigens besondere Gründe, warum der aktuelle Exporteur nur accessor.componentType float, uint und ushort unterstützt? glTF 2.0 kann zusätzlich zu char, uchar und short umgehen.

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

@takahirox nicht wirklich, ich habe diese jetzt gerade definiert, weil sie für die Art von Attributen verwendet werden, die wir gerade unterstützen (Positionen, Normalen, Farben, UVs, Indizes..).
Der nächste Schritt, an dem ich arbeite, sind die Texturen, also brauchen wir zum Beispiel andere wie uchar

OK, also werde ich zuerst an den accessor.componentType s arbeiten, es sei denn, Sie haben bereits mit der Implementierung begonnen.

Fast fertig, aber meine PR sollte mit #11978 in Konflikt geraten.
Also sende ich meine, sobald #11978 zusammengeführt ist und ich den Konflikt behebe.

Würden Sie der Liste eine Animation hinzufügen?

@takahirox sicher, es könnte großartig sein, Animationen hinzuzufügen. Ich habe es nur nicht hinzugefügt, weil ich mit dem aktuellen Stand der Animationsfunktionen von Three.js nicht vertraut genug war, aber wenn du Lust hast, es zu übernehmen, wäre es großartig;)

Planen Sie, BufferGeometry-Gruppen zu unterstützen?
Decken die GLTF-Spezifikationen das ab oder würde dies dazu führen, dass für jede Gruppe ein neues Mesh erstellt wird?
Dies muss auch berücksichtigt werden, da die Materialeigenschaft eines Meshs eine Reihe von Materialien ist.

@marcatec Die glTF-Spezifikation hat eine Unterscheidung zwischen "Mesh" und "primitive", die es Ihnen ermöglichen würde, BufferGeometry-Gruppen zu erstellen, die jeweils auf ein anderes Material verweisen könnten. Derzeit optimiert THREE.GLTFLoader das Laden von Primitiven nicht – es erstellt separate Meshes – aber das könnte implementiert werden.

Tolle Arbeit, tolle Liste und gut zu wissen, dass es schon so viel Unterstützung für das Format gibt! Funktioniert auch sehr gut zusammen mit dem gltf Blender Exporter. Kann es kaum erwarten, Lichter zu unterstützen! Mach weiter so mit der tollen Arbeit.

Ich stimme zu, tolle Arbeit!

Ist geplant, neben StandardMaterial auch andere Materialien zu unterstützen?

Vielen Dank!

@homerjam alle Materialeigenschaften, die mit MeshStandardMaterial geteilt werden, werden beibehalten – zum Beispiel würde ein MeshPhongMaterial, das map und normalMap , mit diesen intakten Texturen exportiert, aber wenn Sie es zurück in Three.js importieren, wird es exportiert wird ein MeshStandardMaterial sein. Dafür führt der Exporteur derzeit eine naive Umstellung auf PBR durch.

Round-Trip-Unterstützung (Phong aus GLTFExporter exportieren, Phong aus GLTFLoader laden) erfordert laufende Arbeiten am glTF-Format: https://github.com/KhronosGroup/glTF/pull/1150

baseColorTexture : Wird unterstützt (material.map), aber texCoord ist immer auf 0 gesetzt

@fernandojsg könntest du klären, was hier fehlt? Da .map immer der erste UV-Satz in Three.js ist, klingt dies nach der richtigen Darstellung in glTF?

Außerdem habe ich drei Punkte auf der Liste durchgestrichen. Begründung unten:

• Tangenten
  
  
  
  • Three.js berechnet sie nur auf der GPU; Das Hinzufügen einer Implementierung nur für den Exporter klingt nicht ideal.
  
  
• spärliches Zubehör
  
  
  
  • Ich denke, dies sollte am besten der Post-Export-Optimierung überlassen werden , wie
  
  
• Überprüfen Sie, ob das Material mit dem glTF-Standard übereinstimmt, und lassen Sie es weg
  
  
  
  • fühlt sich an wie ein Randfall / Durcheinander, kann gerne umgesetzt werden, wenn sich jemand stark fühlt
  
  

Beim Exportieren nach GLB aus dem Editor habe ich festgestellt, dass alphaMap , roughnessMap und metalnessMap nicht exportiert werden.

In #13397 habe ich gesagt, dass normalMap nicht exportiert wird, aber es scheint, als hätte ich mich geirrt.

Beim Exportieren nach GLB aus dem Editor habe ich festgestellt, dass alphaMap, rawnessMap und metalnessMap nicht exportiert werden.

Ich werde heute daran arbeiten, es sei denn, es hat schon jemand angefangen.

@donmccurdy

spärliches Zubehör
Ich denke, dies sollte am besten der Post-Export-Optimierung überlassen werden, wie das Skript von mattdesl.

Ich habe das Gefühl, dass der Exporter spärliche Accessoren für Morph unterstützt. Ich werde es später versuchen.

@takahirox cool! fortfahren!

Ich glaube nicht, dass alphaMap in glTF 2.0 unterstützt wird.

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

Ja, das habe ich befürchtet.... Was ist mit metalnessMap und roughnessMap ?

Ich arbeite jetzt an ihnen!

13415

Apropos Bildformate. glTF 2.0 unterstützt nur .png und .jpg als externe Bilddateien. Ich überlege, wie ich nicht unterstützte Bildformatdateien (zB: .bmp) im Nicht- embedImages Modus handhabe.

1. In .png oder .jpg konvertieren und einbetten
2. Kümmere dich nicht. Als Original-Bilddateien exportieren
3. Nicht exportieren

Ich bevorzuge 1. Irgendwelche Gedanken?

Wow, ich schätze die Werke von euch wirklich sehr.

Ich hoffe, dass Multi-material meshes so schnell wie möglich implementiert wird, da die meisten 3D-Modelle Multi-Materialien verwenden.

1. In .png oder .jpg konvertieren und einbetten
2. Kümmere dich nicht. Als Original-Bilddateien exportieren
3. Nicht exportieren

Ich stimme für 3 und logge eine Warnung in der Konsole ein.

Ich hoffe, dass Multi-Material-Netze so schnell wie möglich implementiert werden, da die meisten 3D-Modelle Multi-Materialien verwenden.

Zugegeben, für mich ist dies das Hauptproblem, das die Verwendung des Exporteurs verhindert.

Ich hoffe, dass Multi-Material-Netze so schnell wie möglich implementiert werden, da die meisten 3D-Modelle Multi-Materialien verwenden.

Wie ich im anderen Thread schon sagte, arbeite ich daran.

1. In .png oder .jpg konvertieren und einbetten
2. Kümmere dich nicht. Als Original-Bilddateien exportieren
3. Nicht exportieren

Ich stimme für 3 und protokolliere eine Warnung in der Konsole

Ja, ich dachte, 3. wäre einfacher und für die Benutzer nicht verwirrend. Ein eingebettetes Bild im Nicht- emedImages Modus zu erhalten, wäre etwas verwirrend.

Der Grund, warum ich 1. bevorzuge, war die Konvertierung von anderen Formaten in glTF. Bei einigen (oder vielen) anderen Formaten gibt es keine Bildformatbeschränkung.

Der Exporteur konvertiert im embedImages Modus. Das Hinzufügen von "Option embedImages verwenden, wenn Sie konvertieren möchten" zur Konsolenwarnung wäre also gut, denke ich.

Ich würde auch für 3 gehen. Da das Konvertieren von anderen Formaten mühsam sein kann, müssen Sie sowieso einige Formate gegenüber anderen priorisieren. Wahrscheinlich lohnt es sich, jetzt 3 zu machen und abzuwarten, ob gltf neue Texturformate wie ktx oder so unterstützt und wir die Implementierung überdenken könnten.

Wie in https://github.com/mrdoob/three.js/pull/13415#issuecomment -369022383 beschrieben, wäre es schön, wenn der Exporteur die ambientRoughnessMetalness Textur für den Benutzer erstellen könnte. Es ist jedoch wahrscheinlich besser, diesen Code in ImageUtils .

Ich habe die Checkliste mit den neuesten Änderungen aktualisiert. Ich habe @takahirox zum multimaterial hinzugefügt und übernehme selbst die Aufgabe zum Erstellen von Bildern.
Ich habe auch die Erweiterung material_unlit hinzugefügt, obwohl sie sich noch im Entwurf befindet, glaube ich, dass sie kurz vor der Veröffentlichung steht und sich nicht so viel ändern wird (/cc @donmccurdy)

Ich hoffe, dass Multi-Material-Netze so schnell wie möglich implementiert werden, da die meisten 3D-Modelle Multi-Materialien verwenden.

Wie ich im anderen Thread schon sagte, arbeite ich daran.

WIP... (Miku hat Multimaterial)

Über nicht unterstützte Bildformate, ok, gehen wir für 3.

@takahirox sieht gut aus! 👍

Übrigens, sind Sie an der Unterstützung von Zip-Archiven interessiert? .glTF + externe .bin und Texturen würden zu anderen Authoring-Tools passen (vielleicht), aber mit Nicht-Archiven schwer zu machen. ZIP-Archiv wäre also notwendig. Und wir können die exportierte Dateigröße reduzieren.

Ich möchte es und in meiner Filiale vor Ort ausprobiert, kann ich später teilen, wenn Sie interessiert sind.

Ist das nicht so ziemlich das Gleiche wie das Gzipping eines glb?

.glTF + externe .bin und Texturen würden zu anderen Authoring-Tools passen (vielleicht)

Ich hoffe, Authoring-Tools benötigen keine separaten Dateien; Wir ermutigen alle, GLB standardmäßig zu verwenden. Aber es ist sicher einfacher, ein Bild von Hand zu bearbeiten, wenn es nicht eingebettet ist.

Keine eindeutige Meinung darüber, ob wir diese Funktionalität direkt in THREE.GLTFExporter einfügen wollen... aber ich denke fast, dass wir nicht zu viele Optionen haben sollten, die stattdessen nachträgliche Optimierungen auf der glTF sein könnten. Ein anderes Beispiel, Draco ist ziemlich kompliziert und erfordert mehrere externe Dateien, also ist es vielleicht besser, spezialisierte glTF-zu-glTF-Tools diese Optimierung durchführen zu lassen? Und auf ähnliche Weise könnten wir einen glb-unpacker (im Gegensatz zu http://glb-packer.glitch.me/) erstellen, um den Leuten zu helfen, Dateien von GLB nach ZIP zu entpacken, wenn wir herausfinden, dass die Leute ihn brauchen.

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

... die ursprüngliche Absicht von gltf-pipeline - und eigentlich von glTF im Allgemeinen - Exporteure so einfach wie möglich zu machen und die Optimierungen auf ein gemeinsames Tool zu übertragen. Es hilft natürlich auch bei der Fragmentierung.

das heißt, es gibt noch keinen glb-unpacker, den ich kenne...

@mrdoob

Ich wollte, dass Texturbilder extern sind und nicht .glTF vs. .glb.

@donmccurdy

Ich habe die https://github.com/KhronosGroup/glTF/issues/1117 Diskussion verfolgt und stimme der Förderung von .glb + eingebetteten Dateien und dem Pipeline-Ansatz jetzt zu. Eine .glb ist gut für die Datenübertragung, insbesondere für den Web- und Pipeline-Ansatz, kann Exporter und Tools einfach und wiederverwendbar halten. (Ich mag auch den UNIX/Linux-Befehlspipeline-Ansatz!)

Ich glaube also nicht, dass der Exporter jetzt die Unterstützung von Zip-Archiven benötigt. Und vielleicht braucht es aus dem gleichen Grund auch keine spärlichen Accessor- und Draco-Unterstützung.

Was glb-unpacker angeht, werde ich es vielleicht in meiner Freizeit schaffen. Ich denke, einige Künstler mögen .glTF + externe Dateien, weil sie ohne glTF-spezifische Tools lesbar sind. Und manchmal können externe Dateien die Ladezeit aufgrund des parallelen Ladens der Datei verkürzen, sodass sie zu Optimierungszwecken verwendet werden können.

In Bezug auf Pipeline-/Optimierungstools möchte ich anmerken, dass wir keine riesigen Daten über das Netzwerk übertragen

Außerdem würden wir uns für Three.js und andere browserbasierte JavaScript-Engines freuen, wenn wir glTF-Optimierungstools haben, die auf Browsern ausgeführt werden. Wir können optimieren/komprimieren, bevor Daten an Benutzer weitergegeben werden. Ohne sie müssen Benutzer die exportierten Daten manuell herunterladen und dann aufgrund von Browserbeschränkungen an Pipeline-Tools übergeben.

Aus dieser Sicht möchte ich, dass ein Tool überall laufen kann, im Browser, auf dem Server, der CUI usw., damit es allgemeiner und wiederverwendbarer wird. Wir wollen nicht die gleichen Tools für verschiedene Plattformen zweimal oder öfter erstellen. Node.js-basiertes Tool wäre also gut? Hat das glTF-Team (Pipeline) irgendwelche Vorschläge? (Vielleicht sollte diese Diskussion in glTF geführt werden, nicht hier.)

Nur für den Fall, dass in GLTFLoader Binärunterstützung als Erweiterung implementiert ist, aber .glb in der Kernspezifikation von glTF 2.0 enthalten ist, richtig?

Nur für den Fall, dass in GLTFLoader Binärunterstützung als Erweiterung implementiert ist, aber .glb in der Kernspezifikation von glTF 2.0 enthalten ist, richtig?

Ja, es war eine Erweiterung in glTF 1.0 und ich habe diesen Code nie verschoben oder umbenannt, nachdem er Teil der glTF 2.0-Kernspezifikation wurde.

Aus dieser Sicht möchte ich, dass ein [Optimierungstool] überall ausgeführt werden kann, im Browser, auf dem Server, der CUI usw., damit es allgemeiner und wiederverwendbarer wird. Node.js-basiertes Tool wäre also gut? Hat das glTF-Team (Pipeline) irgendwelche Vorschläge? (Vielleicht sollte diese Diskussion in glTF geführt werden, nicht hier.)

Es lohnt sich, nach der glTF-Pipeline-Roadmap zu fragen ... nicht sicher, wie allgemein die glTF-Pipeline sein soll, oder ob sie hauptsächlich für Cäsium verwendet wird oder ob es nur um begrenzte Entwicklerzeit geht. Auch glTF-Toolkit sieht relevant aus, läuft aber (derzeit) nur unter Windows. Ich persönlich mag Node.js, aber C++ oder Rust könnten eine vernünftige Wahl bei der Kompilierung nach WASM sein.

Oh, mir fehlte die Zusammenstellung zu WASM. Die Angabe einiger empfohlener Entwicklungsplattformen wäre für Optimierungsentwickler hilfreich. Daher würde ich einen entsprechenden Thread vorschlagen.

Ich stimme @donmccurdy zu, da ich der Meinung bin, dass diese Optimierungen in der Pipeline in einem anderen Repository als Three.js leben könnten, sodass jeder davon profitieren könnte. Ich muss noch die Unterschiede zwischen der gltf-Pipeline und den Toolkit-Tools überprüfen, aber ich würde erwarten, dass diese Art von Funktionen darin enthalten sind.
Ich stimme auch zu, dass die Quellsprache, solange wir ein WASM haben, keine Rolle spielt, aber es ist auch wahr, dass, wenn es in node.js geschrieben ist, wahrscheinlich viele der Community rund um die 3D-Web-Engines helfen könnten, sie zu verbessern, da im Moment sind sowieso das Hauptziel für dieses Dateiformat.

Ich bin mir nicht sicher, ob ich "Optimieren vor der Transformation" verstehe ... es gibt verschiedene Arten von Transformationen, die eine Pipeline an einem Modell durchführen kann, und Optimierungen sind wahrscheinlich die gebräuchlichste Transformationsart?

Darüber hinaus vereinbart. Es ist gut, fokussierte Tools auf niedriger Ebene zu haben, die verwendet werden können, um andere Tools zu erstellen oder in eine benutzerfreundlichere GUI einzubinden.

Ups, es ist ein Tippfehler. Nicht transformieren, sondern übertragen. Ich meinte, die meisten Benutzer wollen optimieren/komprimieren, bevor sie Daten über das Netzwerk senden. Ich habe die Beiträge aktualisiert, damit sie übersichtlicher sind.

Hallo Leute

Ich verwende den THREE.js GLTF-Exporter, um eine gesamte Aframe-Szene als gltf-Objekt zu exportieren.
Wie kann ich die auf aframe definierten a-Animations-Tags als Teil der Animationen im gltf-Objekt erhalten?

@donmccurdy @fernandojsg @mrdoob

Hallo @siddhartpai — THREE.GLTFExporter konvertiert nur THREE.AnimationClip Objekte in glTF-Animationen, während das Animationssystem von A-Frame TweenJS verwendet. Dies ist derzeit also nicht möglich. Vielleicht möchten Sie ein Issue in A-Frame oder dem A-Frame Inspector öffnen, die auch GLTFExporter , um es als zukünftige Funktion anzufordern.

Multi-Material-Unterstützung #13536

Mir ist gerade aufgefallen, dass der Validator bei jedem normalen Element in einer nicht normalisierten Pufferansicht einen Fehler auslöst. zB Wenn ich nicht initialisierte Werte wie [0,0,0] gespeichert habe, wird dieser Fehler ausgelöst.
Da es sich um einen Fehler und nicht um eine Warnung / einen Hinweis handelt, sehe ich, dass es empfindlich zu beheben ist. Was halten Sie davon, sicherzustellen, dass die normalen Bufferview-Elemente normalisiert sind? Sollten wir dennoch für Werte, die nicht normalisiert werden können, wie [0,0,0], einen gültigen Einheitsvektor verwenden? /cc @donmccurdy

Scheint, als ob NORMAL normalisiert werden sollte.

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

NORMAL | "VEC3" | 5126 (SCHWIMMEN) | Normalisierte XYZ-Scheitelpunktnormalen

Ich stimme der Gewährleistung zu, da Three.js normal keine solche Einschränkung hat.

Ja, aber was ist zu tun, wenn Sie keinen tatsächlichen Normalwert haben, z. B. einen unbenutzten Wert von [0,0,0], erstellen Sie einfach einen gültigen und das ist in Ordnung? sagen wir [1,0,0]. Daher sollten wir den Pufferview-Code ändern, um zu erkennen, dass wir ein normales Attribut analysieren, und jedes einzelne normalisieren, bevor wir es in der Datenansicht speichern.

was zu tun ist, wenn Sie keinen tatsächlichen Normalwert haben, z. B. einen ungenutzten Wert von [0,0,0]

Hm.... durch ein gültiges ersetzen und eine Warnung anzeigen?

Daher sollten wir den Pufferview-Code ändern, um zu erkennen, dass wir ein normales Attribut analysieren, und jedes einzelne normalisieren, bevor wir es in der Datenansicht speichern.

Ich bevorzuge es in processMesh() weil es einfacher wäre, wie

var originalNormal = geometry.attributes.normal;

if ( hasNonNormalizedValues( originalNormal ) ) {

    geometry.attributes.normal = createNormalizedAttribute( originalNormal );

}

processAccessorHere();

geometry.attributes.normal = originalNormal;

Wenn wir dies in processBufferView() tun, wird der Code etwas komplex, da wir darauf achten müssen, ob die Daten von verschiedenen Attributen geteilt werden, zum Beispiel Position und Normal. (Ich weiß, dass es ein sehr seltener Anwendungsfall ist, aber Three.js schränkt nicht ein.)

Ja, ich mag diesen Ansatz, ich hatte Angst, die Normalen nach dem Exportieren zu ändern, aber es sollte in Ordnung sein, wenn wir eine Referenz speichern und sie nach dem Abschluss wieder zurücksetzen. :+1: Würde es Ihnen etwas ausmachen, mit diesen Änderungen eine PR zu forcieren? oder soll ich das machen?

Ok, ich werde. (Haben Sie es eilig, das zu beheben?)

@takahirox cool, danke! aber keine Eile, ich habe nur den Zustand des Exporteurs überprüft ^_^

OK, dann mache ich das diese Woche ~morgen~.

Richtig, glTF erlaubt nicht das Auslassen von Normalen auf bestimmten Scheitelpunkten, aber nicht anderen in einem einzelnen Primitiv. Wir müssen einen Wert angeben, diese Scheitelpunkte entfernen oder einen Fehler auslösen.

Ich würde es vorziehen, die Dinge für den Benutzer einfacher zu machen, daher ist meine Stimme dafür, ein neues Normals-Array zu erstellen, das sie normalisiert und einen (0,1,0)-Wert für die leeren hinzufügt.

Hört sich gut an. Wenn es bei großen Modellen langsam ist, möchten wir vielleicht eine Option checkNormals oder ähnliches, damit Benutzer, die dies nicht benötigen, sich abmelden können, anstatt jeden Scheitelpunkt zu scannen.

Ja, das gleiche wollte ich gerade schreiben! :D

Wenn es bei großen Modellen langsam ist, möchten wir vielleicht eine checkNormals-Option oder ähnliches, damit Benutzer, die dies nicht benötigen, sich abmelden können, anstatt jeden Scheitelpunkt zu scannen.

Ich werde zuerst PR ohne diese Option machen. Fügen wir bei Bedarf hinzu. Persönlich nehme ich an, dass diese Überprüfung nicht viel verlangsamt.

Ich werde zuerst PR ohne diese Option machen. Fügen wir bei Bedarf hinzu. Persönlich nehme ich an, dass diese Überprüfung nicht viel verlangsamt.

Ich habe die ganzen Puffer normalisiert, wenn ich jeden Strich auf a-painter geladen habe, und es war ziemlich langsam

Selbst wenn Sie nur überprüfen, ob sie normalisiert sind?

@takahirox du musst die Länge sowieso berechnen, also wird es sich wohl nicht so sehr ändern

Hm, ok. Werde ich mit dem PR auswerten.

Es ist die erste GLTFExporter-Funktion, die wir eingeführt haben, die jede Berechnung mit jedem Scheitelpunkt durchführt (außer der relativen/absoluten Morph-Zielkonvertierung), also ja, potenziell langsamer.

Gute Arbeit! IMHO sollte in core drei.js zusammengeführt werden, anstatt in "Beispiele".
Würde gerne KHR_lights_punctual Unterstützung sehen!

PR https://github.com/mrdoob/three.js/pull/15519 fügt KHR_lights_punctual hinzu. :)

Ich denke, dieses Problem kann wahrscheinlich geschlossen werden – die verbleibenden Elemente sind weniger kritisch für Komfort oder Optimierung und können an anderer Stelle nachverfolgt werden:

• [ ] Bufferviews wiederverwenden
• [ ] verschmelzen automatisch Metall-/Roh-/Ao-Texturen

Hey Leute, weiß jemand, wie ich ein benutzerdefiniertes geformtes Mesh exportieren kann, indem ich Morph-Änderungen anwendet, die die Morphs anwenden und aus dem endgültigen Objekt entfernen?
Like diese Frage https://stackoverflow.com/questions/57423471/how-to-export-morph-changed-meshes-from-threejs-application
Danke im Voraus!

@vini-guerrero Bitte verwenden Sie die Foren (https://discourse.threejs.org/) oder Stack Overflow für Hilfe, anstatt GitHub-Probleme.