Visor IFC web: qué mirar antes de elegir tecnología
Los tres visores abrían el IFC de demostración en menos de un minuto. El problema apareció con los modelos del estudio. El primero cargó bien el edificio pequeño; el segundo sufrió con una federación de instalaciones; el tercero dibujó todo, pero dejó varias propiedades bajo nombres imposibles de filtrar. Elegir un visor IFC web por la portada del producto había resultado tan fiable como elegir una grúa por el color.
Un visor IFC web puede servir para abrir, revisar, comentar o integrar modelos desde el navegador. La decisión depende del uso, los archivos reales y las condiciones de datos. No basta con que muestre geometría. Hay que probar esquemas, propiedades, rendimiento, privacidad, colaboración, extensibilidad y coste operativo.
Tabla de contenidos
La evaluación empezó con tres tareas y tres modelos
El estudio definió tareas: una persona externa debía abrir y consultar; coordinación necesitaba revisar propiedades y aislar sistemas; desarrollo quería integrar el visor en un portal.
Preparó tres IFC. Uno pequeño y limpio; otro federado con geometría pesada; y un tercero con conjuntos de propiedades, clasificaciones y relaciones problemáticas. También incluyó incidencias conocidas.
Los modelos no pretendían representar todo el mercado. Representaban el trabajo del estudio. La misma herramienta podía ser excelente para consulta ligera y mala para análisis masivo.
Abrir el archivo fue la primera prueba, no la conclusión
Se midieron tiempo de carga, primera vista útil, memoria y respuesta al navegar. Un visor que tarda más pero permite trabajar progresivamente podía ser mejor que otro que congela la interfaz hasta terminar.
Los errores debían explicar formato, tamaño o procesamiento. La evaluación registraba fallos y límites observados, sin convertir una única prueba en promesa universal.
También se probó actualización. Cargar otra versión debía conservar claridad sobre cuál estaba abierta. Una URL genérica sin versión podía confundir revisión e historia.
La geometría se inspeccionó donde suele fallar
El equipo revisó huecos, elementos inclinados, objetos complejos y coordenadas. Comparó extensiones y plantas con un visor de referencia y el origen.
No buscó fidelidad fotográfica. Quería saber si podía coordinar y localizar. Una representación simplificada era aceptable si no ocultaba condiciones críticas.
Las secciones, mediciones y selección se probaron. Una herramienta que muestra bien pero selecciona objetos fragmentados puede dificultar el trabajo posterior.
Las propiedades decidieron más que el sombreado
El tercer IFC contenía propiedades en varios conjuntos, tipos y relaciones. El equipo buscó valores, filtró por clasificación y exportó resultados cuando era posible.
Se comprobó si el visor distinguía instancia y tipo, unidades y valores vacíos. Un panel que enseña todo sin estructura puede parecer completo y ser difícil de usar.
Para validación formal, el estudio seguía utilizando herramientas específicas. El visor ayudaba a explorar; no recibía automáticamente autoridad de control de calidad.
Los esquemas y la compatibilidad se verificaron con fecha
La documentación del producto indicaba formatos y versiones soportadas, pero el equipo lo probó. «Compatible con IFC» no revela todas las entidades, geometrías o relaciones interpretadas.
Las condiciones podían depender del plan, del tamaño o del procesamiento cloud. Cada hallazgo se registraba con versión y fecha. Las comparativas envejecen y conviene que lo hagan con dignidad.
Si una capacidad era beta o requería configuración, se anotaba. La decisión no mezclaba demo y producción.
La federación mostró el coste del contexto
Coordinación necesitaba abrir varias disciplinas, controlar visibilidad y conservar posición. Algunos visores trataban cada archivo por separado; otros ofrecían una federación gestionada.
Se probaron coordenadas y transformaciones. Un modelo desplazado podía invalidar la revisión aunque cada archivo aislado abriese correctamente.
La federación aumentaba memoria y gestión de versiones. El equipo decidió si la plataforma debía guardar combinaciones o si el portal las construiría bajo demanda.
La colaboración añadió identidad e historia
Comentar un elemento requería usuario, modelo, versión, cámara y estado. Un marcador sin ciclo de vida no bastaba. El equipo probó asignación, notificaciones y cierre.
BCF podía facilitar intercambio con otras herramientas si la implementación conservaba referencias. Se ensayó el recorrido, no solo el botón de exportar.
Para una consulta pública ocasional, estas funciones podían sobrar. La colaboración también trae permisos, retención y soporte.
La privacidad cambió por completo la lista corta
Algunos modelos no podían subirse a servicios externos sin acuerdo. El equipo revisó ubicación, cifrado, retención, borrado y entrenamiento de servicios cuando correspondía.
Un visor cliente que procesa localmente podía reducir transferencia y aumentar requisitos del dispositivo. Un servicio cloud podía mejorar rendimiento y colaboración, con otra dependencia.
Las condiciones comerciales se verificaban, no se inferían de «gratis». Una demo gratuita puede tener límites de almacenamiento, tamaño, privacidad o uso.
La seguridad se probó con usuarios reales
El estudio creó perfiles de cliente, colaborador y coordinador. Comprobó qué modelos y acciones veía cada uno. Las URLs compartidas no debían saltar permisos.
Los tokens eran temporales y los secretos quedaban en servidor. La aplicación integrada verificaba membership antes de entregar acceso.
También se probó revocación. Quitar un usuario debía impedir nuevas consultas y respetar política sobre copias locales. Compartir es una función; dejar de compartir también.
La extensibilidad separó producto cerrado y componente
El portal necesitaba escuchar selección, abrir incidencias y consultar propiedades. Se evaluaron SDK, API, eventos y capacidad de personalización.
Una extensión potente podía acelerar desarrollo y aumentar acoplamiento. El equipo aisló el visor detrás de contratos propios para no guardar IDs efímeros como dominio.
La documentación, licencias de desarrollo y versiones formaban parte. Un ejemplo en GitHub no equivale a soporte de producción.
El rendimiento incluyó dispositivos modestos
Las pruebas se ejecutaron en un portátil de obra, una tableta y una red limitada. Se midió interacción, no solo carga. Cortes y filtros debían responder sin bloquear.
Se observaron degradaciones: reducir detalles, cargar por zonas o limitar disciplinas. La aplicación informaba cuando el modelo excedía capacidades.
La solución no podía exigir una estación gráfica para cumplir precisamente la promesa de acceso web. Aunque pedir una GPU nueva siempre produce reuniones interesantes.
La accesibilidad ofreció rutas fuera del 3D
El visor incluía árbol, búsqueda, propiedades y tablas. Las acciones podían utilizar teclado. Los estados no dependían solo del color.
Para personas que necesitaban un informe, una tabla era más eficaz que navegar. El portal ofrecía alternativas. El 3D era contexto, no obligación.
Esta decisión mejoró también uso móvil y automatización. Los datos no quedaban atrapados detrás de una escena gráfica.
Los costes incluyeron más que licencia
Se estimaron usuarios, almacenamiento, procesamiento, transferencia, soporte e integración. Una solución open source podía evitar licencias y exigir infraestructura y desarrollo.
Un producto gestionado podía reducir operación y limitar personalización o salida. El coste se calculó por escenario y volumen, verificando precios actuales.
La migración también contaba. Incidencias, vistas y metadatos podían quedar ligados a la plataforma. La estrategia de exportación se revisó antes de adoptar.
Una matriz ordenó la decisión
| Uso | Prioridad | Pregunta de prueba |
|---|---|---|
| Abrir y consultar | Simplicidad y compatibilidad | ¿Una persona externa completa la tarea sin formación? |
| Revisar | Propiedades, filtros y geometría | ¿Encuentra y explica los problemas conocidos? |
| Colaborar | Versiones, issues y permisos | ¿La incidencia conserva contexto y se verifica? |
| Integrar | SDK, API y estabilidad | ¿El portal controla identidad y ciclo de vida? |
| Datos sensibles | Privacidad y residencia | ¿El despliegue cumple el contrato real? |
La puntuación se acompañaba de evidencia y peso por proyecto. Un ganador global habría ocultado que distintos equipos necesitaban perfiles diferentes.
El piloto evitó comprometer toda la biblioteca
Se eligió un proyecto y un grupo pequeño. Durante varias semanas se registraron tiempos, fallos, soporte y tareas completadas. Se probaron actualizaciones y accesos externos.
Los usuarios no puntuaban únicamente estética. Explicaban si podían revisar, encontrar propiedades y cerrar incidencias. Desarrollo evaluaba mantenimiento.
La herramienta que mejor abría el modelo pequeño no fue la elegida para coordinación. La decisión siguió el uso principal.
Cuándo basta una herramienta más simple
Para enviar una vista puntual, quizá sirva un visor local o un enlace temporal. Para control formal, una aplicación especializada puede ser mejor. Una plataforma colaborativa se justifica si el proceso la utiliza.
También puede ser preferible construir sobre un componente si existe capacidad y requisitos diferenciadores. No conviene hacerlo solo por evitar una suscripción.
Si los modelos contienen datos malos, ningún visor arreglará la exportación. Puede ayudar a descubrirla, que ya es bastante.
El mejor visor fue el que terminó el trabajo
El estudio eligió una solución para coordinación y mantuvo otra ligera para consultas simples. Documentó límites, modelos de prueba y fecha. No declaró un campeón eterno.
Para elegir un visor IFC web, define la tarea, prueba archivos reales y revisa privacidad, rendimiento, datos, colaboración y coste. Repite la evaluación cuando cambien productos o necesidades.
Si todos los candidatos abren el cubo de ejemplo, enhorabuena: has comprobado que saben abrir un cubo. Ahora prueba el modelo de instalaciones y prepara café; ahí empieza la comparativa.
Respuestas