Programación visual para arquitectos: piensa con relaciones, no con sintaxis
Conectar cajitas parece una manera razonable de evitar la sintaxis. Hasta que el grafo ocupa tres pantallas y descubrir dónde se divide una lista exige seguir un cable como si buscáramos una avería en obra. Me toca explicar programación visual; intentaré hacerlo antes de que otra captura de nodos pase por una explicación. Partiremos de una regla de fachada para ver cómo una relación se convierte en operaciones, qué datos circulan y qué ocurre cuando el proyecto cambia.
La programación visual encaja bien en este tipo de problema porque permite dibujar relaciones en lugar de escribir instrucciones. Una longitud entra en un nodo, se divide según una modulación y produce posiciones. Los huecos descuentan zonas; los límites del panel corrigen el reparto. Dynamo o Grasshopper pueden mostrar ese recorrido de una manera que un equipo de diseño reconoce con relativa facilidad.
La facilidad dura mientras el grafo sigue contando la historia. Si después de unas semanas solo su autor sabe qué cable contiene la modulación buena, ya no tenemos una explicación visual: tenemos un programa difícil de leer con un fondo gris muy grande. Sigamos la fachada para ver dónde cambia una cosa en la otra.
Tabla de contenidos
El primer grafo se dibuja mejor fuera del ordenador
Antes de buscar nodos, pondría la regla en una hoja. El tramo de fachada tiene una longitud útil; se propone un ancho de panel; el número de piezas debe ser entero; las juntas se reparten y los huecos eliminan o recortan módulos. También hay excepciones: encuentros de esquina, puertas y zonas donde la estructura obliga a mover una junta.
Este croquis separa dos tipos de decisión. Algunas pueden calcularse, como el número aproximado de paneles. Otras necesitan criterio, como aceptar una pieza especial junto a una esquina. Si ambas se mezclan desde el principio, el grafo acumulará condiciones para imitar decisiones que quizá deberían seguir en manos de quien desarrolla la fachada.
Con el proceso visible, el lienzo ya no es el lugar donde descubrimos qué queremos hacer. Se convierte en la representación de algo que el equipo puede discutir: entradas, cálculo, comprobaciones y salida. Parece un detalle menor, pero evita bastantes grupos llamados “prueba”, “prueba buena” y “ahora sí final”.
De una longitud a una propuesta que se pueda revisar
La primera versión recibe un tramo sin huecos. Divide su longitud por el ancho objetivo, redondea a un número razonable de paneles y recalcula el ancho real para repartir el ajuste. En lugar de crear geometría definitiva, devuelve líneas de junta y una tabla con cantidad, ancho resultante y desviación respecto a la modulación.
Esa salida permite comprobar la regla antes de complicarla. Probaríamos un tramo divisible exactamente, otro con un pequeño residuo y uno tan corto que no admite la solución. El tercer caso no debería generar una colección de paneles minúsculos solo porque matemáticamente caben. Tiene que quedar marcado para revisión.
Cuando la base funciona, entran los huecos. Aquí las listas empiezan a importar: una fachada contiene tramos y cada tramo puede contener varios intervalos disponibles. Si aplanamos todo sin entender la estructura, el grafo puede repartir paneles entre zonas que nunca debieron conectarse. El resultado será geométricamente creativo y constructivamente bastante difícil de defender.
La guía de biblioteca de Dynamo explica el papel de los nodos de inspección del dato. Los utilizaría entre etapas para comprobar qué tramos ha detectado el grafo, qué intervalos quedan después de descontar los huecos y qué modulación propone en cada uno. Si una lista ya no corresponde con la fachada, no aceptaría la geometría final por muy convincente que resulte: primero hay que encontrar dónde se perdió esa relación. La previsualización sirve para discutir la regla mientras todavía podemos seguir sus efectos, no solo para embellecer la entrega.
La programación visual funciona cuando podemos seguir el dato
En un buen grafo, la longitud entra por la izquierda y podemos seguir su transformación hasta las juntas propuestas. Los grupos deberían describir intención —“obtener tramos útiles”, “evaluar piezas residuales”— y no limitarse a clasificar nodos por colores. Una nota breve sobre la excepción de las esquinas vale más que un rectángulo perfectamente alineado sin explicación.
La organización también marca fronteras. Primero leemos y analizamos; después generamos una propuesta; solo al final escribimos geometría o elementos en el modelo. Esa separación permite ejecutar la parte de análisis sin llenar Revit de objetos de prueba y facilita comparar el antes y el después.
Los nodos personalizados ayudan cuando una operación está estable y se reutiliza. Ocultar dentro de uno la lógica que todavía estamos intentando comprender solo desplaza el problema. El grafo principal queda limpio, sí, pero al abrir la caja aparece el mismo desorden con menos contexto.
Entonces llega otra persona y cambia el ancho del panel
Hasta ahora el grafo lo manejaba quien conocía cada supuesto. Al entregarlo a otra persona aparecen preguntas muy razonables: qué unidades espera, dónde se introduce el ancho mínimo, si puede seleccionar varias fachadas y qué significa una salida vacía. La herramienta necesita responderlas sin una llamada de media hora.
Las entradas editables deben quedar juntas, con valores iniciales prudentes y límites comprensibles. El resultado debería distinguir entre tramos resueltos, advertencias y casos no evaluables. “0 elementos creados” puede significar que no había nada que hacer o que la selección estaba mal; son noticias bastante distintas.
También hay que registrar paquetes y versiones. Un grafo que depende de cuatro extensiones externas puede ser perfectamente válido, pero esa dependencia forma parte del entregable. La prueba más útil consiste en abrirlo en otro equipo y ejecutarlo sobre un modelo pequeño con un tramo normal, un hueco junto a esquina y una geometría que deba rechazarse.
Si la persona entiende la vista previa, modifica la entrada correcta y sabe qué hacer con las advertencias, el grafo empieza a ser una herramienta. Si necesita que el autor señale qué grupos no debe tocar, todavía es un prototipo con público.
Python aparece cuando las relaciones dejan de caber cómodamente
La fachada puede crecer en complejidad: varios sistemas de panel, prioridades alrededor de huecos, reglas por nivel y un informe comparativo. Representarlo con nodos sigue siendo posible, pero quizá ya no sea la forma más clara. La guía de desarrollo de Dynamo sitúa Python junto con DesignScript y los nodos personalizados entre sus opciones. Python permite reunir validaciones y transformaciones de datos en funciones que se pueden probar por separado.
No movería todo el flujo a un bloque de código. Las entradas y la previsualización pueden seguir visibles; Python se ocuparía de una pieza concreta, por ejemplo evaluar alternativas de modulación y devolver sus advertencias. Así el grafo conserva su valor como conversación y el código absorbe la lógica que empezaba a convertirlo en un mapa del metro.
Grasshopper, Dynamo, Python y las APIs no forman una escalera en la que siempre haya que subir. Son maneras distintas de empaquetar la lógica. Para esta fachada puede bastar un grafo. Convertirlo en aplicación solo porque “queda más profesional” añade instalación y soporte sin mejorar necesariamente la decisión.
El límite aparece cuando intentamos programar la intención completa
Nuestro flujo puede proponer juntas y detectar residuos. No sabe por sí solo si el ritmo de la fachada acompaña al espacio interior, si una esquina merece una pieza especial o si el sistema será fácil de montar. Podemos incorporar algunos criterios; otros seguirán dependiendo de mirar, discutir y coordinar.
La programación visual resulta valiosa cuando retira iteraciones mecánicas y mantiene visibles las reglas. Empieza a estorbar cuando obliga a traducir cada decisión singular a una condición para que el grafo parezca autónomo. En ese punto quizá la herramienta debería preparar alternativas y dejar la elección fuera.
También cuenta la frecuencia. Si esta modulación solo se estudiará una vez, construir un sistema general puede tardar más que resolverla. Si el estudio trabaja con el mismo sistema en muchos proyectos, documentar y probar el grafo empieza a tener sentido. La tecnología no decide ese umbral; lo hacen el uso y el mantenimiento que el equipo puede asumir.
La fachada termina, pero la regla puede quedarse
Al cerrar el ejercicio tenemos algo más útil que una distribución automática. La relación entre tramo, modulación, huecos y excepciones está a la vista; las propuestas dudosas se señalan y otra persona puede repetir el proceso. La herramienta ayuda a pensar porque conserva la lógica sin ocultar sus límites.
Ese es el punto fuerte de la programación visual para arquitectos. Nos deja trabajar con relaciones que ya forman parte del diseño y comprobar cómo cambian al mover una entrada. Si el grafo deja de contar esa historia, toca dividirlo, apoyarse en código o aceptar que una parte del proceso no necesita automatización.
La próxima vez que una regla del proyecto te obligue a repetir el mismo ajuste, dibuja primero sus entradas y excepciones. Quizá termine en Dynamo, Grasshopper o una hoja de cálculo. La buena decisión no será la herramienta más sofisticada, sino la que permita a otra persona entender por qué la junta ha acabado exactamente ahí.
Una regla expresada visualmente debe permitir seguir sus datos y comprender sus excepciones. Si el grafo solo comunica que hubo mucho trabajo conectando cosas, todavía falta enseñarle a explicar su intención. Pide a otra persona que cambie una condición del ejemplo sin preguntarte dónde tocar. El lugar donde se detenga señalará una mejora bastante más útil que recolorear otro grupo.
Respuestas