Technology is often seen as ever-expanding, growing and evolving force. It continues to abstract, enhance, and improve our experience. Technology has the ability to bring us closer to what we really want, which I believe has nothing to do with technology.
I could join the resistance against the mindless filling of space with computationally determined forms but instead I stand in defense of the other, the intuition that we are born with, the centering or reminding of another type of experience, an alternate future.
I find that excessive reliance or an obsession with tools clouds this understanding. I don’t always want to be asking what and why, but I do want to be moving closer towards the one, as opposed to expanding infinitely away from it.
Journal entry, 5/18/2014
A recipe for a physics-based
After reading master-gardener Jinny Blom’s book, The Thoughtful Gardener, followed by Piet Oulaff’s Planting: A New Perspective, I came to the conclusion that my garden is far from optimal. But without dextrous knowledge of hundreds of garden plants to call upon from memory, could I instead create a database and optimize it algorithmically?
I set out with the intention of using a genetics-based or simulated annealing solver, but did not know how to address the packing aspect of the problem. Researching supplementary tools, I came across Kangaroo, a physics engine for Grasshopper. I haven’t used this tool beyond the most basic of tutorials, but maybe something like this would work? See below.
The first step would be to gather all data about a selection of possible plants and the garden site.
Ouldolf provides a helpful index of plants that he uses commonly for planting gardens, based on general hardiness in temperate climates and low-maintenance qualities. This would be a good place to start but should be cross-checked with other horticulturists’ recommendations.
Data fields would include: Scientific name, common name, hardiness zone, recommended soil quality, soil moisture, light exposure, height, average area per plant, recommended minimum plants per spot, plant height per season, structure typology (as classified by Ouldolf for starters), foliage shape, foliage color per season, bloom period, bloom color, bloom shape, bloom size and photos of the plant for reference. Longevity, spreading ability, persistence and self-seeding ability could be included for advanced modeling down the road.
I would assume all pest- and disease-troubled plants would be pre-eliminated from the table, though eventually this could be optional for those gardens that for some reason or another aren’t susceptible to certain problems due to conditions of the site—for example, the existence of a 100% deer-proof fence.
As for the site model, the garden boundaries would be defined as any free-form three-dimensional surface. Non-plantable obstacles such as tree trunks and stepping stones would be noted.
In addition to physical topography there would be several layers of data that describe growing conditions as they change throughout the site. These would include relative soil quality, sunlight, moisture and ideal plant height. These layers would have their own topographies of data and could be modeled by interpolating a mesh from a grid of sample values, or in the case of plant height, could be defined either ‘by design’ or generated from site geometry per the existence of vertical structures and/or the proximity of unsupported garden borders. Similarly, sunlight and moisture theoretically could be generated based on geometry and environmental factors that exist in the model (albeit a very large and complicated model), however the most reliable approach might be to physically install a grid of sensors throughout the garden bed and monitor the data throughout all four seasons, with special emphasis on the growing season, forming a conclusion about general year-round qualities. Or, the garden designer could simply estimate values based on obvious features such as tree canopies, visibly wet and dry areas, etc. It’s important to keep in mind that the rating of microsite conditions can only be as specific as the descriptions of the plants’ ideal habitats, which is rarely (never?) quantitative.
Define the nursery
To begin the simulation, the script would first examine hardiness zone, global maximums and minimums of all of the topography layers and any other global constraints set on the array of possible plants (i.e. no yellow blooms). The remaining plants would be defined as the nursery and assumed to be in infinite supply per plant unless specified otherwise.
Populate the garden
Plants would be modeled as deformable particles with consistent area. The area for each plant would vary, depending on the recommended minimum area defined per species, or via custom input from the designer.
A certain number of instances of each plant particle would be positioned vertically over a flat plane that shares the same domain as the site topographies. The plant particles would be randomized and then ‘dropped’ from above. The intention is that plants and plant clusters would self-organize into a sustainable and attractive arrangement.
Biological needs provided by micro-site conditions
Data from the site topographies would be referenced as forces that act on the fallen particles. Plant particles would be attracted to areas with matching properties and repelled by those with non-compatible properties. There would also be a neutral reaction. The force of attraction or repulsion to a certain area on the site would be equal for all particles, except in the case that some plants might be programmed to seek their matching locations with greater force due to a stronger-than-average need of that plant for a certain quality.
Generating design interest
Just as the plant particles are affected by forces provided by micro-site conditions, they would also react to forces among other plants. These forces would essentially control the overall appearance of the garden throughout the seasons.
Attraction, repulsion and neutral reactions between values of the following data columns would be defined: structure typology, foliage shape, foliage color, bloom period, bloom color, bloom shape, bloom size. These reactions could be adjusted if the designer wanted to change the rules of combination (for example, grass-like plants could be attracted to other grass-like plants by design) but the default case would assume maximum diversity in all of the above.
Biological necessity to design ratio
Because there are so many forces at work, it might be necessary to define a hierarchy in the magnitude of various forces. The forces related biological needs of the plants should probably be defined as stronger than those of design. But the pull/repulsion force for each parameter should be individually addressable so a designer can prioritize his or her intensions.
There would be three layout modes: block, random, and hybrid. In the block layout, plants would be set in designated cluster sizes before dropping. Like the plant particles themselves, these clusters would be deformable. For the random layout, plants would be dropped as singular entities (at their minimum recommended planting size i.e. three plants per foot or one plant per 8”). The hybrid layout combines these two methods. The designer could designate some plants to be dropped in clusters and others to be dropped singularly. In the plant data, each species could be recommended, not recommended or neutral for both types of plantings.
After the simulation is performed, the program should check for errors. Plants that have ended up in unsuitable growing conditions should be highlighted and replaced.
Once the basic mechanism of attraction and repulsion of particles and areas on the site are in place, one could experiment with different population methods. For instance, how are the plants that do not seek a place on the site treated? Do they bounce off of invisible walls until they find a free spot? Is the layout plane tilted this way and that until they settle? Are the unplaced plants gathered and dropped again until none remain?
Plants could be dropped all at once or in predefined groups (this could ultimately lead to a new layout type). Or rather than dropping from above, the plants could be pushed across the site from one or several directions. Or maybe the simulation is modeled in a water tank-like environment, similar to those used by the Self-Assembly Lab at MIT.
Without actually running the simulation, it’s difficult to predict how the plant particles would interact after the moment they are dropped. I would be curious to see if adjusting the time in which the plant-to-plant design-related forces are active affects how thoroughly the plants self-organize. For instance, if the forces are enabled before the plants are dropped, they will already be organized in clusters of compatible design relationships. This might be a good thing—if the plants need all of the time they can get to self-organize—or it might limit the range of possibilities.
When the simulation is complete, the design could be visualized by turning on a ‘viewer’ layer. Simplified and/or abstracted representations of plants would appear when this is toggled. The rendering would be with respect to time, controlled by a slider parameter set per month, that would show flowers’ bloom periods, bloom colors, foliage colors, approximate heights, and any structural changes that might occur throughout the seasons. This model data would be referenced per plant species and simply repeated for each instance of the plant particle in the design.
A more complex case of this feature would take into account micro-site conditions and make adjustments such as plant height based on typical performance of that plant. For example, some plants grow well in average to fertile soil, but plants in more fertile soil will grow taller.
Taking this one step further, the rendering could draw upon longevity, spreading persistence and self-seeding data from the original plant table and create projections for the appearance of the garden in 2, 5, 10, and 20+ years after planting.