@kohantoys: <b>Una brebe historia de lo pa...

Una brebe historia de lo paramétrico

Cuando estaba terminando la facultad un amigo me contó que se podían generar edificios automáticamente usando una función mágica de Rhinoceros. Yo había hecho un curso de Rhino con unos diseñadores industriales del centro de estudiantes de la FADU y la verdad no le veía mucho uso, porque tenia mil métodos posibles de hacer curvas, fileteados, aristas suavizadas, en fin, tonterías que no hacían falta en un edificio.

Hasta que aparecieron Zaha Hadid y Patrick Schumacher.

Con RhinoScript, los usuarios podían escribir macros en VBScript para generar geometría por código. Era lentísimo, pero potente; escribías un script, hacia una formita. Cambiabas una variable, hacia otra formita. Mágico. El tema es que exigía saber programar, lo que era un bajón para un arquitecto.

Mientras tanto, había una funcionalidad en Rhino que casi nadie estaba utilizando. En 2003, el desarrollador David Rutten empezó a experimentar con una idea diferente: y si la lógica de construcción de la geometría fuera visible, editable, conectada en tiempo real? Lo llamó Explicit History, un prototipo de lo que sería Grasshopper.

Explicit history (EH) era un botoncito medio ignorado en la base de Rhinoceros que "recordaba" ciertas operaciones del proceso de modelado. Si dibujabas una polilínea, prendías EH y luego la extruías, luego podías modificar la polilínea el objeto extruido cambiaba automáticamente. Magia, de nuevo. Estoy seguro de que en pleno 2026, muchos de ustedes (sí, ustedes que usan Autocad 2016.) se sorprenderán con el comando. Imaginen cuando recién salió.

Explicit history tenía un solo problema y es que todo funcionaba en el background, lo que hacía difícil (imposible bah) de entender qué formas y operaciones iban concatenándose.

La revolución de Grasshopper

El plugin apareció en versión beta en 2007 bajo el nombre Grasshopper (GH), y fue una pequeña revolución silenciosa. Su interfaz de nodos y cables -el modelo de dataflow visual- permitía a arquitectos y diseñadores construir algoritmos (o geometría algorítmica mejor dicho) sin escribir una sola línea de código. Y esto era un golazo.

La geometría se volvía paramétrica: cambiar un slider redibujaba todo el modelo al instante. Probablemente empezó en Londres bajo Schumacher (que luego escribiría el Manifiesto Paramétrico), pero en pocos años, universidades de todo el mundo lo adoptaron como herramienta central en los talleres de diseño computacional. De hecho, es probable que GH haya inaugurado el concepto mismo de diseño computacional en Arquitectura. Antes era solo modelado 3d, con suerte.

El ecosistema de plugins de Grasshopper es uno de los factores que explica su dominio: una comunidad activa de investigadores y estudios desarrolló extensiones que llevan el entorno hacia disciplinas específicas sin romper el flujo paramétrico del proceso de diseño. Plugins como Karamba3D que integra análisis estructural de elementos finitos directamente en Rhino o Ladybug que conecta datos climáticos reales con simulaciones de radiación solar, confort térmico e iluminación natural, y los plugins de fabricación robótica, como KUKA|prc, HAL Robotics y Robots que traducen líneas y curvas de Grasshopper directamente a código de robot permitieron programar un brazo industrial o una impresora 3d desde el mismo entorno donde se diseña la pieza.

Lo notable era la continuidad en todo el proceso y sin salir de Rhinoceros: un dato de viento calculado por Ladybug puede alimentar un componente de Karamba para dimensionar una estructura, y esa geometría pasar directamente a HAL para generar la trayectoria de fabricación. Grasshopper no era un modelador sino una plataforma de integración técnica.

Una nueva forma de diseñar

Diseñar en Grasshopper implicaba un cambio de mentalidad más que de herramienta. En un modelador convencional se trabaja directamente sobre la geometría, se empuja una cara, se arrastra un punto, se dibuja una curva. En Grasshopper no se toca la geometría literalmente no se puede hacer click): se escribe la lógica que la produce. El diseñador construye un grafo de nodos conectados por cables, donde cada nodo es una operación matemática o geométrica, y el resultado visual es una consecuencia de esa cadena de instrucciones. Cambiar un parámetro al inicio del grafo repropaga el cambio a través de toda la red y regenera el modelo al instante.

Las habilidades que esto exigía son distintas a las del modelado tradicional. No era necesario saber programar en sentido estricto, pero sí pensar de forma algorítmica: descomponer una intención de diseño en pasos lógicos, entender qué es una lista de datos, qué significa operar sobre ella, cómo se propaga la información. Conceptos como árboles de datos, dominios numéricos, transformaciones matriciales o interpolación dejaron de ser abstractos y se volvieron cotidianos.

Diseñar relaciones en vez de diseñar forma, esa fue la revolución de Grasshopper

Diseñar con sliders

El efecto sobre el proceso de diseño fue profundo. La exploración se volvió sistemática: en lugar de probar una variante a mano, se definía el espacio de variantes mediante parámetros y se recorría ese espacio moviendo sliders. Grasshopper favoreció el pensamiento topológico y tipológico -diseñar familias de soluciones en lugar de objetos únicos- y desplazó el esfuerzo creativo hacia la construcción del sistema generativo más que hacia la forma final. La desventaja era que el grafo podía volverse opaco con el tiempo: un archivo de Grasshopper complejo es difícil de leer, mantener o transferir a otros, y la distancia entre la intención del diseñador y el resultado visual a menudo puede generar sorpresas no siempre bienvenidas.

El dominio real de la herramienta llegaba ,en teoría, cuando el diseñador podía leer un grafo como otros leen un plano -entendiendo de un vistazo qué produce cada parte y por qué. Esto era literalmente imposible en el nudo de cables de Grasshopper.

Y de pronto, Claude

Durante años, la alternativa a los grafos interminables de Grasshopper era escribir componentes personalizados en C# o Python directamente dentro del entorno -algo que requería conocimiento real de programación y seguía atado a la lógica interna del canvas. Lo que cambia con modelos de LLM como Claude es significativo: la barrera de entrada a escribir scripts colapsa casi por completo. Una vez mas, no es necesario saber programación para poder programar.

Un diseñador que entiende qué quiere geométricamente -una serie de paneles que rotan en función de la orientación solar, una estructura que vapora su densidad hacia los bordes, una trayectoria robótica que sigue la curvatura de una superficie- puede describir esa intención en lenguaje natural y obtener un script de Python funcional listo para insertar en un componente GHPython. Lo que antes exigía conocer la API de RhinoCommon, la sintaxis de manejo de listas en Python y la lógica de árboles de datos de Grasshopper, ahora puede resolverse en una conversación. El diseñador aporta el criterio de diseño; el modelo aporta la traducción técnica. En el mejor de los casos, claro.

El efecto práctico es que operaciones que en el canvas de Grasshopper requerirían docenas de componentes encadenados -con toda la complejidad visual y fragilidad estructural que eso implica- se condensan en un bloque de código limpio, legible y modificable. Un lenguaje mas o menos universal que personas y LLMs pueden compartir, cosa que los nodos y cables de GH opacaban.

Un solo componente GHPython bien escrito puede reemplazar un subgrafo de cuarenta o cincuenta nodos sin problemas, y además es más fácil de entender, documentar, mantener y compartir. Hay un sólo problema.

Los arquitectos seguimos sin aprender a leer código.

No sé cuales son los planes de Rhino respecto a Grasshopper (un tweet me recordó que existe algo llamado Grashopper2 hace años), pero por experiencia propia, es mucho más simple programar un componente personalizado que ponerse a conectar baterías con cablecitos.

El próximo paso seguramente sea repensar y esquivar todo el proceso de GH y hacer que el usuario describa lo que quiere y más importante aún, cómo controlarlo. Obviamente describir algo con palabras en vez de con formas, modelos o bocetos es bastante mas complejo, el entorno de Rhino y GH hacen que el feedback sea bastante fluido.

En unos días volveré a escribir para dónde creo que va a ir esto con un par de ejemplos.

Buen domingo.