Today I started to work again a bit into Grasshopper, with the initial intent of grasping a bit of the VB.net language. The first task I set up to do was to convert an old Python script to calculate sun position information on a defined location and time. It was initially presented to me by Tobias Schwinn, which in turn based it on an original version from Carlos Lara. The math behind the sun position calculations was taken from this website.

It still does not do much. I will further work on another definition to create a sun diagram in Grasshopper, and later one to work out incident angles on objects. Please, keep in mind these are personal exercises, without much defined goal, and not entirely well written. But it might be useful for some people, so here it is.

Definition: solarPos.ghx

As a part of the course I teach at Bauhaus-Dessau Institute of Architecture, I developed a Delaunay class in Python for Maya to generate the triangulation via mathematical operations (I was also, in the course, using Qhull), based on the algorithm developed by Paul Bourke. It is still very crude and needs lots of works, but it does generate fast and correct triangulations in its current version.

Next step would be to automatize the class to update the triangulation in real-time, and to create user interfaces to make the whole process a bit more friendly. The ultimate goal would be to make it into a plugin for Maya,which I am far away from accomplishing. I guess I won’t develop it much further, but for anyone interested, here is the Python script to download.

One thing I have been noticing after teaching Python+Maya for the last 2 years, is that maybe this is not the right tool for beginners. Contrary to tools such as Processing, or Grasshopper, scripting with Python in Maya has a very long and steep learning curve. You can produce amazing things, but only after a certain amount of time and investment, which in a 4-day workshop is a bit hard. I was pleased, though, with the final results, and I guess the students were quite excited about all the possibilities these new tools bring to your design practice.

Group Eight (Taseva Tanja, Efremovski Martin, Stilinovic Mladen)

Group H_F_H (Lilitkin Sanja, Pejoski Martin, Nikolovski Ivan)

Group H_F_H

Group myGroup (Dojchinoska Dobrica, Strezovska Borka, Arsov Nikolche)

Group Lulala (Nadica Bogoevska, Jasmina Abdul, Petrovski Aleksandar)

Group Lulala

Group Seven (Tonka Anodova, Radica Ugrova, Ivana Stefanovska)

Group Asymptote (Zlatko Lazarovski, Marta Ilievska, Aleksandar Bocevski)

The whole group in the final day

Workshop poster

When seeing the current GH production on the web, I am constantly reminded of the times when Flash was introduced and started to become very popular among web-designers. It was so easy to animate something and put on the web, that it didn’t take long for tons of animated websites to start appearing. But most of them were clearly produced without any critical thinking about them. To produce something really interesting, one had to learn the hard part of Flash, which involved Actionscript.

I feel the same with GH: to really dive deep in it and do interesting stuff, you cannot escape from scripting, either in VB.net inside GH, or by complementing GH definitions with Rhinoscripts run in parallel. Coming from a scripting background (namely Python/Mel in Maya), I see this as a natural and good thing to happen. No nice and easy to use interface will provide deep and complex results.

I do recognize the importance of GH for those starting to think design in a parametric way. It is straight-forward and easy to use, and a great tool to introduce scripting and programming concepts for the novice, and to perform quick and dirty tasks on the fly. And it only makes you hungry for more, which will eventually lead to interesting future developments. I am just afraid that the lack of real understanding about what is happening in the background of all those nice interconnected components will end up producing superficial, eye-candy results, instead of critical parametric architecture.

It was my first “deep” experience with Grasshopper, as I had already messed up with the plugin before, but just superficially. This time, we chose the most difficult topic (dealing with movable components), and I dived into it to produce my first full-working definition.

We did a surface composed by small components which open and close in a system, allowing several regulations of openings. Here are some images of the process:

Grasshopper definition: complete mess

Detail from the GH definition: basic parameters to control the components' variation along the surface

Final surface

Final surface: detail

Open state: positive shearing

Semi-open state: positive shearing

Closed state: positive shearing

Components ready to be assembled

Single component

Component: no shearing

Component: negative shearing

Component: positive shearing

First prototype: folding elements

Putting the assembled components into place

Finalizing the structure

Detail

Final surface: note the variation on the components

This project was realized together with Dorothea von Rotberg and Alex Mitxelena, under the supervision, among others, from Luis Fraguada (LaN), Dimitrie Stefanescu, Ioulietta Zindrou, Maite Bravo and Verena Vogler (all from Iaac in Barcelona).

Resources:

GH definition file: just keep in mind it is my first ever GH definition!
Base .3dm file: you basically need two surfaces, one planar where the components will be applied to, and another one defining the thickness of the components

so parametric… is yet another blog about research and trials concerning parametric architecture and its implications in our practice as architects. I was inspired by so many blogs you can find in the cloud, and my intent is not to be anything different or revolutionary, but to add my own view and experiments to this fascinating field of research.