Es ist eine gültige Funktionsanfrage, aber ich persönlich verstehe Apple/Pixar nicht. Warum führen sie ein neues Dateiformat ein und verwenden nicht nur glTF ? Kann jemand erklären, was USD / USDZ besser macht als glTF ?

USD-Dokumentation: http://graphics.pixar.com/usd/docs/index.html

Es ist eine gültige Funktionsanfrage, aber ich persönlich verstehe Apple/Pixar nicht. Warum führen sie ein neues Dateiformat ein und verwenden nicht nur glTF? Kann jemand erklären, was USD/USDZ besser macht als glTF?

Ich stimme zu, ein Teil davon ist Politik, denke ich. Aber das ist eine separate Diskussion :)

USD gibt es schon seit ein paar Jahren – es wird häufig im Film verwendet und ist keine offensichtliche Wahl für die Laufzeitübertragung. Soweit ich das beurteilen kann, ist USDZ ein Wrapper dafür. Apple hat zu diesem Zeitpunkt nicht viele Details angegeben; Vielleicht haben sie einen Plan, um es laufzeitgerechter zu machen, oder vielleicht war das Messaging auf der WWDC einfach unklar in Bezug auf die tatsächliche Verwendung. Auf jeden Fall denke ich, dass wir wahrscheinlich auf weitere Informationen warten müssen.

Wenn jemand daran interessiert ist, THREE.USDZLoader beizutragen, dann auf jeden Fall. 🙂 Aber die gesamte Dokumentation, die ich bisher gefunden habe, deutet darauf hin, dass das Format sehr eng an die offiziellen (C++/Python) Bibliotheken zum Parsen gebunden ist, ähnlich wie bei FBX und dem FBX SDK. Wenn diese also nicht mit WASM webfreundlich gemacht werden können, scheint die Implementierung der USDZ-Unterstützung in three.js und das Aufrechterhalten von Änderungen im Format im Laufe der Zeit ein sehr zeitaufwändiger Prozess zu sein, ohne die Vorteile dieser Bibliotheken.

Aus Neugier habe ich versucht, die Datei "Retro TV" von https://developer.apple.com/arkit/gallery/ zu öffnen, als wäre es eine einfache ZIP-Datei. Ich habe die .usdz 'entarchiviert', indem ich ihre Erweiterung in .zip umbenannt habe und dann mein Betriebssystem die übliche Öffnungsprozedur ausführen lasse. Vermutlich könnte ähnliches mit https://gildas-lormeau.github.io/zip.js/ erreicht werden.

Folgendes sehe ich, wenn ich die usdz "entpacke":

Die Texturen sind also nur PNGs, auf die wahrscheinlich innerhalb dieser .usdc verwiesen wird, was das nächste Problem darstellt. Laut https://graphics.pixar.com/usd/docs/Converting-Between-Layer-Formats.html , ".usdc-Dateien – Binärformat", das sich in Crate befindet (siehe _Crate File Format_ in https://graphics. pixar.com/usd/docs/USD-Glossary.html) Format.

Es gibt auch .usda, das ASCII-codiert ist, was vermutlich einfacher wäre, einen Loader zu schreiben.

Als grober Überblick über einige Aufgaben dafür würde ein Loader mindestens eine Zip-Datei in JS extrahieren und dann auch die .usda (und möglicherweise auch die binäre Crate .usdc) verstehen.

Hallo @richardmonette , ich habe etwas über USDZ und das USDA-Format recherchiert und einen Proof-of-Concept-GlTF-zu-USDZ-Konverter geschrieben. Vielleicht ist es für Ihre Recherche nützlich: https://github.com/timvanscherpenzeel/gltf-to-usdz. Eine Demo können Sie hier sehen: https://twitter.com/domenicopanacea/status/1011292393801420800 oder probieren Sie es selbst hier aus: https://timvanscherpenzeel.github.io/gltf-to-usdz/ (benötigt iOS 12).

Kurz gesagt: Geometrie wird in OBJ konvertiert, die Metallic-Roughness-Textur wird nach Kanälen aufgeteilt und Texturen werden Y-gespiegelt. Daraus wird eine USDA Datei dynamisch konstruiert und in usdz_converter eingespeist, um das endgültige usdz zu konstruieren.

Ich weiß, dass einige Leute darüber nachdenken, einen direkten Konverter in USDZ zu schreiben, aber zu diesem Zeitpunkt ist nicht viel über das USDC Format bekannt (auch in Bezug auf die Dekodierung).

Hey @TimvanScherpenzeel , danke für deine Nachricht und arbeite daran!

Haben Sie darüber nachgedacht, die USD Python API (https://graphics.pixar.com/usd/docs/Hello-World---Creating-Your-First-USD-Stage.html) zu verwenden? Ich habe mich gefragt, ob es möglich ist, die .obj-Phase zu überspringen und mit Python die glTF zu lesen und auf diese Weise direkt in .usda/c zu gelangen?

Ich hatte viele Probleme beim Einrichten von USD und habe mir noch nicht die Zeit genommen, das Problem zu beheben (ich denke, es hat etwas damit zu tun, dass mehrere Versionen von Python installiert sind und während der Kompilierung mit dem falschen Python verknüpft wird).

Sie könnten die OBJ-Datei tatsächlich direkt in die USDA-Datei schreiben (das könnte tatsächlich ein guter nächster Schritt in meinem Proof of Concept sein). Ich kenne die Dateistruktur der AR Gallery-Beispiele, weil mir ein Mitwirkender an meinem Projekt die USDA-Dateien schickt, nachdem er die USDC-Dateien mit usdcat entschlüsselt hat.

Der ganze Sinn von Apple, das einen USDZ QuickLook bereitstellt, besteht darin, die Verwendung von WebGL, DOM und Javascript vollständig zu umgehen und die Szene direkt mit ARkit2.0 zu verwenden.
Es ist nur ein Meilenstein für ein auf Apple/Pixar-Technologie basierendes rOS.
Wenn sie später Interaktivität/Skriptfähigkeit hinzufügen, wird noch weniger Web-UI benötigt.

Pixar USD, das hocheffiziente OpenSubDiv-Patches für die Geometrie verwendet und auf Mobile Metal portiert wird, wird bald HighEnd PC-VR WebVR übertreffen.
Nicht als Dateiformat, sondern als ganze Experience-Making/Presenting/(-Interaction)-Pipeline.

Daher ist es IMHO wichtiger, USDZ aus AR/VR-Editoren und für Android und Windows zu exportieren, um den USD-Zug zu erreichen, als einen Importeur zur WebGL2 Pipeline hinzuzufügen.

Ein wichtiges Thema ist, dass WebXR auch SubDiv-Patches anstelle von Legacy-Polymeshes unterstützen müsste, um USD, wie es von Apple verwendet wird, vollständig zu unterstützen.

@pixelpartner du hast mich

Es scheint mir, dass es hilfreich wäre, einen in JavaScript zu erstellen, es sei denn, ein Loader ist nativ in Browser integriert.

Ich bin mir sicher, dass Quick Look stark optimiert ist, aber wie sieht der Weg zur Erstellung interaktiver Inhalte mit USDZ-Assets in einem Browser aus?

Es ist eine gültige Funktionsanfrage, aber ich persönlich verstehe Apple/Pixar nicht. Warum führen sie ein neues Dateiformat ein und verwenden nicht nur glTF? Kann jemand erklären, was USD / USDZ besser macht als glTF?

Ich hatte vor kurzem ein Gespräch mit jemandem, der an Produktdarstellungssoftware arbeitet, die nach glTF und USDZ exportiert, also fragte ich ihn, was er davon hält. Sein Fazit: Damit Apple mit einem exklusiven 3D-Format, das nur über ARKit2.0/SceneKit auf seiner Plattform funktioniert, weiterhin behaupten kann, die High-End-Luxus-Wahl zu sein. Die Übernahme des Standardformats glTF würde hier ihren Zielen zuwiderlaufen, sie möchten behaupten können, dass _ihr_ Format besser ist und aufgrund von PBR-Materialeigenschaften, die glTF (noch?) nicht unterstützt, qualitativ hochwertigere Ergebnisse ermöglicht.

16977 und vielleicht #14051 werden wahrscheinlich benötigt, um three.js auf die gleichen Rendering-Standards wie die Angebote von Apple zu bringen, aber ich bin mir nicht sicher, wie sich der aktuelle Zustand oder die zukünftigen Pläne für glTF darauf beziehen.

Auf jeden Fall, wenn auch nur um Apples schändliche Ziele hier zu untergraben, denke ich, dass wir USDZ irgendwann unterstützen müssen.

Damit Apple weiterhin behaupten kann, die High-End-Luxus-Wahl zu sein, mit einem exklusiven 3D-Format, das nur auf ihrer Plattform funktioniert ...

Ich bin bereit, hier im Zweifel mehr zu nutzen – sie haben andere Ziele für ein "Laufzeitformat" als wir (drei + Webentwickler) und können daher andere Entscheidungen treffen. Insbesondere die Bündelung der ~15 MB USD-Laufzeit in iOS bedeutet, dass es ihnen egal ist, dass das Laden von USDZ _ohne_ einer nativen Laufzeit untragbar schwierig ist, und es scheint in Ordnung zu sein, der Webanwendung keinen Zugriff auf das Modell zu gewähren, sondern nur das zu öffnen modellieren Sie stattdessen so, wie es ist, in einer nativen App.

Bei "High-End-Luxus" unterstützt Apples iOS QuickLook-Viewer metallische/raue PBR-Materialien, und das Materialmodell entspricht weitgehend dem, was glTF 2.0 heute unterstützt. Die in Zukunft für glTF 2.0 geplanten zusätzlichen Materialfunktionen, die in https://github.com/mrdoob/three.js/issues/16977 beschrieben sind , würden über das hinausgehen, was Apples USDZ-Zuschauer jetzt unterstützen.

Ich erwähne "Apples USDZ-Zuschauer", weil dies de facto das ist, was die Leute mit USDZ zu meinen scheinen. Aber das USDZ-Format ist technisch gesehen nur eine gezippte USD-Datei und könnte so ziemlich alles enthalten, von einem üblichen Materialmodell bis hin zu einem vollständig benutzerdefinierten Shader. Die Zuschauer von Apple unterstützen eine kleine Teilmenge von USD, und diese Teilmenge ist nicht genau definiert, aber die beste Zusammenfassung, die Sie wahrscheinlich finden werden, ist hier: https://github.com/google/usd_from_gltf#compatibility.

In Bezug auf die Wiedergabetreue möchte ich darauf hinweisen, dass der Model-Viewer glTF-Modelle mit Threejs anzeigt und die Möglichkeit bietet, eine USDZ-Version in iOS Quick Look zu öffnen, und die visuellen Ergebnisse sind ziemlich ähnlich. Diese Seite bietet einige direkte Vergleiche, obwohl sie derzeit leider nicht verfügbar ist.

Auf jeden Fall, wenn auch nur um Apples schändliche Ziele hier zu untergraben, denke ich, dass wir USDZ irgendwann unterstützen müssen.

Siehe https://github.com/mrdoob/three.js/issues/14219#issuecomment -395107896.

Ich möchte hier nur erwähnen, dass es Gründe für die Unterstützung von USD gibt, die über Apple hinausgehen, die "behaupten, eine Luxuswahl zu sein". @Mugen87 fragt: "Kann jemand erklären, was USD/USDZ besser macht als glTF?"
Ein paar Dinge, die mir wichtig sind:

• HDR/Float-Texturen
• Umgebungskarten (UsdLuxDomeLight)
• Flächen- und Kugellichter (UsdLuxRectLight etc.)
• Shadermaterialien (OSL/MDL) mit "Vorschauoberfläche" für WebGL

Mein Anwendungsfall ist das Laden der gleichen Szenenbeschreibung in WebGL und in eine High-End-Rendering-Pipeline - das Verständnis des Aussehens wird sich natürlich unterscheiden und es werden einige Substitutionen stattfinden.

@garyo Beleuchtung und Umgebung werden vom AR-Viewer verarbeitet, um die tatsächliche Umgebung zu simulieren.
Dieses Video gibt Ihnen eine Vorstellung davon, welche Karten sie unterstützen (Albedo, Metallic, Rauheit, Normal, Umgebungsokklusion, Emissiv).
https://developer.apple.com/videos/play/wwdc2018/603/

Was ich gerne sehen würde, ist ein USDA-Exporter von Three.js, damit Sie Modelle, die Sie in einem Three-Projekt erstellt/konfiguriert haben, zur Anzeige in AR speichern können.
"model-view" enthält ein Tag zum Angeben einer USDZ-Modellalternative, wenn es auf iOS angezeigt wird.
https://modelviewer.dev/

Es ist wirklich eine Schande, dass Apple sich für ein Format entschieden hat, das niemand anderes verwendet und das nirgendwo nativ unterstützt wird (Beta-Exporter ist für Blender verfügbar). Sie haben also keine andere Wahl, als alle Ihre vorhandenen Modelle manuell umzuwandeln. Die Tatsache, dass Sie Ihre Texturen einbeziehen müssen, ist auch mühsam, wenn Sie dieselbe Textur für eine ganze Reihe von Modellen verwenden. Sicherlich könnten sie externe Referenzen haben?
Es ist wirklich ein Sammelsurium-Format, das nur Geometrie und Mapping aus den Pixar-Spezifikationen verwendet und sie zusammen mit Ihren Bilddateien zippt.
glTF/glb wäre viel besser gewesen und wir bräuchten nur EIN Modell für überall...
Im Bereich des E-Commerce, den sie anstreben, wird kein Kunde ein Web-Erlebnis wünschen, das NUR für iOS funktioniert. Wie immer müssen wir die ganze Affenarbeit und Wartung erledigen.

@garyo

Mein Anwendungsfall ist das Laden derselben Szenenbeschreibung in WebGL und in eine High-End-Rendering-Pipeline

warte, gibt es eine Möglichkeit, usd(z) in webgl zu laden?

Der Funktionsumfang von USDZ wurde kürzlich mit iOS 13.4 (und RealityComposer 1.4 (133+)) drastisch erweitert.

Apple hat viele USD-Schemata hinzugefügt, die derzeit von keiner anderen Software interpretiert werden können und die möglicherweise einfach ignoriert werden.
Fast die gesamte interaktive Funktionalität von RealityComposer wird jetzt nicht nur in .reality-Szenendateien gespeichert, sondern kann auch in dieser neuen USD-Variante exportiert werden.
Einige neue USD-Funktionen von meinem Kopf:
Begrenzung auslösen, Bereich antippen oder eingeben
gruppierte Animationsaktionen, nacheinander und/oder parallel
Text Geometrie wird im laufenden Betrieb von einem neuen Prim-Typ erstellt, der die Zeichenfolge, Schriftart und Größe übernimmt

Dies eröffnet eine neue Ära. Jeder Entwickler kann jetzt die Pixar-Use-Tools und -Libs (C++/Python 2.6/Python 3.x) auf jeder Plattform verwenden, um USD-Dateien zu schreiben, die entweder einfach Inhalte anzeigen oder interaktive Erlebnisse erstellen können.
Natürlich benötigen Sie zum Testen noch ein iDevice.

-
Liebe Grüße, (Quarantäne gerade beenden, im Homeoffice bleiben)
Aufgeregt Thomas

Am 14.04.2020 um 20:25 schrieb theightyatom [email protected] :
@garyo https://github.com/garyo Beleuchtung und Umgebung werden vom AR-Viewer verarbeitet, um die tatsächliche Umgebung zu simulieren.
Dieses Video gibt Ihnen eine Vorstellung davon, welche Karten sie unterstützen (Albedo, Metallic, Rauheit, Normal, Umgebungsokklusion, Emissiv).
https://developer.apple.com/videos/play/wwdc2018/603/ https://developer.apple.com/videos/play/wwdc2018/603/
Was ich gerne sehen würde, ist ein USDA-Exporter von Three.js, damit Sie Modelle, die Sie in einem Three-Projekt erstellt/konfiguriert haben, zur Anzeige in AR speichern können.
enthält ein Tag zum Angeben einer USDZ-Modellalternative für die Anzeige auf iOS.
https://modelviewer.dev/ https://modelviewer.dev/
Es ist wirklich eine Schande, dass Apple sich für ein Format entschieden hat, das niemand anderes verwendet und das nirgendwo nativ unterstützt wird (Beta-Exporter ist für Blender verfügbar). Sie haben also keine andere Wahl, als alle Ihre vorhandenen Modelle manuell umzuwandeln. Die Tatsache, dass Sie Ihre Texturen einbeziehen müssen, ist auch mühsam, wenn Sie dieselbe Textur für eine ganze Reihe von Modellen verwenden. Sicherlich könnten sie externe Referenzen haben?
Es ist wirklich ein Sammelsurium-Format, das nur Geometrie und Mapping aus den Pixar-Spezifikationen verwendet und sie zusammen mit Ihren Bilddateien zippt.
glTF/glb wäre viel besser gewesen und wir bräuchten nur EIN Modell für überall...

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub https://github.com/mrdoob/three.js/issues/14219#issuecomment-613604756 an oder melden Sie sich ab https://github.com/notifications/unsubscribe-auth/AAAR6X5SXAY32JAPYL5V44TRMSTBTANCNFSM4FDHSX

Mir ist kein webkompatibler Parser für USD oder USDZ bekannt. Das Rendern in WebGL oder einer anderen API ist kein Problem, es ist komplex, den Inhalt der Datei zu parsen – diese Aufgabe wird am besten von der offiziellen USD-Laufzeit erledigt, die Abhängigkeiten wie OpenSubdiv und MaterialX aufweist.

Jeder Entwickler kann jetzt die Pixar-Tools und -Libs (C++/python 2.6/python 3.x) auf jeder Plattform verwenden, um USD-Dateien zu schreiben.

Es wäre schön, USD-Dateien auf jeder Plattform lesen zu können. 🙂 Aus technischen Gründen halte ich eine funktionierende Three.js-Implementierung derzeit nicht für wahrscheinlich. Wenn jemand mit der Freizeit gesegnet ist, würde ich vorschlagen, an der Implementierung von OpenSubdiv (mit WASM?) oder MaterialX (mit THREE.NodeMaterial?) zu arbeiten, da diese auch ohne USD-Parser nützlich wären .

@garyo

Mein Anwendungsfall ist das Laden derselben Szenenbeschreibung in WebGL und in eine High-End-Rendering-Pipeline

warte, gibt es eine Möglichkeit, usd(z) in webgl zu laden?

Nein, das suche ich. Ich habe Szenen (Objekt, Lichter, Materialien, Kamera, Animation usw. - das Ganze) und möchte die gleiche Szene, in welchem ​​Format auch immer, in WebGL (über Three.js) zur Vorschau laden können, und so etwas wie Blender für endgültige Renderings. glTF ist meine beste Option für jetzt, aber es unterstützt nicht die Dinge , die ich erwähnen oben (Bereich Leuchten etc.) Ich verstehe die glTF Leute zögern , mehr hinzuzufügen verfügt , weil sie gezielt die letzte Meile auf Geräte eher als wahre Szene Transfer.
Suche nur nach Optionen.

@garyo Klingt so, als ob Collada das

@themightyatom Ich Godot , keine PBR-Unterstützung usw. überzeugt – das kann sich geändert haben.)

@garyo Collada wurde für den Transfer von Assets zwischen Spieleentwicklern entwickelt, die alle auf verschiedenen Plattformen arbeiten. Es ist kein praktikables Lieferformat, aber es tut sehr gut, wofür es gedacht ist :)
Ich hatte das Glück, eine Woche in Italien mit einem seiner Schöpfer, Rene Arnaud, zu verbringen. Es wurde "aus der Sicht der GPU" geschrieben und ist im Allgemeinen das erste Format, das Änderungen in der Spezifikation unterstützt. (OpenGL, DirectX usw.).

Ich denke, was super wertvoll wäre, wäre https://github.com/google/usd_from_gltf als Exporteur zu integrieren. Mir ist es viel weniger wichtig, USD eröffnen zu können.

Um mit USDZ etwas Nützliches zu tun (Laden oder Exportieren), benötigen Sie das USD-SDK. _USD von glTF_ erfordert das USD SDK als Abhängigkeit, aber das SDK wird im Web nicht unterstützt . Apple umgeht dies, indem es den Webbrowser verlässt und Sie in seine native AR Quick Look-Anwendung führt, aber das ist im Allgemeinen kaum eine Lösung für das Web.