Background to Embryo

Firstly, let me start off with an apology that the initial release of Embryo will be a little later than first anticipated due to many pesky little things getting in the way of development! I can't give a revised date just yet but hopefully it should not be too long. Thank you all for joining the group however, it's nice to know there is some interest for the project and I hope you will forgive me for delaying the release date $:)

I would like to give a little background as to why I started this group and how the Embryo concept for grasshopper initially came about. The short version is probably best stated in mine and Sam Joyce's abstract for our “Thinking Topologically at Early Stage Parametric Design” paper (preprint) published at the recent Advances in Architectural Geometry (AAG) conference:

"Parametric modelling tools have allowed architects and engineers to explore complex geometries with relative ease at the early stage of the design process. Building designs are commonly created by authoring a visual graph representation that generates building geometry in model space. Once a graph is constructed, design exploration can occur by adjusting metric sliders either manually or automatically using optimization algorithms in combination with multi-objective performance criteria. In addition, qualitative aspects such as visual and social concerns may be included in the search process. The authors propose that whilst this way of working has many benefits if the building type is already known, the inflexibility of the graph representation and its top-down method of generation are not well suited to the conceptual design stage where the search space is large and constraints and objectives are often poorly defined. In response, this paper suggests possible ways of liberating parametric modelling tools by allowing changes in the graph topology to occur as well as the metric parameters during building design and optimisation."

Put simply, coding, generative modelling, scripting, etc... all encourage us to lay down design intent at a very early stage, and that intent can then be very hard to escape from if we still wish to indulge in the kind of broad design exploration that the concept stage requires. The inherent inflexibility of programming languages, be they visually represented as a graphs for example or just as pure code is well known by programmers. Good modular structuring of code or neat graph (network) representations can help mitigate and facilitate change, but essentially in an architectural design context the topology of a grasshopper network can be hard to break free from once laid down on the canvas top-down. We can often reach a position at concept stage whereby design exploration takes place with slider variables on only one or at best a few associative models before we really know what our intentions are. This occurs not least because concept stage is when we have the least amount of time to make adjustments ... making 100 different associative models is not a realistic possibility!

Image showing a variety of massing models at the early stages of a tower project. Most require a separate associative model (topological representation) be made if created in grasshopper, even if sliders allow certain metric freedoms.

In terms of architectural computing, this topology problem was acknowledged back in 2001 by Manual DeLanda in his paper: “Deleuze and the Use of the Genetic Algorithm in Architecture“. He asks designers to think not just in terms of metric sliders, but also think topologically about the ‘body-plan’ of a design if manual or automated search algorithms (not just GAs) are to be used not just to solve explicit problems but also to generate novel and surprising designs by using a computational approach. Eleven years on, this paper is especially relevant today because of the following developments:

1. Decision support tools are becoming better integrated and are moving earlier and earlier in the design process. One only has to look at the variety of analysis components available that either David has created in grasshopper himself or exist as third-party components that give designers more and more quantitative feedback on building performance at the early stage. The availability of such components is only likely to increase in the coming years.

2. Solvers are becoming available to the masses. Before, one had to program their own search code or at least know how to import and implement the appropriate libraries. The release of Galapagos was an important moment in architectural design in that knowledge of coding was no longer necessary for designers wishing to engage in hands off search processes, just an ability to understand a visual programming graph based interface such as grasshopper. Multi-objective solvers are just around the corner.

Due to all of the above, I started to wonder if anyone had thought about opening up the structure of the graph to be automated (not crafted explicitly top-down) so that a design's ‘body-plan’ could be open to change as De Landa argues is necessary in a healthy design search. Inspired by Dawkin’s Biomorphs, this could potentially allow the automatic exploration of different building typologies that are represented by different graph structures and not just variables, as required in the above tower design example.

The Stream Gate Component hooked up to Galapagos.

The stream gate component makes a claim for this. Theoretically a numerical slider (which may or may not be associated with Galapagos) can be hooked up in order to explore different network paths. However there is a catch as each avenue must still be explicitly laid down by the designer and hence realistically only a small number of alternative options can be explored unless again you have time to lay down many different potential networks. Instead, you may wish to let go completely and allow the machine to create visual graph structures (or programs) automatically... perhaps ones that can go beyond human cognition (this is a direction that I hope to explore with Embryo).

In opening up the automatic generation of graphs, one has to look at a higher level of abstraction for controlling the process... there is always human involvement somewhere. Such a strategy takes inspiration from the field of Genetic Programming (GP), pioneered by John Koza in the 1990s. In standard GP, computer code is generated automatically, initially represented as LISP tree structures but has now coincidently been applied to directed acyclic graphs (the type used in grasshopper), even allowing graph structures and their components to have a bit string representation. This field is called Cartesian Genetic Programming. Bloat issues are a well-known problem with GP and Embryo will have to tackle these. The beauty of using grasshopper to play out such an approach however is that geometric primitives are already present in the software, as well as their instantiation methods in the compiled component (unlike GC for example). Custom components can be utilised in a similar manner to the functions in CGP.

So anyway, I hope this gives some background to the project. Some of the other major influences that I haven't crammed into in this short introduction (but will no doubt bring up at some point) are the following:

• Shape grammars
• Evolutionary Development (Evo-Devo)
• Morphogenesis
• Lindenmayer Systems (particularly the work of Paul Coates)
• Artifical Embryogenesis

With regards the last point, the name Embryo actually comes from Lewis Wolpert’s book ‘The Triumph of the Embryo’ that has had a big influence on my thinking and although slightly out of date, I urge a read if you have not discovered this book already.

So I hope this can be a place for general discussions about alternative graph manipulation methods as well as the place to discuss Embryo. I'm also excited about the potential of hooking up Embryo to Rabbit, SPM Vector Components, Hoopsnake, Kangaroo etc... but that is all way off in the future! Finally, here is a sneak preview of a very simple example of one of the Embryo components - in this case generating some small graph structures with only a few 'ingredient' components on a blank child canvas:

Embryo - (Very) Simple example from john harding on Vimeo.