C'est une demande de fonctionnalité valide mais personnellement, je ne comprends pas Apple/Pixar. Pourquoi introduisent-ils un nouveau format de fichier et pas seulement glTF ? Quelqu'un peut-il expliquer ce que USD / USDZ fait mieux que glTF ?

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

C'est une demande de fonctionnalité valide mais personnellement, je ne comprends pas Apple/Pixar. Pourquoi introduisent-ils un nouveau format de fichier et pas seulement glTF ? Quelqu'un peut-il expliquer ce que l'USD/USDZ fait mieux que glTF ?

Je suis d'accord, c'est en partie politique, je pense. Cependant, c'est une discussion à part :)

L'USD existe depuis quelques années - il est couramment utilisé dans les films et n'est pas un choix évident pour la transmission à l'exécution. Pour autant que je sache, USDZ est un emballage autour de cela. Apple n'a pas donné beaucoup de détails à ce stade ; peut-être qu'ils ont un plan pour le rendre plus approprié à l'exécution, ou peut-être que le message à la WWDC n'était tout simplement pas clair en ce qui concerne la façon dont ils l'utilisent réellement. En tout cas, je pense que nous devons probablement attendre plus d'informations.

Si quelqu'un est intéressé à contribuer un THREE.USDZLoader , alors par tous les moyens. 🙂 Mais toute la documentation que j'ai trouvée jusqu'à présent suggère que le format est très étroitement lié aux bibliothèques officielles (C++/Python) pour l'analyser, similaire à FBX et au SDK FBX. Donc, à moins que ceux-ci ne puissent être rendus conviviaux pour le Web avec WASM, la mise en œuvre du support USDZ dans three.js et le suivi des changements de format au fil du temps semblent être un processus très long, sans l'avantage de ces bibliothèques.

Par curiosité, j'ai essayé d'ouvrir le fichier "Retro TV" de https://developer.apple.com/arkit/gallery/ comme s'il s'agissait d'un simple zip. J'ai «désarchivé» le .usdz en renommant son extension en .zip, puis en faisant en sorte que mon système d'exploitation effectue sa procédure d'ouverture habituelle. Vraisemblablement, quelque chose de similaire pourrait être réalisé avec https://gildas-lormeau.github.io/zip.js/

Voici ce que je vois lorsque je "désarchive" l'usdz :

Ainsi, les textures ne sont que des PNG, qui sont probablement référencées à partir de ce .usdc, qui est le prochain problème. Selon https://graphics.pixar.com/usd/docs/Converting-Between-Layer-Formats.html , "fichiers .usdc - format binaire" qui se trouve dans Crate (voir _Crate File Format_ dans https://graphics. pixar.com/usd/docs/USD-Glossary.html).

Il y a aussi .usda, qui est encodé en ASCII, ce qui serait probablement plus facile pour écrire un chargeur.

Pour donner un aperçu de certaines choses à faire pour cela, au minimum, un chargeur chercherait à extraire un fichier Zip dans JS, puis à comprendre le .usda (et potentiellement le Crate binaire .usdc également.)

Salut @richardmonette , J'ai fait des recherches sur USDZ et le format USDA et j'ai écrit une preuve de concept de convertisseur glTF vers USDZ. C'est peut-être utile pour vos recherches : https://github.com/timvanscherpenzeel/gltf-to-usdz. Vous pouvez voir une démo ici : https://twitter.com/domenicopanacea/status/1011292393801420800 ou l'essayer vous-même ici : https://timvanscherpenzeel.github.io/gltf-to-usdz/ (nécessite iOS 12).

En bref : la géométrie est convertie en OBJ , la texture de rugosité métallique est divisée par canal et les textures sont inversées en Y. À partir de là, un fichier USDA est construit dynamiquement et introduit dans usdz_converter pour construire le usdz final.

Je sais que certaines personnes envisagent d'écrire un convertisseur direct vers USDZ, mais on ne sait pas grand-chose sur le format USDC à l'heure actuelle (également en termes de décodage).

Hé @TimvanScherpenzeel , merci pour votre message et travaillez dessus !

Avez-vous envisagé d'utiliser l'API Python USD (https://graphics.pixar.com/usd/docs/Hello-World---Creating-Your-First-USD-Stage.html) ? Je me suis demandé s'il serait possible de sauter l'étape .obj et, en utilisant Python, de lire le glTF et d'aller directement dans .usda/c de cette façon ?

J'ai eu beaucoup de problèmes pour configurer USD et je n'ai pas encore pris le temps de résoudre le problème (je pense que cela a quelque chose à voir avec l'installation de plusieurs versions de Python et lors de la compilation, il est lié au mauvais Python).

Vous pouvez en effet écrire le fichier OBJ directement dans le fichier USDA (cela pourrait en fait être une bonne étape suivante dans ma preuve de concept). Je connais la structure des fichiers des exemples AR Gallery car un contributeur à mon projet m'envoie les fichiers USDA après avoir décodé les fichiers USDC avec usdcat .

L'intérêt d'Apple pour fournir un USDZ QuickLook est de contourner totalement l'utilisation de WebGL, DOM et Javascript et d'utiliser directement la scène avec ARkit2.0.
C'est juste une étape importante vers un rOS basé sur la technologie Apple/Pixar.
Lorsqu'ils ajouteront plus tard de l'interactivité/de la scriptabilité, encore moins d'interface utilisateur Web sera nécessaire.

Pixar USD, utilisant des correctifs OpenSubDiv hautement efficaces pour la géométrie, porté sur mobile Metal, surpassera bientôt HighEnd PC-VR WebVR.
Pas en tant que format de fichier, mais en tant que pipeline de création d'expérience/présentation/(-interaction).

Donc, à mon humble avis, il est plus important d'exporter USDZ depuis les éditeurs AR/VR et pour Android et Windows de prendre le train USD, que d'ajouter un importateur au pipeline WebGL2 .

Un problème important est que WebXR devrait également prendre en charge les correctifs SubDiv au lieu des polymeshes hérités pour prendre pleinement en charge l'USD tel qu'il est utilisé par Apple.

@pixelpartner, tu

Il me semble qu'à moins qu'un chargeur ne soit intégré nativement dans les navigateurs, il serait utile d'en créer un en JavaScript.

Je suis sûr que l'aperçu rapide est hautement optimisé, mais quelle est la voie à suivre pour créer du contenu interactif à l'aide d'actifs USDZ dans un navigateur ?

C'est une demande de fonctionnalité valide mais personnellement, je ne comprends pas Apple/Pixar. Pourquoi introduisent-ils un nouveau format de fichier et pas seulement glTF ? Quelqu'un peut-il expliquer ce que USD /USDZ fait mieux que glTF ?

J'ai eu une conversation avec quelqu'un qui travaillait sur un logiciel d'affichage de produits récemment, ils exportent vers glTF et USDZ, alors je lui ai demandé ce qu'il en pensait. Son point de vue en un mot : c'est pour qu'Apple puisse continuer à prétendre être le choix du luxe haut de gamme, avec un format 3D exclusif qui ne fonctionne que sur leur plate-forme via ARKit2.0/SceneKit. Adopter le format glTF standard irait à l'encontre de leurs objectifs ici, ils veulent pouvoir prétendre que _leur_ format est meilleur et permet des résultats de meilleure qualité en raison des propriétés du matériau PBR que glTF ne prend pas (encore ?) en charge.

16977, et peut-être #14051, sont probablement nécessaires pour que three.js soit conforme aux mêmes normes de rendu que les offres d'Apple, mais je ne sais pas comment l'état actuel ou les plans futurs de glTF se rapportent à cela.

Dans tous les cas, ne serait-ce que pour renverser les objectifs infâmes d'Apple ici, je pense que nous devrons soutenir USDZ à un moment donné.

c'est pour qu'Apple puisse continuer à prétendre être le choix du luxe haut de gamme, avec un format 3D exclusif qui ne fonctionne que sur leur plateforme...

Je suis prêt à donner plus de bénéfice du doute ici - ils ont des objectifs différents pour un format "d'exécution" que nous (threejs + développeurs Web) et sont capables de faire des choix différents en conséquence. En particulier, le regroupement de l'environnement d'exécution d'environ 15 Mo USD dans iOS signifie qu'ils ne se soucient pas du fait que le chargement de USDZ _sans_ un environnement d'exécution natif est prohibitif, et ils semblent être d'accord pour ne pas fournir à l'application Web un accès au modèle, mais simplement en ouvrant le modèle tel quel dans une application native à la place.

Sur le "luxe haut de gamme", la visionneuse iOS QuickLook d'Apple prend en charge les matériaux PBR métalliques / rugueux, et le modèle de matériau est largement équivalent à ce que glTF 2.0 prend en charge aujourd'hui. Les fonctionnalités matérielles supplémentaires prévues pour glTF 2.0 à l'avenir, et décrites dans https://github.com/mrdoob/three.js/issues/16977 , iraient au-delà de ce que les téléspectateurs USDZ d'Apple prennent actuellement en charge.

Je mentionne "les téléspectateurs USDZ d'Apple" parce que c'est, de facto, ce que les gens semblent vouloir dire par USDZ. Mais le format USDZ, techniquement, n'est qu'un fichier USD compressé et peut contenir à peu près n'importe quoi, d'un modèle de matériau commun à un shader entièrement personnalisé. Les téléspectateurs d'Apple prennent en charge un petit sous-ensemble d'USD, et ce sous-ensemble n'est pas bien défini, mais le meilleur résumé que vous êtes susceptible de trouver est ici : https://github.com/google/usd_from_gltf#compatibility.

En termes de fidélité de rendu, je voudrais souligner que le visualiseur de modèles affiche les modèles glTF avec threejs et fournit les moyens d'ouvrir une version USDZ dans iOS Quick Look, et les résultats visuels sont assez similaires. Cette page fournit des comparaisons directes, bien qu'elle soit malheureusement en panne en ce moment.

Dans tous les cas, ne serait-ce que pour renverser les objectifs infâmes d'Apple ici, je pense que nous devrons soutenir USDZ à un moment donné.

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

Je veux juste mentionner ici qu'il y a des raisons de soutenir l'USD au-delà d'Apple « prétendant être un choix de luxe ». @ Mugen87 demande "Quelqu'un peut-il expliquer ce que l'USD/USDZ fait mieux que glTF ?"
Quelques choses qui m'intéressent :

• Textures HDR/flottantes
• Cartes d'environnement (UsdLuxDomeLight)
• Lumières de zone et de sphère (UsdLuxRectLight etc.)
• Matériaux de shader (OSL/MDL) avec "surface d'aperçu" pour WebGL

Mon cas d'utilisation est de charger la même description de scène dans WebGL et dans un pipeline de rendu haut de gamme - la compréhension des apparences sera bien sûr différente et une certaine substitution aura lieu.

L' éclairage et l'environnement
Cette vidéo vous donne une idée des cartes qu'elles prennent en charge (albédo, métallique, rugosité, normale, occlusion ambiante, émissive)
https://developer.apple.com/videos/play/wwdc2018/603/

Ce que j'aimerais voir, c'est un exportateur USDA à partir de three.js, afin que vous puissiez enregistrer les modèles que vous avez créés/configurés dans un projet à trois, pour les afficher dans AR.
"model-view" inclut une balise pour spécifier une alternative de modèle USDZ, pour une visualisation sur iOS.
https://modelviewer.dev/

C'est vraiment dommage qu'Apple ait choisi un format que personne d'autre n'utilise et qu'il ne soit pris en charge nulle part en natif (l'exportateur bêta est disponible pour Blender). Vous n'avez donc pas d'autre choix que de convertir manuellement tous vos modèles existants. Le fait que vous deviez inclure vos textures est également pénible si vous utilisez la même texture sur toute une gamme de modèles. Ils pourraient sûrement avoir des références externes ?
C'est vraiment un peu un format méli-mélo, qui n'utilise que la géométrie et la cartographie des spécifications Pixar, et les compresse avec vos fichiers image.
glTF/glb aurait été bien mieux et nous n'aurions besoin que d'UN modèle partout...
Dans le domaine du commerce électronique, ce qu'ils visent, aucun client ne voudra une expérience Web qui fonctionne UNIQUEMENT pour iOS. Comme d'habitude, nous devrons faire tout le travail de singe et l'entretien.

@garyo

Mon cas d'utilisation charge la même description de scène dans WebGL et dans un pipeline de rendu haut de gamme

attendez, y a-t-il un moyen de charger usd(z) dans webgl ?

L'ensemble de fonctionnalités d'USDZ a récemment considérablement augmenté avec iOS 13.4 (et RealityComposer 1.4 (133+))

Apple a ajouté de nombreux schémas USD qu'aucun autre logiciel ne peut actuellement interpréter et pourrait simplement ignorer.
Presque toutes les fonctionnalités interactives de RealityComposer sont désormais non seulement enregistrées dans des fichiers de scène .reality, mais peuvent également être exportées dans cette nouvelle saveur USD.
Quelques nouvelles fonctionnalités USD du haut de ma tête :
Déclenchez la délimitation, appuyez ou entrez dans la zone
Actions d'animation groupées, en séquence et/ou en parallèle
La géométrie du texte est créée à la volée par un nouveau type de Prim qui prend la chaîne, la police et la taille

Cela ouvre une nouvelle ère. Tout développeur peut désormais utiliser les outils et bibliothèques d'utilisation de Pixar (C++/python 2.6/python 3.x) sur n'importe quelle plate-forme pour écrire des fichiers USD qui peuvent soit simplement afficher du contenu, soit créer des expériences interactives.
Évidemment, vous avez toujours besoin d'un iDevice pour les tests.

-
Meilleurs voeux, (juste mettre fin à la quarantaine, rester au bureau à domicile)
Thomas excité

Suis 14.04.2020 à 20:25 schrieb themightyatom [email protected] :
@garyo https://github.com/garyo L' éclairage et l'environnement sont gérés par la visionneuse AR, dans le but de simuler l'environnement réel.
Cette vidéo vous donne une idée des cartes qu'elles prennent en charge (albédo, métallique, rugosité, normale, occlusion ambiante, émissive)
https://developer.apple.com/videos/play/wwdc2018/603/ https://developer.apple.com/videos/play/wwdc2018/603/
Ce que j'aimerais voir, c'est un exportateur USDA à partir de three.js, afin que vous puissiez enregistrer les modèles que vous avez créés/configurés dans un projet à trois, pour les afficher dans AR.
inclut une balise pour spécifier une alternative de modèle USDZ, pour une visualisation sur iOS.
https://modelviewer.dev/ https://modelviewer.dev/
C'est vraiment dommage qu'Apple ait choisi un format que personne d'autre n'utilise et qu'il ne soit pris en charge nulle part en natif (l'exportateur bêta est disponible pour Blender). Vous n'avez donc pas d'autre choix que de convertir manuellement tous vos modèles existants. Le fait que vous deviez inclure vos textures est également pénible si vous utilisez la même texture sur toute une gamme de modèles. Ils pourraient sûrement avoir des références externes ?
C'est vraiment un peu un format méli-mélo, qui n'utilise que la géométrie et la cartographie des spécifications Pixar, et les compresse avec vos fichiers image.
glTF/glb aurait été bien mieux et nous n'aurions besoin que d'UN modèle partout...

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub https://github.com/mrdoob/three.js/issues/14219#issuecomment-613604756 , ou désabonnez-vous https://github.com/notifications/unsubscribe-auth/AAAR6X5SXAY32JAPYL5V44TRMSTBTANCNFSM4FDHSXWQ .

Je ne connais aucun analyseur compatible Web pour l'USD ou l'USDZ. Le rendu dans WebGL ou une autre API n'est pas un problème, c'est l'analyse du contenu du fichier qui est complexe - cette tâche est mieux gérée par le runtime officiel USD, qui a des dépendances telles que OpenSubdiv et MaterialX.

Tout développeur peut désormais utiliser les outils et bibliothèques d'utilisation de Pixar (C++/python 2.6/python 3.x) sur n'importe quelle plate-forme pour écrire des fichiers USD.

Pouvoir lire les fichiers USD sur n'importe quelle plate-forme serait bien. 🙂 Pour des raisons techniques, je ne pense pas qu'une implémentation fonctionnelle de three.js soit probable pour le moment. Si quelqu'un a la chance d'avoir du temps libre, ma suggestion serait de travailler sur la mise en œuvre d'OpenSubdiv (avec WASM ?) .

@garyo

Mon cas d'utilisation charge la même description de scène dans WebGL et dans un pipeline de rendu haut de gamme

attendez, y a-t-il un moyen de charger usd(z) dans webgl ?

Non, c'est ce que je recherche. J'ai des scènes (objet, lumières, matériaux, caméra, animation, etc. - le tout) et je veux pouvoir charger la même scène, dans n'importe quel format, dans WebGL (via three.js) pour la prévisualisation, et quelque chose comme Blender pour les rendus finaux. glTF est ma meilleure option pour l' instant, mais il ne supporte pas les choses que je mentionne ci - dessus (zone lumières , etc.) Je comprends les gens de glTF sont réticents à ajouter plus de fonctionnalités , car ils sont le ciblage dernier mile à des appareils plutôt que de vraie scène transfert.
Je cherche juste des options.

@garyo On dirait que Collada pourrait faire l'

@themightyatom J'ai examiné Collada il y a quelques années - je Godot , pas de support PBR, etc. - cela a peut-être changé.)

@garyo Collada a été conçu pour transférer des actifs entre les développeurs de jeux travaillant tous sur différentes plates-formes. Ce n'est pas un format de livraison viable, mais il fait très bien ce pour quoi il est destiné :)
J'ai eu la chance de passer une semaine en Italie avec l'un de ses créateurs, René Arnaud. Il est écrit "du point de vue du GPU" et est généralement le premier format à prendre en charge les changements de spécifications. (OpenGL, DirectX, etc.).

Je pense que ce qui serait super utile, c'est d'intégrer https://github.com/google/usd_from_gltf en tant qu'exportateur. Beaucoup moins important pour moi de pouvoir ouvrir l'USD.

Pour faire quoi que ce soit d'utile avec USDZ (charger ou exporter), vous aurez besoin du SDK USD. _USD de glTF_ nécessite le SDK USD en tant que dépendance, mais le SDK n'est pas pris en charge sur le Web . Apple contourne ce problème en quittant le navigateur Web et en vous emmenant dans leur application native AR Quick Look, mais ce n'est guère une solution pour le Web en général.