¡Lista muy extensa!
También propongo el cargador AMF (http://en.wikipedia.org/wiki/Additive_Manufacturing_File_Format).
(formato de archivo 3D utilizado para la impresión 3D).
Ya tengo hecho lo básico del cargador, así que podría modificarlo un poco y agregar a los ejemplos.

La mayoría de estos cargadores son más importantes para casos especiales, como un editor, porque para, digamos, juegos, sería mejor convertirlos al formato three.js de inmediato, ¿verdad? En estos casos los convertidores/exportadores son más importantes.

Probamos glTF como un reemplazo para los formatos de tres como una optimización: allí los datos son binarios y se pueden comprimir con compresión geom.

Herst [email protected] kirjoitti 28 de octubre de 2014 kello 5:38 p. m.:

La mayoría de estos cargadores son más importantes para casos especiales, como un editor, porque para, digamos, juegos, sería mejor convertirlos al formato three.js de inmediato, ¿verdad? En estos casos los convertidores/exportadores son más importantes.

—
Responda a este correo electrónico directamente o véalo en GitHub.

@kaosat-dev ¡Agregado a la lista!
@Herst Sí. Es principalmente para editores o aplicaciones que no requieren tiempos de carga rápidos.

También estoy buscando un cargador IGES. Incluso tal vez comenzaría a construir uno yo mismo, pero no estoy seguro de por dónde empezar.

¿Qué tal agregar 3DM (usado por Rhinoceros ) a la lista?

agregó @nyaaao . ¡Gracias!

Acerca del cargador 3DS:

Hola a todos, hace mucho tiempo, necesitaba hacer un cargador 3DS para el motor 3D Web 3DzzD, eso fue un poco difícil de hacer... no es difícil obtener algunos primeros resultados, sino manejar todos los fragmentos correctamente, pero después de algunas veces Me las arreglé para producir un cargador bastante eficiente. Las especificaciones del formato de archivo 3DS son difíciles de encontrar, pero terminé de encontrar una que funcionó bastante bien. Construí el cargador para 3DzzD con esta documentación y funciona incluso mejor que el del Photoshop actual (mejor manejo en pivote/grupos suaves/escala/fotograma clave/etc...), así que aquí están las especificaciones que he usado (El código fuente de 3DzzD es de código abierto y puede ayudar, pero el código es realmente feo... un proyecto de hace diez años...)

http://dzzd.net/3DSChunkDefinitions.html

Acerca del cargador OBJ:

Modifiqué el cargador OBJ actual y obtuve al menos 10/15 FPS más en muchos modelos 3D, pero por ahora no encontré cómo debo hacer para publicar estos cambios.

El problema se debió principalmente al hecho de que el cargador OBJ actual crea demasiados objetos (más que el modelo 3D original, un objeto creado en cada cambio de material) y también las 3dFaces con el mismo material no se agruparon incluso dentro del mismo objeto, y estaba produciendo demasiadas llamadas WebGL

http://dzzd.net/3DSChunkDefinitions.html

¡Gracias! Añadido al primer mensaje.

El problema se debió principalmente al hecho de que el cargador OBJ actual crea demasiados objetos (más que el modelo 3D original, un objeto creado en cada cambio de material) y también las 3dFaces con el mismo material no se agruparon incluso dentro del mismo objeto, y estaba produciendo demasiadas llamadas WebGL

¡Oh! Interesante. Sin embargo, te refieres al OBJMTLLoader . ¿Correcto?

¡Oh! Interesante. Sin embargo, te refieres al OBJMTLLoader. ¿Correcto?

Sí, para ser más precisos, el bloque "if (/^usemtl /.test(line))" crea un nuevo objeto/malla para cada cambio de material, esto termina con un rendimiento deficiente y una jerarquía de objetos incorrecta.

Publicaré un caso de prueba simple que muestra la diferencia entre el cargador actual y el modificado (la diferencia se nota principalmente en el dispositivo móvil)

Aquí está el caso de prueba para el cargador actual y el optimizado:

http://demo.dzzd.fr/tresjs/OBJMTLLoaderTest/

EDITAR:
Obtuve 10 FPS en GalaxyTab3 con el cargador actual y más de 60 FPS con el nuevo, la diferencia puede ser difícil de ver en dispositivos rápidos

PD: Si te preguntas de dónde viene el modelo 3D :)

¿Alguien sabe acerca de IGES. Realmente me vendría bien un cargador IGES. ¿Si alguien pudiera señalarme una dirección para comenzar a construir uno? O si hay uno por ahí en alguna parte. Noté que la gente en http://www.3dfile.io/ y algunos de los otros sitios de visualización 3D usan ThreeJS y permiten cargas IGES.

K3D.js (licencia MIT) tiene un analizador para OBJ, 3DS, MD2 y Collada. http://k3d.ivank.net. Ver #3843.

¿Qué hay de NIfTI para el médico?

@jugl ¿Tiene alguna información sobre el formato?

Realmente espero los modelos .m2, es una gran comunidad alrededor. Ofrecería mi ayuda con los archivos modelo, etc. Puede ponerse en contacto conmigo para ese caso en skype: deexone. Como sugerencia de un desarrollador de lib, http://bridge.net/ podría usarse para transformar su lib a js.

Hola, tengo un cargador BVH que analiza un archivo BVH y genera un TRES. Esqueleto y AnimationClip para facilitar su uso con el Mezclador:
https://github.com/herzig/BVHImporter
y el ejemplo de trabajo: http://herzig.github.io/BVHImporter/
Se prueba principalmente en los archivos CMU BVH y algunos otros.

¿Hay alguna guía sobre cómo debería verse la API del cargador?

@herzig Dulce! ¡Un BVHLoader sería increíble! Los cargadores básicamente tienen .load() y .parse() . Puede usar MD2Loader como referencia, pero me encantaría limpiar su código si hace una PR con lo que tiene ahora (también agradecería mucho un ejemplo + una animación de muestra).

Hola,
solo para sincronizar esta lista con el cargador de archivos en el repositorio...

3MFLoader no se encuentra en la lista pero ya está implementado.
BinaryLoader no se encuentra en la lista pero ya está implementado.
Falta DDSLoader en la lista pero ya está implementado.
FBXLoader no está marcado pero ya está implementado.
HDRCubeTextureLoader no se encuentra en la lista pero ya está implementado.
MD2Loader no está marcado pero ya está implementado.
NRRDLoader no está marcado pero ya está implementado.
PCDLLoader no se encuentra en la lista pero ya está implementado.
PlayCanvasLoader no se encuentra en la lista pero ya está implementado.
Falta RGBLLoader en la lista pero ya está implementado.
SVGLoader no está marcado pero ya está implementado.
TGALoader no se encuentra en la lista pero ya está implementado.
TTFLoader no se encuentra en la lista pero ya está implementado.

Siguiente:

ASCLoader debe agregarse a la lista y PR se enviará en unos días.
LASLoader debe agregarse a la lista y PR se enviará en unos días.
XYZLoader debe agregarse a la lista y PR se enviará en unos días.

Atentamente,
Tristán

solo para sincronizar esta lista con el cargador de archivos en el repositorio...

¡Actualizado!

OpenCTM podría ser una buena adición, ya que Autodesk lo está utilizando para sus
servicio de almacenamiento en la nube
https://en.m.wikipedia.org/wiki/OpenCTM

El domingo 13 de noviembre de 2016 a las 6:33 a. m. Mr.doob [email protected] escribió:

solo para sincronizar esta lista con el cargador de archivos en el repositorio...

¡Actualizado!

—
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/mrdoob/tres.js/issues/5524#issuecomment-260168120 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAkmxkkOn179ZJvqc8yScOoxnaDGzuH6ks5q9qE6gaJpZM4CzpFw
.

@dlabz Ya tenemos CTMLoader .

Estoy trabajando con algunos desarrolladores de iOS en el espacio AR, ¿podría haber un cargador para los archivos binarios SCN utilizados por Apple en ARKit? Estoy trabajando para hacer uso de BinaryLoader y veremos si puedo hacerlo funcionar.

¿Hay alguna especificación en alguna parte para ese formato SCN ?

@mrdoob Lo siento, llegué tan tarde. NIfTI es un formato de datos de RMN que se transfiere desde DICOM. Mi solución actual es obtener una forma 3D como formato VTK/OBJ.

Veo. ¿Hay alguna especificación en alguna parte?

¿Qué hay del cargador IFC? Este formato se está usando muy común en la construcción para su modelo 3d.

@YouYue123 https://github.com/mrdoob/three.js/issues/9764

@mrdoob Muchas gracias.

@mrdoob ¿cuáles son las pautas + requisitos previos de conocimiento para construir un cargador de tres.js?
Quiero construir uno, pero quiero estar seguro de hacerlo de la manera correcta. Gracias

@Aarbel , ¿para qué formato desea construir un cargador?

Archivos @looeee .ifc

La estructura básica de su cargador se vería así:

import {
    FileLoader,
    Loader,
    LoaderUtils
} from '../../../build/three.module.js';

function IFCLoader( manager ) {

    Loader.call( this, manager );

}

IFCLoader.prototype = Object.assign( Object.create( Loader.prototype ), {

    constructor: IFCLoader,

    load: function ( url, onLoad, onProgress, onError ) {

        var scope = this;

        var path = ( this.path !== undefined ) ? this.path : LoaderUtils.extractUrlBase( url );

        var loader = new FileLoader( scope.manager );

        loader.load( url, function ( text ) {

            try {

                scope.parse( text, path, onLoad, onError );

            } catch ( e ) {

                if ( onError !== undefined ) {

                    onError( e );

                } else {

                    throw e;

                }

            }

        }, onProgress, onError );

    },

    parse: function ( text, path, onLoad, onError ) {

        // parsing logic goes here

    }

} );

Gracias, trabajaré en ello el próximo mes.

¡Buena suerte! 😊

¿Debería ser crossOrigin Anonymous ?

He reutilizado el patrón de GLTFLoader y ColladaLoader .

Me gustaría ver un cargador LWO.
La especificación del archivo está bien documentada aquí: http://static.lightwave3d.com/sdk/2018/html/filefmts/lwo3.html

A menudo veo un tamaño de archivo LWO de alrededor de 1/10 del de OBJ, y el formato puede contener datos de transformación y una serie de otras características que OBJ no permite. Además, muchos de los modelos que la NASA pone a disposición solo están en formato LWO https://nasa3d.arc.nasa.gov/search/lwo/model

Si supiera lo que estoy haciendo, intentaría ponerlo en marcha, pero escribir un cargador está más allá de todo lo que he hecho antes.

FWIW hay un analizador LWO aquí: https ://github.com/marcbizal/lwo-parser... hipotéticamente sería un buen comienzo para un cargador o un convertidor, pero desafortunadamente no parece ser compatible con la versión particular del formato LWO que utiliza la NASA. Espera LWOB (¿binario?) pero la cadena de versión mágica en el modelo de la NASA que probé era LWO2. Si encuentra un analizador en funcionamiento escrito en un idioma que no sea JS, puede ser más fácil escribir un convertidor a algo compatible con three.js, en lugar de intentar escribir un nuevo analizador en JS.

Hola, mi horario cambió mucho, así que no tengo tiempo para trabajar en el cargador .ifc para three.js. Podría ser genial obtener el contacto de este tipo: https://github.com/mrdoob/three.js/issues/9764

lo siento no me di cuenta

Estaba haciendo un cargador de "LWO 2". Sin embargo, pensé que no había demanda y no lo completé.

http://adrs2002.com/sandbox/lwoLoader/lwoTest.html
https://github.com/adrs2002/tresLwoLoader

Espero que sea útil para algo.

Hola todos,

Vi que M2 está en la lista.

Esto es interesante para mí porque me gustaría realizar un visor de personajes, objetos, NPC y elementos con Three.

En relación con M2 es también BLP2 (Blizzard Picture File) que similar a la compresión de textura DDS S3 utilizado.

He encontrado hasta ahora:

.m2 = https://github.com/vjeux/jsWoWModelViewer

.blp

• https://wowdev.wiki/BLP
• http://wowwiki.wikia.com/wiki/BLP_file
• https://github.com/Kruithne/js-blp
• https://en.wikipedia.org/wiki/S3_Texture_Compression

Yo mismo trato de agregarlo, pero todavía soy un poco inexperto con todo: D

@adrs2002 ¡ Un LWOLoader sería genial! ¿Te gustaría hacer un PR con lo que tienes?

Yo mismo trato de agregarlo, pero todavía soy un poco inexperto con todo: D

Tómate tu tiempo 👌

¡Un LWOLoader sería genial!

Escribí un cargador LWO3 hace un par de meses, trabajando para onthez.com.
Acordamos un período de exclusividad y luego lo aportamos aquí. Con suerte, en algún momento a finales de febrero.

Creo que @jds580s es Justin de on the z, tal vez pueda dar una mejor idea de cuándo podemos agregarlo aquí.

@mrdoob @looeee
Creo que la confirmación de LWO2 loader es innecesaria si se confirmará el LWO3 loader de looeee.
El formato LWO3 se debe a que contiene todos los éxitos del formato LWO2.

¡LWOLoader ha aterrizado! 😁

16011

¿Alguna actualización sobre el cargador IFC? ¡Sería bueno para las vistas de la construcción!

Probé un IFCLoader y cómo decir... ¡Esto es bastante imposible! El código completo requerido para poder analizar correctamente el formato IFC es de alrededor de 650 archivos de clase. (Lo sé porque yo lo hice). El cargador será 5 veces más grande que la biblioteca Threejs.

Acerca de las especificaciones si desea implementar las suyas propias: http://standards.buildingsmart.org/IFC/RELEASE/IFC4_1/FINAL/HTML/

Podría liberar mi código, y un poco de ayuda sería genial. Pero no esperes ver este cargador en ThreeJs antes de un tiempo...

Podría liberar mi código, y un poco de ayuda sería genial. Pero no esperes ver este cargador en ThreeJs antes de un tiempo...

¿Por qué no?

Por cierto: últimamente hablé con un colega y me dijo que IFC se basa en el formato STEP, que es muy conocido en la comunidad CAD. En general, STEP es realmente difícil de analizar y necesitaría escribir un analizador personalizado similar a VRMLLoader . Sin embargo, los archivos IFC también se pueden expresar en XML (tienen la extensión .ifcxml ). Dichos archivos serían mucho más fáciles de manejar (consulte 3MFLoader o ColladaLoader ) para que el cargador pueda concentrarse en la creación de datos de geometría real. ¿Tal vez sea más fácil crear un cargador que solo admita .ifcxml al principio?

@mrdoob , @Mugen87

¿Por qué no?

Porque

El cargador será 5 veces más grande que la biblioteca Threejs.

y uso Class con las últimas características de javascript.

IFC se basa en el formato STEP, muy conocido en la comunidad CAD.

Sí, algún día te mostraré lo que estoy haciendo con Threejs;)

Los archivos IFC también se pueden expresar en XML (tienen la extensión .ifcxml).
...
¿Tal vez sea más fácil crear un cargador que solo admita .ifcxml al principio?

El análisis claramente no es un gran problema. ¡Pero la generación de geometrías es! Porque el formato ifc no contiene ninguna geometría. Pero use la interpolación/interacción entre objetos para determinar la geometría final.

De todos modos, si lo deseas, tal vez deberías crear una rama específica para esto antes de tomar cualquier decisión. Solo para ver lo GRANDE.

El cargador será 5 veces más grande que la biblioteca Threejs.

Bueno, sí, si el cargador no es tan compacto como los demás, probablemente sea mejor poner el código en un repositorio separado.

@Itee ¿ Algún plan para lanzar IFCLOADER pronto?
Estaría interesado en ver la GRAN cosa

No se sabe de nadie dispuesto a aportarlo y mantenerlo...

Estoy felizmente usando el conversor IFC de IfcOpenShell, hace buena geometría y materiales, puede hacer Collada DAE (que usamos para importar a Unity), IIRC OBJ y también estaba allí glTF hoy en día.

Estoy felizmente usando el conversor IFC de IfcOpenShell, hace buena geometría y materiales, puede hacer Collada DAE (que usamos para importar a Unity), IIRC OBJ y también estaba allí glTF hoy en día.

Pero, ¿utiliza alguno de los datos de IFC como Buildingstorey, Site, etc.?
No hay duda de que la web sería mejor si pudiera analizar IFC y no esta mierda de cliente-servidor con la que todos están tratando.

Le he dado una oportunidad a esto recientemente. Me las he arreglado para generar algo de geometría.

Pero en realidad debería ser esto:

Lo básico que salió mal es la ubicación real y la rotación aquí y mis matemáticas 3D son casi inexistentes (simplemente no tengo paciencia).

Aunque hay muchas clases en el esquema IFC. El tamaño del archivo final podría reducirse mediante el uso de interfaces Typescript y el uso de funciones para buscar y aplicar los argumentos de cada 'PASO' en el archivo.

En resumen, para un cargador IFC; No sé si tenemos un genio de las matemáticas en 3D, porque eso resolvería muchos problemas al analizar las relaciones matemáticas mientras se construye la geometría.

Pero, ¿utiliza alguno de los datos de IFC como Buildingstorey, Site, etc.?

Sí, a través del servicio de conversión de Tridify, que también usa IfcOpenShell (también lo he usado localmente) para el geom. Me imagino que esos metadatos son lo que es fácil de analizar.

La generación de geometría es de hecho no trivial. Si quiere hacerlo en el navegador, tal vez pueda compilar IfcOpenShell en WebAssembly y usarlo como una biblioteca desde su Javascript. Es C ++ simple sin GUI ni nada, solo una biblioteca para la cual hay una interfaz de línea de comandos por separado, por lo que también podría ser fácil de construir para la web. El análisis de IFC es un poco pesado, por lo que podría ser bueno obtener el rendimiento de WASM y el bajo consumo de memoria. Y lib hace un hermoso trabajo al crear el geom.

@MaartenBreeedveld Puedo ayudar con las matemáticas, para la base teórica no tengo dudas y tengo algo de experiencia con ifc, de hecho, podría haber varias transformaciones en serie requeridas para las coordenadas mundiales. Para la implementación en three.js quizás sea posible optimizarlo.

Pero, ¿utiliza alguno de los datos de IFC como Buildingstorey, Site, etc.?

Sí, a través del servicio de conversión de Tridify, que también usa IfcOpenShell (también lo he usado localmente) para el geom. Me imagino que esos metadatos son lo que es fácil de analizar.

La generación de geometría es de hecho no trivial. Si quiere hacerlo en el navegador, tal vez pueda compilar IfcOpenShell en WebAssembly y usarlo como una biblioteca desde su Javascript. Es C ++ simple sin GUI ni nada, solo una biblioteca para la cual hay una interfaz de línea de comandos por separado, por lo que también podría ser fácil de construir para la web. El análisis de IFC es un poco pesado, por lo que podría ser bueno obtener el rendimiento de WASM y el bajo consumo de memoria. Y lib hace un hermoso trabajo al crear el geom.

Hemos intentado esto en el pasado. Pero la versión compilada de WASM es una descarga de 40 MB. Supongo que esto se debe a todas las bibliotecas a las que se hace referencia en ifcConvert.

@Jesusbill , ¡Impresionante! Actualmente, no tengo tiempo para trabajar en este proyecto. Pero si está bien, volveré contigo.

¡Impresionante! Actualmente, no tengo tiempo para trabajar en este proyecto. Pero si está bien, volveré contigo.

Suena bien @MaartenBreeedveld

Se agregó VDBLoader a la lista. https://www.openvdb.org/

¿Alguna idea sobre IFCLOADER? @mrdoob

no

Con respecto a un cargador 3dm: comencé a trabajar en esto ahora que la biblioteca openNURBS se compiló en wasm gracias a emscripten ( rhino3dm ).

Estoy trabajando en esto aquí y he comenzado y funcionando el soporte de malla, breps, extrusiones, nubes de puntos, materiales, capas y grupos.

Archivos Relevantes:

• cargador
• Biblioteca
• ejemplo html
• archivo de ejemplo

Espero enviar un PR que admita más tipos de objetos en algún momento _pronto_. Debo admitir que tengo poca experiencia con trabajadores web y me estoy apoyando en los ejemplos de draco y cargador base . Esperemos que #18234 simplifique esto un poco.

ps, ya estamos agregando compatibilidad con threejs directamente a la biblioteca rhino3dm.js como aquí y aquí .

Editar: actualizar los enlaces para que apunten a la bifurcación de la organización McNeel.

Podemos comprobar esto;)