Actualizado el 13 de septiembre de 2026
Qué conserva una conversión 3D y cuánto cuesta
Convertir una malla no sale gratis ni es una operación sin pérdidas. GLB y glTF lo conservan todo. OBJ conserva los objetos separados y sus nombres de material, pero descarta el color por vértice. STL conserva solo los triángulos. PLY conserva el color por vértice, pero aplana la escena en una sola malla. USDZ conservó los dos objetos y las UV, perdió el color por vértice y los nombres de material al releerlo, y escribe un zip de USDA. Las cifras de abajo se midieron, no se estimaron.
Cada cifra de esta página sale de ejecutar el mismo conversor que usa este sitio, con archivos reales, y de leer los atributos directamente de los bytes que escribió. Medido el 13 de septiembre de 2026 con three.js r179. El método está al final de la página y el script está en el repositorio.
¿Qué conserva cada formato?#
Una escena de referencia con dos cubos con nombres distintos, cada uno con su propio material metálico con nombre, color por vértice, coordenadas UV y normales, se convirtió a los seis destinos. GLB y glTF volvieron completos. Todos los demás formatos perdieron algo, y cada uno perdió algo distinto.
| Destino | Dos objetos | Coordenadas UV | Color por vértice | Nombres de material | Número de vértices |
|---|---|---|---|---|---|
| GLB | Se conservan los 2 | Se conserva | Se conserva | Se conserva | 48 vértices |
| glTF | Se conservan los 2 | Se conserva | Se conserva | Se conserva | 48 vértices |
| OBJ | Se conservan los 2 | Se conserva | Se pierde | Se conserva | 72 vértices |
| STL | Fusionados en 1 | Se pierde | Se pierde | Se pierde | 72 vértices |
| PLY | Fusionados en 1 | Se conserva | Se conserva | Se pierde | 48 vértices |
| USDZ | Se conservan los 2 | Se conserva | Se pierde | Se pierde | 72 vértices |
¿Por qué STL y PLY fusionan una escena en una sola malla?#
Ninguno de los dos formatos tiene grafo de escena. GLB, glTF y OBJ pueden describir varios objetos con nombre en un mismo archivo; STL describe un único sólido y PLY una única lista de elementos, así que los dos cubos llegan como una sola malla y no hay forma de volver a separarlos.
Es la pérdida que más sorprende, porque no se ve. El modelo convertido se ve idéntico en un visor. Solo cuando intentas seleccionar, cambiar el material o animar una de sus partes descubres que las partes ya no existen.
Si el modelo tiene que seguir siendo separable, el destino tiene que ser GLB, glTF u OBJ. Si va a un laminador o a una impresión de un solo material, la fusión no te cuesta nada.
¿Cuánto crece el archivo?#
Más de lo que la mayoría espera. En una malla generada real, el OBJ ocupó 5,6 veces lo que el GLB de origen, y el PLY 1,4 veces. Los dos llevan la misma geometría.
| Conversión | Origen | Resultado | Proporción | Vértices escritos |
|---|---|---|---|---|
| mug.glb a GLB | 880 KB | 1173 KB | 1,3x | 25.000 |
| mug.glb a glTF | 880 KB | 1564 KB | 1,8x | 25.000 |
| mug.glb a OBJ | 880 KB | 4928 KB | 5,6x | 150.000 |
| mug.glb a STL | 880 KB | 2441 KB | 2,8x | 150.000 |
| mug.glb a PLY | 880 KB | 1221 KB | 1,4x | 25.000 |
| mug.glb a USDZ | 880 KB | 2927 KB | 3,3x | 150.000 |
| lion.glb a GLB | 8768 KB | 11.690 KB | 1,3x | 249.369 |
| lion.glb a glTF | 8768 KB | 15.587 KB | 1,8x | 249.369 |
| lion.glb a OBJ | 8768 KB | 51.880 KB | 5,9x | 1.496.202 |
| lion.glb a STL | 8768 KB | 24.352 KB | 2,8x | 1.496.202 |
| lion.glb a PLY | 8768 KB | 12.176 KB | 1,4x | 249.369 |
| lion.glb a USDZ | 8768 KB | 30.487 KB | 3,5x | 1.496.202 |
¿Por qué OBJ y STL multiplican el número de vértices?#
Porque ninguno de los dos comparte vértices entre triángulos. Una malla bien indexada guarda cada esquina una sola vez y la referencia desde todos los triángulos que la tocan; OBJ y STL, tal como se escriben aquí, guardan por separado las tres esquinas de cada triángulo. En la prueba con lion.glb, eso convirtió 249.369 vértices en 1.496.202, unas 6 veces más.
La geometría no cambia. La misma superficie, los mismos triángulos, la misma silueta; solo la contabilidad sale más cara, y el archivo crece más o menos en la misma proporción.
PLY es el contraejemplo útil. Mantiene el índice, así que la misma malla se escribe con un tamaño cercano al del origen y sigue llevando el color por vértice. Para una malla grande en la que solo hay que conservar la geometría, PLY es el destino honesto más barato de esta lista.
El texto frente al binario lo agrava. glTF es JSON con los búferes codificados en base64, lo que cuesta alrededor de un 33 por ciento más que el GLB idéntico, porque base64 convierte cada tres bytes en cuatro.
¿Por qué creció el archivo incluso al convertir de GLB a GLB?#
Porque el conversor calcula las normales de vértice de cualquier malla que llega sin ellas y después las escribe. Una malla generada a menudo no tiene ningún atributo de normales, así que el viaje de ida y vuelta añade un vector completo más por vértice.
La prueba con mug.glb es un ejemplo claro: entran 880 KB y salen 1173 KB, sin ningún cambio en la geometría. Las normales añadidas son la diferencia.
Es una decisión deliberada, no un defecto. Una malla sin normales se ve con sombreado plano y facetada en la mayoría de los visores, así que el conversor las calcula una vez al cargarla en lugar de dejar que cada herramienta posterior tenga que adivinarlas.
¿La conversión cambia la forma?#
No. Cada destino se convirtió y después se volvió a leer, y la superficie salió idéntica: el mismo número de triángulos y la misma área de superficie total, hasta el límite de la medición, en una malla de 498.734 triángulos. La geometría es la parte de un archivo 3D que sobrevive intacta a la conversión.
| Destino | Triángulos después | Error de área de superficie | Cómo se guardan las coordenadas |
|---|---|---|---|
| GLB | sin cambios | 0% | float32 binario |
| glTF | sin cambios | 0% | búfer en base64 |
| OBJ | sin cambios | 0% | texto con 17 decimales |
| STL | sin cambios | 0% | float32 binario |
| PLY | sin cambios | 0% | float32 binario |
| USDZ | sin cambios | 0% | zip de USDA |
Entonces, ¿la conversión 3D tiene pérdidas o no?#
Las dos cosas, y la distinción es lo útil. La geometría no pierde nada: la forma que entra es la forma que sale. Todo lo que envuelve a la geometría sí se pierde, y qué partes pierdes depende por completo del destino que elegiste.
Aquí nada trunca las coordenadas. GLB, STL y PLY escriben floats binarios de 32 bits. glTF incrusta el mismo búfer binario como base64 dentro de su JSON. USDZ escribe un zip de USDA. OBJ es el único que escribe las posiciones como texto decimal, y las escribe con precisión completa en lugar de redondearlas, que es parte de la razón por la que sus archivos son mucho más grandes.
Eso significa que la preocupación habitual, que cada conversión degrada un poco el modelo, como volver a guardar un JPEG, no se aplica. Convertir de GLB a OBJ y volver no suaviza la malla.
Lo que sí hace es descartar lo que aparece más arriba en esta página: el grafo de escena en STL y PLY, el color por vértice en OBJ, STL y USDZ, los nombres de material en STL, PLY y USDZ, y las UV en STL. Esas pérdidas son permanentes, en el sentido de que volver a convertir no puede inventarlas de nuevo.
¿Qué destino deberías elegir?#
Elige el destino según lo que tiene que sobrevivir, no según la extensión que la herramienta receptora pone primero en su lista. Estas son las elecciones defendibles a partir de lo que se midió arriba.
| Si necesitas | Elige | Por qué |
|---|---|---|
| Todo conservado, en un solo archivo | GLB | El único destino que conservó juntos el grafo de escena, los nombres de material, las UV y el color por vértice, con el tamaño más pequeño de los formatos completos. |
| Todo conservado, legible por una persona | glTF | El mismo contenido que GLB, alrededor de un 33 por ciento más grande porque los búferes van en base64 dentro del JSON. |
| Objetos separados con nombre en un programa de escritorio | OBJ | Conservó los dos objetos y los dos nombres de material. Descarta el color por vértice y escribe el archivo más grande de los seis. |
| Impresión 3D | STL | Triángulos y nada más, que es todo lo que lee un laminador. El más pequeño de los destinos que no son glTF en una malla real. |
| Geometría y color por vértice, con poco peso | PLY | El único destino que no es glTF que conservó el color por vértice, y mantiene el índice, así que se queda cerca del tamaño del origen. |
| Quick Look de Apple / RA en iPhone | USDZ | Conservó los dos objetos y las UV en la escena de referencia. Perdió el color por vértice y los nombres de material al releerlo. Un zip de USDA que un teléfono puede abrir. |
Qué define estos formatos#
Las mediciones de arriba son nuestras; lo que cada formato puede llevar no lo decidimos nosotros. Estas son las especificaciones y las referencias de formato que lo deciden, para que lo que dice esta página se pueda comprobar en la fuente en lugar de creerlo sin más.
- Especificación de glTF 2.0The Khronos Group
Define el grafo de escena, los materiales y los accesores que llevan GLB y glTF, y explica por qué fueron los únicos destinos que sobrevivieron intactos aquí.
- Tipo de medio model/gltf-binaryIANA
El tipo registrado para GLB, el contenedor binario que se midió arriba.
- Tipo de medio model/stlIANA
STL tal como está registrado: triángulos y normales de cara, sin ningún campo para color, UV, materiales ni nombres de objeto.
- El formato de archivo Wavefront OBJPaul Bourke
La referencia de siempre para OBJ, que no tiene un campo propio para el color por vértice, lo que coincide con lo que descartó la conversión.
- El formato de archivo de polígonos PLYPaul Bourke
Documenta las propiedades por vértice, color incluido, que hacen de PLY el único destino que no es glTF que lo conserva aquí.
- Especificación del formato de archivo USDZPixar / OpenUSD
USDZ es un zip cuya primera entrada es la escena USDA. Ese es el paquete que este conversor escribe y lee.
Cómo se midió#
La medición ejecuta el producto, no una descripción de él. El script importa los mismos cargadores y exportadores que el conversor del navegador, con las mismas opciones, y está en el repositorio para que las cifras se puedan reproducir o discutir.
- Construir una escena de referencia con dos cubos con nombre, cada uno con un material metálico con nombre, color por vértice, coordenadas UV y normales.
- Cargar mallas generadas reales de la misma forma en que el conversor carga el archivo que le das, incluido el paso que calcula las normales de vértice cuando una malla llega sin ellas.
- Exportar a GLB, glTF, OBJ, STL, PLY y USDZ con los mismos exportadores que llama el conversor y los mismos ajustes binarios.
- Registrar el tamaño en bytes de cada resultado.
- Leer los atributos directamente de los bytes escritos y no de una escena recargada, porque un cargador se inventa lo que el archivo no contiene: un OBJ sin líneas vn se recarga igualmente con un atributo de normales sintetizado.
- Publicar la tabla directamente a partir de ese resultado. Medido el 13 de septiembre de 2026 con three.js r179.
Preguntas
- ¿Convertir un archivo 3D pierde calidad?
- La forma no. Cada destino se convirtió y se volvió a leer, y el número de triángulos y el área de superficie total salieron idénticos en una malla de 498.734 triángulos, sin truncar coordenadas en ningún formato. Lo que se pierde es todo lo que rodea a la geometría, y depende del destino: STL descarta las UV, el color, los materiales y el grafo de escena; OBJ descarta el color por vértice; PLY descarta los nombres de material y fusiona la escena; USDZ descarta el color por vértice y los nombres de material al releerlo; GLB y glTF lo conservaron todo.
- ¿Qué formato 3D ocupa menos?
- GLB, en una malla real. En estas pruebas GLB escribió 1173 KB donde OBJ escribió 4928 KB para el mismo modelo, porque GLB es binario y mantiene un índice de vértices compartido, mientras que el OBJ resultante es texto y guarda por separado cada esquina de cada triángulo.
- ¿Por qué mi OBJ ocupa mucho más que el GLB del que salió?
- Por dos razones, las dos medidas: OBJ es texto y no binario, y el OBJ que se escribe aquí no comparte vértices entre triángulos, así que el número de vértices se multiplica por unas 6 en una malla bien indexada. La superficie es idéntica; la contabilidad no.
- ¿STL conserva el color?
- No. Un STL binario guarda una normal de cara y tres esquinas por triángulo, y no tiene ningún campo para color, UV, materiales ni nombres de objeto. Eso se cumplió en todos los STL escritos en estas pruebas.
- ¿Puedo conservar el color por vértice sin usar GLB?
- Sí, con PLY. En estas pruebas fue el único destino que no es glTF que declaró una propiedad de color en su cabecera. Eso sí, aplana una escena de varios objetos en una sola malla, así que conservas el color y pierdes las partes.
- ¿Convertir un modelo 3D una y otra vez lo degrada?
- No. A diferencia de volver a guardar un JPEG, una conversión 3D no acumula error: las coordenadas se copian como floats binarios o, en el caso de OBJ, se escriben como decimales con precisión completa. Un viaje de ida y vuelta por cualquiera de estos formatos devolvió la superficie idéntica. Lo que no vuelve es la información de materiales y de escena que el destino no podía llevar desde el principio.
- ¿Puedo reproducir estas cifras?
- Sí. El script de medición está en el repositorio, en scripts/measure-conversions.mjs, y escribe el JSON que lee esta página. Se ejecutó por última vez el 13 de septiembre de 2026 con three.js r179.
