Thread Truncated (Cap Enforced)
Only the first 20 tweets are unrolled into slides to ensure reliable PDF exporting and high server performance.
Canvas & Ratio
Choose your destination platform format
Layout Template
Choose a content structure for your slides
Preset Themes
Typography & Sizing
Brand Kit Customization
AGENCYConfigure brand assets for headers & footers
Outro Slide CTA
Customize your closing call-to-action slide
Background Pattern
Build Your Carousel
Drag and drop any post card below onto a slide, or use the quick buttons to insert content/images instantly!
<b>Una brebe historia de lo paramétrico</b>
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 <i>lentísimo</i>, pero potente; escribías un <i>script</i>, 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ó <i>Explicit History</i>, un prototipo de lo que sería <i>Grasshopper</i>.
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ó.
<i>Explicit history</i> 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.
<b>La revolución de Grasshopper</b>
El plugin apareció en versión beta en 2007 bajo el nombre <i>Grasshopper </i>(GH), y fue una pequeña revolución silenciosa. Su interfaz de nodos y cables -el modelo de <i>dataflow visual</i>- 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 <i>paramétrica</i>: cambiar un slider redibujaba todo el modelo al instante. Probablemente empezó en Londres bajo Schumacher (que luego escribiría el <a target="_blank" href="https://designmanifestos.org/patrik-schumacher-parametricism-as-style-parametricist-manifesto/" color="blue">Manifiesto Paramétrico</a>), 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 <i>diseño computacional </i>en Arquitectura. Antes era solo modelado 3d, con suerte.
El ecosistema de <i>plugins </i>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 <i>Karamba3D</i> que integra análisis estructural de elementos finitos directamente en Rhino o <i>Ladybug que </i>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 <i>KUKA|prc, HAL Robotics y Robots</i> 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 <i>Ladybug </i>puede alimentar un componente de <i>Karamba </i>para dimensionar una estructura, y esa geometría pasar directamente a <i>HAL </i>para generar la trayectoria de fabricación. Grasshopper no era un modelador sino una plataforma de integración técnica.
<b>Una nueva forma de diseñar</b>
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): <i>se escribe la lógica que la produce</i>. 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 <i>repropaga </i>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
<b>Diseñar con sliders</b>
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 <i>topológico y tipológico </i>-diseñar familias de soluciones en lugar de objetos únicos- y desplazó el esfuerzo creativo hacia la construcción del <i>sistema generativo</i> 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.