Adapting Computation to Adapting Landscapes

Originally published in Kerb 21: Adapted Practices. Cited as Belesky, Philip. "Adapting Computation to Adapting Landscapes." Kerb, no. 21 (May 20, 2013): 50–54.

Since the 1960s, architects have experimented with the architectural applications of computer programming. Over the past decade, these investigations have become increasingly refined, forming a body of computational design practices that are now regularly used in the architectural design process.1

In contrast, few landscape architects have adopted computational design practices.2 At first, this lag in adoption seems odd. Various computer-aided design programs, such as Rhinoceros, are common to both professions and features a thriving online ecosystem of free scripts and plug-ins that enable designers to easily use and share computational techniques.3

One reason that few landscape architects have embraced computational design practices is that they can be unfamiliar and unsuitable. The current canon of computational design techniques is distinctly architectural, aimed at generating and optimising form so that architects can better design complex geometries, complex structures, and complex details. Looking to the few landscape-focused practitioners who do use computational tools, we see designs that typically feature branching, flowing, twisted, folding, and fracturing surface geometries. Here, the formalisms common to the architectural avant-garde have been appropriated by way of a 90-degree rotation: façades turned to become fields.

This approach has its place, but such techniques are not viable or desirable responses to every design problem in landscape architecture. Landscapes are dynamic, subject to the shifting-states of natural systems. In the face of this dynamic complexity, contemporary practices often turn to diagrammatic representations that define process-driven design strategies. Yet, there is a tension between the productive abstraction of the diagram and the need to rigorously resolve its assertions against the actual conditions of a site.4 5

The computational design process offers a means to release this tension. It requires the designer to translate portions of their design intent into computer code using a textual or graphical programming interface. At any point during this process, the computer can resolve the logic of the code, rendering it into 3D form and testing its performance against various criteria. For landscape architects, diagrammatic design strategies are typically very amenable being translated into computational logics, as programming itself operates through a similar process of mapping and organising concepts.6 By doing so, the quantitative and qualitative effects of processes and relationships that were previously asserted in diagrams can now be tested — automatically and in detail — against the goals and context of the design.

This presents a way to design landscapes whereby the medium of the design process begins to resemble what it represents. Unlike plans or diagrams, a computationally defined design emerges from a series of generative rules that establish a dynamic system. By creating rules that account for the temporality, uncertainty, and dynamism of landscape systems, we can begin to make these phenomena truly operative within the design process. A design for a waterfront could be seamlessly tested against simulations of the hydrological systems that govern tidal flushing, coastal erosion, sea level rises, and storm surges. Planting plans could automatically match particular species to local changes in substrate, grade, saturation, and shading, while maintaining a cohesive composition that maintains ecological diversity and aesthetic effects. These capabilities are already present in our current design process. But rigorously analysing the effects of ecological systems is often an arduous undertaking that may require specialist knowledge. By outsourcing these tasks to the computer, they can be performed effortlessly, allowing intuition and analysis to act in tandem throughout the design process.

However, the potential of a computational landscape architecture is presently limited by a lack of computational techniques that focus on landscape systems. In the same way that architects have created tools to simulate how structural, solar, and thermal systems operate, we should develop tools that make hydrological, ecological, and other landscape systems active within the design process. These tools exist within scientific research and specialised software; the challenge is to adapt and integrate their capabilities into the computer-aided design programs that landscape architects already use.

If this challenge can be overcome, it is unlikely that the introduction of computational tools would have the same effect as they have had in architecture. Whereas digital fabrication and digital design techniques acted as complementary catalysts that enabled architects to expand the limits of what could be built, advanced forms of fabrication have less relevance in landscape architecture given the primacy of landform and vegetation. Instead of enabling formal novelty, a computational practice of landscape architecture would generate a more subtle, but substantial, benefit. If we can better analyse and understand how our designs interact with the complexities of dynamic landscape systems, then many aspects of the design process stand to gain. Adapting computation might not change the capabilities of landscapes, but rather improve our own capabilities as landscape architects.


  1. Mark Burry, Scripting Cultures (West Sussex, England: John Wiley and Sons, 2011).
  2. As an example, Digital Landscape Architecture Now, details the work of 39 practices, 17 of which are identified as using computational tools such as Grasshopper. However, only 6 of the 17 could be broadly classified as landscape-focused practices (such as STOSS) rather than an architecture-focused practices (such as Zaha Hadid Architects). For more see Nadia Amoroso, Digital Landscape Architecture Now (London, United Kingdom: Thames & Hudson Ltd, 2012).
  3. Daniel Davis, “Modelled on Software Engineering” (Doctoral Thesis, RMIT University, 2013).
  4. Peter Connolly, “What Is Design Research in Landscape Architecture?” in Technique, ed. René van der Velde and Peter Connolly (Melbourne, Australia: RMIT University Press, 2002), 20–33.
  5. Richard Weller, “Drawing the Landscape,” in Representing Landscapes: A Visual Collection of Landscape Architectural Drawings, ed. Nadia Amoroso (Abingdon, England: Routledge, 2012), 63–71.
  6. Following Pia Ednie-Brown, “Programming involves diagrammatic thinking, operating through notating and mapping out the interplays of relations.” Ednie-Brown, Pia. “All-over, over-All: Biothing and Emergent Composition”. Architectural Design 76, no. 4 (2006): 72–81.
With thanks to Johanna's editing, and to Dion's questioning.

I'm a designer, developer, and educator who likes to work on tools for mapping and modelling. More about me