21.5.11
Blog Moved Now I've Decided on a Project Title
Like I said in my first post for this master's of architecture studio subject, I was only using this blog URL as a placeholder until I decided on a title for my final project. Now that I've picked it - evolvedDesignInformant - I've copied all relevant posts to a new blog at evolveddesigninformant.blogspot.com and will only be posting master's of architecture stuff to that blog in the future.
19.5.11
Experimenting with Rhinoceros Grasshopper Video 2 Uploaded
I decided to squeeze in a little more "fiddling time" in transit to and from uni yesterday. One of the first things I said I wanted to know how to make in Grasshopper was a smooth, undulating surface. Thus, the aim of this model was to make an undulating surface, with a few extra things thrown into the mix to expand the amount of things I'd need to figure out to get a finished model. If I recall correctly, the time taken for this model was about 90 minutes.
There weren't many hiccups through this video, since I'm getting more used to knowing where to look for the kinds of functions I want. The main sticking point this time was when I tried to give the undulating 2D surface thickness. My initial thought was to duplicate the surface upwards with a "move", and then try the "cap holes" function. However, that didn't work since "cap holes" only works for holes defined by planar curves, rather than intelligently joining vertices with edges, and the resulting closed polygons with surfaces like I'd hoped. I ended up realising an "extrude" was all I needed.
After that, the only confusing thing was figuring out how the solid functions work. At first, I couldn't figure out why two cylinders would no longer work for a solid union when I was trying to intersect them, but then I noticed that Grasshopper's cylinder primitive isn't a closed solid, so trying to perform a solid union for them when their open ends weren't exactly planar would end up failing. After using cap holes, that problem was fixed.
Another thing: I just took a look at PK's blog and saw he'd posted a video using Grasshopper's "Galapagos" capsule. I remember Russell mentioning it in a previous studio class, but I'd forgotten to check it out. Looking at some videos and fiddling briefly with it in Grasshopper to evolve solutions to various simple equations, it seems to be exactly the sort of thing I'd be interested in using to evolve different aspects of my final design!
I'll definitely be using it to see what I can do with it.
There weren't many hiccups through this video, since I'm getting more used to knowing where to look for the kinds of functions I want. The main sticking point this time was when I tried to give the undulating 2D surface thickness. My initial thought was to duplicate the surface upwards with a "move", and then try the "cap holes" function. However, that didn't work since "cap holes" only works for holes defined by planar curves, rather than intelligently joining vertices with edges, and the resulting closed polygons with surfaces like I'd hoped. I ended up realising an "extrude" was all I needed.
After that, the only confusing thing was figuring out how the solid functions work. At first, I couldn't figure out why two cylinders would no longer work for a solid union when I was trying to intersect them, but then I noticed that Grasshopper's cylinder primitive isn't a closed solid, so trying to perform a solid union for them when their open ends weren't exactly planar would end up failing. After using cap holes, that problem was fixed.
Another thing: I just took a look at PK's blog and saw he'd posted a video using Grasshopper's "Galapagos" capsule. I remember Russell mentioning it in a previous studio class, but I'd forgotten to check it out. Looking at some videos and fiddling briefly with it in Grasshopper to evolve solutions to various simple equations, it seems to be exactly the sort of thing I'd be interested in using to evolve different aspects of my final design!
I'll definitely be using it to see what I can do with it.
17.5.11
Experimenting with Rhinoceros Grasshopper Video Uploaded
The video finished rendering and uploading, so here it is!
Experimenting with Rhinoceros Grasshopper
I'm currently rendering a video made using Chronolapse while I toyed around with Grasshopper. Shortly into the video, I decided to give myself something to try to achieve by the end of it - a twisted rectangular prism shape with rectangles along it representing floors. Looking back over it and playing a little more with Grasshopper, I noticed there are a few tools I could possibly have used to make the final form much faster.
However, the main point of this stage of my computer modelling experiment is to get myself familiar with Grasshopper, rather than efficiently producing an end result in one go. As with any experiment, the criterion of success is what is learnt.
The main sticking point was when it came to combining two lists of transforms - one list of rotations, one list of translations - so that I'd get one list of transforms that each represented a rotation and translation. I found out how to combine an entire list of transforms into a single transform, but that was the closest I could get. So, in a bit of desperation and having never before programmed in VB.NET, I fiddled wildly with it in a script until I got my head around how Grasshopper let you handle its parameters and "output" - which is really just any variables passed by reference rather than by value.
The next sticking point was that I couldn't find an object reference that would drastically speed up the rate at which I could throw together the script. I noticed the IDE had an autocomplete list that would pop up as you wrote your script, but it wasn't really comprehensive enough for me to know what each variable or method in the list was for. After Googling for a while and finding nothing, I resorted to looking in the plugin folder for Grasshopper, and found RhinoCommon.xml under Plug-ins/Grasshopper/rh_common/RhinoCommon.xml (relative to the Rhino install folder). You'll probably see a few flashes of it opened in Chrome in the video once I upload it. It was somewhat helpful because I could easily Ctrl+F and enter the name of the type I wanted, and hit Ctrl+G until I found it. Admittedly, that took quite a few Ctrl+Gs at times, but on the way, I was finding a few useful tidbits here and there.
After I got past that point - and a few sundry errors to do with invalid typecasting of Transform to Vector3 - it was fairly smooth sailing.
I intend for my next experiment in Grasshopper will involve generating a form that's a little more complex, but I'm not quite sure what would be appropriate yet.
I'll put the Chronolapse video up in my next post when it finishes rendering.
However, the main point of this stage of my computer modelling experiment is to get myself familiar with Grasshopper, rather than efficiently producing an end result in one go. As with any experiment, the criterion of success is what is learnt.
The main sticking point was when it came to combining two lists of transforms - one list of rotations, one list of translations - so that I'd get one list of transforms that each represented a rotation and translation. I found out how to combine an entire list of transforms into a single transform, but that was the closest I could get. So, in a bit of desperation and having never before programmed in VB.NET, I fiddled wildly with it in a script until I got my head around how Grasshopper let you handle its parameters and "output" - which is really just any variables passed by reference rather than by value.
The next sticking point was that I couldn't find an object reference that would drastically speed up the rate at which I could throw together the script. I noticed the IDE had an autocomplete list that would pop up as you wrote your script, but it wasn't really comprehensive enough for me to know what each variable or method in the list was for. After Googling for a while and finding nothing, I resorted to looking in the plugin folder for Grasshopper, and found RhinoCommon.xml under Plug-ins/Grasshopper/rh_common/RhinoCommon.xml (relative to the Rhino install folder). You'll probably see a few flashes of it opened in Chrome in the video once I upload it. It was somewhat helpful because I could easily Ctrl+F and enter the name of the type I wanted, and hit Ctrl+G until I found it. Admittedly, that took quite a few Ctrl+Gs at times, but on the way, I was finding a few useful tidbits here and there.
After I got past that point - and a few sundry errors to do with invalid typecasting of Transform to Vector3 - it was fairly smooth sailing.
I intend for my next experiment in Grasshopper will involve generating a form that's a little more complex, but I'm not quite sure what would be appropriate yet.
I'll put the Chronolapse video up in my next post when it finishes rendering.
16.5.11
Experimenting with Evolution Programming 2
After today's effort, I've made some significant steps with the evolution program you see milling away in the background whenever you move your mouse in Firefox or Chrome. For a simple description of how to interact with it, wave the mouse over empty space in the background to spawn new "creatures" (squares). Over time, the creatures consume energy and so start to shrink (like a dying flower). To feed a creature to keep it alive, wave the mouse off it and back on it again. If a creature stays alive until maturity (currently 0.3 seconds), it gives birth to anywhere between 1 and 8 children into the adjacent blocks around it. Birthing happens in a reliable manner (eg, most successful births make a child in the position directly below the parent), which you'll probably notice as the creatures appearing to fall downwards like Tetris blocks. Creatures come in two colours, determined by how implicitly nervous they are - blue creatures shiver more the more nervous they are, whereas orange creatures aren't implicitly nervous enough to shiver.
Currently, I have a system that emulates:
Random variation could be added with some careful effort, but I suspect its results wouldn't really manifest in any way noticeably different from what you currently see.
I'm still working on getting a reliable "feeding" method added to the mix, beyond children eating the elderly. What I was trying for a while - and you can still see commented out in my JS draw() function - was a feeding method that let creatures eat adjacent creatures. This was working well, but it dominated the living patterns of the creatures. With only a few creatures near one another, a checkerboard pattern would almost immediately form, with babies being born into the "holes" and getting immediately eaten by an adjacent adult with more energy.
In the attempt to get feeding working in a more complex way, I added a randomised variable that let lower-energy creatures occasionally eat higher-energy ones, but it only either slightly dampened the checkerboard effect, or resulted in flickering graphical madness.
Other than that, I encountered a few interesting phenomena. The funniest was creating what is best described as a race of immortal zombies, because creatures, when dead, were still able to feed off the living creatures near them. Another thing that happened was an explosion in the creature population when I accidentally made it possible for a parent to give birth to more children than it had the energy for.
I should mention that this idea came from a Java Applet that I found. It didn't model evolution, but it did model thermodynamics. Here it is, linked from his website, Repeat While True.
Interestingly, the Applet was made in Processing, which I've seen is installed on the FBE's computers. I don't have immediate plans to try it out since there's so much software I'm already planning to get my head around as part of these experiments, but it's definitely piqued my interest.
Currently, I have a system that emulates:
- Creatures (each square is a potential creature, until one is either born there, or spawned there)
- Genes (of three genes: metabolic rate, aggressiveness, and nervousness),
- Inheritance of genes,
- Replication (because of the above two),
- Energy transfer (in the form of children taking energy from parents at birth, and children absorbing the energy of the elderly if they're occupying the same space when born, causing the elderly to die and be replaced),
- Thermodynamic behaviour for the most part (eg, ignoring energy given by the mouse through feeding and spawning creatures, energy isn't created out of nowhere, and is only "lost" as useless energy).
Random variation could be added with some careful effort, but I suspect its results wouldn't really manifest in any way noticeably different from what you currently see.
I'm still working on getting a reliable "feeding" method added to the mix, beyond children eating the elderly. What I was trying for a while - and you can still see commented out in my JS draw() function - was a feeding method that let creatures eat adjacent creatures. This was working well, but it dominated the living patterns of the creatures. With only a few creatures near one another, a checkerboard pattern would almost immediately form, with babies being born into the "holes" and getting immediately eaten by an adjacent adult with more energy.
In the attempt to get feeding working in a more complex way, I added a randomised variable that let lower-energy creatures occasionally eat higher-energy ones, but it only either slightly dampened the checkerboard effect, or resulted in flickering graphical madness.
Other than that, I encountered a few interesting phenomena. The funniest was creating what is best described as a race of immortal zombies, because creatures, when dead, were still able to feed off the living creatures near them. Another thing that happened was an explosion in the creature population when I accidentally made it possible for a parent to give birth to more children than it had the energy for.
I should mention that this idea came from a Java Applet that I found. It didn't model evolution, but it did model thermodynamics. Here it is, linked from his website, Repeat While True.
About CellShades
CellShades is derived from the concept of cellular automata, showing how complex behaviour of organic appearance can emerge from a simple set of rules. Using the mouse, the user spills liquid onto a virtual petri-dish. If the amount of liquid on any position on the grid remains above a certain level for a prolonged time, cells will emerge there. These cells will move and consume liquid to harvest energy according to a set of parameters which you may change and toy around with.
The intensity of the liquid on the grid is visualized by a color gradient from orange to purple.
CellShades is derived from the concept of cellular automata, showing how complex behaviour of organic appearance can emerge from a simple set of rules. Using the mouse, the user spills liquid onto a virtual petri-dish. If the amount of liquid on any position on the grid remains above a certain level for a prolonged time, cells will emerge there. These cells will move and consume liquid to harvest energy according to a set of parameters which you may change and toy around with.
The intensity of the liquid on the grid is visualized by a color gradient from orange to purple.
Interestingly, the Applet was made in Processing, which I've seen is installed on the FBE's computers. I don't have immediate plans to try it out since there's so much software I'm already planning to get my head around as part of these experiments, but it's definitely piqued my interest.
Subscribe to:
Posts (Atom)