IFC y openBIM: cómo dejar de perder información cada vez que cambia el software

Nos llegó una vez un modelo estructural para coordinar que, al abrirlo, tenía todas las vigas convertidas en objetos genéricos sin un solo dato: ni material, ni nivel, ni marca. El modelo original estaba perfecto — lo verificamos después — pero la exportación al formato IFC se había hecho con la configuración por defecto, y en el viaje se perdió todo lo que hacía útil al modelo. La empresa que lo mandó ni se enteró: nadie abre el archivo que exporta. Esa escena se repite tanto en los intercambios que auditamos que dejó de sorprendernos, y es la razón de este artículo.

El problema que IFC resuelve (y el que crea si lo usás mal)

IFC — Industry Foundation Classes, el estándar abierto de buildingSMART — existe para que un proyecto no quede rehén del software en que se modeló. Arquitectura en Archicad, estructura en Revit, la constructora revisando en un visor gratuito: el openBIM propone que todos lean el mismo lenguaje sin licencias cruzadas. El problema es que IFC no es un botón, es un esquema de datos enorme, y exportar mal a IFC es peor que no exportar: genera la ilusión de interoperabilidad BIM mientras la información se degrada silenciosamente en cada intercambio.

¿La culpa es del formato? Es la excusa más repetida del sector — "IFC pierde información" — y en nuestra experiencia es falsa en la mayoría de los casos: la información no la pierde el formato, la pierde una exportación que nadie configuró ni verificó.

MVD y versiones: IFC 2x3 vs. IFC 4 en la práctica

Lo primero que hay que entender es que no se exporta "a IFC" a secas: se exporta a una versión del esquema y a un MVD — Model View Definition, el subconjunto del esquema pensado para un uso concreto. IFC 2x3 con el MVD Coordination View sigue siendo el intercambio más robusto y universalmente soportado para coordinación; IFC 4 con Reference View mejora geometrías y propiedades, pero el soporte entre plataformas todavía es desparejo, y esa asimetría genera sorpresas.

La regla práctica que aplicamos: la versión y el MVD no los decide cada empresa por su cuenta, los fija el plan de ejecución BIM del proyecto, y todos exportan igual. Cuando cada estudio exporta "como le funciona", el modelo federado hereda las inconsistencias de todos.

Los errores de exportación que vemos en los modelos que auditamos

Auditando modelos IFC de terceros, los mismos errores aparecen una y otra vez, con una frecuencia que ya nos permitió armar un catálogo propio. Los más dañinos:

• Clasificación incorrecta de entidades: muros modelados como elementos genéricos, equipamiento exportado como BuildingElementProxy. El objeto está, pero ningún software aguas abajo puede filtrarlo ni computarlo.
• Property sets vacíos o no mapeados: los parámetros existen en el modelo nativo pero nadie configuró su mapeo a los Psets del IFC, así que llegan al otro lado sin datos.
• Origen y coordenadas desalineados: cada disciplina exporta desde su propio punto base y el modelo federado aparece con las estructuras a kilómetros de la arquitectura.
• Geometría explotada: exportaciones que convierten elementos paramétricos en mallas trianguladas pesadísimas, que multiplican el tamaño del archivo y matan cualquier chequeo posterior.
• Niveles y estructura espacial rota: elementos sin asignación de piso, que en un cómputo por niveles simplemente desaparecen.

Ninguno de estos errores es exótico y ninguno requiere software adicional para evitarse: requieren configurar la exportación una vez, bien, y verificar el archivo exportado antes de mandarlo. Ese paso de verificación — abrir tu propio IFC en un visor neutral — es el hábito más barato y menos practicado del openBIM.

Flujo openBIM real: distintas plataformas, un solo lenguaje

En proyectos donde nos tocó coordinar equipos que trabajaban en plataformas distintas, el flujo que funciona es menos glamoroso que las presentaciones: un plan de ejecución que fija versión IFC, MVD, punto base compartido, nomenclatura y qué property sets viajan; una exportación configurada y documentada por disciplina; y un ciclo de verificación donde cada modelo se chequea al recibirse, antes de federar. Con eso resuelto, la detección de interferencias sobre el modelo federado deja de dar falsos positivos por problemas de intercambio y empieza a encontrar conflictos reales.

Nada de esto es improvisable a mitad de proyecto: las reglas de intercambio se pactan al inicio, y ahí el marco de ISO 19650 da el vocabulario y la estructura para que el acuerdo quede escrito y no en la memoria de un coordinador.

BCF: el formato hermano que casi nadie aprovecha

Queda un formato de la familia openBIM que merece más uso del que tiene: BCF, el BIM Collaboration Format. Mientras IFC transporta el modelo, BCF transporta las conversaciones sobre el modelo — observaciones con posición de cámara, elementos involucrados, responsable y estado. La alternativa habitual, capturas de pantalla pegadas en un PDF o en correos, hace que cada observación haya que buscarla a mano en el modelo. Con BCF, el revisor marca el problema y el modelador aparece parado exactamente frente a él, en su propio software. Es interoperabilidad aplicada a la gestión, no solo a la geometría — y es la pieza que hace posible coordinar proyectos a distancia entre equipos de distintos países.

Nuestra postura: el openBIM funciona, pero no es gratis — se paga en configuración inicial, disciplina de verificación y acuerdos escritos. Lo que sí es gratis es el costo de ignorarlo, hasta que deja de serlo. Si querés arrancar por lo concreto, en nuestra sección de recursos tenés una checklist de coordinación BIM que incluye los puntos de verificación de intercambios que usamos en proyectos reales.