In the first theoretical part of my blog I talked about How I see myself in the process of Design. Now I would like to get started on how I would go about my process, changing the original Genr8 plugin.
First of all, as I started to gain interest in the topic of artificial life, and started to conceive a project of my own, I soon realized how different this was from anything I had ever done before. You see, the creative process in Architectural design as an art is surrounded by myth, but in truth is a very simple(but painful) process. People like to think that the best ideas ever conceived have come in the form of sketches on napkins while sipping to red vine in some exotic location. It is just not the truth. This way of regarding the artist or the process will get you nowhere intellectually.
Parametric Design software has been conceived as a method of correlating dimensions and variables with geometry where as when the fundamental part- values change, whole segments change as well. Using this with CAD – Software it is supposed that you get a degree of creativity in the process because you would actually see the result of your actions immediately. (Like a paralell to scripting)
Well, as I talked about in my first post(A1), you are still working with the notion that your ONE hand so to speak, is creating the masterpiece, because so many considerations have to be taken into account for EVERY LINE THAT YOU DRAW in your models.
So my idea has been to introduce stochastic principles, probability and evolution into the mix.
There is no magic, there is no reinventing the wheel. I am simply asking ; why not try to design a system that can produce millions of designs where all those considerations(read: parameters) are taken into account – All the considerations that you cannot keep in mind when designing by “hand” ? Why not try, instead of fighting the current ?
Basically I start with the pieces of software that I introduced earlier, namely Autodesk Maya and the Genr8 plugin. The Genr8 plugin which is a plug-in application, an extension of Autodesk Maya 3D – software, is described in its entirety on the website linked above. The literary references and background info take up volumes and will be described on the mentioned website, not here. To me, Maya and Genr8 are both amazing pieces of software, and most of all, they are extendable and can be manipulated. From the designer point of view, the Genr8 Plugin is a mammoth of a plugin, with thousands of lines of code. If you get past this early notion though, it is merely a mental obstacle to get your head around. For me it seems like investing in the first creation of Gottlieb Daimler as far as future design is concerned. What the plugin basically does is generate surfaces based on iterative rules and surrounding forces. Sound familiar ? Yes, the idea came from biology, and plant growth to be exact. A biologist named Aristid Lindenmayer described a system for animating the development of bacteria, which was then brought on to plants and ended up as L – Systems after the creator. It was found that nature’s processes in this regard were quite well described by the systems, and again this spawned ideas in creative minds. One of those ideas were formulated very precisely by Martin Hemberg of the Emergent Design Group at M.I.T. It created the Genr8 plug-in for Autodesk Maya, and through a C++ programmed application incorporated into Maya it seeks to generate, rather than manually describe, a design of a surface through evolution. This is my basic starting point.
What I have done so far is to assemble and compile a debug version of the 2001 Genr8 plugin for newer versions of Autodesk Maya. Post B2 will show how I have gone about it, and also how I have started to analyze the Source code for the plugin. Why ? Because if you learn which code/literary strings trigger which validated processes, you could be in possession of a very powerful tool for further development here. From the authors source code I have generated diagrams in Microsoft Visual studio C++ programming environment, through UML diagrams. These diagrams show how the code works and connects and they are essential to be able to decipher the original programming code. The UML modelling I have done up to this point of writing is very basic and based on dependency, heritage and composition.
So the purpose of my first two posts has been to introduce the idea of visual design on another level than what we are used to as Architects. But there is a giant leap from this idea to the generation of a validated situation(loci) with construction models.
Here I will start with the technical part of the plugin:
To examine the existing relationships and patterns in the computer source code, you can generate dependency graphs. In mathematics, computer science and digital electronics, a dependency graph is a directed graph representing dependencies of several objects towards each other. It is possible to derive an evaluation order or the absence of an evaluation order that respects the given dependencies from the dependency graph. If the derivation of something is possible, is dependent on dependencies of other elements, and the order of them. If there is no starting point, and every element depends on another, we have an impossible evaluation, and so a circular dependency. A dependency graph without such is called a directed acyclic graph.(exemplified in post B3). This is something good which we can work with and which we touch upon again when dealing with the inner workings of Autodesk Maya.
To communicate intentions of software, create layer diagrams(In Visual Studio, you can use a layer diagram to visualize the logical architecture of your system). A layer diagram organizes the physical artifacts in your system into logical, abstract groups called layers. These layers help you identify, describe, and differentiate the kinds of tasks that those artifacts perform. Each layer can also contain additional layers, or sub-layers, that describe smaller specific tasks that discrete groups of artifacts perform. One can then use these diagrams to keep e.g your own code consistent with the code of the original design.
To understand how the code implements a method, generate sequence diagrams.
To explore the structure of existing classes, create class diagrams.
To model and communicate different aspects of the system, draw Unified Modeling Language (UML) diagrams. These tools create a common glossary of sorts, for visualizing and discussing the inner workings of the software.
Software code(like Architectural design project structure) is getting increasingly difficult to manage, because of sheer size and complexity. Also, it is a proven fact that most people need to be able to visualize their ideas through some sort of figurative representation to be able to understand and develop. For explanatory and rhetorical reasons throughout, substituting parts of that rhetoric for simple figures can and will help you in a design process. This is true also when it comes to programming.
So what is important for me when trying to understand the source code through uml diagrams ? For a start I would like to be able to have a diagram that shows me either class – or header files, and then be able to directly inspect these files to see their particular code. In this way I can appreciate what each function, object, sentence or word inflicts on other files, functions, objects, sentences or words. It is obvious that when 1 letter can bring down your whole application, it is necessary to have a control system for it. So while showcasing diagrams as fixed images can help people understand certain principles, it is nowhere near good enough to really analyze the calculations that are being done.
Another important part is the piece by piece method, where you seek to understand each function, all its methods and all its objects. This I am making good use of through extended unit testing. This approach though has to be supplemented, because if you contemplate that “the whole is more than the sum of its parts”, you also understand that pure technical knowledge will not automatically give you a perspective on the design that is finally going to be made, nor the machine that will create it. But I can’t stop there. As mentioned sequence diagrams show what happens when functions are called and which files are involved. This is crucial for being able to visualize for others and yourself the broad strokes of the system, on a canvas that sometimes can seem without boundaries.
So, from there let’s start to generate some visuals. From compiling the code( Blog post B2), you get the compiled dll(Dynamic linked library), or mll as Maya calls it. From this, and with the help of Visual Studio, you can directly from the “Architecture” menu generate some diagrams. I have chosen to create a class – diagram + a dependency graph diagram with the “include file” – option. These can be seen also in blog post B2. The good thing about working with these in Visual studio, is:
In the case of the class – diagram: You can see the hierarchy of the plug – in by way of classes. Also you can when you want jump directly to the code to have a look. Bare in mind that for now I am just using these diagrams to appreciate the code and how it works.
In the case of the Dependency Graph Diagram: Here you can appreciate which files are included in the plugin( Directly or indirectly), which FILES are connected + externals from C++ standard libraries, Maya libraries and externals from windows sdk. Here also you can directly inspect all code by interacting with the diagrams.
For you to be able to generate the diagrams the compile must be completed without errors. Warnings are common, but most diagrams will not build with errors. Refer to blog – post B2 to get an idea of how to do it correctly.
It is said that the virtual function is the “lens” with which you can start analyzing a project. If we start from there we can see that we now have a possibility of much easier tracking code through the project, by just looking at the generated diagrams. If we start to look we can easily determine parent classes and child classes.
That beginning signals the end of this post, with the parts of the software being exposed as I move along…