Es una solicitud de función válida, pero personalmente no entiendo Apple / Pixar. ¿Por qué están introduciendo un nuevo formato de archivo y no solo usan glTF ? ¿Alguien puede explicar lo que USD / USDZ hace mejor que glTF ?

Documentación en USD: http://graphics.pixar.com/usd/docs/index.html

Es una solicitud de función válida, pero personalmente no entiendo Apple / Pixar. ¿Por qué están introduciendo un nuevo formato de archivo y no solo usan glTF? ¿Alguien puede explicar qué hace mejor el USD / USDZ que el glTF?

Estoy de acuerdo, creo que parte de eso es política. Sin embargo, esa es una discusión separada :)

USD ha existido durante un par de años; se usa comúnmente en películas y no es una opción obvia para la transmisión en tiempo de ejecución. Por lo que puedo decir, USDZ es un envoltorio para eso. Apple no ha dado muchos detalles en este momento; tal vez tengan algún plan para hacerlo más apropiado para el tiempo de ejecución, o tal vez el mensaje en la WWDC no fue claro con respecto a cómo lo están usando realmente. En cualquier caso, creo que probablemente debamos esperar más información.

Si alguien está interesado en contribuir con THREE.USDZLoader , entonces por supuesto. 🙂 Pero toda la documentación que he encontrado hasta ahora sugiere que el formato está muy relacionado con las bibliotecas oficiales (C ++ / Python) para analizarlo, similar a FBX y FBX SDK. Entonces, a menos que se puedan hacer compatibles con la web con WASM, implementar el soporte de USDZ en three.js y mantenerse al día con los cambios en el formato a lo largo del tiempo parece un proceso que consume mucho tiempo, sin el beneficio de esas bibliotecas.

Por curiosidad, intenté abrir el archivo "Retro TV" de https://developer.apple.com/arkit/gallery/ como si fuera un simple zip. "Desarchivé" el .usdz cambiando el nombre de su extensión a .zip, y luego hice que mi sistema operativo realizara su procedimiento de apertura habitual. Presumiblemente, se podría lograr algo similar con https://gildas-lormeau.github.io/zip.js/

Esto es lo que veo cuando 'desarchivo' el usdz:

Entonces, las texturas son solo PNG, a los que probablemente se hace referencia desde dentro de ese .usdc, que es el siguiente problema. Según https://graphics.pixar.com/usd/docs/Converting-Between-Layer-Formats.html , "archivos .usdc - formato binario" que se encuentra en Crate (consulte _Crate File Format_ en https: // graphics. pixar.com/usd/docs/USD-Glossary.html).

También existe .usda, que está codificado en ASCII, lo que presumiblemente sería más fácil de escribir en un cargador.

Como resumen de algunas tareas pendientes para esto, como mínimo un Loader estaría buscando extraer un archivo Zip en JS y luego también comprender el .usda (y potencialmente el .usdc Crate binario también).

Hola @richardmonette , investigué un poco sobre USDZ y el formato USDA y escribí un convertidor de prueba de concepto de glTF a USDZ. Quizás sea útil para su investigación: https://github.com/timvanscherpenzeel/gltf-to-usdz. Puede ver una demostración aquí: https://twitter.com/domenicopanacea/status/1011292393801420800 o pruébelo usted mismo aquí: https://timvanscherpenzeel.github.io/gltf-to-usdz/ (requiere iOS 12).

En resumen: la geometría se convierte a OBJ , la textura de rugosidad metálica se divide por canal y las texturas se invierten en Y. A partir de esto, se construye dinámicamente un archivo USDA y se alimenta a usdz_converter para construir el usdz final.

Sé que algunas personas están buscando escribir un convertidor directo a USDZ, pero no se sabe mucho sobre el formato USDC en este momento (también en términos de decodificación).

Hola @TimvanScherpenzeel , ¡gracias por tu mensaje y trabaja en esto!

¿Ha considerado utilizar la API de USD Python (https://graphics.pixar.com/usd/docs/Hello-World---Creating-Your-First-USD-Stage.html)? Me preguntaba si sería posible omitir la etapa .obj y, usando Python, leer el glTF e ir directamente a .usda / c de esa manera.

Tuve muchos problemas al configurar USD y aún no me he tomado el tiempo para solucionar el problema (creo que tiene algo que ver con tener varias versiones de Python instaladas y durante la compilación se vincula al Python incorrecto).

De hecho, podría escribir el archivo OBJ directamente en el archivo del USDA (que en realidad podría ser un buen paso siguiente en mi prueba de concepto). Conozco la estructura de archivos de los ejemplos de AR Gallery porque un colaborador de mi proyecto me envió los archivos del USDA después de haberlos decodificado con usdcat .

El objetivo de Apple al proporcionar un USDZ QuickLook es omitir totalmente el uso de WebGL, DOM y Javascript y usar directamente la escena con ARkit2.0.
Es solo un hito para un rOS basado en la tecnología de Apple / Pixar.
Cuando luego agreguen interactividad / capacidad de secuencia de comandos, se necesitará incluso menos interfaz de usuario web.

Pixar USD, que utiliza parches OpenSubDiv altamente eficientes para geometría, trasladados a Metal móvil pronto superará a HighEnd PC-VR WebVR.
No como un formato de archivo, sino como una tubería completa de creación de experiencias / presentación / (interacción).

Entonces, en mi humilde opinión, es más importante exportar USDZ de los editores AR / VR y para Android y Windows para tomar el tren USD, que agregar un importador al canal de WebGL2 .

Un problema importante es que WebXR también tendría que admitir parches SubDiv en lugar de polymeshes heredados para admitir completamente USD como lo usa Apple.

@pixelpartner me perdiste.

Me parece que, a menos que un cargador esté integrado de forma nativa en los navegadores, sería útil crear uno en JavaScript.

Estoy seguro de que la vista rápida está altamente optimizada, pero ¿cuál es el camino a seguir para crear contenido interactivo utilizando activos de USDZ en un navegador?

Es una solicitud de función válida, pero personalmente no entiendo Apple / Pixar. ¿Por qué están introduciendo un nuevo formato de archivo y no solo usan glTF? ¿Alguien puede explicar qué hace mejor el USD / USDZ que el glTF?

Recientemente, tuve una charla con alguien que trabajaba en software de visualización de productos, exportaban a glTF y USDZ, así que le pregunté qué pensaba sobre esto. Su opinión en pocas palabras: es para que Apple pueda seguir afirmando ser la opción de lujo de alta gama, con un formato 3D exclusivo que solo funciona en su plataforma a través de ARKit2.0 / SceneKit. Adoptar el formato glTF estándar sería contrario a sus objetivos aquí, quieren poder afirmar que _su_ formato es mejor y permite resultados de mayor calidad debido a las propiedades del material PBR que glTF no admite (¿todavía?).

16977, y quizás # 14051, probablemente sean necesarios para obtener three.js con los mismos estándares de renderizado que las ofertas de Apple, pero no estoy seguro de cómo se relacionan el estado actual o los planes futuros para glTF con esto.

En cualquier caso, aunque solo sea por subvertir los nefastos objetivos de Apple aquí, creo que tendremos que apoyar al USDZ en algún momento.

es para que Apple pueda seguir afirmando ser la opción de lujo de alta gama, con un formato 3D exclusivo que solo funciona en su plataforma ...

Estoy dispuesto a dar más beneficio de la duda aquí: tienen diferentes objetivos para un formato de "tiempo de ejecución" que nosotros (threejs + web devs) y, como resultado, podemos hacer diferentes elecciones. En particular, agrupar el tiempo de ejecución de ~ 15MB USD en iOS significa que no les importa que cargar USDZ _sin_ un tiempo de ejecución nativo sea prohibitivamente difícil, y parecen estar de acuerdo con no proporcionar a la aplicación web ningún acceso al modelo, sino simplemente abrir el en su lugar, modele tal cual en una aplicación nativa.

En cuanto al "lujo de gama alta", el visor QuickLook de iOS de Apple admite materiales PBR metálicos / rugosos, y el modelo de material es en gran medida equivalente a lo que es compatible con glTF 2.0 en la actualidad. Las características de material adicionales planeadas para glTF 2.0 en el futuro, y descritas en https://github.com/mrdoob/three.js/issues/16977 , irían más allá de lo que los espectadores USDZ de Apple admiten ahora.

Menciono "espectadores USDZ de Apple" porque eso es, de facto, lo que la gente parece querer decir con USDZ. Pero el formato USDZ, técnicamente, es solo un archivo USD comprimido y podría contener prácticamente cualquier cosa, desde un modelo de material común hasta un sombreador completamente personalizado. Los espectadores de Apple admiten un pequeño subconjunto de USD, y ese subconjunto no está bien definido, pero el mejor resumen que probablemente encontrará está aquí: https://github.com/google/usd_from_gltf#compatibility.

En términos de fidelidad de representación, señalaría que model-viewer muestra modelos glTF con threejs y proporciona los medios para abrir una versión USDZ en iOS Quick Look, y los resultados visuales son bastante similares. Esta página proporciona algunas comparaciones directas, aunque desafortunadamente no está disponible en este momento.

En cualquier caso, aunque solo sea por subvertir los nefastos objetivos de Apple aquí, creo que tendremos que apoyar al USDZ en algún momento.

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

Solo quiero mencionar aquí que hay razones para apoyar al USD más allá de que Apple "afirme ser una opción de lujo". @ Mugen87 pregunta "¿Alguien puede explicar qué hace mejor el USD / USDZ que el glTF?"
Algunas cosas que me importan:

• Texturas HDR / flotantes
• Mapas de entorno (UsdLuxDomeLight)
• Luces de área y esfera (UsdLuxRectLight, etc.)
• Materiales de sombreado (OSL / MDL) con "superficie de vista previa" para WebGL

Mi caso de uso es cargar la misma descripción de escena en WebGL y en una canalización de renderizado de alta gama; por supuesto, comprender que el aspecto será diferente y se producirá alguna sustitución.

La iluminación y el entorno de realidad aumentada , en un intento de simular el entorno real.
Este video le da una idea de qué mapas admiten (albedo, metálico, rugosidad, normal, oclusión ambiental, emisivo)
https://developer.apple.com/videos/play/wwdc2018/603/

Lo que me gustaría ver es un exportador USDA de three.js, para que pueda guardar los modelos que ha creado / configurado en un proyecto de tres, para verlos en AR.
"model-view" incluye una etiqueta para especificar una alternativa de modelo USDZ, para cuando se ve en iOS.
https://modelviewer.dev/

Realmente es una pena que Apple haya optado por un formato que nadie más usa y que no se admite de forma nativa en ninguna parte (el exportador beta está disponible para Blender). Por lo tanto, no tiene más remedio que convertir manualmente todos sus modelos existentes. El hecho de que tenga que incluir sus texturas también es un problema si usa la misma textura en toda una gama de modelos. ¿Seguramente podrían tener referencias externas?
Es realmente un formato un poco mezcolanza, que solo utiliza geometría y mapeo de las especificaciones de Pixar, y los comprime junto con sus archivos de imagen.
glTF / glb habría sido mucho mejor y solo necesitaríamos UN modelo para todas partes ...
En el ámbito del comercio electrónico, que es a lo que apuntan, ningún cliente querrá una experiencia web que SOLO funcione para iOS. Como de costumbre, tendremos que hacer todo el trabajo y el mantenimiento.

@garyo

Mi caso de uso es cargar la misma descripción de escena en WebGL y en una canalización de renderizado de alta gama

espera, ¿hay alguna manera de cargar usd (z) en webgl?

El conjunto de funciones de USDZ aumentó drásticamente recientemente con iOS 13.4 (y RealityComposer 1.4 (133+))

Apple agregó muchos esquemas de USD que actualmente ningún otro software puede interpretar y podría simplemente ignorar.
Casi toda la funcionalidad interactiva de RealityComposer ahora no solo se guarda en archivos de escena .reality, sino que también se puede exportar en esta nueva versión de USD.
Algunas características nuevas de USD de la parte superior de mi cabeza:
Activar delimitación, tocar o ingresar al área
Acciones de animación agrupadas, en secuencia y / o en paralelo
Text Geometrie se crea sobre la marcha mediante un nuevo tipo de Prim que toma la cadena, la fuente y el tamaño

Esto abre una nueva era. Cualquier desarrollador ahora puede usar las herramientas de uso de Pixar y las bibliotecas (C ++ / python 2.6 / python 3.x) en cualquier plataforma para escribir archivos USD que pueden simplemente mostrar contenido o crear experiencias interactivas.
Obviamente, todavía necesitas un iDevice para probar.

-
Mis mejores deseos (acaba de terminar la cuarentena, permanecer en la oficina en casa)
Thomas emocionado

Soy 14.04.2020 um 20:25 schrieb themightyatom [email protected] :
@garyo https://github.com/garyo La iluminación y el entorno son manejados por el visor de RA, en un intento de simular el entorno real.
Este video le da una idea de qué mapas admiten (albedo, metálico, rugosidad, normal, oclusión ambiental, emisivo)
https://developer.apple.com/videos/play/wwdc2018/603/ https://developer.apple.com/videos/play/wwdc2018/603/
Lo que me gustaría ver es un exportador USDA de three.js, para que pueda guardar los modelos que ha creado / configurado en un proyecto de tres, para verlos en AR.
incluye una etiqueta para especificar una alternativa de modelo USDZ, para cuando se ve en iOS.
https://modelviewer.dev/ https://modelviewer.dev/
Realmente es una pena que Apple haya optado por un formato que nadie más usa y que no se admite de forma nativa en ninguna parte (el exportador beta está disponible para Blender). Por lo tanto, no tiene más remedio que convertir manualmente todos sus modelos existentes. El hecho de que tenga que incluir sus texturas también es un problema si usa la misma textura en toda una gama de modelos. ¿Seguramente podrían tener referencias externas?
Es realmente un formato un poco mezcolanza, que solo utiliza geometría y mapeo de las especificaciones de Pixar, y los comprime junto con sus archivos de imagen.
glTF / glb habría sido mucho mejor y solo necesitaríamos UN modelo para todas partes ...

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub https://github.com/mrdoob/three.js/issues/14219#issuecomment-613604756 , o cancele la suscripción https://github.com/notifications/unsubscribe-auth/AAAR6X5SXAY32JAPYL5V44TRMSTBTANCNFSWM4 .

No conozco ningún analizador compatible con la web para USD o USDZ. La representación en WebGL u otra API no es un problema, el análisis del contenido del archivo es complejo; esa tarea se maneja mejor con el tiempo de ejecución oficial de USD, que tiene dependencias que incluyen OpenSubdiv y MaterialX.

Cualquier desarrollador ahora puede usar las herramientas de uso de Pixar y las bibliotecas (C ++ / python 2.6 / python 3.x) en cualquier plataforma para escribir archivos USD.

Sería bueno poder leer archivos USD en cualquier plataforma. 🙂 Por razones técnicas, no creo que sea probable una implementación funcional de three.js en este momento. Si alguien tiene la suerte de tener tiempo libre, mi sugerencia sería trabajar en la implementación de OpenSubdiv (w / WASM?) O MaterialX (w / THREE.NodeMaterial?), Ya que serían útiles por derecho propio, incluso sin un analizador de USD .

@garyo

Mi caso de uso es cargar la misma descripción de escena en WebGL y en una canalización de renderizado de alta gama

espera, ¿hay alguna manera de cargar usd (z) en webgl?

No, eso es lo que estoy buscando. Tengo escenas (objeto, luces, materiales, cámara, animación, etc., todo) y quiero poder cargar la misma escena, en cualquier formato, en WebGL (a través de three.js) para obtener una vista previa, y algo como Blender para renders finales. glTF es mi mejor opción por ahora, pero no es compatible con las cosas que mencioné anteriormente (luces de área, etc.). Entiendo que la gente de glTF es reacia a agregar más funciones porque apuntan a la última milla a los dispositivos en lugar de a la escena real. transferir.
Solo busco opciones.

@garyo ¿ Suena como si Collada encajara a la

@themightyatom Miré a Collada hace un par de años, puede que tenga que volver a visitarlo. Gracias. (En ese momento estaba convencido por argumentos como el de Godot , sin soporte de PBR, etc., eso puede haber cambiado).

@garyo Collada fue diseñado para transferir activos entre desarrolladores de juegos que trabajan en diferentes plataformas. No es un formato de entrega viable, pero hace muy bien su función :)
Tuve la suerte de pasar una semana en Italia con uno de sus creadores, Rene Arnaud. Está escrito "desde la perspectiva de la GPU" y generalmente es el primer formato que admite cambios en las especificaciones. (OpenGL, DirectX, etc.).

Creo que lo que sería súper valioso es integrar https://github.com/google/usd_from_gltf como exportador. Mucho menos importante para mí poder abrir USD.

Para hacer algo útil con USDZ (cargar o exportar), necesitará USD SDK. _USD de glTF_ requiere USD SDK como dependencia, pero el SDK no es compatible con la web . Apple soluciona esto dejando el navegador web y llevándote a su aplicación AR Quick Look nativa, pero esa no es una solución para la web en general.