Three.js: GLTFExporter GLB compatible con visor de Facebook

Creado en 22 feb. 2018  ·  56Comentarios  ·  Fuente: mrdoob/three.js

Después de que Facebook anunció el soporte de glTF en su línea de tiempo , he estado tratando de usar GLTFExporter para generar algo de glTF binario ( glb ) para probar esta nueva función.

Pero he encontrado algunos problemas hasta ahora:

  • [x] Los fragmentos GLB deben estar alineados con 4 bytes https://github.com/mrdoob/three.js/pull/13395
  • [x] Validación: corrige znear y zfar: https://github.com/mrdoob/three.js/pull/13396
  • [x] Color de vértice: Facebook solo admite RGBA, pero no RGB. Como se muestra en el mensaje de validación :
    [msg] => Vertex COLOR_0 attributes of type RGB are (temporarily) notsupported. They must be RGBA. . Aunque COLOR_0 podría ser vec3 o vec4 y podríamos incluir un parámetro opcional para forzar la conversión del atributo color de 3 a 4 componentes, no Creo que deberíamos hacer ese truco ya que nuestra implementación actual sigue las especificaciones y no veo ningún otro caso de uso para esa conversión que simplemente secuestrar el validador de Facebook mientras están trabajando para solucionarlo. <- Actualización: esto debería hacerse en las próximas semanas, por lo que no necesitamos solucionarlo
  • [x] No se admiten mallas no indexadas: `[msg] => Las primitivas de malla sin índices (temporales) no se admiten.
  • [] Exportar otros modos primitivos (actualmente solo se admite TRIANGLE)

Más información: https://developers.facebook.com/docs/sharing/3d-posts/glb-tutorials

Enhancement

Comentario más útil

Hola amigos, a partir de esta mañana, Facebook ya no rechaza los colores de vértice RGB (VEC3) como "no válidos".

Los requisitos de las texturas del poder de dos permanecen por el momento, pero también estoy trabajando en eso.

Todos 56 comentarios

/ ping @zellski

¡Oye! Sí, ese cheque RGBA debería desaparecer en dos semanas. No trabajes alrededor de eso. :)

Estoy tratando de convertir WaltHead.obj a glb. Lo estoy cargando en https://threejs.org/editor/ y exportándolo a GLB desde allí (que ya debería tener los últimos parches).

Aquí está WaltHead.glb y esto es lo que

Your GLB File has the following errors: The 3D model could not be posted: The JSON portion of this model file is invalid.

🤔

Es JSON sintácticamente válido, pero los nulos en este fragmento de WaltHead.gltf no se ajustan al esquema de tipo:

    {
      "bufferView": 2,
      "componentType": 5126,
      "count": 48480,
      "max": [
        null,
        null
      ],
      "min": [
        null,
        null
      ],
      "type": "VEC2"
    }

La herramienta de validación Khronos glTF también enumera alrededor de 10,000 instancias de algún otro error en el archivo, todos en el orden de:

        /accessors/2: Accessor element at index 28922 is NaN or Infinity.

Entonces, parece que tal vez se está generando un descriptor de acceso durante la exportación de glTF, para ser llenado con índices, pero ¿nunca recibe ninguno?

Los rayos UV son NaN: 🙃

screen shot 2018-02-21 at 9 27 57 pm

@mrdoob @donmccurdy arreglado! https://github.com/mrdoob/three.js/pull/13400
Aunque todavía no podemos mostrar ese ejemplo debido a

[msg] => Mesh primitives without indices are (temporary) unsupported.

(agregado a la lista de tareas pendientes)

@zellski , ¿tienes alguna estimación sobre esa característica? ;)

@fernandojsg Este es un poco más complicado. Se arreglará, pero puede que tarde un poco más. tl; dr ¿Quizás un mes?

Explicación más larga: el problema es similar al color de vértice anterior, en el sentido de que son las implementaciones de nuestros clientes las que se están quedando atrás, y mi validador en el backend solo los protege de modelos que aún no pueden manejar.

Obviamente, tenemos que admitir geometría no indexada, cuanto antes, mejor. Idealmente en los clientes, pero también para entonces debería tener mi código de backend al máximo de la potencia de la Estrella de la Muerte, donde transformamos todos los archivos .gltf cargados de manera perezosa / bajo demanda, según las necesidades de los clientes individuales. En ese momento, podemos hacer cosas interesantes como crear geometría indexada en el servidor para la conveniencia de nuestros clientes.

Supongo que el error anterior se produce cuando three.js está intentando exportar primitivas que, naturalmente, no están indexadas en su representación en tiempo de ejecución.

Supongo que el error anterior se produce cuando three.js está intentando exportar primitivas que, naturalmente, no están indexadas en su representación en tiempo de ejecución.

@zellski ¡ eso es! Algunas primitivas u objetos cargados en tres no están indexados. El primer caso de uso que pensé para el cargador glb de facebook fue incluir dibujos de nuestra aplicación A-Painter (más información: https://blog.mozvr.com/tag/a-painter/) y usamos geometría no indexada allí también, por lo que sería genial tener apoyo para eso;)
Solo quería saber si eso estaba en la hoja de ruta, así que saber que es todo y que podríamos tenerlo en aproximadamente un mes, es más que razonable;) ¡gracias por compartir esa información!

Mientras tanto, es posible que tengamos que agregar un atributo de índice tonto (como en 0, 1, 2, 3, 4, 5, 6, 7, 8, ...) 😕

@mrdoob, ¿te refieres a tener algún método para convertir no indexado a indexado como quieras, o agregar el truco directamente en el exportador?

Sí, agregue un truco temporal en el exportador ...

No sé, solo quiero que las cosas funcionen y no tener que decirle a la gente, "¿oh? ¿Tu modelo no funciona en Facebook? Eso es porque ... ¿sabes qué son las geometrías indexadas? Sí, no deberías, pero ... "

¡Si, lo tengo! Ok, echaré un vistazo para ver si puedo agregar algún truco no tan sucio :)

@zellski para el contexto ...

Agregué un Export GLB en http://threejs.org/editor/ que usa este GLTFExporter .

screen shot 2018-02-22 at 11 03 42 am

Video: cómo exportar el modelo como glTF en Three.js Editor: D

https://twitter.com/superhoge/status/966689549803053056

Créame, entiendo la renuencia a agregar trucos. Es una gran lucha mantener una perspectiva paciente ahora que hemos lanzado ...

¿Podrías hacer el truco de GLTFExporter en una bifurcación que se usa en http://threejs.org/editor/ pero no en otro lugar? Espero que hayamos solucionado esta falla para cuando salga r91, por lo que parece un poco inútil que ustedes escriban un código cuidadoso y responsable para ello.

¿Podrías hacer el truco de GLTFExporter en una bifurcación que se usa en http://threejs.org/editor/ pero no en otro lugar?

¡Sí, no te preocupes!

Espero haber solucionado este defecto para cuando salga r91

Oh, mi objetivo es lanzar el ~ 1 de marzo. Se cambió el ciclo de publicación a principios de mes para tener las publicaciones mensuales adecuadas.

Parece que todavía tenemos más funciones para agregar antes de promocionar esto de todos modos. No creo que estemos exportando mapas de rugosidad, metálicos, normales o alfa.

La última prueba, usando 2 mapas difusos, una de las nubes es un png transparente:
https://www.facebook.com/fakemrdoob/posts/950266411809572

No estoy seguro de dónde viene el aparente alphaTest: 0.5 ...

Solo usando la solución alternativa para índices :)
https://www.facebook.com/fernandojsg/posts/10156405595122044

@mrdoob, ¿le importa agregar las funciones que faltan que encuentra y que no están relacionadas con los requisitos de Facebook sobre este tema: https://github.com/mrdoob/three.js/issues/11951
Aunque necesito actualizar el estado allí 😇

Suena bien. Lo probaré exportando y volviendo a arrastrar al editor.
¿Deberíamos cerrar este?

@mrdoob Lo dejaría abierto hasta que el problema de RGB vs RGBA para colores de vértice se resuelva en el lado de Facebook, por lo que si las personas vienen aquí en busca de ayuda, podrían leerlo en lugar de abrir otro problema.

Por cierto, acabo de encontrar este enlace con información útil: https://developers.facebook.com/docs/sharing/3d-posts/glb-tutorials

Aparentemente, las texturas deben tener poder de 2 ...
https://twitter.com/drupalati/status/967486854630055936

¿No convierte Three.js automáticamente la imagen de sin potencia de dos a potencia de dos sobre la marcha?

Si, lo siento. Los clientes móviles aún no cambian de tamaño, por lo que debemos rechazarlo durante la validación por un tiempo. Probablemente haremos el cambio de tamaño en el servidor, ya que tenemos un control completo sobre la canalización de entrega. Espero que esta restricción también se elimine en 2-3 semanas.

@takahirox Sí, three.js cambiará de tamaño sobre la marcha. Pero los clientes nativos de Facebook no usan three.js.

La lista completa de funciones de glTF que Facebook aún no admite, en orden aproximado de ETA:

  • Sin colores de vértice RGB; debe ser RGBA.
  • Sin texturas NPOT para ciertas combinaciones de sujeción / filtro
  • Solo geometría triangular indexada.
  • Sin animaciones (ignoradas en silencio)
  • Sin accesos escasos (falla la validación)
  • Sin objetivos de transformación (si alguna malla tiene una propiedad de 'objetivo', el modelo falla en la validación)
  • Sin cámaras (ignoradas en silencio) (por ahora)

También:

  • Tamaño máximo de archivo 3 MB
  • Ninguna dimensión de textura superior a 4096
  • No hay extensiones que no sean KHR_material_unlit (por ahora)

Creo que eso es todo.

Hice PR # 13424 para forzar textura POT porque creo que valdría la pena no solo para FB.

Al usar GLTFExporter para exportar una malla de múltiples materiales (una matriz de material), recibí este error:

GLTFExporter.js:623 Uncaught TypeError: Cannot read property 'toArray' of undefined
    at processMaterial (GLTFExporter.js:623)

@ Ben-Mack Ese es un problema conocido y estoy trabajando en ello ahora. (Pero tomaría un poco de tiempo).

@zellski ¿ algún plan para el apoyo de draco en fb? Puedo bajar mis mallas de 40 MB a 5 MB, pero ese último par de MB simplemente no desaparecerá.

@ webprofusion-chrisc (hombre, esa es una @ larga para un teclado de teléfono) sí, Draco definitivamente está en la hoja de ruta. Necesita un poco de trabajo de ingeniería, por lo que falta al menos un mes, pero, en muchos sentidos, hemos construido nuestras suposiciones en torno a él, como usted dice, para muchos modelos, el límite de 3 MB es simplemente insostenible. (Todavía no estoy seguro de qué podemos hacer para ayudar con las texturas).

(Todavía no estoy seguro de qué podemos hacer para ayudar con las texturas).

@donmccurdy está progresando en ese frente: https://github.com/mrdoob/three.js/pull/12877 😀

Podemos esperar texturas entre un 25% y un 30% más pequeñas de GLTFExporter con el # 12877.

A largo plazo, Binomial está trabajando con Khronos para crear una extensión para texturas comprimidas multiplataforma en glTF: https://www.khronos.org/blog/call-for-participation-gltf-creating-a-compressed-texture-extension .

De acuerdo ... Después de # 12877 y # 13451, una exportación GLB que solía ser de 3.3MB ahora es de 480KB 😊

¡Frio! # 13451 significa que el tamaño del archivo de imagen será mayor si convertimos jpg a png.

¡Frio! # 13451 significa que el tamaño del archivo de imagen será mayor si convertimos jpg a png.

Si. # 13451 es una pequeña solución debido al hecho de que el editor no permite cambiar el formato de una textura en este momento. Pero hacemos lo mismo en la biblioteca de todos modos ...

https://github.com/mrdoob/three.js/blob/dev/src/loaders/TextureLoader.js#L34

Pero sí, GLTFExpoter actualmente se guarda como jpg cuando texture.format === THREE.RGBFormat .

https://github.com/mrdoob/three.js/blob/dev/examples/js/exporters/GLTFExporter.js#L493

Lo que no es ideal, porque estamos recomprimiendo un jpg ... ¿Pero mejor que exportaciones de gran tamaño, supongo?

Tuve que agregar código a FBX2glTF que realmente inspecciona los valores alfa de incluso las imágenes RGBA, porque las personas (o, más precisamente, las herramientas de las personas) las crean de forma predeterminada y, con frecuencia, es completamente innecesario mantenerlas como PNG. Incluso después de probar los trituradores PNG habilitados para GPU más brutales y de optimización no lineal que existen, parece que JPEG realmente gobierna el gallinero ... ¡la diferencia de tamaño es bastante increíble!

Estoy un poco preocupado por el sangrado entre canales para cosas como la textura ORM (oclusión / rugosidad / metal) donde cada componente transporta datos que son completamente independientes de los datos de los otros componentes ... pero en la práctica parece funcionar bien.

El exportador también podría hacer que el nivel de calidad sea opcional al usar canvas.toDataURL (mimeType): mis texturas se generan en tiempo de ejecución a partir de imágenes compuestas, eso también ayudaría.

@zellski para el

@ webprofusion-chrisc Sí, podemos terminar haciendo eso. Por el momento, hemos apostado por .glb como entidad transmitida, lo que es difícil de combinar con la transmisión selectiva de tipo LOD (ya que solo hay un archivo secuencial sin acceso aleatorio). Pero espero que reevaluaremos los supuestos básicos con bastante frecuencia, dependiendo de cómo vayan las cosas. :)

GLTFExporter puede exportar BufferGeometry e importar a Facebook bien. Pero cualquier Geometry o BufferGeometry convertido usando el método fromGeometry no funciona en Facebook. Siempre recibo esto en el validador de FB:

[msg] => Los atributos de vértice COLOR_0 de tipo RGB no se admiten (temporalmente). Deben ser RGBA.

Paso para reproducir:

  • Usando el ejemplo más reciente de misc_exporter_gltf en dev, Export Sphere o Walthead funciona bien en FB, pero el resultado de export Scene1 no se puede importar a FB.

¿Es este un comportamiento esperado y tengo que esperar al lado de FB?

Esperaba que BufferGeometry usando fromGeometry debería funcionar de manera extraíble como BufferGeometry normal, por favor guíeme algunas soluciones rápidas para superar este problema.

@ Ben-Mack, esto es algo que debería arreglarse en las próximas semanas según @zellski -> https://github.com/mrdoob/three.js/issues/13397#issuecomment -367534958

A partir de la compilación 161 en adelante (la versión actual de la App Store es 160) de la aplicación principal de FB, esto ya no será un bloqueo y eliminaremos esta verificación de validación. Espero que esto suceda dentro de la semana.

@zellski ¡ eso es increíble! Gracias :)

Aunque me hace preguntarme ...

La razón "real" por la que THREE.GLTFExporter no puede exportar THREE.Geometry es porque cuando convertimos THREE.Geometry a THREE.BufferGeometry estamos creando un color atributo que, en la mayoría de los casos, está lleno de ceros.

Entonces, una "solución" (y optimización) sería no exportar el atributo color si material.vertexColors se establece en THREE.NoColors ?

Ops No sabía eso: D eso es sin duda una optimización imprescindible: D

@fernandojsg gracias por las actualizaciones que hiciste, muy apreciado. Hay dos cosas más que vale la pena agregar:

  1. Soporte de mallas multimaterial. Los que tienen grupos en sus geometrías y arreglos en Mesh.material - actualmente no se pueden exportar correctamente;
  2. Mejor compatibilidad entre el único material MeshStandardMaterial compatible y el resultado que tenemos en Facebook. Hasta ahora, las superficies metálicas y difusas se ven bastante diferentes en three.js y en Facebook. ¿Quizás algún día tengamos un material especial de "Facebook"?

Gracias

@ov Creo que es probable que ambos se solucionen alrededor de r91:

  1. exportación de múltiples materiales https://github.com/mrdoob/three.js/pull/13536
  2. correcciones de metal / rugosidad https://github.com/mrdoob/three.js/pull/13501

Es posible que los materiales de Facebook tampoco sean del todo correctos todavía, pero glTF es bastante específico sobre cómo deberían aparecer las cosas, por lo que eventualmente deberíamos converger.

Oh, también deberíamos agregar la capacidad de exportar KHR_materials_unlit ...

EDITAR: Abierto https://github.com/mrdoob/three.js/pull/13566

La razón "real" por la que THREE.GLTFExporter no puede exportar THREE.Geometry es porque cuando convertimos THREE.Geometry a THREE.BufferGeometry estamos creando un atributo de color que, en la mayoría de los casos, está lleno de ceros.

Entonces, una "solución" (y optimización) sería no exportar el atributo de color si material.vertexColors se establece en THREE.NoColors?

+1 espero que esto se solucione pronto. Muchas bibliotecas para Three.js siguen funcionando en función de THREE.Geometry .

(FB todavía tiene el error ...must be RGBA con THREE.Geometry )

@ Ben-Mack, ¿qué bibliotecas estás usando que todavía usan Geometry? Quizás podríamos trabajar con los propietarios para actualizarlos.

@looeee Por favor, eche un vistazo a esta biblioteca: https://github.com/a-jie/threejs-geometry-modifiers

Hola amigos, a partir de esta mañana, Facebook ya no rechaza los colores de vértice RGB (VEC3) como "no válidos".

Los requisitos de las texturas del poder de dos permanecen por el momento, pero también estoy trabajando en eso.

@zellski coool! :) Estoy muy cerca de tener un apoyo total para un pintor: D ¿Hay algún plan para implementar el resto de los modos primitivos? En este momento, creo que solo se admiten TRIANGLE, podría ser genial apoyar el resto, por ejemplo, en A-painter estamos usando TRIANGLE_STRIP para ahorrar algo de espacio 👼

Sería una locura no implementarlos, ¿verdad? Idealmente, deberían aceptarse todos los glTF válidos. Sin embargo, no sé cómo se priorizará ese trabajo. Somos un equipo pequeño con muchos impulsos fuertes. :)

Creo que este problema ahora se puede cerrar.

¿Fue útil esta página
0 / 5 - 0 calificaciones