Embryo

I've decided to release at least an alpha version of Embryo for people to play with. It's been too long, and my dreams to get all bugs ironed out have faded away like tears in rain. Anyway, here it is :)

Embryo introduces ideas from Genetic Programming (GP) (not to be confused with genetic algorithms) to Grasshopper. It would be nice to get people thinking about working at higher levels of abstraction in a design computing context. It was the late Paul Coates who introduced me to GP in architectural design ten years ago.

Simply put, the idea is to write a program that writes a program (or in Grasshopper, generates a dataflow-based definition). There are good reasons I believe for looking into this outlined in my thesis (a kind of manual for Embryo is given in Chapter 6).

The three examples included should give an idea of what can be done, although I will upload more in due course as these only scratch the surface. Getting Embryo to work with Galapagos proved to be a bit of a challenge. The example included in the zip only shows a simple combinatorial problem that can be solved with Embryo, but the potential to find new parametric definitions for existing geometry is an exciting one.

Please note that there are some known bugs. For example, attempting to delete the component whilst active will crash Grasshopper, an event that I haven't been able to deal with yet. Also, I would advise not creating more than 1,000 components if you can help it!

One final point - I am not a software engineer and nor do I want to become one. Embryo should be seen as an idea more than a polished piece of software, but I'm curious to see if anyone cares or can use it in a meaningful way.

I will put the source up on git in due course if anyone is interested in how to manipulate components on the canvas and the suchlike, or branching to create their own Embryos.

(typical Embryo setup with random input)

(using gene pools and galapagos)

(component list)

Attachments:

Embryo-0.4.1.zip, 118 KB

Replies to This Discussion

Permalink Reply by Fred Becquelin on August 4, 2015 at 0:07

Hurrah!
I wish I wasn't on holiday...

Permalink Reply by Ángel Linares on August 4, 2015 at 4:01

YEAHHH!!! Just in time! Thanks for the effort and the amazing work!! I have to give it a try. The concept behind this plugin is veeeery interesting. I would definitely take a look at that code :)

Permalink Reply by Amir Soltani on August 4, 2015 at 12:37

This is awesome! thank you for the link to your thesis and congrats, it is very interesting and informative indeed. I'm also very excited to try Embryo Alpha, thank you again for sharing it.

Permalink Reply by djordje on August 5, 2015 at 2:52

One more big "Thank you" for sharing the project John!!

Permalink Reply by Marios Tsiliakos on August 5, 2015 at 2:58

Very nice indeed John,

Let's see where this leads too.

Will post back any interesting findings.

Cheers,

Permalink Reply by Thibault Schwartz on August 5, 2015 at 4:48

Really nice!

Permalink Reply by Arthur Mamou-Mani on August 5, 2015 at 5:34

Amazing - Downloading now :) Thank you so much John!

Permalink Reply by Chris Mackey on August 5, 2015 at 16:08

THIS IS AWESOME!

Very excited to play around with this. And the source code would be an invaluable learning resource!!!

Thanks for keeping it open!

Permalink Reply by Daniel González Abalde on September 1, 2015 at 12:25

Hi John,
Thank you for your fascinating work. Some considerations:

1. How can I pick up the curve geometry type? The GetGeometry component seems does not to want help me.
2. When you do not use the override random, the workflow is fucking hard. I understand the scheme topology/function, but is difficult to handle. Could you, when you can, publish some example more about this?.
3. Would it not be possible (and easy) adding a component that blocks the use of a parameter? That is, in the ingredients, inserting a component to the inputs that will not be used (and not considered by the topology).

4. Would it be useful to add a couple of components that act as magnets to add probabilities of connection between two components? That is, between output of a component of the ingredients, and the input of another component.
5. Would it be possible to add groups of connected components, rather than individual components in the ingredients? It's a nuisance having to individually deduct the map of connections. It would be nice to have the option of using a piece of definition as a component itself.
6. Why you have implemented this topology/function format? Did you take into consideration do with tree-path format? But I do not really know what I'm talking about.
7. Can you establish a list of intervals, rather than a single possible for the sliders domain?

It was cool to get into that, although I have seen just a little your thesis, some of my neurons have been exploited by overheating. Thank you, what do you currently do?

Permalink Reply by John Harding on September 10, 2015 at 12:18

Hi Daniel,

Thanks for your response, much appreciated. Some replies:

1. What is required is something like the geometry pipeline, otherwise you'll get everything. I'll make sure its there for the next release.

2. Of course, I agree the support is woeful for this at present. Find attached an example of trying to find a completely new definition for a target geometry. Using galapagos with these inputs help the machine get quite close. Obviously, its a combinatorial problem so bloat is an issue.

3. It's a great idea, and a thought I've had on the todo list. It's trickier than you think though due to the way you have to instantiate a component on the canvas. In addition, persistent data in the ingredient components that exists in the generated ones is possible.

4. Again, yes options for the inputs is a good idea and one I'm working on.

5. Indeed. Ideally, you should be able to put clusters in the ingredients. This is where things start to get very tricky without the help of David :) . If I can get user objects to work, then that's a step in the right direction. At present, you need to compile new components to get Embryo to include them.

6. Because it was the easiest to implement with the gene pools. Revising this to make it more efficient is a good idea, because at the moment it aint.

7. Good idea. I can include that in the options component.

Finally, just to say implementation in Grasshopper has its pros and cons, it's obviously not built for this kind of thing. In the future, I'd like to build an independent plug-in for Rhino that will handle GP better.

Anyway, thanks for having a go! I still intend to make the repository public.

As to what I do, I used to lead the Ramboll Computational Design team in London but we've all gone our separate ways now. I'm now a lecturer in Computational Design at the University of West of England (UWE) in the UK.

Attachments:

example-004-shapeanalysis.gh, 24 KB

Permalink Reply by Zeynep Aksoz on October 8, 2015 at 11:08

Hey John!

Very strong tool. However I am having problems getting the geometry in to the parent space i.e. if i am trying to connect more than one components from child space the get geometry componen does not accept any input. Did you ever had this?

Can you also open up a little more about parent input and parent output components?

And in the ingredients some components as interpolate(curve) or loft are not necessarily working in my case. Can you open up on this a little bit as well?

Thanks for the great tool

Cheers

Permalink Reply by John Harding on November 7, 2015 at 16:40

Hi Zeynep.

Some answers:

Embryo will not currently accept more than one wire per input, hence cummulative lists are a bit of a problem (hence why interpolate or loft won't work). In theory, using a merge component before them should work (stick one in the ingredients). What is really required is that not just single components but 'bits of graphs' (or even using clusters) should be used to assemble the model (see point 5 in the thread above). Coding this is quite tricky without being David, and perhaps this is where Grasshopper isn't the correct platform.
Parent inputs and outputs are used to tag parameters on the parent canvas for inclusion in the graph generation... so you can tag the output from a slider for example in the usual canvas space (see attached example).
Not sure about the getGeometry not picking up information. Can you upload an example? Try adding something downstream of the GetGeometry component to trigger it.

John.

Attachments: