Adapting Computation to Adapting Landscapes

Originally published in Kerb 21: Adapted Practices.

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. Many feature a thriving online ecosystem of shared 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.45

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 can be readily translated into code, 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 form 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 must 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 these tools by integrating 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, the applications of fabrication are more limited in landscape architecture, where both soft and hard landforms must be constructed. Without new technologies that address tasks such as grading and planting, the level of complexity that can be constructed efficiently remains limited.

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, Architectural Design and Programming (John Wiley; 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, ed., Digital Landscape Architecture Now (Thames & Hudson Ltd, 2012).

  3. Daniel Davis et al., “Design Ecosystems: Customising the Architectural Design Environment with Software Plug-ins,” Architectural Design 83, no. 2 (March 2013): 124–131.

  4. Peter Connolly, “What is Design Research in Landscape Architecture?” in Technique (RMIT University, 2002), 20–33.

  5. Nadia Amoroso, ed., “Drawing the Landscape,” in Representing Landscapes: A Visual Collection of Landscape Architectural Drawings (Routledge, 2012), 63–71.

  6. Following Pia Ednie-Brown, “Programming involves diagrammatic thinking, operating through notating and mapping out the interplays of relations.” Pia Ednie-Brown, “All-Over, Over-All: biothing and Emergent Composition,” Architectural Design 76, no. 4 (July 2006): 72–81