Convertir Modelos de Revit en Cantidades de Obra

Un take-off de cantidades en Revit no es una exportación de geometría. Exportar geometría es un problema resuelto hace años: sacar volúmenes y áreas de un modelo toma una tarde. El trabajo de verdad está en convertir “este elemento es un muro de concreto de 12 metros cúbicos” en lo que un presupuesto realmente necesita: kilos de acero de refuerzo, metros cuadrados de formaleta, volumen de vaciado, tiempo de curado y las horas de cuadrilla para colocarlo. Esa traducción es donde está la ingeniería, y está casi completamente indocumentada.

Resumen rápido

• Extraer geometría es la mitad fácil; mapear esa geometría a una estructura de costos es la mitad que determina si el resultado sirve.
• El mapeo depende de las convenciones de modelado, así que el techo de calidad de cualquier extracción lo fija cómo se levantó el modelo.
• Revit guarda las longitudes internamente en pies decimales sin importar las unidades que muestre en pantalla, lo que produce números equivocados de aspecto plausible cuando se ignora.
• Cada versión de Revit trae sus propios ensamblados de API, así que un add-in se compila por versión y soportar versiones es un compromiso de mantenimiento, no una tarea de una sola vez.
• Cuatro decisiones de diseño determinan si el pipeline sobrevive al contacto con un proyecto real. Ninguna es obvia, y todas salen más baratas antes de escribir código.

CodeBranch construyó una integración con Revit para Building Companion, la plataforma de control presupuestal que usa un contratista eléctrico, alimentando las cantidades extraídas al mismo motor de Análisis de Precios Unitarios descrito en el caso de control presupuestal a medida. Este artículo trata sobre las decisiones que obliga a tomar un pipeline así, y lo que cuesta cada una — una instancia concreta del patrón más amplio que describimos en qué construyen las empresas de construcción cuando su plataforma se queda corta.

¿Por qué un take-off de Revit no es simplemente una exportación?

Porque un presupuesto no está organizado como lo está un modelo.

Un modelo se organiza por objeto. Un muro estructural de concreto es un elemento con un volumen, un material y un conjunto de parámetros. Un presupuesto se organiza por el trabajo necesario para producir ese objeto: el concreto por vaciar, el acero por figurar y amarrar, la formaleta por armar y desencofrar, las horas de mano de obra, el tiempo de equipo, el transporte. Un elemento del modelo se convierte en muchas líneas de presupuesto, y la relación entre ellos es una regla, no una propiedad guardada en el archivo.

Esa regla no vive en ninguna parte dentro de Revit. Vive en cómo el equipo de presupuestos entiende el trabajo — razón por la cual, en la última medición sistemática de tecnología en construcción, el 62% de las empresas seguía presupuestando en hojas de cálculo pese a la adopción generalizada de BIM. Los modelos existían; la capa de traducción no. El trabajo de la integración es codificarla.

CodeBranch diseña estas capas de extracción para que emitan actividades y no volúmenes, porque una línea de presupuesto que dice “12 m³ de concreto” todavía necesita que alguien la convierta en algo comprable, lo que devuelve el paso manual al lugar donde estaba.

Por eso también la calidad del resultado tiene un techo fijado por el modelo. Un pipeline de extracción no puede recuperar información que el modelador nunca ingresó. Si los tipos de muro no distinguen entre muros estructurales y divisorios, ninguna cantidad de procesamiento va a separarlos, y el presupuestador va a detectar el error — o peor, no lo va a detectar.

¿Cómo se mapea un elemento de Revit a una plantilla de costos?

Esta es la decisión que determina si el pipeline es estable o frágil, y hay dos respuestas defendibles.

Mapear por GUID de shared parameter. Los parámetros compartidos de Revit llevan un identificador único global que sobrevive a los cambios de nombre. Se vincula un parámetro compartido a las familias en alcance, se escribe ahí la clasificación de costos, y el mapeo se mantiene sin importar cómo llamen al tipo después. El costo está aguas arriba: alguien tiene que cargar el archivo de parámetros compartidos en el proyecto, aplicarlo a cada familia relevante, y seguir haciéndolo a medida que llegan familias nuevas. Le está pidiendo al equipo de modelado que mantenga metadatos para un sistema que quizá no usa.

Mapear por nombre de familia y tipo. No se le exige nada al modelador: el add-in lee los nombres que ya están y los cruza contra una tabla de equivalencias. Funciona de inmediato sobre modelos existentes sin ningún cambio aguas arriba. Se rompe el día en que alguien renombra un tipo, duplica una familia con un sufijo, o un subcontratista entrega un modelo con su propia nomenclatura. La falla es silenciosa a menos que se diseñe para detectarla.

Ninguna columna gana de forma absoluta. Los parámetros compartidos son la respuesta correcta para un propietario o contratista que controla el estándar de modelado en todos sus proyectos. Los nombres son la respuesta correcta cuando los modelos llegan de terceros que uno no controla y la alternativa es no integrar nada. La mayoría de los sistemas en producción termina con una estrategia primaria y un fallback, y la pregunta honesta no es cuál elegir sino qué pasa cuando la primaria falla.

¿Contra qué versión de Revit se está compilando?

Cada lanzamiento de Revit trae sus propios ensamblados de API. Un add-in compilado contra los ensamblados de API de una versión no carga en otra, así que soportar Revit 2023 y 2024 son dos compilaciones, y cada lanzamiento nuevo es una más.

Es un compromiso de mantenimiento que rara vez aparece en la estimación del proyecto. La cadencia de Autodesk es anual, los clientes actualizan a su propio ritmo, y un contratista grande va a tener varias versiones en uso al mismo tiempo entre equipos de proyecto. La pregunta práctica es si la base de código aísla las llamadas específicas de versión detrás de una abstracción, de modo que soportar un lanzamiento nuevo sea un adaptador pequeño, o si la lógica de extracción está escrita directamente contra la API y cada versión es una bifurcación.

Lo mismo aplica al despliegue. Un add-in se registra mediante un manifiesto ubicado en la carpeta de complementos de Revit, por versión y por máquina. Ponerlo en cincuenta estaciones de trabajo de presupuestos y mantenerlo actualizado es un problema de TI que pertenece al plan, no un detalle que se descubre en el despliegue.

¿Por qué sus números salen equivocados por un factor de tres?

Revit guarda las longitudes internamente en pies decimales, sin importar lo que muestre el proyecto. Un modelo que despliega milímetros está almacenando pies. Al leer un parámetro de longitud directamente se obtiene un número internamente consistente, plausible, y equivocado para todo cálculo posterior que asuma unidades métricas.

La documentación de desarrolladores de Autodesk ofrece utilidades de conversión precisamente por esto, y el modo de falla es lo que lo hace peligroso: nada lanza una excepción. La extracción termina, el presupuesto se llena, y el error aparece cuando alguien nota que el pedido de concreto no cuadra. Las áreas y los volúmenes agravan el problema, porque el error escala con el exponente: una longitud equivocada por un factor de 3,28 se convierte en un volumen equivocado por un factor de 35.

Cualquier pipeline de extracción necesita conversión de unidades en el borde y una prueba que lo detecte. La prueba es trivial de escribir y el error es caro de encontrar en producción.

¿A dónde envía los datos el add-in?

Un add-in de escritorio corre dentro del proceso de Revit en la máquina de un presupuestador. Las cantidades extraídas tienen que llegar a un sistema central, y eso tiene dos formas.

Directo a una API. El add-in llama al backend, lo que significa que necesita credenciales en el escritorio y acceso de red desde dentro de una sesión de Revit. También significa que la extracción está tan disponible como la conexión, y que una llamada fallida a mitad de extracción necesita manejo.

A través de un archivo intermedio. El add-in escribe una exportación estructurada que se recoge por separado. Más simple, funciona sin conexión, y el presupuestador puede inspeccionar lo extraído antes de que se vuelva presupuesto — beneficio nada trivial cuando la confianza en los números es todo el punto. El costo es que deja de ser en tiempo real, y alguien tiene que hacerse cargo del traspaso.

La elección interactúa con la pregunta anterior sobre autenticación: un add-in que guarda credenciales en una estación compartida es una postura de seguridad distinta a uno que escribe un archivo.

¿Qué pasa cuando cambia el modelo?

Este es el caso que separa una demostración de un sistema, porque el modelo siempre cambia.

Un diseñador engruesa una losa, agrega una columna, revisa un trazado de tendones. Si el pipeline solo puede procesar un modelo completo desde cero, es una herramienta de reportes que produce una fotografía que alguien tiene que conciliar a mano contra la anterior. Si puede identificar qué cambió y actualizar solo las líneas de presupuesto afectadas, se vuelve parte de cómo se gestiona el proyecto.

Hacer lo segundo exige una identidad estable para los elementos del modelo entre extracciones y una estrategia para qué pasa con una línea de presupuesto cuyo elemento fue borrado — o cuyo elemento sigue existiendo pero ahora cuesta algo distinto. Ninguna de las dos es difícil por separado. Juntas son el problema de diseño que la mayoría de estos proyectos subestima, y CodeBranch lo plantea durante la definición en vez de descubrirlo cuando llega el primer modelo revisado.

¿Qué hay que decidir antes de escribir código?

Cuatro cosas, en este orden, porque cada una condiciona la siguiente:

La estrategia de mapeo, porque determina qué se necesita del equipo de modelado y cuánto tiempo toma conseguirlo. Esta decisión tiene una dependencia organizacional, lo que la vuelve la más lenta de cambiar después.

La política de soporte de versiones, porque le da forma a la estructura del código. Meter una capa de abstracción a posteriori es más caro que diseñar para ella.

La ruta de los datos del escritorio al sistema, porque define el diseño de seguridad y autenticación, y eso es difícil de revisar una vez los presupuestadores están usando la herramienta.

El modelo de manejo de cambios, porque las actualizaciones incrementales exigen que la identidad de los elementos se rastree desde la primera extracción. Agregarlo después significa que los datos históricos no lo soportan.

Ninguna de estas es una incógnita técnica: todas son resolubles. Son decisiones con consecuencias organizacionales, y por eso pertenecen a una fase de definición y no a un sprint. CodeBranch corre esa fase antes de desarrollar en cada proyecto, y una integración BIM es el caso más claro de por qué: los errores caros aquí son arquitectónicos, y se cometen en la primera semana. El costo de equivocarse es el mismo que el NIST cuantificó hace dos décadas para la interoperabilidad inadecuada en instalaciones de capital — dos tercios del cual recae sobre los propietarios, no sobre quienes construyeron los sistemas.