That Open Components: del visor a tu aplicación BIM

El IFC gira y los muros cambian de color: estamos a dos capturas de llamar producto a la demostración. Entonces alguien pregunta si puede guardar una observación, recuperarla mañana y saber sobre qué versión la hizo. El edificio continúa girando, completamente ajeno al alcance que acabamos de descubrir. That Open Components aporta piezas para construir el visor. Vamos a distinguirlas del resto de la aplicación antes de que «ya se ve» se convierta en una estimación de lo que falta.

That Open Components ofrece una base para desarrollar aplicaciones BIM con piezas reutilizables. Su interés está en poder componer una experiencia propia, sin resolver desde cero cada operación de visualización. Para entender qué nos ahorra y qué trabajo seguimos asumiendo, recorreremos un portal hipotético donde una coordinadora consulta modelos y prepara observaciones. El objetivo es reconocer las responsabilidades antes de convertir el primer ejemplo funcional en el lugar donde acabemos guardándolo todo.

Entender qué piezas estás incorporando al proyecto

La introducción oficial de Components presenta componentes con reglas comunes de acceso y gestión de su ciclo de vida. Es una base útil cuando varias partes de la aplicación necesitan trabajar con el mismo entorno BIM. El ecosistema incluye bibliotecas relacionadas, como Fragments para la representación de modelos y herramientas de interfaz. Conviene reconocer sus responsabilidades antes de instalar dependencias: dos nombres que aparecen juntos en un tutorial no están resolviendo necesariamente el mismo problema.

Para orientarse sin entrar todavía en código, podemos separar cuatro trabajos. La escena, la cámara y el renderizador permiten presentar y recorrer el espacio. La gestión de modelos incorpora el contenido sobre el que se trabaja. Las herramientas de selección, visibilidad o propiedades permiten interactuar con él. Finalmente, la aplicación decide qué significa cada acción para el usuario: qué proyecto está abierto, qué entrega se consulta y dónde se conserva una observación. Esa última capa necesita decisiones propias, por muchas operaciones visuales que ya estén disponibles.

En nuestro portal, pulsar una puerta puede iniciar una consulta de propiedades. El componente conoce una selección dentro del modelo cargado; el portal necesita relacionarla con una entrega y decidir qué datos mostrar. Si la coordinadora crea una observación, también hará falta conservar su texto y su contexto. La distinción evita colocar reglas de negocio en cada respuesta de un botón. Funciona muy bien en la primera pantalla y se convierte en arqueología aplicada cuando otra pantalla necesita hacer lo mismo.

La ventaja de utilizar piezas es que podemos elegir la experiencia que merece construirse. Tal vez el portal solo necesita localizar una sala, consultar su clasificación y ocultar el resto de la planta. No hay obligación de mostrar todas las herramientas disponibles para demostrar que la instalación fue completa. Un componente resuelve una capacidad; la interfaz tiene que ayudar a terminar una tarea. Enseñar más controles de los necesarios puede ser una forma particularmente laboriosa de empeorar el resultado.

Crear un entorno 3D con un ciclo de vida claro

El tutorial de Worlds muestra cómo reunir escena, cámara y renderizador en un entorno de visualización. Esta estructura permite entender quién presenta el modelo y desde dónde se controla la vista. Para una primera exploración, seguir el ejemplo oficial de una versión concreta ayuda más que combinar fragmentos de tutoriales de épocas diferentes. Una API puede conservar el nombre de una clase mientras cambia su forma de inicialización. Los ejemplos antiguos tienen derecho a existir; nuestra aplicación tiene derecho a no mezclarlos al azar.

Cuando integramos esa vista en una aplicación, hay que decidir cuándo se crea y cuándo se destruye. Imaginemos que la coordinadora entra en un proyecto, vuelve al listado y abre otro. Si cada visita crea otro renderizador y nuevas suscripciones a eventos sin liberar las anteriores, la aplicación puede acumular recursos y comportamientos duplicados. La primera apertura no revela ese problema. La quinta suele estar bastante más interesada en participar en la conversación.

Por eso concentraría la conexión con el motor en un módulo identificable: crear el entorno, cargar y retirar modelos, traducir eventos relevantes y liberar recursos al salir. Las pantallas podrían pedir «mostrar esta entrega» o recibir «se ha seleccionado este elemento» sin tener que reproducir toda la inicialización. No hace falta construir una arquitectura de gran corporación para conseguirlo. Basta con evitar que cada botón tenga una opinión propia sobre cómo debe nacer el visor.

También conviene distinguir el estado visual del estado guardado. La cámara y la selección pueden ser locales a la sesión. Una observación que se pretende recuperar mañana necesita persistencia y confirmación de guardado. Si el usuario cambia de vista, no debería perder un texto sin entender qué ha pasado. El componente puede proporcionar las operaciones con las que construimos esa experiencia; la aplicación tiene que decidir su comportamiento y comunicarlo. La serenidad del modelo al seguir girando no sirve como comprobante de que algo se haya guardado.

Preparar el IFC y conservar la relación con su origen

IFC es un formato de intercambio con información de objetos y relaciones. Para visualizarlo en este ecosistema, el flujo de IfcLoader lo convierte a Fragments y carga el resultado. La documentación propone conservar esa representación para reutilizarla en sesiones posteriores. Esta diferencia entre importar el origen y abrir una representación preparada ayuda a diseñar la carga y a interpretar el rendimiento. Si cada visita repite el procesamiento inicial, estaremos midiendo y pagando en recursos una decisión de nuestra aplicación.

El FragmentsManager gestiona la incorporación y retirada de modelos Fragments, con un worker para las operaciones que corresponden a esa arquitectura. Un worker permite ejecutar trabajo en otro hilo del navegador; no significa automáticamente que exista un servidor procesando el archivo. Conviene aclarar esa diferencia porque «lo hemos pasado a un worker» puede mejorar la respuesta de la interfaz sin trasladar el consumo de memoria fuera del dispositivo de la coordinadora.

En el portal hipotético, relacionaría el artefacto preparado con el archivo de origen, la entrega y la configuración que lo generó. Así podríamos regenerarlo cuando cambie el proceso sin perder el significado de los comentarios. La representación de visualización no debería convertirse en la única evidencia disponible si necesitamos conservar el intercambio original. También mostraría el progreso y los errores de forma distinta: un archivo pendiente de preparar, uno que se está cargando y otro que no se ha podido interpretar requieren respuestas diferentes.

La importación merece pruebas con el contenido que vamos a utilizar. Una geometría ausente puede proceder del archivo o de las clases y opciones incluidas en la conversión. Un panel con propiedades no demuestra que una regla de calidad se haya cumplido. Antes de atribuir un fallo a la biblioteca, hace falta localizar su origen; antes de declarar el modelo válido, hace falta definir la validación. El visor puede ayudar a investigar ambas cosas. No ha solicitado ser el notario de la entrega.

Mediría el recorrido con modelos representativos y con el dispositivo previsto, distinguiendo primera conversión y aperturas posteriores. Añadiría cambios sucesivos de modelo para observar la liberación de recursos. Es más útil conocer cómo responde nuestra tarea habitual que repetir una promesa genérica de velocidad. La geometría, la cantidad de objetos, las propiedades y el equipo afectan a la experiencia; una cifra de un ejemplo no se convierte en garantía por aparecer junto a una biblioteca eficiente.

Traducir las interacciones a decisiones del proyecto

La consulta de una puerta ofrece un buen ejemplo de lo que pertenece al producto. Al seleccionarla, la coordinadora puede necesitar su código, su clasificación y una característica concreta. La aplicación debe saber qué propiedad corresponde a cada dato y qué mostrar cuando falta. Volcar todo lo encontrado en un panel no elimina esa responsabilidad: obliga a la persona a interpretar la estructura del modelo cada vez. Una interfaz para coordinar debería ahorrar ese trabajo, sin ocultar el origen de la información cuando haga falta revisarlo.

Filtrar el edificio completo es otra tarea distinta de consultar una selección. Puede requerir un índice de propiedades, consultas específicas o datos preparados fuera del visor. Lo decidiríamos según el volumen y el uso, en lugar de recorrer cada elemento en cada interacción por haber sido la primera forma de obtener un resultado. También distinguiríamos valores de tipo e instancia y sus unidades. Si el usuario pregunta por una dimensión, merece saber qué dimensión está viendo; el hecho de que las dos se llamen «ancho» no las hace intercambiables.

Cuando una selección se convierte en una observación persistente, guardaría el modelo, la versión y referencias cuyo significado hayamos comprobado. La cámara puede ayudar a reconstruir la vista, pero no reemplaza la identidad del objeto. Al publicar otra entrega habrá que comprobar si la referencia sigue resolviéndose y qué ocurre si el elemento se ha sustituido. No debería reasignarse una observación automáticamente a una puerta cercana solo porque resulta cómodo continuar. La continuidad del proyecto necesita algo más sólido que proximidad geométrica.

Si el portal es compartido, usuarios, acceso a proyectos y guardado de observaciones requieren servicios que apliquen esas reglas. La interfaz puede impedir acciones inapropiadas para orientar al usuario, y el servidor debe comprobar las solicitudes antes de entregar datos o registrar efectos. Los secretos de las integraciones se custodian fuera del navegador. Components facilita la experiencia BIM; no puede decidir por nosotros quién tiene permiso para aprobar una observación dentro de una organización concreta.

Por último, ofrecería rutas que no dependan exclusivamente de acertar sobre una pieza pequeña en 3D: búsqueda, listas y un panel comprensible. La selección gráfica aporta contexto; una tabla puede ser mejor para revisar datos repetidos. El usuario no necesita conocer las fronteras entre bibliotecas para completar la tarea. Si termina pensando en cómo funciona nuestra arquitectura, probablemente le hemos asignado una parte del trabajo de desarrollo sin avisar.

Mantener la herramienta cuando el ejemplo ya funciona

La compatibilidad de las dependencias forma parte del diseño. La documentación de inicio pide coordinar las versiones utilizadas en el ecosistema; al preparar un proyecto conviene comprobar el manifiesto de los paquetes concretos y conservar el archivo de bloqueo de dependencias. No copiaría una versión porque aparece en un artículo antiguo ni actualizaría todas las piezas a la vez antes de una entrega. Primero identificaría una combinación compatible y después comprobaría los recorridos que nuestra aplicación utiliza.

La licencia también se revisa en las fuentes de cada pieza. El repositorio de engine_components declara MIT, pero una aplicación puede incorporar otras dependencias, contenidos y servicios con sus propias condiciones. Esa comprobación debe acompañar al inventario real. La apertura del código permite inspeccionarlo y adaptarlo; el coste de desarrollo, alojamiento, pruebas y soporte sigue existiendo. Es una distribución de responsabilidades que puede interesarnos mucho, siempre que no confundamos «podemos construirlo» con «ya está construido».

Antes de invitar a más personas, propondría un pequeño conjunto de pruebas del producto: abrir una entrega conocida, localizar un elemento, comprobar su propiedad, guardar una observación y recuperarla al volver. Después añadiría archivo no compatible, fallo de carga y usuario sin acceso. Las actualizaciones deberían repetir esos recorridos y revisar la liberación de recursos al entrar y salir. No afirmo que estas pruebas estén ejecutadas aquí: son el criterio con el que daría el siguiente paso desde el prototipo.

Construir con That Open Components tiene sentido cuando necesitamos controlar una experiencia o integración concreta y podemos mantenerla. Si una plataforma existente ya cubre el recorrido, su adopción puede ser más conveniente. La decisión mejora cuando sabemos qué parte queremos diferenciar y qué obligaciones aceptamos. El primer IFC que gira merece celebrarse. Haber previsto qué ocurre cuando no gira, cuando falta una propiedad y cuando vuelve otro usuario suele ser lo que permite entregar la herramienta.

Construye una tarea completa alrededor del visor: localizar un elemento, consultar su dato y conservar una observación con contexto. Ese recorrido mostrará qué resuelven los componentes y qué debe aportar tu aplicación. Si la planificación sigue diciendo que solo falta poner un botón, pregunta qué guardará ese botón. La respuesta suele ocupar bastante más que su etiqueta.