Three.js: Utils: Exportadores obsoletos (Blender, 3DS Max y Maya)

+1 para esto: la existencia de exportadores desactualizados y con un mantenimiento deficiente en el repositorio es un punto de confusión innecesario para los recién llegados, especialmente porque, como señala @ Mugen87 , ahora hay opciones mucho mejores.

Nota: el exportador oficial de GLTF Blender (https://github.com/KhronosGroup/glTF-Blender-Exporter) actualmente no permite la exportación adecuada de animaciones (actualmente solo se admite 1 animación por objeto).
https://github.com/KhronosGroup/glTF-Blender-Exporter/issues/112

@Usnul, ¿cómo se compara eso con el exportador JSON de Blender en este repositorio?

@looeee
Blender JSON exporter exporta animaciones sin problemas. Hay algunos fallos extraños con UV o normales de vértice en ciertas condiciones que no están presentes en el exportador GLTF, pero esa es otra historia.

De acuerdo, no uso Blender, así que no comentaré más sobre eso.

Sin embargo, puedo decir por experiencia que intentar usar el exportador 3DS Max, que no se ha actualizado en varios años, es un dolor de cabeza interminable y apoyaría firmemente su eliminación del repositorio en favor del formato FBX.
Casi todo lo que exporta el exportador 3DS Max FBX ahora es compatible con FBXLoader y, dado que AutoDesk mantiene ese exportador, podemos contar con que se mantendrá actualizado.

De manera similar con el exportador Maya FBX, aunque el FBXLoader aún debe actualizarse para admitir adecuadamente los puntos de pivote allí.

Cuando recuerdo correctamente, Blender no exporta animaciones cuando seleccionas BufferGeometry . Definitivamente hay un problema con los objetivos de transformación, consulte el n. ° 10932. Además, el exportador utiliza el formato de jerarquía de animación "antiguo" y no el del sistema de animación actual.

Creo que también deberíamos eliminar el README del exportador de Revit; solo se vincula a un repositorio separado que parece que apenas se ha tocado en los últimos años.

Probablemente hay cientos de herramientas de three.js a las que podríamos vincularnos de esta manera, pero a menos que estemos dispuestos a asegurarnos de que se mantengan activamente y funcionen correctamente, no creo que sea necesario incluir enlaces a ellas aquí.

Buscar en Google "three.js revit exporter" encuentra que el repositorio está bien de todos modos.

Creo que también deberíamos eliminar el README del exportador de Revit; solo se vincula a un repositorio separado que parece que apenas se ha tocado en los últimos años.

👍

La existencia de exportadores desactualizados y con un mantenimiento deficiente en el repositorio es un punto de confusión innecesario para los recién llegados.

Solo quiero resaltar esta declaración porque creo que es muy importante para three.js . Cuando los usuarios se encuentran con estos exportadores, esperan herramientas que simplemente funcionen. Pero en la mayoría de los casos se confunden y tal vez tengan una mala impresión de todo el proyecto. Eso no es bueno. 😢

Como usuario inocente, me atrevo a hacer un comentario ...

Concerniente a Blender:
Si three.js tuviera un importador de formato .blend nativo ,
Evidentemente, no habría necesidad de un exportador.

Sin esfuerzo de instalación en el lado de la licuadora,
sin compilación de blender API / structs a javascript a través del código Python ...

Hubo tremendos esfuerzos para escribir el exportador JSON en Python,
Me pregunto por qué ustedes, colaboradores, no eligieron esta forma ...

@wolfgangvonludwigsburg
Es una pregunta bastante sencilla de responder. El formato de mezcla no está muy cerca de la representación interna de three.js, por lo que es necesaria alguna conversión. El formato JSON de three.js está muy cerca de la representación interna, por lo que el trabajo de conversión de la representación de Blender a three.js está ahí de cualquier manera, ya sea que elija llamarlo Exportador o Cargador. Dicho esto, .blend no es un formato de transferencia común, nada excepto blender realmente lo admite, por lo que tener un cargador para él satisfaría a una audiencia bastante pequeña, ya que incluso las personas que usan blender prolíficamente tienden a usar también otro software, y .blend no es un formato de elección como formato de intercambio. Por lo general, es obj, fbx o algún estándar abierto como gltf o collada.

@wolfgangvonludwigsburg si _fue_ buscar en la construcción de un cargador de archivos .blend, este probablemente sería un buen lugar para comenzar:

https://raginggazebo.com/parsing-blender-3d-files-blend-1-of-3/

¡Muchas gracias por tus comentarios!

Pero, ¿por qué el exportador Blender JSON es tan propenso a errores ...
=> Depende de la API de Blender, está escrito en Python, debe comprender las estructuras de datos de Blender,
y se compila en un formato JSON, que three.js reconvierte en sus partes internas ...

Muchas tareas, que todos pueden (¡y realmente hacen!) Fallar, principalmente en los cambios de versión de Blender.
Bueno, preferiría la forma de "compilación directa de datos" ...

Bueno, preferiría la forma de "compilación directa de datos".

Ese no es un buen enfoque. Cargar archivos blend directamente en las aplicaciones es una especie de mal uso. En su lugar, debe utilizar un formato de archivo destinado a la transferencia de datos y la entrega de activos. glTF es el primer formato estandarizado que se enfoca en este aspecto desde el punto de vista de la aplicación. Esa es una de las razones por las que promociono glTF tantas veces 😇. Debería ser el estándar para todas las próximas aplicaciones 3D.

Bueno, preferiría la forma de "compilación directa de datos" ...

Desafortunadamente, existen problemas más profundos al usar .blend esta manera. Almacena cosas como el historial de edición, el estado actual de la interfaz de usuario de Blender, los datos del complemento de Blender. El formato cambia a medida que salen los nuevos lanzamientos de Blender. Y los tamaños de archivo pueden ser muy grandes, por lo que nunca sería una buena opción para aplicaciones 3D de alta calidad. La mejor manera de obtener datos directamente de Blender es usar las API de Blender (como hacen los exportadores FBX y glTF), en lugar de intentar aplicar ingeniería inversa al formato interno .blend Blender.

A la pregunta original, omitiré agregar un voto de sí / no ya que no tengo mucha familiaridad con los flujos de trabajo de creación en 3D.

Pero como mantenedor y principalmente desarrollador de JS, ser capaz de concentrarse en la carga y el soporte de formatos como FBX y glTF, que han mantenido activamente herramientas de creación de terceros, parece más probable que dé resultados confiables.

Aparte, si hay algún problema con el ecosistema glTF actual que le impida ser un flujo de trabajo lo suficientemente bueno como para resolver este tipo de necesidad, también son comentarios útiles. 🙂

No discutí el uso del formato .blend de Blender como formato de intercambio general ,
pero puede simplificar la colaboración entre Blender y three.js ...

No puedo estimar los esfuerzos, manteniendo un exportador de Python + GUI bajo el marco de Blender,
pero supongo que esto puede convertirse fácilmente en un horror ... ;-)

@donmccurdy
Por cierto, Wavefront .obj, 3D Studio .3ds también son formatos nativos, que se utilizan ampliamente ...

Por cierto, Wavefront .obj, 3D Studio .3ds también son formatos nativos, que se utilizan ampliamente ...

Sí, creo que OBJ no se menciona aquí porque el formato no admite algunas funciones populares como la animación, pero ciertamente three.js seguirá admitiendo OBJ durante mucho tiempo: es un formato clásico y confiable.

De 3DS Max .3ds está en la misma categoría que Blender de .blend o Maya de .mlt o de Cinema4d .c4d . Cada editor tiene su propio formato interno, y esos formatos cambian a medida que lo hace el software. Mantener cargadores para el formato interno privado de cada herramienta de modelado es mucho más difícil y propenso a errores que usar los formatos de exportación que han proporcionado los propios desarrolladores del editor. Vale la pena señalar que tanto 3DS como Blender vienen con la exportación FBX incorporada, mantenida por sus autores, y que Blender también tendrá la exportación glTF incorporada en una versión futura.

Un último lanzamiento ...

Ya tenemos una herramienta de modelado independiente ex / importador: Collada,
pero por alguna razón esto parece no ser tan aceptado.

Preferiblemente, tenía este tipo de implementación en mente:
una solución de carga, basada en Google Protocol Buffers

https://developers.google.com/protocol-buffers/

Es un

... mecanismo extensible, neutral en cuanto al lenguaje, a la plataforma, para serializar datos estructurados: piense en XML, pero más pequeño, más rápido y más simple.

Dado que los datos vectoriales 2D / 3D con los que tenemos que lidiar no son de naturaleza demasiado compleja, desarrollar un esquema de archivo de datos de Blender debería ser simplemente factible ...

En realidad, hay un analizador de archivos de mezcla en javascript 😁
https://github.com/Galactrax/js.blend

uhh, recibo apoyo ... - gracias mrdoob ;-))

El mayor (en términos de Terrabyte) la solicitud de modelo 3D (3D de Google Maps) utiliza este tipo eficiente (protobufs) de aplicación ...

Seguir el camino de la carga de .blend puede no ser muy sensato. Pero no es realmente tan diferente de cargar .dae y .fbx ...

De todos modos, estoy de acuerdo con la idea de desacreditar a los exportadores.
Sin embargo, esperaría hasta que gltf esté un poco más maduro y probado. Verano 2018?

Estoy de acuerdo con eliminar a esos exportadores también. Incluso podría moverlos a otro repositorio donde puedan RIP :)

Sin embargo, esperaría hasta que gltf esté un poco más maduro y probado. Verano 2018?

Esperar me parece razonable. En particular para glTF, sería bueno tener algunas cosas en su lugar primero:

• [] Envío de Blender con exportación glTF incorporada y soporte de animación múltiple.
• [x] Flujo de trabajo mejorado de Maya y 3DS Max a glTF, o simplemente más pruebas de FBX2GLTF .
• [x] Actualizaciones del convertidor COLLADA2GLTF oficial para glTF 2.0.

Revisar la pregunta en el verano de 2018 parece correcto.

Sin embargo, esperaría hasta que gltf esté un poco más maduro y probado. Verano 2018?

Para el exportador de Blender, suelo estar de acuerdo. Sin embargo, recomiendo eliminar al menos el exportador 3DS Max de inmediato, ya que ya existe una alternativa madura y mucho mejor en FBX.

Sin embargo, recomiendo eliminar al menos el exportador 3DS Max de inmediato, ya que ya existe una alternativa madura y mucho mejor en FBX.

Me suena bien 👌

De acuerdo, el exportador 3DS Max se ha ido. Revisemos a los otros exportadores (Blender y Maya) en unos meses.

No creo que cambie mucho con respecto al exportador Maya en ese momento.

Probablemente deberíamos evaluar eso ahora. Lo probaré y veré si vale la pena conservarlo durante los próximos días.

Buena sugerencia 👍.

Mientras estemos aquí, ¿cuál es el estado de https://github.com/mrdoob/three.js/tree/dev/utils/converters/fbx ? Parece que podría ser reemplazado por un script node.js como el convertidor obj2three, simplemente usando THREE.FBXLoader y serializando al final. Actualmente, el convertidor tiene muchos problemas abiertos:

No animation support
Only Lambert and Phong materials are supported
Some camera properties are not converted correctly
Some light properties are not converted correctly
Some material properties are not converted correctly
Textures must be put in asset's folder, and use relative path in the material

También los convertidores msgPack, UTF8 y CTM: no se han tocado en años.

¿Siguen siendo útiles para alguien?

@donmccurdy Me temo que no puedes usar FBXLoader dentro de un script de node.js ya que no tienes acceso al DOM. Todos los cargadores que utilizan TextureLoader tienen una dependencia de ImageLoader y, por lo tanto, de document . Obtendremos errores de tiempo de ejecución como ReferenceError: document is not defined . El mismo problema para el objeto window que se accede desde FileLoader .

Como solución temporal, ¿quizás podríamos redefinir ImageLoader y FileLoader en el archivo fbx2three.js ?

¿Quizás podríamos redefinir ImageLoader y FileLoader en el archivo fbx2three.js?

Creo que esto sería lo suficientemente simple y aún requeriría mucho menos código que el convertidor de Python que hay ahora ... Lo intentaré.

¿Quizás podríamos redefinir ImageLoader y FileLoader en el archivo fbx2three.js?

Buena idea: rubor:

El .3ds de 3DS Max está en la misma categoría que el .blend de Blender o el .mlt de Maya o el .c4d de Cinema4D.

Esto puede no ser del todo cierto, .max se parece más a la misma categoría, .3ds está bastante simplificado.

Me gustó tener el exportador 3ds max como ejemplo de cómo escribir un exportador, y también en maxscript. No creo que alguna vez pude exportar el espacio de tangente correcto desde 3ds max a través de fbx, con maxscript es fácil experimentar y tomar las cosas que necesita.

¿Vale la pena poner en un nuevo repositorio, con las renuncias de responsabilidad adecuadas? Todo por ejemplos de cómo escribir un exportador, pero si no se le da mantenimiento y FBXLoader ahora es más confiable, no queremos que la gente asuma que es la forma recomendada de convertir activos de 3DS Max en three.js.

Sí, en todo caso, voto por un nuevo repositorio.

Solo quería agregar antes de abandonar por completo el formato json: estamos usando el exportador de Blender para exportar escenas, es decir, configurando la jerarquía de cámaras y escenas con animaciones y propiedades personalizadas junto con objetos de marcador de posición, que luego se reemplazan dinámicamente en tiempo de ejecución por mallas reales (cargadas De otras maneras). Como esto es 'solo' json, es muy fácil introspectar y modificar en js y hacer este tipo de cosas. No estoy seguro, por ejemplo, glTF (al menos en su forma actual) se ajusta bien como formato de escena, por lo que espero que el exportador de Blender y el formato json se queden un poco más tiempo

@pjoe Espero que sea más probable que el formato JSON y el exportador de Blender se queden en el corto plazo que otras cosas mencionadas en este hilo (por ejemplo, exportadores 3DS Max + Maya).

Pero de todos modos, sería bueno recibir sus comentarios sobre glTF y el exportador de Blender . Todo lo que mencionaste es compatible:

• configurar la cámara
• jerarquía de escenas
• animaciones (para múltiples acciones de Blender, necesitará un exportador diferente )
• propiedades personalizadas (seleccione "Exportar extras" en las opciones)
• "solo JSON" para los materiales, metadatos, etc. Los datos de malla se optimizan como una carga útil binaria separada

@donmccurdy debe admitir que no tengo mucha experiencia con glTF (al menos todavía), aunque intenté leer la especificación :)

Supongo que mi principal 'carne de res' con glTF (que creo que es un gran formato de transporte y también excelente para obtener 'los bytes' tan rápida y directamente como sea posible en los búferes de GPU) es que todas las referencias se basan en índices, lo cual no es bueno apto para un formato de escena mutable. Entonces, si, por ejemplo, desea eliminar entradas o agregar cosas en el medio, debe actualizar todas las referencias a índices después de ese lugar. Hacer esta 'gestión de índices' rápidamente se vuelve bastante complicado en mi opinión.

Desde el breve tiempo que pasé con el exportador de blender glTF, también parecía bastante inmaduro en ese momento (hace unos dos meses). Eso obviamente se puede rectificar ayudando a mejorarlo :)

... todas las referencias se basan en índices, lo que no es una buena opción para un formato de escena mutable. Entonces, si, por ejemplo, desea eliminar entradas o agregar cosas en el medio, debe actualizar todas las referencias a índices después de ese lugar.

Sí, no está diseñado para ediciones manuales en ese sentido y, como formato de tiempo de ejecución / transmisión, probablemente nunca lo estará. Hay varias bibliotecas para trabajar con él que podrían ayudar.

En general, he encontrado que el exportador glTF Blender ofrece mejores resultados que cualquier otra salida de Blender, pero por favor, registre los errores si ha encontrado problemas particulares. :)

@donmccurdy acordó que glTF se mantiene fiel a ser para transporte / tiempo de ejecución ... una de las mejores cosas de esto, es exactamente que no está tratando de adaptarse a todos los formatos (como collada, no me hagas empezar).

Estamos tratando de evitar bibliotecas adicionales o gastos generales de conversión, ya que estamos haciendo una aplicación web que debe ser pequeña y rápida, y hasta ahora el formato JSON three.js ha sido una buena opción como formato de escena para este caso de uso. Ser capaz de configurar toda la escena en Blender, por ejemplo, con la animación de la cámara, solo exportar, cargar y en tiempo de ejecución reemplazar modelos dinámicamente (para lo que probablemente terminaremos usando glTF en algún momento pronto), todo esto lo convierte en una canalización razonablemente fluida para nosotros :)

Como nota al margen, también usamos el cargador json del paquete web para incluir el archivo de escena en nuestro paquete principal, lo que hace que sea aún más fácil de manejar.

No creo que cambie mucho con respecto al exportador Maya en ese momento. Probablemente deberíamos evaluar eso ahora. Lo probaré y veré si vale la pena conservarlo durante los próximos días.

@looeee Tengo curiosidad, ¿tienes alguna noticia sobre esto 😊? ¿Crees que podemos eliminar el exportador ahora y hacer referencia a FBX lugar?

¿Crees que podemos eliminar el exportador ahora y hacer referencia a FBX en su lugar?

Solo hice una pequeña cantidad de pruebas, planeé hacer más, pero no he tenido tiempo. Pero diría que sí, deberíamos eliminarlo y trabajar para que FBXLoader sea totalmente compatible con Maya.

Participar como usuario del exportador de Blender aquí: una ventaja de tener JSON es que es extremadamente simple de modificar después de la exportación. Blender es solo una parte de nuestra cadena de herramientas automatizada, y procesamos mucho el JSON exportado, antes de que esté listo para ir a nuestro visor web. Tener un formato de transferencia tan cercano al formato interno de threejs es una gran ventaja para nosotros.

Además, hemos hecho algunas pruebas con otros formatos de exportación, y hemos descubierto que el formato JSON no es tan malo en términos de tamaño de transferencia, una vez comprimido decentemente, mucho mejor que Collada o FBX, por ejemplo. Hicimos una prueba rápida basada en protobuffers, y podríamos ir un poco más pequeños de esa manera, pero nada que valiera la pena para nosotros.

Para escenas grandes y clientes lentos, la velocidad de análisis y conversión al modelo interno de ThreeJS también se vuelve importante. Dado que el análisis de JSON está muy optimizado en los navegadores, y dado que la estructura del modelo es muy similar, hemos asumido que el formato JSON funcionaría bastante bien en este sentido. En realidad, no he probado esto.

Soft8Soft acaba de lanzar el exportador basado en glTF para 3ds Max . Por lo tanto, podría ser una buena alternativa al exportador JSON eliminado.

Gracias @alexkowel , genial ver eso (¡y felicidades!). Si pudiera agregar un enlace en este hilo , lo listaremos con otros recursos glTF. 🙂

@dherben buenos puntos, gracias -

Acerca de la velocidad de análisis, espero que descubra que glTF es aún más rápido. Básicamente, la diferencia es que los metadatos siguen siendo "solo JSON", mientras que las grandes partes de la carga útil (posiciones de vértice, datos de animación) están en un fragmento de ArrayBuffer que se puede utilizar para crear una matriz con tipo para constructores THREE.BufferAttribute . En un cargador totalmente optimizado (no sé si THREE.GLTFLoader todavía está allí), nunca tienes que leer o copiar esos datos en JS.

Pero para las modificaciones a los datos como parte de una canalización, estoy de acuerdo en que es más fácil trabajar con JSON simple, como dijiste. Hay bibliotecas en varios idiomas para trabajar con glTF, pero las herramientas aún no están muy desarrolladas.

Estado actual de este problema:

Exportadores:

• [X] Exportador maya
• [X] Exportador de 3DS Max
• [X] Exportador de licuadoras
  
  
  
  • no va a ninguna parte en este momento, puede volver a visitarlo en el futuro.
  
  
  • Eliminado en mayo de 2018.
  
  

Convertidores:

• [] FBX
  
  
  
  • reemplazo simplificado propuesto como https://github.com/mrdoob/three.js/pull/13013; necesita pruebas
  
  
• [] CTM (no discutido)
• [] utf8 (no discutido)
• [] obj2three (no discutido)

EDITAR: Actualizado en mayo de 2018.

@donmccurdy Solo quería volver después de experimentar más con glTF Blender exporter y Three.js loader. Resulta que en realidad está funcionando bastante bien como formato de escena para nuestro caso de uso hasta ahora. Lo que estoy haciendo ahora es cargar el archivo glTF exportado a una escena Three.js y luego manipular la jerarquía de la escena Three.js (intercambiando marcadores de posición con elementos cargados dinámicamente) antes de hacer el primer render.

Probablemente todavía hay algunas características que me gustaría ver en el exportador glTF, intentaré comentar o hacer relaciones públicas allí :)

Probablemente todavía hay algunas características que me gustaría ver en el exportador glTF, intentaré comentar o hacer relaciones públicas allí :)

¡Impresionante, por favor hazlo! 🙂

El exportador de Blender no va a ninguna parte en este momento, puede volver a visitarlo en el futuro.

Entonces, ¿alguien va a estar trabajando en los errores actuales del exportador de Blender? Espero que la respuesta sea no. En ese caso, deberíamos decirlo.

Si nadie más lo hace antes que yo ... Me gustaría, al menos, intentar resolver los problemas de rotación. N.º 13130

Entonces, ¿alguien va a estar trabajando en los errores actuales del exportador de Blender? Espero que la respuesta sea no.

No leí toda la discusión, sino mis dos centavos.

La semana pasada me pidieron que ayudara a una empresa que tiene una solución que usa Three.js en la entrega de contenido dentro de la exhibición permanente. Señalizaciones con modelos 3D que los usuarios pueden explorar e interactuar. Los desarrolladores originales que se han ido hace mucho tiempo han utilizado el formato JSON Three.js . Preparar y obtener nuevos modelos (con la condición de que no se cambie el código de tiempo de ejecución) es una verdadera pesadilla.

En mi humilde opinión, Three.js debería centrarse en admitir formatos establecidos y de rápido crecimiento como FBX y glTF . Prioridad en aquellos formatos que pueden contener múltiples contenedores de datos UV (por lo tanto, NO se debe alentar al querido OBJ). Luego animación. Sé que el complemento de exportación de Blender supuestamente es compatible con ambos, pero también lo hace FBX.

Imagina el flujo de trabajo al que se destinan las cosas de Blender'ed

1) WebGL
Three.js obviamente 😃

2) OpenGL 3.3+
crudo / Cinder

3) OpenGL ES 2.0 en RISC
De smartphone a RaspberryPi

4) Motores de juego

5) Aplicaciones de gráficos en tiempo real que están integradas con servidores de medios (Hippo, disfraz D3)
Los que usan los chicos de efectos visuales de escenario.

En lugar de tener que usar muchos exportadores diferentes para diferentes salidas, el objetivo sería usar 1, máximo 2 formatos. Al escribir OGL en los primeros 3 casos ... se debe usar el mismo formato de modelo, eso es todo. En los dos últimos puntos, FBX es el rey (las diferentes implementaciones de COLLADA entre paquetes dificultan el trabajo) y, en realidad, el modelo no está "expuesto".
No estoy atacando el formato JSON Three.js o el complemento Blender ( @mrdoob 🙇 🙏), tiene (¿tuvo?) Su uso y probablemente se inventó para resolver problemas que otros formatos no podían en ese momento en primer lugar (y yo sí también tienen síndrome NIHS).
Solo quiero compartir eso desde la perspectiva en la que uno tiene que entregar constantemente a diferentes resultados dentro de la industria El formato JSON Three.js no encaja en el panorama, es superfluo.

@kroko definitivamente de acuerdo 👍

Creo que el panorama de los formatos está empezando a ser más claro. El formato three.js json se realizó porque no había formato json en ese momento. Definir un formato de archivo era lo último que quería hacer cuando ya estaba haciendo un motor de renderizado y una API 😩

Como novato, Three.js JSON exporter fue muy educativo porque me permitió ver los datos sin procesar y la estructura subyacente de las geometrías de salida. Otros exportadores, por muy eficientes que sean, no le permiten ver los datos porque en su mayoría están en formato binario.

Estoy de acuerdo en que eliminarlo de este repositorio sería la mejor opción hoy, pero como dijo @hccampos , tal vez podría colocarse en su propio repositorio para que permanezca con fines educativos.

Estoy de acuerdo en que eliminarlo de este repositorio sería la mejor opción hoy, pero como dijo @hccampos , tal vez podría colocarse en su propio repositorio para que permanezca con fines educativos.

Siempre existirá la opción de exportar como JSON desde http://threejs.org/editor/

Cerrado en https://github.com/mrdoob/three.js/pull/14117.

Sugiero que cerremos ahora todos los problemas abiertos relacionados con el exportador de Blender. ¿Acordado?

Creo que alguien puede escribir alguna documentación / canalización "oficial" para la exportación / importación de modelos 3D (para características básicas y especiales), solucionar problemas comunes y eliminar o actualizar todos los documentos y ejemplos obsoletos. Por ejemplo, el ejemplo del caballero es muy confuso, dado que ya no tiene un exportador json de blender. Tal vez JSONLoader para modelos 3d debería mantenerse solo para retrocompatibilidad, pero tenemos que leer eso, etc.

@stmaccarelli, hay documentación nueva aquí: https://threejs.org/docs/#manual/introduction/Loading -3D-models, pero sí, ¡háganos saber qué más sería útil!

@donmccurdy Creo que el papel es pobre.
En este momento, todo el sistema de importación / animación en 3D, dada la combinación de documentación, ejemplos y cosas que se encuentran en Internet de diferentes épocas, es confuso.

El documento maestro del Sistema de animación estaría bien si las referencias de los objetos individuales fueran correctas.
Tomemos la referencia de AnimationClip. No estoy seguro de estar exportando morphTargets de la manera correcta, pero aquí leo:

_.CreateClipsFromMorphTargetSequences (nombre: String, morphTargetSequence: Array, fps: Number, noLoop: Boolean): Array
Devuelve una matriz de nuevos AnimationClips creados a partir de las secuencias de meta de transformación de una geometría, tratando de ordenar los nombres de meta de transformación en patrones basados ​​en grupos de animación como "Walk_001, Walk_002, Run_001, Run_002 ..." _

El problema es que si importo un archivo glTF, no hay una matriz morphTargetSequence ... hay algunos objetos morphTargetSomething almacenados aquí y allá, pero no sé qué y cómo usar.

Creo que deberíamos tener algunos documentos que describan la administración / flujos de trabajo de modelos 3D con ejemplos muy simples.
Y las referencias de los cargadores 3D deben respetar la misma plantilla.
Digamos
1- importación simple de modelos 3D
2- importación de material (s) (con todas las campanas y silbatos como los diferentes mapas, mapas params, manejo multimaterial, etc)
3- importación de escenas completas (por ejemplo, cómo recorrer / administrar escenas importadas como las de glTF)
4- importación y gestión de animaciones esqueléticas
5- importación y gestión de animaciones morph

También debemos comprobar que todos los ejemplos que presentan la carga del modelo 3D, respetan el mismo patrón.

Deberíamos actualizar los ejemplos, y aunque no sea posible, deberíamos escribir claramente que algunas partes están obsoletas y qué (como en el ejemplo del caballero ...)

_EG- si decidimos que el formato de archivo JSON para el modelo 3D debería ser obsoleto, a favor de, digamos, glTF, no tiene sentido que el único ejemplo de animación que presenta tanto animación esquelética como morphtargets sea el antiguo caballero, que usa un Modelo JSON de hace 10 versiones, que almacena una estructura de datos que ya no se usa.

@stmaccarelli No existe un único flujo de trabajo de un extremo a otro recomendado; Creo que sería difícil proporcionar eso dados los diferentes niveles de habilidad, preferencias por herramientas de modelado gratuitas o de pago y necesidades particulares.

No creo que normalmente necesites ese método CreateClipsFromMorphTargetSequences . El documento anterior no entra en detalles sobre el uso de ningún cargador en particular (como mencionas, son inconsistentes), pero los documentos GLTFLoader sí lo hacen:

loader.load('foo.glb', function(gltf) {
  const clips = gltf.clips;  // Array<THREE.AnimationClip>
  const model = gltf.scene; // THREE.Scene
  ...
});

En este caso, no importa si los clips son TRS, de piel o de metamorfosis; puede reproducir todas las animaciones por igual. Escribí un posible flujo de trabajo usando Mixamo y Blender . Aquí hay otro que usa Maya .

También debemos comprobar que todos los ejemplos que presentan la carga del modelo 3D, respetan el mismo patrón.

Y las referencias de los cargadores 3D deben respetar la misma plantilla.

Este es un punto justo y tenemos espacio para mejorar aquí.

No tiene sentido que el único ejemplo de animación que presenta tanto animación esquelética como morphtargets sea el antiguo caballero, que usa un modelo JSON de hace 10 versiones, que almacena una estructura de datos que ya no se usa.

Estrictamente hablando, el formato JSON y la estructura de datos no están en desuso, y sigue siendo una forma totalmente razonable de [de] serializar una escena, pero se toma el punto. @mrdoob ¿qué opinas de que reemplacemos algunos de los ejemplos de animación? Tal como:

animation / keyframes / json
animation / scene
animation / skinning / blending
animation / skinning / morph

¿Qué opinas de que reemplacemos algunos de los ejemplos de animación?

+1 para esto. Voto por reemplazar al menos al soldado de animation / skinning / blending a con un modelo más moderno de Mixamo, como este:

Podríamos combinar entre inactivo / caminar / correr, y probablemente sería posible convertir el modelo a glTF si se prefiere.

El tamaño del modelo sería de alrededor de 9 MB, mientras que el modelo actual junto con todos los archivos asociados es de 71 MB.

Por animation / skinning / morph podríamos usar el modelo con el que he estado probando objetivos de transformación FBX:

Tiene aproximadamente el mismo tamaño que el modelo de caballero actual, pero dado que los objetivos de transformación se usan más comúnmente para las expresiones faciales, diría que este tiene más sentido. Nuevamente, actualmente está en formato FBX, pero podría convertirse a glTF si se prefiere.

A continuación, se muestran algunos ejemplos a tener en cuenta:

| captura de pantalla | enlace | tamaño |
| --- | --- | - |
| | enlace | 6 MB |
| | enlace | 3 MB |
| | enlace | 5 MB |
| | enlace | 12 MB |

Todos están animados, funcionan correctamente en three.js y probablemente podrían comprimirse u optimizarse un poco más que la versión de descarga de Sketchfab. No tengo un personaje manipulado con buenos ciclos de correr / caminar, pero el flujo de trabajo Mixamo-> glTF no es tan malo.