É uma solicitação de recurso válida, mas pessoalmente não entendo a Apple / Pixar. Por que eles estão introduzindo um novo formato de arquivo e não apenas usando glTF ? Alguém pode explicar o que USD / USDZ faz melhor do que glTF ?

Documentação de USD: http://graphics.pixar.com/usd/docs/index.html

É uma solicitação de recurso válida, mas pessoalmente não entendo a Apple / Pixar. Por que eles estão introduzindo um novo formato de arquivo e não apenas usando glTF? Alguém pode explicar o que USD / USDZ faz melhor do que glTF?

Eu concordo, parte disso é política, eu acho. No entanto, essa é uma discussão separada :)

O USD existe há alguns anos - é comumente usado em filmes e não é uma escolha óbvia para transmissão em tempo de execução. Até onde eu posso dizer, USDZ é um invólucro em torno disso. A Apple não deu muitos detalhes neste momento; talvez eles tenham algum plano para torná-lo mais apropriado para o tempo de execução, ou talvez a mensagem na WWDC não esteja clara a respeito de como eles estão realmente usando. Em qualquer caso, acho que provavelmente precisamos esperar por mais informações.

Se alguém estiver interessado em contribuir com THREE.USDZLoader , então, por favor. 🙂 Mas toda a documentação que encontrei até agora sugere que o formato está intimamente ligado às bibliotecas oficiais (C ++ / Python) para analisá-lo, semelhante ao FBX e ao FBX SDK. Portanto, a menos que eles possam ser compatíveis com a Web com WASM, implementar o suporte a USDZ em three.js e acompanhar as mudanças no formato ao longo do tempo parece um processo muito demorado, sem o benefício dessas bibliotecas.

Por curiosidade, tentei abrir o arquivo "Retro TV" de https://developer.apple.com/arkit/gallery/ como se fosse um simples zip. Eu 'desarquivei' o .usdz renomeando sua extensão para .zip e, em seguida, fiz meu SO fazer seu procedimento usual de abertura. Presumivelmente, algo semelhante poderia ser alcançado com https://gildas-lormeau.github.io/zip.js/

Isso é o que vejo quando "desarquivo" o usdz:

Portanto, as texturas são apenas PNGs, que provavelmente são referenciadas de dentro desse .usdc, que é a próxima edição. De acordo com https://graphics.pixar.com/usd/docs/Converting-Between-Layer-Formats.html , "arquivos .usdc - formato binário" que está em Crate (consulte _Formato de arquivo de taxa_ em https: // gráficos. formato pixar.com/usd/docs/USD-Glossary.html).

Há também .usda, que é codificado em ASCII, o que provavelmente seria mais fácil de escrever em um carregador.

Como um esboço de alguns itens por-fazer para isso, no mínimo, um Loader estaria procurando extrair um arquivo Zip em JS e, em seguida, também entenderia o .usda (e potencialmente o Crate .usdc binário também).

Olá @richardmonette , Fiz algumas pesquisas sobre USDZ e o formato USDA e escrevi uma prova de conceito do conversor de glTF para USDZ. Talvez seja útil para sua pesquisa: https://github.com/timvanscherpenzeel/gltf-to-usdz. Você pode ver uma demonstração aqui: https://twitter.com/domenicopanacea/status/1011292393801420800 ou experimente você mesmo aqui: https://timvanscherpenzeel.github.io/gltf-to-usdz/ (requer iOS 12).

Resumindo: a geometria é convertida para OBJ , a textura de rugosidade metálica é dividida por canal e as texturas são invertidas. A partir disso, um arquivo USDA é construído dinamicamente e alimentado em usdz_converter para construir o usdz final.

Eu sei que algumas pessoas estão pensando em escrever um conversor direto para USDZ, mas não muito se sabe sobre o formato USDC neste momento (também em termos de decodificação).

Olá @TimvanScherpenzeel , obrigado pela sua mensagem e trabalho nisso!

Você já pensou em usar a API USD Python (https://graphics.pixar.com/usd/docs/Hello-World---Creating-Your-First-USD-Stage.html)? Gostaria de saber se seria possível pular o estágio .obj e, usando Python, ler o glTF e ir direto para .usda / c dessa forma.

Tive muitos problemas ao configurar o USD e ainda não tive tempo para consertar o problema (acho que tem a ver com ter várias versões do Python instaladas e durante a compilação ele vincula ao Python errado).

Você poderia, de fato, escrever o arquivo OBJ diretamente no arquivo USDA (isso poderia ser um bom próximo passo em minha prova de conceito). Eu conheço a estrutura de arquivos dos exemplos da Galeria AR porque um contribuidor do meu projeto me enviou os arquivos USDA depois de ter os arquivos USDC decodificados com usdcat .

O objetivo da Apple em fornecer um USDZ QuickLook é ignorar totalmente o uso de WebGL, DOM e Javascript e usar diretamente a cena com ARkit2.0.
É apenas um marco para um rOS baseado na tecnologia Apple / Pixar.
Quando mais tarde eles adicionarem interatividade / capacidade de script, ainda menos Web-UI será necessária.

Pixar USD, usando Patches OpenSubDiv altamente eficientes para geometria, portados para Metal móvel em breve superará o desempenho do HighEnd PC-VR WebVR.
Não como um formato de arquivo, mas como um pipeline completo de fazer experiências / apresentar / (- interação).

Então IMHO é mais importante exportar USDZ dos editores AR / VR e para Android e Windows pegar o trem do USD, do que adicionar um importador ao pipeline WebGL2 .

Uma questão importante é que o WebXR também teria que oferecer suporte a patches SubDiv em vez de polymeshes legados para oferecer suporte total ao USD usado pela Apple.

@pixelpartner, você

Parece-me que, a menos que um carregador seja construído nativamente em navegadores, seria útil construir um em JavaScript.

Tenho certeza de que o quick look é altamente otimizado, mas qual é o caminho a seguir para a criação de conteúdo interativo usando ativos USDZ em um navegador?

É uma solicitação de recurso válida, mas pessoalmente não entendo a Apple / Pixar. Por que eles estão introduzindo um novo formato de arquivo e não apenas usando glTF? Alguém pode explicar o que USD / USDZ faz melhor do que glTF?

Eu conversei com alguém que trabalha com software de exibição de produto recentemente, eles exportam para glTF e USDZ, então perguntei a ele o que ele acha disso. Sua opinião em poucas palavras: é para que a Apple possa continuar a reivindicar ser a escolha de luxo de ponta, com um formato 3D exclusivo que só funciona em sua plataforma via ARKit2.0 / SceneKit. Adotar o formato glTF padrão seria contrário aos seus objetivos aqui, eles querem ser capazes de afirmar que _seu_ formato é melhor e permite resultados de maior qualidade devido às propriedades do material PBR que o glTF (ainda?) Não suporta.

16977, e talvez # 14051, são provavelmente necessários para obter o three.js com os mesmos padrões de renderização das ofertas da Apple, mas não tenho certeza de como o estado atual ou os planos futuros para glTF se relacionam com isso.

Em qualquer caso, pelo menos para subverter os nefastos objetivos da Apple aqui, acho que precisaremos apoiar o USDZ em algum momento.

é para que a Apple possa continuar a reivindicar ser a escolha de luxo de ponta, com um formato 3D exclusivo que só funciona em sua plataforma ...

Estou disposto a dar mais benefícios à dúvida aqui - eles têm objetivos diferentes para um formato de "tempo de execução" do que nós (threejs + desenvolvedores da web) temos e, como resultado, somos capazes de fazer escolhas diferentes. Em particular, agrupar o tempo de execução de ~ 15 MB USD no iOS significa que eles não se importam que carregar USDZ _sem_ um tempo de execução nativo seja proibitivamente difícil, e eles parecem estar OK em não fornecer ao aplicativo da web qualquer acesso ao modelo, mas apenas abrir o modelar no estado em que se encontra em um aplicativo nativo.

No "luxo de ponta", o visualizador iOS QuickLook da Apple suporta materiais PBR metálicos / rugosos, e o modelo do material é amplamente equivalente ao que o glTF 2.0 suporta hoje. Os recursos materiais adicionais planejados para glTF 2.0 no futuro, e descritos em https://github.com/mrdoob/three.js/issues/16977 , iriam além do que os visualizadores USDZ da Apple suportam agora.

Menciono "visualizadores de USDZ da Apple" porque é, de fato, o que as pessoas parecem querer dizer com USDZ. Mas o formato USDZ, tecnicamente, é apenas um arquivo USD compactado e pode conter praticamente qualquer coisa, desde um modelo de material comum a um shader totalmente personalizado. Os visualizadores da Apple suportam um pequeno subconjunto de dólares americanos, e esse subconjunto não está bem definido, mas o melhor resumo que você provavelmente encontrará está aqui: https://github.com/google/usd_from_gltf#compatibility.

Em termos de fidelidade de renderização, eu diria que o visualizador de modelos exibe modelos glTF com threejs e fornece os meios para abrir uma versão USDZ no iOS Quick Look, e os resultados visuais são bastante semelhantes. Esta página fornece algumas comparações diretas, embora, infelizmente, esteja desativada no momento.

Em qualquer caso, pelo menos para subverter os nefastos objetivos da Apple aqui, acho que precisaremos apoiar o USDZ em algum momento.

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

Eu só quero mencionar aqui que há razões para apoiar o USD além da Apple "alegando ser uma escolha de luxo". @ Mugen87 pergunta "Alguém pode explicar o que USD / USDZ faz melhor do que glTF?"
Algumas coisas que me interessam:

• HDR / texturas flutuantes
• Mapas de ambiente (UsdLuxDomeLight)
• Luzes de área e esfera (UsdLuxRectLight etc.)
• Materiais de shader (OSL / MDL) com "superfície de visualização" para WebGL

Meu caso de uso é carregar a mesma descrição de cena no WebGL e em um pipeline de renderização de última geração - entender que a aparência será diferente, é claro, e algumas substituições ocorrerão.

A iluminação e o ambiente do
Este vídeo dá uma ideia de quais mapas eles suportam (albedo, metálico, rugosidade, normal, oclusão ambiental, emissivo)
https://developer.apple.com/videos/play/wwdc2018/603/

O que eu gostaria de ver é um exportador USDA de three.js, para que você possa salvar modelos que você criou / configurou em um projeto três, para visualização em AR.
"model-view" inclui uma tag para especificar uma alternativa de modelo USDZ, para quando visualizado no iOS.
https://modelviewer.dev/

É realmente uma pena que a Apple optou por um formato que ninguém mais usa e não é suportado nativamente em nenhum lugar (o exportador beta está disponível para o Blender). Portanto, você não tem escolha a não ser converter manualmente todos os modelos existentes. O fato de você ter que incluir suas texturas também é uma dor se você usar a mesma textura em toda uma gama de modelos. Certamente eles poderiam ter referências externas?
É realmente um formato meio confuso, que só utiliza geometria e mapeamento das especificações da Pixar e os compacta com seus arquivos de imagem.
glTF / glb teria sido muito melhor e precisaríamos apenas de UM modelo para todos os lugares ...
No reino do e-commerce, que é o que eles almejam, nenhum cliente vai querer uma experiência na web que funcione SOMENTE para iOS. Como de costume, teremos que fazer todo o trabalho e manutenção do macaco.

@garyo

Meu caso de uso é carregar a mesma descrição de cena no WebGL e em um pipeline de renderização de ponta

espere, existe uma maneira de carregar usd (z) no webgl?

O conjunto de recursos do USDZ recentemente aumentou drasticamente com iOS 13.4 (e RealityComposer 1.4 (133+))

A Apple adicionou muitos esquemas de USD que atualmente nenhum outro software pode interpretar e pode simplesmente ignorar.
Quase toda a funcionalidade interativa do RealityComposer agora não é apenas salva em arquivos de cena .reality, mas também pode ser exportada neste novo tipo de USD.
Alguns novos recursos de USD no topo da minha cabeça:
Limite do gatilho, toque ou entre na área
Ações de animação agrupadas, em sequência e / ou paralelas
A geometria do texto é criada instantaneamente por um novo tipo de Prim que pega a string, a fonte e o tamanho

Isso abre uma nova era. Qualquer desenvolvedor agora pode usar as ferramentas e bibliotecas de uso da Pixar (C ++ / python 2.6 / python 3.x) em qualquer plataforma para escrever arquivos USD que podem simplesmente mostrar o conteúdo ou criar experiências interativas.
Obviamente, você ainda precisa de um iDevice para teste.

-
Atenciosamente, (acabando com a quarentena, permanecendo no escritório em casa)
Thomas animado

Am 14.04.2020 um 20:25 schrieb themightyatom notificaçõ[email protected] :
@garyo https://github.com/garyo iluminação e ambiente são gerenciados pelo visualizador de AR, em uma tentativa de simular o ambiente real.
Este vídeo dá uma ideia de quais mapas eles suportam (albedo, metálico, rugosidade, normal, oclusão ambiental, emissivo)
https://developer.apple.com/videos/play/wwdc2018/603/ https://developer.apple.com/videos/play/wwdc2018/603/
O que eu gostaria de ver é um exportador USDA de three.js, para que você possa salvar modelos que você criou / configurou em um projeto três, para visualização em AR.
inclui uma tag para especificar uma alternativa de modelo USDZ, para quando visualizado no iOS.
https://modelviewer.dev/ https://modelviewer.dev/
É realmente uma pena que a Apple optou por um formato que ninguém mais usa e não é suportado nativamente em nenhum lugar (o exportador beta está disponível para o Blender). Portanto, você não tem escolha a não ser converter manualmente todos os modelos existentes. O fato de você ter que incluir suas texturas também é uma dor se você usar a mesma textura em toda uma gama de modelos. Certamente eles poderiam ter referências externas?
É realmente um formato meio confuso, que só utiliza geometria e mapeamento das especificações da Pixar e os compacta com seus arquivos de imagem.
glTF / glb teria sido muito melhor e precisaríamos apenas de UM modelo para todos os lugares ...

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub https://github.com/mrdoob/three.js/issues/14219#issuecomment-613604756 ou cancele a inscrição https://github.com/notifications/unsubscribe-auth/AAAR6X5SXAY32JAPYL5V44TRMSTBTANCNFSWM4 .

Não conheço nenhum analisador compatível com a web para USD ou USDZ. Renderizar em WebGL ou outra API não é um problema, é analisar o conteúdo do arquivo que é complexo - essa tarefa é mais bem tratada pelo tempo de execução oficial do USD, que tem dependências incluindo OpenSubdiv e MaterialX.

Qualquer desenvolvedor agora pode usar as ferramentas e libs de uso da Pixar (C ++ / python 2.6 / python 3.x) em qualquer plataforma para gravar arquivos em USD.

Ser capaz de ler arquivos em dólares americanos em qualquer plataforma seria bom. 🙂 Por motivos técnicos, não acho que uma implementação funcional do three.js seja provável agora. Se alguém for abençoado com o tempo livre, minha sugestão seria trabalhar na implementação de OpenSubdiv (w / WASM?) Ou MaterialX (w / THREE.NodeMaterial?), Pois esses seriam úteis por si só, mesmo sem um analisador de USD .

@garyo

Meu caso de uso é carregar a mesma descrição de cena no WebGL e em um pipeline de renderização de ponta

espere, existe uma maneira de carregar usd (z) no webgl?

Não, é isso que estou procurando. Eu tenho cenas (objeto, luzes, materiais, câmera, animação, etc. - a coisa toda) e quero ser capaz de carregar a mesma cena, em qualquer formato, em WebGL (via three.js) para visualização e algo assim como o Blender para renderizações finais. glTF é minha melhor opção por enquanto, mas não suporta as coisas que mencionei acima (luzes de área etc.). Eu entendo que o pessoal do glTF está relutante em adicionar mais recursos porque eles estão direcionando a última milha para dispositivos ao invés de cenas reais transferir.
Apenas procurando opções.

@garyo Parece que Collada pode servir para isso? Eu uso uma versão editada do exportador collada de three.js para levar ativos para o Blender para renderizações.

@themightyatom Pesquisei o Collada alguns anos atrás - talvez tenha que revisitá-lo. Obrigado. (Na época, fui convencido por argumentos como o de Godot , nenhum suporte da PBR, etc - isso pode ter mudado.)

@garyo Collada foi projetado para transferir ativos entre desenvolvedores de jogos, todos trabalhando em plataformas diferentes. Não é um formato de entrega viável, mas cumpre muito bem o seu propósito :)
Tive a sorte de passar uma semana na Itália com um de seus criadores, Rene Arnaud. É escrito "da perspectiva da GPU" e geralmente é o primeiro formato a suportar mudanças nas especificações. (OpenGL, DirectX, etc.).

Acho que seria muito valioso integrar https://github.com/google/usd_from_gltf como um exportador. Muito menos importante para mim ser capaz de abrir USD.

Para fazer qualquer coisa útil com o USDZ (carregar ou exportar), você precisará do SDK do USD. _USD de glTF_ requer o SDK do USD como uma dependência, mas o SDK não é compatível com a web . A Apple contorna isso deixando o navegador da web e levando você para seu aplicativo AR Quick Look nativo, mas isso dificilmente é uma solução para a web em geral.