Programación BIM: de una regla a tu propia herramienta

Hoy toca explicar qué es programar: darle instrucciones a una máquina para que un humano deje de repetir una tarea que ya sabe describir. Reservaré mi fascinación para cuando aparezca una excepción; suelen llegar antes que la documentación. Si trabajas con modelos, vistas o tablas, lo interesante es convertir una intención en una regla ejecutable y comprobable. Coleccionar lenguajes en el perfil profesional produce una salida bastante más rápida, pero al modelo no le cambia gran cosa.

La programación BIM aplica esa lógica a información y procesos del proyecto: consultar elementos, transformar datos, comprobar reglas o preparar operaciones sobre un modelo. Vamos a seguir un caso hipotético sencillo que puede crecer: crear vistas a partir de una tabla. Al principio bastará una rutina pequeña; si termina utilizándola todo el equipo, también tendrá que explicar sus límites, sus resultados y cómo se mantiene. El salto depende de la responsabilidad que adquiere, no del número de líneas.

Programar empieza cuando explicas la regla sin saltarte pasos

Imagina una tabla que pide una vista de planta para varios niveles. Cada fila indica el nivel, la disciplina, un nombre propuesto y una plantilla. Para una persona que conoce el proyecto puede parecer suficiente: abre Revit, busca los niveles y crea las vistas. El programa necesita que concretes cómo identifica cada nivel, qué tipo de vista corresponde y qué debe hacer si el nombre ya existe. Donde tú reconoces una situación, la herramienta necesita una condición y una respuesta.

Ese es el primer trabajo de programación: describir una secuencia sin depender de decisiones que solo conoce quien la ejecuta. Leer la tabla, comprobar las columnas, encontrar las referencias en el modelo, detectar conflictos y preparar las operaciones son pasos distintos. La sintaxis vendrá después para expresarlos en una herramienta concreta. Un grafo con nodos también puede representar esa secuencia; que se vea como un dibujo no le permite ignorar la lógica.

Supón que dos filas piden el mismo nombre. Podrías detener la operación, omitir una o pedir una corrección, pero no deberías dejar que la herramienta elija silenciosamente. Lo mismo ocurre si falta una plantilla. Aplicar otra «parecida» puede producir un resultado que se abra y, sin embargo, incumpla lo que necesitaba el usuario. El éxito técnico de crear un objeto no demuestra el éxito del trabajo que pretendías realizar.

Para empezar no necesitas dominar una arquitectura compleja. Necesitas un caso pequeño, unas entradas conocidas y un resultado esperado que puedas revisar. Una tabla de tres filas es suficiente para comprobar que has entendido la selección y la regla. Lanzarte directamente sobre todos los modelos de la oficina añade volumen al experimento, pero muy poca capacidad para comprender qué ha pasado. Yo agradezco la ambición; los modelos compartidos preferirían que viniese dosificada.

Separa lo que lees, lo que propones y lo que modificas

Antes de crear vistas, haz que la rutina muestre un plan. Para cada fila debería indicar qué nivel ha encontrado, qué plantilla utilizaría y si crearía una vista, reutilizaría una existente o detendría esa petición. Una persona puede comprobar ese plan sin llenar el modelo de pruebas. Si la selección ya está equivocada, la corrección pertenece a la lectura o a la regla; todavía no necesitas investigar objetos recién creados.

La diferencia entre reutilizar y actualizar merece atención. Si una vista ya existe, quizá el usuario solo quiera reconocerla y omitir la creación. Cambiarle la plantilla, la escala o el nombre sería otra operación con otras consecuencias. Explica cada acción y delimita qué propiedades puede modificar la herramienta. Una opción llamada «actualizar todo» es cómoda de colocar en una interfaz; bastante menos cómoda de interpretar cuando afecta a vistas que alguien ya había preparado.

Una vez confirmado el plan, la ejecución debe comprobar de nuevo las condiciones relevantes. Entre la propuesta y la modificación puede haber cambiado el modelo. La documentación de transacciones de la API de Revit explica el mecanismo que gobierna los cambios en el documento. La forma de manejarlo depende de cómo estés integrado: no copies sin más una solución de un complemento a un nodo de Dynamo que ya gestione su propio contexto.

También hay que decidir qué hacer si falla una fila. En un proceso puedes necesitar cancelar el conjunto; en otro, aceptar unidades correctas y presentar las pendientes de forma explícita. No existe una respuesta universal. Lo que sí debería evitarse es anunciar éxito y esconder una mitad sin ejecutar. El informe final debe distinguir lo creado, lo omitido, lo que ya existía y lo que no pudo completarse.

Prueba esos resultados con entradas pequeñas y conocidas: nivel inexistente, plantilla ausente, nombre duplicado y vista ya creada. Comprueba también qué ocurre al repetir la ejecución. Si cada intento añade una copia, el usuario necesita saberlo y la herramienta quizá necesite reconocer su trabajo anterior. El segundo clic no debería ser un experimento nuevo sobre la paciencia del modelo.

Dynamo, Python y C# resuelven necesidades que se solapan

El Dynamo Primer presenta Dynamo como un entorno de programación visual. En el caso de las vistas puede ayudarte a seguir cómo se seleccionan niveles y se construyen nombres, y a discutir la lógica con alguien que reconoce los datos del modelo. Sigue siendo programación: las listas, los tipos y los valores que faltan importan aunque estén unidos por cables muy bien dibujados.

Python puede resultar útil cuando quieres organizar una lógica que se repite, tratar datos o construir informes. También puede formar parte de un flujo de Dynamo o de otra integración. Su uso no implica abandonar el grafo ni obtener acceso automático a Revit desde cualquier terminal. Antes de elegir una biblioteca o copiar un ejemplo, comprueba el intérprete, las dependencias y el entorno donde se ejecutará. «Está escrito en Python» todavía deja bastantes preguntas sin responder.

Un complemento en C# sobre la API de Revit puede encajar si necesitas una interfaz integrada, un comportamiento controlado y una distribución para usuarios que no deberían editar la lógica. Eso añade obligaciones de compilación, instalación, compatibilidad y soporte. No convierte por sí solo una regla ambigua en una herramienta fiable. Migrar a otro lenguaje sin aclarar qué significa «actualizar vista» solo permite discutir la misma ambigüedad dentro de un proyecto más grande.

La decisión útil depende del uso. Una persona experta que ejecuta una operación acotada puede trabajar con un script bien delimitado. Un equipo que necesita repetir el proceso sin conocer sus detalles puede justificar una interfaz y un canal de distribución más estables. Un prototipo también puede ser suficiente para aprender y descartarse después. No hace falta ascender cada grafo a producto corporativo para que su existencia haya tenido sentido.

Cuando otras personas dependen del script, cambia el trabajo

Volvamos al caso de las vistas. Si otra persona copia la rutina a un proyecto con niveles y plantillas distintos, aparecerán decisiones que antes estaban escondidas en la configuración inicial. Separa lo que es una regla general de lo que cambia por encargo. El patrón de nombres, las referencias de plantillas y las exclusiones pueden necesitar configuración; el comportamiento ante una entrada inválida debería seguir siendo comprensible y comprobable.

No conviertas cada excepción en otra casilla sin explicación. Si una petición altera el propósito de la herramienta, quizá necesite otra operación o quedar fuera de alcance. Una rutina para preparar vistas no tiene por qué convertirse también en publicador de IFC, corrector de familias y gestor documental porque ya esté abierta dentro de Revit. Cada capacidad añadida multiplica las combinaciones que alguien tendrá que revisar cuando falle.

Distribuir también forma parte del problema. Si cada usuario conserva una copia distinta, será difícil reproducir una incidencia o saber qué versión produjo un resultado. Decide cómo se entrega la versión válida y qué configuraciones admite. Un registro proporcionado puede conservar versión de herramienta, referencia del modelo, configuración y resumen de acciones. Recoge lo necesario para investigar el trabajo; no hagas de la trazabilidad una excusa para acumular datos personales sin propósito.

Los mensajes deben ayudar a quien ejecuta. «No se encuentra la plantilla solicitada en este modelo» permite revisar una referencia; una excepción del lenguaje sin contexto obliga a buscar al autor. Puede conservarse el detalle técnico para diagnóstico, pero la interfaz necesita explicar si se ha modificado algo, qué parte falló y qué se puede hacer después. Que el programa reconozca su propio problema ya es un avance notable sobre ciertas reuniones.

La guía de complementos de Revit es una referencia para entender esa integración, pero no sustituye una estrategia de entrega y mantenimiento. Declara qué versiones soportas y compruébalas con casos conocidos. Evita prometer compatibilidad con una versión que solo has visto anunciada o que utiliza otra persona en otro proyecto.

Aumenta las garantías cuando aumente la responsabilidad

Una herramienta que modifica cincuenta vistas debería ofrecer más garantías que un ejercicio que imprime tres nombres. Necesita comprobaciones, una explicación de sus efectos y una recuperación adecuada a su operación. Eso no obliga a montar un sistema enorme desde el primer día: obliga a valorar qué puede salir mal y a poder detectarlo antes de que el usuario confíe en un resultado incorrecto.

Conserva ejemplos pequeños para comprobar cada regla y una muestra representativa del contexto real. Si cambia el requisito de nombres, revisa tanto los casos correctos como las colisiones. Si actualizas una dependencia, comprueba la lectura, el plan y la ejecución. La lógica que no necesita acceso al modelo puede separarse para probarla por su cuenta; las operaciones de Revit seguirán necesitando comprobación en su entorno. Ninguna de las dos capas sustituye a la otra.

Asigna responsabilidades antes de repartir la herramienta. Alguien debe decidir qué proceso se ofrece; alguien, mantener la implementación y atender sus fallos. Cuenta ese esfuerzo al valorar el retorno de la automatización BIM. Si la rutina ocurre pocas veces y cambia mucho, quizá siga bastando una ayuda pequeña ejecutada por una persona que conoce sus límites. Más software también significa más cosas que conservar funcionando.

Describe una tarea mediante entrada, regla y salida, y añade qué ocurre cuando falta un dato. Ese primer esfuerzo sirve con nodos o con código. Si todavía no puedes explicar la regla, no delegues la decisión al programa y esperes que la sintaxis la resuelva. Las máquinas repiten instrucciones con una disciplina admirable; redactarlas sigue formando parte del encargo humano.