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.

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.

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

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.