Diseño computacional en arquitectura: reglas y decisiones

Treinta deslizadores y una fachada que se retuerce. Nadie toca los valores durante la presentación porque el único rango estable parece ser el que ya está puesto. Podemos aplaudir la geometría o hacer una pregunta bastante menos agradecida: ¿qué decisión permite tomar mejor? El diseño computacional tiene interés cuando las relaciones ayudan a explorar el proyecto. Como colección de mandos que nadie entiende, ya existían cuadros eléctricos antes de que lo llamásemos innovación.

El diseño computacional en arquitectura utiliza reglas y procedimientos para trabajar con relaciones que importan al proyecto. Puede servir para una fachada compleja y también para comparar una distribución bastante convencional. Lo valioso es formular el problema de manera que variar una entrada produzca un resultado comprensible y evaluable. Seguiremos un ejemplo hipotético de protecciones solares para entender dónde ayudan los parámetros, qué aporta explorar alternativas y qué debe ocurrir antes de llevar una opción al modelo de producción.

Formula una decisión que merezca explorar alternativas

Imagina una fachada en la que queremos estudiar la profundidad y separación de unas lamas. Nos interesa reducir exposición solar, conservar vistas y evitar una colección interminable de piezas distintas. Son intereses que pueden competir. Si solo optimizamos una medida de radiación, el proceso podría proponer una solución estupenda para esa cifra y bastante antipática para quien espere mirar por la ventana. La función hace lo que se le pide; los deseos que se quedaron fuera no protestan desde el código.

Antes de construir el modelo computacional hay que distinguir entradas, restricciones y resultados. La orientación y la geometría del edificio pueden ser datos de partida; la profundidad de las lamas puede variar dentro de un rango; el módulo constructivo puede imponer límites. Las métricas describen lo que queremos comparar. No es necesario convertir todo en variable. Si un eje estructural está aprobado y no se va a discutir, añadirle un control solo amplía el espacio de posibilidades que después habrá que descartar.

Un buen primer ejercicio utiliza pocas variables y conserva un caso de referencia entendido. Por ejemplo, comparar una solución sin protecciones con dos o tres profundidades dentro del módulo previsto. Esas primeras alternativas permiten comprobar si las relaciones se comportan como esperamos. Si una lama más profunda empeora una métrica que suponíamos favorable, toca investigar entradas, cálculo y geometría. Generar otras quinientas opciones antes de entender las primeras multiplica el misterio con notable eficiencia.

También conviene decidir cuándo este esfuerzo compensa. Para una solución estable que solo cambiará una vez, un dibujo o una familia sencilla puede ser suficiente. Si habrá muchas iteraciones o dependencias que se corrigen repetidamente, expresar las relaciones puede ahorrar trabajo y revelar posibilidades. El criterio no es si el proyecto merece una etiqueta moderna, sino si el modelo computacional ayuda a decidir y si alguien podrá mantenerlo cuando cambie una condición.

Distingue parametrizar, describir un algoritmo y generar opciones

Una relación paramétrica establece dependencias: al cambiar una separación se recalculan posiciones o cantidades. El valor reside en mantener esa relación de forma coherente. No implica que la herramienta sepa qué separación es buena. Un deslizador permite recorrer un rango, pero alguien debe definir sus límites y comprobar qué sucede cerca de ellos. Si acepta valores que producen piezas imposibles, la libertad del usuario está creciendo a costa de la utilidad del resultado.

Un algoritmo añade un procedimiento explícito. En la fachada del ejemplo podría dividir cada tramo, reservar encuentros, colocar lamas y resolver lo que queda en los extremos. Las esquinas y los huecos estrechos necesitan tratamiento propio; suelen ser precisamente los lugares donde un ejemplo perfecto deja de servir. Observar estados intermedios ayuda a ver si el fallo está en la división, en la selección de tramos o en la generación de piezas. La imagen final rara vez explica sola todas esas decisiones.

Un proceso generativo produce y evalúa alternativas según criterios definidos. La explicación de diseño generativo de Autodesk describe esa relación entre entradas, objetivos, restricciones y resultados. Puede incorporar métodos de exploración u optimización sin que eso implique necesariamente aprendizaje automático. Introducir IA es otra decisión: no resulta obligatoria para distribuir lamas o comparar una función que ya sabemos expresar.

En la práctica estas capas pueden combinarse. Un grafo paramétrico puede producir cada alternativa y un método de búsqueda decidir qué combinaciones explorar. La persona revisa qué compromisos acepta y qué aspectos quedan fuera de las métricas. No hace falta declarar una jerarquía en la que todo lo generativo sea superior a todo lo manual. Si la pregunta se resuelve mejor con tres opciones bien estudiadas, una nube de diez mil miniaturas solo introduce un problema nuevo de selección.

Compara con métricas honestas y conserva lo que dejan fuera

La calidad de la comparación depende de los datos y del nivel de fidelidad del cálculo. Una evaluación simplificada puede orientar una decisión temprana sin demostrar el comportamiento final del edificio. Hay que declarar sus supuestos y utilizar el análisis adecuado antes de extraer conclusiones que no puede sostener. Los decimales impresionan bastante; no mejoran por sí mismos una orientación equivocada, un archivo climático inadecuado o una simplificación geométrica que elimina parte del problema.

En nuestro ejemplo, cada opción debería conservar su configuración y mostrar las medidas que estamos comparando, además de las restricciones incumplidas. Podría interesar observar exposición estimada, cantidad de material y número de piezas distintas. Esas métricas no sustituyen una evaluación completa de confort, vistas o construcción. Permiten mantener una conversación concreta: qué mejora una alternativa, qué empeora y qué tendremos que estudiar con más detalle antes de elegirla.

Si una solución mejora una medida y empeora otra, hace falta discutir el compromiso. No conviene esconderlo dentro de una puntuación ponderada que nadie puede explicar. Una suma de indicadores puede ser útil si el equipo comprende sus unidades, normalización y pesos, pero también puede disfrazar una preferencia como necesidad matemática. La documentación de criterios de estudio de Autodesk distingue objetivos, restricciones, variables y constantes; esa separación ayuda a no tratar todas las decisiones como un número que hay que maximizar.

Guarda asimismo las razones cualitativas del descarte. Una opción puede funcionar bien en el cálculo y complicar una esquina, el mantenimiento o la relación con la calle. No es obligatorio fingir que todos esos juicios caben en una fórmula. Lo importante es que la revisión sea comprensible y que no se atribuya al algoritmo la elección que ha hecho el equipo. El ordenador puede organizar evidencia con paciencia; el gusto y la responsabilidad no se transfieren al archivo por guardarlo como resultado.

Diseña también el paso de la exploración a la entrega

La opción elegida necesita llegar al entorno de producción de una forma que pueda documentarse y modificarse. Para la fachada habría que definir cómo se traducen las lamas a tipos, dimensiones y relaciones del modelo BIM. Exportar una geometría opaca puede servir para estudiar una forma, pero quizá no para producir cantidades o documentación constructiva. La salida debe responder a lo que el siguiente equipo necesita hacer, igual que las entradas respondían a la pregunta inicial.

También hay decisiones de fabricación: módulos, juntas, tolerancias y límites de las piezas especiales. Si el generador produce una profundidad distinta para cada lama, puede estar creando una variedad que el sistema constructivo no admite razonablemente. Esos límites deberían incorporarse cuando corresponda y contrastarse con los especialistas. Una alternativa puede ser interesante para explorar y seguir necesitando bastante trabajo antes de convertirse en una solución construible.

Prueba cambios incómodos: un tramo muy corto, una planta irregular, un hueco en una esquina o una entrada ausente. El modelo debe señalar cuándo no puede resolver el caso. Si se actualiza el algoritmo, compara la misma configuración y revisa las diferencias antes de regenerar una entrega. Conserva versiones e identificadores donde el flujo los necesite. Una modificación aparentemente pequeña puede producir muchos objetos nuevos, y el equipo receptor merece enterarse antes de que desaparezca su seguimiento.

La interfaz debe ayudar a quienes van a usarla. Nombres de parámetros ligados a decisiones, rangos razonables y una explicación de límites suelen aportar más que una docena de controles adicionales. No todos necesitan editar el grafo, pero alguien debe poder mantenerlo y explicar sus resultados. Empezar con una herramienta acotada favorece esa transferencia. Si solo funciona cuando su creador está sentado al lado, parte de la solución todavía está alojada en una persona.

Una buena exploración permite explicar qué cambia, qué se mantiene y por qué una opción merece pasar al proyecto. Si solo puedes defenderla diciendo que el algoritmo la ha encontrado, todavía falta criterio de diseño. Elige una relación que hoy te obligue a rehacer trabajo y empieza por volverla comprensible; la fachada imposible puede esperar a que sus reglas sepan presentarse.