¡Esto pinta muy bien!

Por cierto, estamos planeando eliminar THREE.GLTFLoader y renombrar GLTF2Loader → GLTFLoader pronto *. Podría ser una buena idea cambiar el nombre del exportador a GLTFExporter antes de que llegue r87, para evitar confusiones y así no se requerirá un cambio de nombre entre lanzamientos. Ups, me perdí que ya lo nombraste de esa manera ... ¡continúa! 😆

* @mrdoob , ¿alguna preferencia sobre cuándo debería suceder? En mi opinión, podríamos hacer esto ahora, a menos que queramos mantener GLTFLoader en r87 con solo una advertencia de depreciación, y eliminarlo en r88.

Creo que cuanto antes mejor. Siempre que el nuevo GLTFLoader sea ​​capaz de detectar 1.0 y advierta al usuario que solo admitimos 2.0+.

IIRC que podemos detectar viendo asset como mencioné antes.

IIRC que podemos detectar viendo activos como mencioné antes.

✅ ¡Sí! https://github.com/mrdoob/three.js/pull/11864

¡Frio! Pero encontré un error menor. Estoy haciendo relaciones públicas ahora. Unámonos antes de cambiar el nombre.

¿Podemos especificar los elementos en los que alguien está trabajando en la lista de verificación?

@takahirox seguro! la gente podría simplemente escribir comentarios aquí y yo podría actualizar la lista y señalar a un RP si ya está sucediendo algo

Lo siguiente en lo que trabajaré es en las texturas, para convertirlas a base64 en lugar de usar solo la url

¡Gracias! Quiero ayudar a hacer glTF exporter. Estoy investigando en qué puedo ayudar en la lista de verificación ...

Por cierto, ¿ha dejado deliberadamente dos variables WEBGL_CONSTANTS y THREE_TO_WEBGL globales?

@takahirox genial!
Con respecto a las dos variables, esto es algo que voy a abordar en el siguiente RP para que forme parte del WebGLUtils y simplemente importarlo. No tiene sentido que cada uno que necesite estas constantes necesite redefinirlas cada vez.

@takahirox por cierto, siéntase libre de proponer nuevos elementos a la lista, ¡por supuesto! ;)

@fernandojsg ¡Seguro! Acerca de las variables, quería proponer moverlas a algún lugar si se declaran a propósito como globales, por lo que es bueno saber que sí.

Quiero trabajar en la vista de búfer compartida.

BufferViews: actualmente estoy creando un nuevo bufferView para cada Accessor, esto debería arreglarse para usar solo uno para estos atributos que comparten el mismo componentType

La razón por la que uno para los atributos que comparten el mismo tipo de componente, no uno para todos los atributos, es para la alineación de datos, ¿correcto?

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#data -alignment

Genial, acabo de agregarlo a la lista 👍 Sí, básicamente desea compartir la misma vista de búfer para el componente con el mismo tipo, por ejemplo, si tiene posición y normal, tendrá dos accesos VEC3 pero apuntarán a la misma vista de búfer. Ese podría ser un gran punto de partida;)

Quiero decir, la razón por la que no permitimos que la vista del búfer se comparta entre diferentes tipos de componentes (por ejemplo: flotante y corta) es para mantener una buena alineación de datos, ¿correcto?

Creo que puede almacenar en la misma vista de búfer diferentes tipos de componentes siempre que tengan el mismo target , por ejemplo normal (Vec3) , position (Vec3) y uv (Vec2) podría estar en la misma vista de búfer pero indices no. @donmccurdy, ¿ podrías confirmarlo?

Sí, de acuerdo. Y como menciona esta especificación glTF

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#data -alignment

El desplazamiento de un descriptor de acceso en un bufferView (es decir, accessor.byteOffset) y el desplazamiento de un descriptor de acceso en un búfer (es decir, accessor.byteOffset + bufferView.byteOffset) debe ser un múltiplo del tamaño del tipo de componente del descriptor de acceso.

Es una buena idea que separemos las vistas de búfer entre los diferentes componentType (= tipo de datos como float y short, no vec2 o vec3) para simplificar. Si los separamos entre diferentes tipos de componentes de longitud de datos, estará más optimizado.

Por cierto, ¿hay alguna razón especial por la que el exportador actual solo admite accessor.componentType float, uint y ushort? glTF 2.0 puede manejar char, uchar y short, además de ellos.

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#accessorcomponenttype -white_check_mark

@takahirox no realmente, acabo de definir estos a estas alturas porque son los que se usan para el tipo de atributos que admitimos en este momento (posiciones, normales, colores, uvs, índices ...).
El siguiente paso en el que estoy trabajando son las texturas, por lo que necesitaremos otros como uchar por ejemplo

De acuerdo, primero trabajaré en accessor.componentType s a menos que ya hayas comenzado a impl.

Casi listo, pero mi PR debería entrar en conflicto con # 11978.
Así que envío el mío una vez que se fusiona el # 11978 y soluciono el conflicto.

¿Agregaría animación a la lista?

@takahirox seguro, podría ser genial agregar animación. Simplemente no lo agregué porque no estaba lo suficientemente familiarizado con el estado actual de las funciones de animación en three.js, pero si tiene ganas de hacerse cargo, sería genial;)

¿Planea apoyar a los grupos de BufferGeometry?
¿Las especificaciones GLTF cubren eso o resultarían en la creación de una nueva malla para cada grupo?
Esto también debe tener en cuenta, la propiedad material de una malla es una matriz de materiales.

@marcatec La especificación glTF tiene una distinción de "malla" frente a "primitiva" que le permitiría crear grupos BufferGeometry que podrían hacer referencia a un material diferente. Actualmente THREE.GLTFLoader no optimiza las primitivas de carga, crea mallas separadas, pero eso podría implementarse.

¡Buen trabajo, excelente lista y es bueno saber que ya hay mucho apoyo en el formato! También funciona muy bien junto con gltf blender exporter. ¡No puedo esperar por el soporte de las luces! Mantener el buen trabajo.

Estoy de acuerdo, ¡gran trabajo!

¿Hay planes para agregar soporte para otros materiales además de StandardMaterial?

¡Gracias!

@homerjam se conservarán todas las propiedades del material compartidas con MeshStandardMaterial; por ejemplo, un MeshPhongMaterial que use map y normalMap se exportaría con esas texturas intactas, pero cuando lo importes de nuevo a three.js será un MeshStandardMaterial. El exportador actualmente realiza una conversión ingenua a PBR para esto.

El soporte de ida y vuelta (exportar Phong desde GLTFExporter, cargar Phong desde GLTFLoader) requerirá un trabajo en progreso en el formato glTF: https://github.com/KhronosGroup/glTF/pull/1150

baseColorTexture : es compatible (material.map) pero texCoord siempre se establece en 0

@fernandojsg ¿ podrías aclarar lo que falta aquí? Dado que .map es siempre el primer conjunto de UV en three.js, ¿suena como la forma correcta de representar eso en glTF?

También un aviso, taché tres elementos de la lista. Razonamiento a continuación:

• tangentes
  
  
  
  • three.js solo los calcula en la GPU; agregar una implementación solo para el exportador no suena ideal.
  
  
• accesores escasos
  
  
  
  • Creo que es mejor dejar esto para la optimización posterior a la exportación, como el script de mattdesl .
  
  
• compruebe si el material coincide con glTF predeterminado y omítalo
  
  
  
  • se siente como un caso marginal / desorden, siéntase libre de implementar si alguien se siente fuerte
  
  

Al exportar a GLB desde el editor, he notado que alphaMap , roughnessMap y metalnessMap no se exportan.

En # 13397 dije que normalMap ninguno se exporta, pero parece que estaba equivocado.

Al exportar a GLB desde el editor, he notado que alphaMap, roughnessMap y metalnessMap no se exportan.

Trabajaré en esto hoy a menos que alguien ya haya comenzado.

@donmccurdy

accesores escasos
Creo que es mejor dejar esto para la optimización posterior a la exportación, como el script de mattdesl.

Tener ganas de permitir que el exportador admita accesos escasos para la transformación. Voy a intentar más tarde.

@takahirox genial! ¡adelante!

No creo que alphaMap sea ​​compatible con glTF 2.0.

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#material

Sí, temía que ... ¿Qué pasa con metalnessMap y roughnessMap ?

¡Estoy trabajando en ellos ahora!

13415

Respecto a los formatos de imagen. glTF 2.0 solo admite .png y .jpg como archivos de imagen externos. Estoy considerando cómo manejar archivos de formato de imagen no admitidos (por ejemplo: .bmp) en modo que no sea embedImages .

1. Convierta a .png o .jpg e incruste
2. No importa. Exportar como archivos de imagen originales
3. No exportar

Prefiero 1. ¿Alguna idea?

Vaya, realmente aprecio el trabajo de ustedes.

Espero que Multi-material meshes se implemente lo antes posible porque la mayoría de los modelos 3D utilizan múltiples materiales.

1. Convierta a .png o .jpg e incruste
2. No importa. Exportar como archivos de imagen originales
3. No exportar

Voto por 3 y registrando una advertencia en la consola.

Espero que las mallas de materiales múltiples se implementen lo antes posible porque la mayoría de los modelos 3D utilizan materiales múltiples.

De acuerdo, para mí este es el problema número uno que impide el uso del exportador.

Espero que las mallas de materiales múltiples se implementen lo antes posible porque la mayoría de los modelos 3D utilizan materiales múltiples.

Como dije en el otro hilo, estoy trabajando en eso.

1. Convierta a .png o .jpg e incruste
2. No importa. Exportar como archivos de imagen originales
3. No exportar

Voto por 3 y registrando una advertencia en la consola

Sí, llegué a pensar que 3. sería más simple y no confuso para los usuarios. Obtener una imagen incrustada en un modo que no sea emedImages sería un poco confuso.

La razón por la que prefiero 1. fue para convertir otros formatos a glTF. Algunos (o muchos) de otros formatos no tienen limitación de formato de imagen.

El exportador convierte en modo embedImages . Por lo tanto, creo que sería bueno agregar la opción "use embedImages si desea convertir" a la advertencia de la consola.

Yo también iría por 3. Como la conversión desde otros formatos puede ser tediosa, de todos modos deberá priorizar algunos formatos frente a otros. Probablemente valga la pena hacer 3 ahora mismo y esperar a ver si gltf agrega soporte a nuevos formatos de textura como ktx y podríamos revisar la implementación.

Como se discutió en https://github.com/mrdoob/three.js/pull/13415#issuecomment -369022383, sería bueno si el exportador pudiera componer la textura ambientRoughnessMetalness para el usuario. Sin embargo, probablemente sea mejor colocar ese código en ImageUtils .

Actualicé la lista de verificación con los últimos cambios. Agregué @takahirox al elemento multimaterial , y me ocuparé de la tarea de composición de imágenes.
También agregué la extensión material_unlit, aunque todavía está en borrador, creo que está bastante cerca de lanzarse y no cambiará mucho (/ cc @donmccurdy)

Espero que las mallas de materiales múltiples se implementen lo antes posible porque la mayoría de los modelos 3D utilizan materiales múltiples.

Como dije en el otro hilo, estoy trabajando en eso.

WIP ... (Miku tiene varios materiales)

Acerca de los formatos de imagen no compatibles, de acuerdo, vayamos por 3.

@takahirox se ve bien! 👍

Por cierto, ¿estáis interesados ​​en la compatibilidad con archivos zip? .glTF + .bin externo y texturas se ajustarían a otras herramientas de creación (tal vez), pero es difícil de hacer sin archivos. Por lo que sería necesario un archivo zip. Y podemos reducir el tamaño del archivo exportado.

Lo quiero y lo probé en mi sucursal local antes, puedo compartirlo más tarde si está interesado.

¿No es eso más o menos lo mismo que gzip un glb?

.glTF + .bin externo y texturas se ajustarían a otras herramientas de creación (tal vez)

Espero que las herramientas de creación no requieran archivos separados; animamos a todo el mundo a utilizar GLB de forma predeterminada. Pero es más fácil editar manualmente una imagen si no está incrustada, seguro.

No hay una opinión sólida sobre si queremos poner esa funcionalidad en THREE.GLTFExporter directamente ... pero casi creo que no deberíamos tener demasiadas opciones que podrían ser post-optimizaciones en glTF. Otro ejemplo, Draco es algo complicado y requiere varios archivos externos, por lo que tal vez sea mejor dejar que las herramientas especializadas de glTF a glTF hagan esa optimización. Y de manera similar, podríamos hacer un glb-unpacker (opuesto a http://glb-packer.glitch.me/) para ayudar a las personas a descomprimir archivos de GLB a ZIP si descubrimos que la gente lo necesita.

De https://github.com/KhronosGroup/glTF/issues/1256 -

... la intención original de gltf-pipeline, y realmente glTF en general, hace que los exportadores sean lo más simples posible y llevan las optimizaciones a una herramienta común. También, por supuesto, ayudará con la fragmentación.

Dicho esto, todavía no existe ningún desempaquetador glb que yo sepa ...

@mrdoob

Quería que las imágenes de textura fueran externas, en lugar de .glTF frente a .glb.

@donmccurdy

Seguí la discusión https://github.com/KhronosGroup/glTF/issues/1117 y estoy de acuerdo con alentar ahora los archivos incrustados .glb + y el enfoque de canalización. Un .glb es bueno para la transmisión de datos, especialmente para la web y el enfoque de canalización puede mantener los exportadores y las herramientas simples y reutilizables. (¡También me gusta el enfoque de canalización de comandos de UNIX / Linux!)

Así que no creo que el exportador necesite ahora compatibilidad con archivos zip. Y tal vez tampoco necesite un acceso escaso y soporte de Draco por la misma razón.

En cuanto a glb-unpacker, puede que lo consiga en mi tiempo libre. Creo que a algunos artistas les gustan los archivos externos .glTF + porque son legibles sin herramientas específicas de glTF. Y, a veces, los archivos externos pueden reducir el tiempo de carga debido al archivo de carga paralela, por lo que podría usarse con fines de optimización.

Con respecto a las herramientas de optimización / canalización, quiero señalar que no queremos transferir grandes datos a través de la red. Los usuarios quieren optimizar / comprimir antes de ~ transformar ~ transferir datos. Por lo tanto, el servicio web de optimización glTF a veces no funciona bien para datos grandes porque el usuario necesita enviar archivos grandes al servidor.

Además, para Three.js y otros motores basados ​​en navegador JavaScript, estaríamos felices si tuviéramos herramientas de optimización glTF que se ejecutan en el navegador. Podemos optimizar / comprimir antes de que los datos se pasen a los usuarios. Sin ellos, los usuarios deben descargar manualmente los datos exportados y luego pasarlos a las herramientas de canalización debido a las limitaciones del navegador.

Desde este punto de vista, quiero que una herramienta pueda ejecutarse en cualquier lugar, en el navegador, en el servidor, CUI, etc., para que sea más común y reutilizable. No queremos crear herramientas con el mismo propósito dos veces o más para diferentes plataformas. Entonces, ¿la herramienta basada en node.js sería buena? ¿El equipo de glTF (canalización) tiene alguna sugerencia? (Quizás esta discusión debería hacerse en glTF, no aquí).

Por si acaso, en GLTFLoader soporte binario se implementa como extensión pero .glb está en la especificación principal de glTF 2.0, ¿correcto?

Por si acaso, en GLTFLoader, el soporte binario se implementa como extensión, pero .glb está en la especificación principal de glTF 2.0, ¿correcto?

Sí, era una extensión en glTF 1.0 y simplemente nunca reubiqué o renombré ese código después de que se convirtió en parte de la especificación central de glTF 2.0.

Desde este punto de vista, quiero que [herramientas de optimización] se puedan ejecutar en cualquier lugar, en el navegador, en el servidor, CUI, etc., para que sea más común y reutilizable. Entonces, ¿la herramienta basada en node.js sería buena? ¿El equipo de glTF (canalización) tiene alguna sugerencia? (Quizás esta discusión debería hacerse en glTF, no aquí).

Valdría la pena preguntar sobre glTF-Toolkit parece relevante, pero (actualmente) solo se ejecuta en Windows. Personalmente, me gusta Node.js, pero C ++ o Rust podrían ser opciones razonables con la compilación en WASM.

Oh, me faltaba la compilación de WASM. Especificar algunas plataformas de desarrollo recomendadas sería bueno para los desarrolladores de optimización. Así que propondría un hilo apropiado.

Estoy de acuerdo con @donmccurdy ya que creo que estas optimizaciones en proceso podrían vivir en un repositorio diferente a three.js, por lo que todos podrían beneficiarse de ellas. Todavía necesito verificar las diferencias entre la canalización gltf y las herramientas del kit de herramientas, pero espero que este tipo de características se incluyan en ellas.
También estoy de acuerdo en que mientras tengamos un WASM, realmente no importaría el idioma de origen, pero también es cierto que si está escrito en node.js probablemente mucha de la comunidad alrededor de los motores web 3d podría ayudar a mejorarlos como ahora mismo son el objetivo principal de este formato de archivo de todos modos.

No estoy seguro de entender lo que es "optimizar antes de transformar" ... hay varios tipos de transformaciones que una canalización puede hacer en un modelo, y las optimizaciones son probablemente el tipo de transformación más común.

De acuerdo más allá de eso. Es bueno tener herramientas enfocadas de bajo nivel que pueden usarse para construir otras herramientas o conectarse a una GUI más fácil de usar.

Vaya, es un error tipográfico. No transformando sino transfiriendo. Quiero decir, la mayoría de los usuarios quieren optimizar / comprimir antes de enviar datos a través de la red. Actualicé las publicaciones para tenerlas más claras.

Hola tios

Estoy usando THREE.js GLTF Exporter para exportar una escena completa de un marco como un objeto gltf.
¿Cómo puedo hacer que las etiquetas de animación a definidas en un marco formen parte de las animaciones en el objeto gltf?

@donmccurdy @fernandojsg @mrdoob

Hola @siddhartpai - THREE.GLTFExporter solo convierte objetos THREE.AnimationClip en animaciones glTF, mientras que el sistema de animación de A-Frame usa TweenJS. Así que actualmente esto no es posible. Es posible que desee abrir un problema en A-Frame o en A-Frame Inspector, que también usan GLTFExporter , para solicitarlo como una función futura.

Soporte multimaterial # 13536

Acabo de notar que el validador arroja un error en cada elemento normal en una vista de búfer que no está normalizada. Por ejemplo, si almacené valores no inicializados como [0,0,0], arrojará ese error.
Como es un error y no una advertencia / aviso, veo que es delicado corregirlo. ¿Qué piensas acerca de garantizar que los elementos normales de bufferview estén normalizados? Aun así, para valores que no se pueden normalizar como [0,0,0], ¿deberíamos usar un vector unitario válido? / cc @donmccurdy

Parece que NORMAL debería normalizarse.

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#meshes

NORMAL | "VEC3" | 5126 (FLOTADOR) | Normales de vértice XYZ normalizadas

De acuerdo con asegurar porque Three.js normal no tiene tal limitación.

Sí, pero ¿qué hacer cuando no tienes un valor normal real, como un valor no utilizado de [0,0,0], simplemente crea uno válido y está bien? digamos [1,0,0]. Así que deberíamos modificar el código de la vista de búfer para detectar que estamos analizando un atributo normal y normalizar cada uno antes de guardarlo en la vista de datos.

qué hacer cuando no tiene un valor normal real, como un valor no utilizado de [0,0,0]

Hm ... reemplazando por uno válido y mostrando una advertencia?

Así que deberíamos modificar el código de la vista de búfer para detectar que estamos analizando un atributo normal y normalizar cada uno antes de guardarlo en la vista de datos.

Prefiero hacer eso en processMesh() porque sería más simple, como

var originalNormal = geometry.attributes.normal;

if ( hasNonNormalizedValues( originalNormal ) ) {

    geometry.attributes.normal = createNormalizedAttribute( originalNormal );

}

processAccessorHere();

geometry.attributes.normal = originalNormal;

Si hacemos eso en processBufferView() , el código se volvería un poco complejo porque debemos preocuparnos si los datos se comparten entre diferentes atributos, por ejemplo, posición y normal. (Sé que es un caso de uso muy raro, pero Three.js no restringe).

Sí, me gusta ese enfoque, tenía miedo de modificar las normales después de exportar, pero debería estar bien si guardamos una referencia y la volvemos a colocar después de terminar. : +1: ¿Te importaría impulsar un PR con estos cambios? o quieres que lo haga?

Esta bien lo hare. (¿Tienes prisa por arreglar eso?)

@takahirox genial, ¡gracias! pero no hay prisa, solo estaba revisando el estado del exportador ^ _ ^

Bien, entonces lo haré ~ mañana ~ esta semana.

Correcto, glTF no permite omitir normales en vértices particulares pero no otros en una sola primitiva. Tendremos que proporcionar algún tipo de valor, eliminar estos vértices o lanzar un error.

Preferiría facilitarle las cosas al usuario, por lo que mi voto es crear una nueva matriz de normales normalizándolos y agregando un valor (0,1,0) para los vacíos.

Parece bien. Si es lento para modelos grandes, es posible que deseemos una opción checkNormals o algo así, para que los usuarios que no lo necesiten pueden optar por no hacerlo, en lugar de escanear cada vértice.

¡Sí, estaba a punto de escribir lo mismo! :D

Si es lento para modelos grandes, es posible que deseemos una opción checkNormals o algo así, para que los usuarios que no lo necesiten puedan optar por no hacerlo, en lugar de escanear cada vértice.

Primero haré relaciones públicas sin esa opción. Agreguemos cuando / si es necesario. Personalmente, supongo que este control no se ralentiza mucho.

Primero haré relaciones públicas sin esa opción. Agreguemos cuando / si es necesario. Personalmente, supongo que este control no se ralentiza mucho.

Estaba normalizando todos los búferes al cargar cada trazo en un pintor y era bastante lento

¿Incluso si solo verificas si están normalizados?

@takahirox necesitarás calcular la longitud de todos modos, así que supongo que no cambiará tanto

HM esta bien. Lo evaluaré con el PR.

Es la primera característica de GLTFExporter que hemos introducido que hace cualquier cálculo con cada vértice (excepto la conversión de objetivo de morfo relativo / absoluto) así que sí, potencialmente más lento ... de cualquier manera.

¡Buen trabajo! En mi humilde opinión, debería fusionarse en el núcleo three.js, en lugar de en "ejemplos".
¡Me encantaría ver el soporte de KHR_lights_punctual !

PR https://github.com/mrdoob/three.js/pull/15519 agrega KHR_lights_punctual. :)

Creo que este problema probablemente se pueda solucionar: los elementos restantes son una conveniencia u optimización menos críticas y se pueden rastrear en otros lugares:

• [] reutilizar vistas de búfer
• [] fusiona automáticamente texturas metal / rugosa / ao

Hola chicos, ¿alguien sabe cómo puedo exportar una malla con forma personalizada mediante cambios de transformación aplicando las transformaciones y eliminándolas del objeto final?
Como esta pregunta https://stackoverflow.com/questions/57423471/how-to-export-morph-changed-meshes-from-threejs-application
¡Gracias por adelantado!

@ vini-guerrero Utilice los foros (https://discourse.threejs.org/) o Stack Overflow para obtener ayuda, en lugar de problemas de GitHub.