Blog de coolOrange

Cuando la exportación glTF de Inventor no es suficiente para las plataformas posteriores

Escrito por Marco Mirandola | 30-jun-2026 15:06:30

Se aprueba un diseño, el ensamblaje está listo y la plataforma de destino necesita datos 3D para su visualización. Alguien ejecuta la exportación a glTF desde Inventor y entrega el resultado. La plataforma no puede procesarlo. La estructura del archivo no es la que espera el sistema. Faltan los metadatos. La exportación fue técnicamente correcta, pero aun así no fue suficiente.

Se trata de un patrón que se repite con frecuencia en entornos de Autodesk Vault, donde los datos de ingeniería deben salir del entorno CAD y llegar a un sistema externo en un formato utilizable. El problema no es el formato, sino la forma y el contenido de la salida.

 

Dónde surge la brecha en los flujos de trabajo de Vault

Rara vez se necesita el formato glTF dentro del propio Inventor. Cobra relevancia cuando los datos 3D tienen que trasladarse a otro lugar: un catálogo de piezas de recambio, un visor 3D basado en navegador o una plataforma que necesita geometría ligera para su visualización e interacción. En esos casos, la exportación a glTF es un paso más dentro de un proceso más amplio de transferencia de datos de ingeniería, no el final del proceso.

Inventor ya admite la exportación a glTF de forma nativa. Se producen dos carencias concretas cuando esa salida llega a un sistema posterior.

Estructura del archivo: en el caso de los ensamblajes con contenido relacionado con los materiales, Inventor genera un archivo .gltf junto con un archivo .bin independiente que contiene la carga útil binaria. Técnicamente, se trata de un glTF correcto, pero muchas plataformas posteriores no están diseñadas para gestionar un par de archivos. Esperan un único archivo autónomo, a veces denominado «glTF Binary» o .glb, en el que la geometría, los materiales y los datos de la escena estén todos integrados juntos. Entregar dos archivos a un sistema que espera uno solo provoca una importación fallida o que se rechace la carga.

Metadatos: En la mayoría de los casos de visualización posteriores, la geometría por sí sola no es suficiente. La plataforma necesita saber qué elemento representa a qué componente. Puede necesitar un número de pieza, una descripción, un identificador de pieza de recambio u otra propiedad que ya se encuentre en Autodesk Vault. Sin esa información integrada en la estructura exportada, el modelo no es más que una carcasa visual. El sistema posterior no puede identificar los componentes ni los atributos de superficie, ni admite interacciones más allá del renderizado 3D básico.

El requisito real es: generar glTF desde Inventor como parte de un proceso de automatización controlado de Vault, producir un archivo de salida autónomo e incluir los metadatos de Vault que cada instancia necesita para que la plataforma posterior funcione correctamente.

 

Automatización del posprocesamiento de glTF dentro de Autodesk Vault

El enfoque consiste en implementar esto como una tarea impulsada por Vault mediante powerJobs. Inventor se encarga de la exportación nativa a glTF. La automatización de powerJobs se ejecuta tras ese paso y ajusta la salida para el caso de uso posterior.

El formato glTF se basa en JSON. Describe la escena, hace referencia a los búferes y vincula entre sí la geometría, los materiales y los nodos. Inventor escribe esa estructura en un archivo BIN independiente que contiene la carga útil binaria. El trabajo lee ambos archivos, convierte el contenido binario en un búfer codificado en base64 y lo incrusta directamente en la estructura JSON. El resultado es un único archivo autónomo, en lugar de un par de archivos, que es el formato que la mayoría de las plataformas posteriores esperan realmente.

En el mismo paso, el proceso amplía la jerarquía de nodos con metadatos de Vault. Las propiedades relevantes, incluidos los números de pieza, las descripciones, los identificadores de piezas de recambio y cualquier otro atributo de los elementos de Vault, se escriben en las entradas correspondientes dentro de la estructura de nodos glTF. De este modo, la plataforma posterior puede identificar los componentes y acceder a sus atributos directamente desde el modelo, sin necesidad de realizar una consulta de datos por separado.

Ambos pasos consisten en modificaciones controladas de la estructura exportada. La geometría y los materiales de Inventor permanecen inalterados. El proceso de powerJobs solo ajusta la forma en que se empaquetan los datos y los metadatos que estos contienen.

Dado que la lógica se encuentra en la capa de automatización de Vault, el mismo trabajo puede activarse ante un cambio en el estado del ciclo de vida, utilizarse dentro de un flujo de trabajo de publicación o ejecutarse bajo demanda. coolOrange powerJobs ofrece la flexibilidad de combinar la exportación nativa de Inventor con el procesamiento adicional que requiere un flujo de trabajo real posterior.

Qué genera la automatización

La plataforma posterior recibe un archivo que realmente puede utilizar. En lugar de una exportación técnicamente correcta pero que no se puede utilizar, el resultado es:

  • Un único archivo glTF autónomo con contenido binario incrustado, sin necesidad de gestionar pares de archivos
  • Metadatos de Vault escritos en cada nodo de ocurrencia, de modo que la plataforma pueda identificar los componentes y mostrar sus atributos
  • Un archivo generado por un proceso de automatización controlado de Vault, no por un paso de exportación manual

La exportación ya no es una tarea manual. Se ejecuta al producirse un cambio en el ciclo de vida, como parte de un paso de publicación o bajo demanda. Esto elimina la variabilidad y garantiza que el archivo entregado refleje siempre el estado aprobado del diseño.

 

Por qué este enfoque es escalable

Dado que la lógica de posprocesamiento se encuentra en powerJobs, se adapta a medida que evolucionan los requisitos. Se pueden introducir propiedades adicionales de Vault, diferentes puntos de activación del ciclo de vida o cambios en la estructura de salida sin necesidad de reconstruir el flujo de trabajo desde cero. El mismo patrón que funciona para una familia de productos se aplica a todo el entorno de Vault una vez establecido.

Para los administradores de Vault y los gestores de CAD que gestionan requisitos de entrega similares en múltiples proyectos, esto también elimina la inconsistencia derivada de que cada paso de exportación se realice de forma diferente cada vez. El trabajo define qué se exporta, cómo se empaqueta y qué metadatos incluye. El resultado es coherente en cada versión.

 

Preguntas frecuentes sobre la exportación a glTF desde Autodesk Vault

¿Puede Autodesk Vault automatizar la exportación a glTF desde Inventor?
Sí. Mediante powerJobs, un trabajo de Vault puede hacer que Inventor exporte a glTF y, a continuación, posprocesar el resultado, incrustando el contenido binario y añadiendo metadatos de Vault, como parte de un flujo de trabajo basado en el ciclo de vida o de publicación.

¿Cómo puedo crear un único archivo glTF autónomo desde Inventor?
La exportación nativa de Inventor genera un archivo .gltf junto con un archivo .bin. Para generar un archivo autónomo, el contenido binario debe codificarse en base64 e integrarse en la estructura JSON. Esta conversión puede automatizarse dentro de una tarea de Vault utilizando powerJobs.

¿Cómo añado metadatos de Vault a una exportación glTF desde Inventor?
Las propiedades de los elementos de Vault, como los números de pieza, las descripciones, los identificadores de piezas de recambio y otros atributos, pueden escribirse en los nodos de ocurrencia correspondientes dentro de la estructura glTF durante el posprocesamiento. Esto requiere un paso adicional tras la exportación nativa de Inventor, del que se encarga powerJobs como parte del mismo trabajo de automatización.

¿Por qué la plataforma de destino no puede abrir mi exportación glTF de Inventor?
Las razones más comunes son que la plataforma espera un único archivo autónomo en lugar de un par .gltf + .bin, o que requiere metadatos de los componentes incrustados en la estructura del archivo que Inventor no incluye de forma predeterminada. Ambas carencias pueden solucionarse mediante un posprocesamiento automatizado en un trabajo de Vault.

¿Qué activa la exportación glTF en un flujo de trabajo de Vault?
El desencadenante depende del proceso. Entre las opciones habituales se incluyen un cambio de estado del ciclo de vida (como la transición a «Publicado»), una acción de publicación explícita o una solicitud de trabajo bajo demanda. powerJobs admite todas estas opciones como desencadenantes de trabajos dentro de Autodesk Vault.

 

Conclusión

Inventor ya puede exportar glTF. En escenarios sencillos, eso es suficiente.

No es suficiente cuando la plataforma posterior espera un único archivo autónomo, cuando los datos de renderizado deben permanecer incrustados en él y cuando cada instancia también necesita metadatos de Vault para que la plataforma funcione correctamente. La pieza que falta es un posprocesamiento controlado dentro del flujo de trabajo de automatización de Vault.

El enfoque de powerJobs conserva la exportación nativa de Inventor y adapta el resultado al formato de archivo que el sistema posterior realmente necesita. El resultado es coherente en cada versión, sin necesidad de ajustes manuales.