Categories - Main Pages
A -AbstractFeeds - Personal Blog - Master Thesis
The starting point for me personally has been a master degree in Architecture, built upon 3 years at an art college. In addition to this I have been programming in several low level computer languages for 20 years.
So here I will present certain concepts of shape and form through mathematical principles, and how certain people have come to bind them to the practice of design, architecture, art and the notion of aesthetics. Mathematics, through geometry and its sub – concepts and understanding of it, is my prime interest both in art and design now. My contribution through this blog comes in the form of the linkage of concepts and different disciplines, and as you will see, the construction of what I have come to believe to be my idea of the design that has developed in me over the years.
I do not presume to revolutionize design through this blog, I only wish to show what I think computer software industry has made a lot of designers forget ,through the development of interfaces as simple representation of complicated technology. Because once you start to dive into the depths of computational ability you start realizing just how restricted you have been using ordinary graphical user interfaces. And therein lies true revelation.
Digital programming – Competence in a creative process, and why it is increasingly valuable in an ever more complex Architecture.
I will start by saying that instead of a theoretical dispute, I will soon move on to examples and finally my own projects, to show what I feel is the inevitable evolution of the conceptual designer. Most computer software for design do not span the chasms of different disciplines, and so you are stuck with a tool that does nothing for you but produce a replica of what you sketched out as an idea on paper or produce something that you do not comprehend or care about the extents of. Using the software in the manner that the industry dictates, does nothing but keep design paradigms at status quo, which means little real creativity in my book. Also consider this: How are you supposed to creatively master a tool that you don’t really understand on a fundamental basis?
I have to admit that I lacked perspective and control of big Architectural projects, and especially I struggled with the validation of the design process. Maybe it is this struggle that has forced me to try out the creative process on another level. By another level I mean to say putting the emphasis on another part of the design process, and also the problem of reorganizing the management of the process itself. Creating and coding your own tools for a task is what I am referring to here.
Example:
The mathematical calculator is still being used as an independent tool for calculating numbers used in more or less isolated incidents. The relation between the calculation and the use of the calculation is apparent. All laptops in use today have a much larger capacity for calculation than the traditional calculator , but it depends largely on the software implemented on the computer. Given the right algorithms, one can perform a variety of tasks, across the borders of a single piece of software and on to the next. The problem with this capacity is that it requires a large amount of specialized skill and validation of that skill and the tasks, and so calculations can not be directly used as validated design results.
When referring to design on another level earlier on , I am really talking about making a tool that can take decisions for me, scan the universe of possibilities, all according to my recipe, or algorithm. This would in my case be a digital tool that you produce yourself, for the task or tasks that you have set out to handle. This method of working is in Architectural design loosely called tooling, and commercially it has been exemplified in the book “Tooling : Pamphlet Architecture 27 ” by Aranda and Lasch. http://www.arandalasch.com/ or http://www.amazon.co.uk/Tooling-Pamphlet-Architecture-Benjamin-Christopher/dp/1568985479 The problem I have with this kind of approach in general though, is the “starting from scratch” – notion. I felt at least on my own behalf that I should make use of what has been there from the dawn of computers. The consequence and acceptance of the inevitable fact that we will someday get replaced by artificial life.
A method for solving a problem can be called an algorithm. We all use them, all the time. Some are rather simple, some are extremely complex. Algorithms are used in computer programming for solving specific problems, performing certain subsequent specific tasks. The computer does not know what it is doing( as of this write- up anyway 🙂 ), nor does the end-user of a piece of software, and yet these calculations and their organization are what make it all happen. By making software more flexible though, applications can now be extended fairly easily by the end-user. By writing the code for an extension, plug- in, script or routine, or just “plugging it in”, it is possible to extend the capabilities of an application in the way that you see fit to solve a task. Industry standards can potentially be implemented through libraries and classes used in the different programming languages through API’s( Application programming interfaces), and thereby be directly be incorporated into the melting pot that is the software application.
So what is the point of this ?
I became acquainted with a flexible software and database many years ago called Autodesk Maya. It is an application for representing modeling and animation in 3D virtual space. The good thing about this piece of software is its core flexibility. If something in this software doesn’t fill your needs, you can change it or create the functionality yourself so that it does what you want. The reason for this flexibility is that the program consist of so called ‘nodes’, that perform certain tasks and connect to other nodes( Like a black box concept). You do not need to know what is going on in a node on all levels of application design, but if you do you can control just about everything that goes on in this piece of software. Why again is this interesting ? When I started thinking about making my own tool, intuitively this is what I was interested in. Mathematical building blocks. Modules that can be copied, reused and repurposed. From working with traditional GUI(Graphical User Interface) of an application, where you move, drag and click, there is quite the adjustment when you contemplate using a software in a manner like this. But If you are interested in being creative with software tools, either in author – , or during run- time, I would say this is the only way to go. I think this is by far the most interesting path for the designer to take in using this kind of Computer Aided Design software.
Autodesk Maya has its own scripting language,MEL(Maya embedded language), which directly interprets commands made by the user onto the ‘physical’ environment in the graphical user interface. This is like rapid prototyping , where the effects of your literary commands show up immediately in the environment. This language operates on one level, while the programming language of C++ operates on a lower level(Lower meaning more abstract). I have chosen to set up a diagram of the different levels here for those who need to visualize it:
Level 3 – Maya visual
interface( Interactive on the level of Microsoft Windows) This is
where the designer tends to do most of his/her work.
Level 2 – MEL (Maya
Embedded Language) Scripting language operating directly on objects
in the Maya environment.
Level 1 – C++ / Maya API
Programming language. The code in which the application was written.
This is general language that has to be compiled into a program and
then run by the user.
Level 0 – Binary
language. Really only two digits combined in ways to make other
symbols.
This diagram can be disputed pertaining my choice of Level – digits, but for now I will let them stand. I will not delve on assembly language here.
For a given plug- in (extension of maya’s functionality), you could set up a diagram like this( showing relation) :
So initially I have been talking about design on a different level, and here you have my take on it:
Instead of designing on level 3 , it is desirable to start designing a tool on level 1. By way of this abstraction level I will then be doing evolutionary operations on binary data material.
Skyscrapers, or high rise buildings are basically very complex structures. The level of engineering and the size of these projects in real life make them mammoth tasks for even large international firms of architecture , engineering and entrepreneurship, no matter how big they are or how efficiently they may be organized.
I am not going to focus on all these details. I see a point in drawing parallels between the high- rise and geometrically visualizing a plant in nature. Especially I am interested in the way the plant conforms to its surroundings, and particularly how it originates and evolves by way of light from the sun through direct light, reflection and refraction. ( More on this can be found in blog-post B4)
Therefore my Architectural design will showcase some of the technical aspects of such a hybrid, such as spatial and structural organization of the architecton that I conveniently call the simplified skyscraper. Conditions being parameters of light angles, physical elevation, gravity and the context of the building. As stated in chapter 1.2 of the original Genr8 whitepaper ; ” One purpose of this thesis is to create a tool that is useful to a designer. It is certainly beyond the scope of this thesis to create a tool that takes all aspects of architectural design in consideration. The focus of GENR8 is on growth, and in particular we want to mimic biological growth. Architects are intrigued by natural form and they find organic qualities in design very compelling. Furthermore, the architects desire a growth process that takes place in a specific environment and reacts to the elements of the environment. To narrow it down even further, we decided to create a tool that generates surfaces. Surfaces are obviously very useful to a designer and they can be used in a wide range of contexts”
It seems fair to take this simplified approach for a masters degree, as it takes engineering firms years to figure out the statics and technical details of a complex structural project + similarly long time for designers to conform to the implementation. As such it is futile to try to do the work of all these people. The properties of newer materials have also paved the way for an easier conceptual design route , meaning it should be possible to envisage a construction without having to solve for every constructional detail, as materials can be used to implement a lot of different constructional concepts. That is of course true for each generation, as we conform to using what has worked for earlier generations without having to reinvent the wheel. That also becomes less interesting as the task is not so much that of making the building feasible constructively anymore, it is about functionality and the user-aspect. Additionally I am developing a concept of a structure, not from any pure imagination but from work done in computer programming, mathematics(Geometry), physics(optics), botany, language theory plus of course Architectural design.
Now before I move on I have to say that Architecture, and its industry has had a relatively limited scientific investigation of the topic of light compared to other scientific fields. Admittedly the masters of old designed great projects for harnessing the power and beauty of the sun, but compared to exact science in general, and especially technological advances, there seems to be a lot left to discover.
Light structure
Some years ago I did a limited and very simple project on a type of inverted architectural structure. It was inverted in the sense that the notion of maximizing the openings in the facade for the purpose of letting in as much light as possible, was now in fact inverted so that the structure facade had a minimal percentage of openings. The clue here being of course that inside, this structure had glass walls and floors where ever possible, letting light trough the facade by the short- end side of the glass rather like the principle of fiber optics. Here I refer to Huygens’s Principle. While light scatters circularly from an impact point between to mediums somewhat, it tends to follow a medium ,like glass, in a wave – like fashion, meaning it will pass through using the shortest way possible. Very interesting in this aspect becomes the concept of fiber-optics. Such concepts are in fact used not only for sending light but indeed also information. This of course opens up new possibilities in the functionality of a building.
Because of the limited time for the before mentioned project the structure had its origin in a simple plan drawing which was made for the purpose of showcasing the effect of the light as it was carried through the glass and projected onto an opposing surface.
In an urban setting with a very warm climate there would be an abundance of situations where large scale buildings like high – rises would benefit from having controlled lighting and therefore a kind of inverted facade. Of course the lighting of buildings in general is made beneficial nowadays through blenders and light control systems. But this is far from the purity of a Corbusier church, where the light is “molded” into the church room. There hasn’t really been focus on light in the same sense in post modern architecture. I believe the reason for this is the focus on construction technology and the advances in construction processes.
The big issue with thinking in lines like these , on a big scale would be the sheer complexity of the construction. That is why I started thinking about a automation process. I have through my earlier blog posts begun an investigation of a plug-in for Autodesk Maya called Genr8, and by now it should be obvious what it is and at least to some extent what it entails. One should also now begin to see the connection between this automated growth process that is Genr8 and the diversity that lies in the application of a system like that, onto an articulated axiom, like for example a plan drawing and further more on to something like a structure of a building. In the very nature of L – systems as used in the Genr8 plugin is this : self -avoiding, space filling, self- similar curves that make up surfaces. While these terms are not regularly used in Architectural design, that is not because they are not interesting in that context. Rather we are not used to describing our graphical notation in the same terms. But in fact Fractals as described as a mathematical description of a naturally occurring phenomenon describe very well the self-avoiding, space- filling and self- similar qualities that we appreciate in our Architectural drawings. Is that coincidental ?
So where do we start ? Well, considering the wide range of research being included through my literature list, I am now narrowing down to the city square block and the Architectural floor plan. I have started developing a partially user-defined system in that regard, where a visitor to my linked website could also visit the Skyscraper project page, choose a destination for the potential project, set the boundaries for it, choose environmental conditions and the values for their variables, settle on a base for the structure – and then set it off with the push of a button.
Somehow I would like to be able to develop a floor plan that would be capable of growing extensively upwards, keeping and further developing solutions to spacial problems or challenges. Is it possible ? Of course. Look at scripts you run through user interfaces of ex. Autocad/revit/Archicad etc. It is difficult however to be aware of what you are producing, and if what you produce serves the original purpose. For this I have settled on a technique which we often use in Architectural design which is sketch modeling. Using your hands and your thoughts to quickly produce a lot of different limited spacial models and molding your idea. What I want to do here though, is a bit different. While it is normal for limited models to come together into a coherent project, that simplified end product is not the ultimate goal in my case. Like reverse engineering I want to find the mechanisms that connect each spacial element, so that generic rules can be established and applied to other floor plans. The challenge would be many– fold:
Get an idea of a good floor plan for a tall building combined with the idea of my principle of organization and sunlight. A generalization or an average is a possibility, at least as a plan-drawing fitness tool.
Make the Genr8 plugin by Martin Hemberg work with plan drawings in the form of extended polygons or polylines.
Rework the plug-in accordingly. It seems to be possible to make grammars describe objects(genomes/axioms) more extensive than the simple polygon. The challenge there is to find these grammars.
Decoupling the growth process from the grammars. Make sure the grammars are not able to produce erroneous results(f.ex self – avoiding curve crashing with itself), and thereby being able to freely search an enormous amount of solutions. In this way the architectural process could then also return to “normal”, as you would be able to sit down and go through the chosen design, working out detailed solutions using more or less intuitive fitness assessment. Some research has been done in that particular respect ( See blog- post B4 on the topic of Rosenman, Schnier, Gero)
Now I’ve got an idea for how to attack this as an architectural design project. Using the thought of inheritance and composition in the c++ programming language which I have become accustomed to, I have also become a believer of the language’s UML idea of “Casting the solution in the same terms as the problem” as it is phrased in “Thinking in c++” ( Eckel, Bruce – Mindview, inc. , 2000)
Quote;
“tremendously beneficial because you don’t need a lot of intermediate models to get from a description of the problem to a description of the solution. ”
This in fact suggests to me that you have a balance which lets you more easily “sketch” out possible solutions while making sure they are valid for the actual problem. To me this is the “magic” that languages bring us, without getting to poetic : To be able to put into words what is too infinite to describe elsewhere. Being able to describe something in language or diagrammatically without worrying about it being interpreted as THE design itself is something architects and critics of architectural design struggle a lot with on a daily basis, and it is something of which you don’t learn in school.( The same can be said for most parts of this project of course).
Now begins a period of really pushing the limits of my intellect – very difficult analysis, implementation, testing and creative work in parallel that I have chosen to describe as :
Controlled desperation.
So with that I present a diagram of my Architectural project:
The starting point for me personally has been the education for a master degree in Architecture.
I was supposed to become an architect, but I must admit that no one was able to describe Architecture to me in a way that I could appreciate, nor could I express my ideas. What I can appreciate though is aesthetics. Beauty. These words speak to me and do not need further explanation as such. What I need to explain to myself and to others, is why…. Why are things beautiful, aesthetically pleasing. What is it about the configuration of visual objects that we generally like as opposed to what we dislike? And why do we need the ugly to be able to discern the beautiful ? Through an education of art and Architecture that has been influenced by both extremely liberal, and then the overly strict environments and views on art as such, I have indeed become fed up with the notion that there is something “mystical” or “magical” out there governing things, something that does not have to be explained. At the same time I believe in the following: As an artist; If it is aesthetically pleasing it is worth pursuing. If it is worth pursuing it is possible to engineer. Leave some work for experts, and focus on being the creator. As you maybe can gather my past has left me rather ambiguous on these matters.
So instead I will here present certain known concepts of shape and form through mathematical principles, and how certain people have come to bind them to the practice of architecture, art and the notion of aesthetics. Mathematics, through geometry and its sub – concepts, and understanding of it is my prime interest both in art and Architecture now. My contribution through this blog comes in the form of the linkage of concepts, and as you will see, the construction of what I have come to believe to be my idea of the architecture that has been presented to me over the years.
I do not presume to revolutionize Architecture through this blog, I only wish to show what I think computer software industry has made a lot of designers forget ,through the development of interfaces as simple representation of complicated technology. Because once you start to dive into the depths of computational technology you start realizing just how naive your ideas were. And therein lies true revelation.
Digital programming – Competence in a creative process, and why it is increasingly valuable in an ever more complex Architecture.
I will start by saying that instead of a theoretical dispute, I will soon move on to examples and finally my own project, to show what I feel is the inevitable evolution of the Architect. I think this will also emphasize a new meaning of the word Architectural Design, and thereby add something to a discussion about Architectural Design Paradigms.
It has become somewhat apparent to me through my years as Architecture/art student and creative individual what inspires my creations. Sadly, I have then also come to see my limitations. As I see it, I have certain abilities that enable me to imagine 3 – dimensional space from limited input. So form seems to be my thing. This complies fairly well with research on how the typical male human brain works.
The problem is that these abilities have potential that seems to only realize itself when ideas are organized, on multiple levels, and calculated, beyond what my poor brain is capable of. Often it is difficult to see where your limitations lie when working on a design. The possibilities and ideas seem as vague dreams, and they can disappear just as fast if you don’t catch their essence. I say this because these ideas come from an enormous universe of more or less equally valid solutions to a problem, a universe that is far to big for any human to systematically catalog, let alone control. THIS universe is one that I feel should be more accessible, through computing power that nearly all of us are in possession of. Your own dream catcher.. This is what computers should have been all along, isn’t it ?
It seems that this is not remotely the case. Most computer software for design do not span the chasms of different disciplines, and so you are stuck with a tool that does nothing for you but produce a replica of what you sketched out as an idea on paper or produce something that you do not comprehend or care about the extents of. Using the software in the manner that the industry forced upon us, does nothing but keep design paradigms at status quo, which means little real creativity in my book. Also consider this: How are you supposed to creatively master a tool that you don’t really understand on a fundamental basis?
I have to admit that I lack perspective and control of big Architectural projects, and especially I struggle with the validation of the design process. Maybe it is this struggle that has forced me to try out the creative process on another level. By another level I mean to say putting the emphasis on another part of the design process, and also the problem of reorganizing the management of the process itself.
Example:
The mathematical calculator is still being used as an independent tool for calculating numbers used in more or less isolated incidents. The relation between the calculation and the use of the calculation is apparent. All laptops in use today have a much larger capacity for calculation than the traditional calculator , but it depends largely on the software implemented on the computer. Given the right algorithms, one can perform a variety of tasks, across the borders of a single piece of software and on to the next. The problem with this capacity is that it requires a large amount of specialized skill and validation of that skill, and so calculations can not be directly used as validated design results.
When referring to design on another level earlier on , I am really talking about making a tool that can take decisions for me, scan the universe of possibilities, all according to my recipe, or algorithm. This would in my case be a digital tool that you produce yourself, for the task or tasks that you have set out to handle. This method of working is in Architectural design loosely called tooling, and commercially it has been exemplified in the book “Tooling : Pamphlet Architecture 27 ” by Aranda and Lasch. http://www.arandalasch.com/ or http://www.amazon.co.uk/Tooling-Pamphlet-Architecture-Benjamin-Christopher/dp/1568985479 The problem I have with this kind of approach in general though, is the “starting from scratch” – notion. I felt at least on my own behalf that I should make use of what has been there from the dawn of computers. The consequence of the inevitable fact that we will someday get replaced by artificial life.
A method for solving a problem can be called an algorithm. We all use them, all the time. Some are rather simple, some are extremely complex. Algorithms are used in computer programming for solving specific problems, performing certain specific tasks. The computer does not know what it is doing( as of this write up anyway 🙂 ), nor does the end-user of a piece of software, and yet these calculations and their organization are what make it all happen. By making software more flexible though, applications can now be extended fairly easily by the end-user. By writing the code for an extension, plug- in, script or routine, or just “plugging it in”, it is possible to extend the capabilities of an application in the way that you see fit to solve a task. Industry standards can potentially be implemented through libraries and classes used in the different programming languages through API’s( Application programming interfaces), and thereby be directly be incorporated into the melting pot that is the software application.
So what is my reason for dwelling on this ?
I became acquainted with a flexible piece of software some years ago called Autodesk Maya. It is an application for representing modeling and animation in 3D virtual space. The good thing about this piece of software is its core flexibility. If something in this software doesn’t fill your needs, you can change it or create the functionality yourself so that it does what you want. The reason for this flexibility is that the program consist of so called ‘nodes’, that perform certain tasks and connect to other nodes( Like a black box concept). You do not need to know what is going on in a node on all levels of application design, but if you do you can control just about everything that goes on in this piece of software. Why again is this interesting ? When I started thinking about making my own tool, intuitively this is what I was interested in. Mathematical building blocks. Modules that can be reused and repurposed. From working with traditional GUI(Graphical User Interface) of an application, where you move, drag and click, there is quite the adjustment when you contemplate using a software in a manner like this. But If you are interested in being creative with software tools, either in author – time or during run- time, I would say this is the only way to go. I think this is by far the most interesting path for the Architectural designer to take in using this kind of Computer Aided Design software, although the graphical windows of the application interface would have you think otherwise. But aside from generating objects inside the software through a setup of rules and regulations( a system) , I do not see creativity in neither this kind of software or the Computer – Aided Architectural Design software like Autocad, Revit or Archicad.
Autodesk Maya has its own scripting language,MEL(Maya embedded language), which directly interprets commands made by the user onto the ‘physical’ environment in the graphical user interface. This is like rapid prototyping , where the effects of your literary commands show up immediately in the environment. This language operates on one level, while the programming language of C++ operates on a lower level(Lower meaning more abstract). I have chosen to set up a diagram of the different levels here for those who need to visualize it:
Level 3 – Maya visual
interface( Interactive on the level of Microsoft Windows) This is
where the designer tends to do most of his/her work.
Level 2 – MEL (Maya
Embedded Language) Scripting language operating directly on objects
in the Maya environment.
Level 1 – C++ / Maya API
Programming language. The code in which the application was written.
This is general language that has to be compiled into a program and
then run by the user.
Level 0 – Binary
language. Really only two digits combined in ways to make other
symbols.
This diagram can be disputed pertaining my choice of Level – digits, but for now I will let them stand. I will not delve on assembly language here.
For a given plug- in (extension of maya’s functionality), you could set up a diagram like this( showing relation) :
So initially I have been talking about design on a different level, and here you have my take on it:
Instead of designing on level 3 , it is desirable to start designing a tool on level 1. By way of this abstraction level I will then be doing genetic operations in binary material.
Autodesk Maya is indeed designed to be an open and extensible product. The Maya® Software Development Kit (SDK) contains a rich set of facilities that can help you add new functionality to the Maya software. The SDK includes a C++ API called the Maya API that provides functionality for querying and changing the Maya model along with the ability to add new Maya objects to the Maya model. The scripting languages MEL and Python are key to Maya being open and extensible. I will focus here on MEL and the Maya C++ API for the purpose of extending the functionality of Maya. During the design of Maya, the C++ API was built in to maximize its extensibility. In fact , on Windows, you can launch Maya directly from the Microsoft® Visual Studio® development system and debug the plug-in as you would any other Windows application.
At the lowest level, Maya is a very efficient database for storing graphical information. Databases are extremely efficient in general when storing, querying and producing data quickly. This particular database is represented by the Dependency Graph (DG). Information in the DG is stored in objects called nodes. Nodes have properties called attributes that store the configurable characteristics of each node. Similar types of attributes can be connected together, letting data flow from one node to another. On the abstracted layer that is the API and where you have access to Mayas Dependency Graph, you work with objects and function sets to access these internal nodes. Objects are very lightweight classes that provide RTTI (Run Time Type Identification) and can be used in a type-less manner. A function set is a user owned structure that allows operations on Maya owned objects. Since an object is simply a handle that knows its type, a function set provides you with a tool that acts upon objects of the right type. These function sets usually have names that match the Maya features, such as MFnSkinCluster and MfnNurbsSurface. For example, the MFnSkinCluster class can be instantiated with an object of type kSkinCluster, and subsequently can be used to perform operations on that object. The object itself is not able to perform any functions without the aid of its function set. I am already assuming some background knowledge on the part of the reader here, but I leave a documentation reference to the Autodesk Maya API here.
In C++ you work with functions and objects in the same classes, but here we have to consider how the dependency graph works when designing something like a plug- in. Functions and data are separated in Maya. For further description of this follow the upcoming blogs, or click here.
For now this is a introduction into the technicalities of the Maya API. I will continue in the next Articles on a more detailed description of how the C++ API works, and how you can introduce your own functionality into the Maya Dependency Graph, and make your own virtual tools for 3d design.
Now on to the plug – in itself, which needs a bit more explanation.
The original GENR8 plugin is a surface modeling tool that simulates organic growth of surfaces in an
environment. The creator found map Lindenmayer-systems to be a suitable model for this kind of growth. Aristid Lindenmayer was a biologist who made the L -systems for describing growth of plants. But computers work with numbers and character strings, so the field of grammars and grammatical evolution became an essential part of the process, in addition to evolutionary algorithms, who have been used traditionally for computer optimization problems. The plugin, working in sync with Autodesk Maya 3d software can be seen working in the following diagrammatical way :
This does not take into account the Autodesk Maya environment however, but we will get back to that.
To use L – Systems they had to be mapped to three dimensions, and environmental factors were added. The important thing to note for now is that you have a seed or a genome which is defined as an integer string, and you have a grammar of word strings and rules that work on that Integer string. The rules, in accordance with the diagram, govern how the grammar works the string – The end result is the surface. Suffice to say the methods involved are well known in science. The way Lindenmayer combined them and the way in which the Genr8 plug – in uses them are nevertheless more unusual, as they involve the cross discipline factor.
For general updating of your personal knowledge- base, I would consider these links:
http://www.cplusplus.com/ – Catch up on your C++
http://www.davidgould.com/Books/CMP1/index.html – Complete Maya Programming, with descriptions of MEL, C++API, Maya Classes and everything else you would need to know.
For info about the original Genr8 plugin and my personal development of it, also see the dedicated webpage http://www.evolvedtools.com/Genr8Page.html on my personal website.
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…
Ok, so last technical blog post( B1), set out to describe the software that is actually going to perform the main 3 – dimensional tasks in Autodesk Maya. That was the “what”.
Now it is over to the “how”. I have assembled the source files for the original plugin. I then set up the Visual studio environment using the project property settings I learned from MayaPluginWizard, which is available from here. I tweaked them a bit to be able to compile the .mll Plugin – file. Here’s how( I am linking to my own website here for a somewhat more lengthy introduction : Compile. This step can take some time but I am moving on to the Visualization of the code, since compiling will always yield different challenges for people on different hardware and software.
So, the end of this post starts to visualize the source code of Genr8 and its dependencies. Click here to view dependency graph generated in Visual studio from the solution of the debug compile of the code.( If using Firefox make sure to open with… internet explorer -IF you do not have a working xml-plugin for your Firefox version).
Also, to supplement this, it is a good idea to start mentally visualizing the hierarchy of the classes, and also its members. A non – expanded class diagram and also an expanded version provided here. To get down to the gritty part of cataloging and appreciating the code, I have made an interactive model for showcasing the exact source code files of the original plugin.
As blogs go, for me personally this is just as much learning as it is telling about it. In Architectural design you have something called exploded diagrams – drawings or models that show all the “parts” – exploded out in a straight- lined direction according to object- shape, so that you can potentially see the relations of a structure.
First of all I have to say: It seems incredible to me that when dealing with structural notations or formulae, that most people don’t stop and ask questions. Of course on a personal level I do understand because it is frustrating and tough to have to consider and in fact appreciate the logic that propagates through systems described by mathematics. Nevertheless there are obvious underlying problems when doing geometric modelling virtually or tactile without understanding the logic and interdependence of underlying variables and functionality.
That being said this blog post will only serve as a simple prelude to the complementing “technical” blog post B3. I plan to expose the elements of L-Systems through dissecting the Genr8 Plugin, and I am starting with the elementary math, as I truly do not believe one can be creative with interactive computer modelling systems otherwise.
L-systems are the basis for generation in these studies of alternative methods for Architectural creativity. They are made up of many processes and procedures and in this case they mimic the growth of plants .
For the development of structures from axioms, which are the hypothetical “seed of the plant” we rely on abstracted processes. One abstraction used for interpreting code into virtual structure has been named a “turtle”. Imagine as an example such a being moving freely in no-gravity virtual space , and making graphical notation of the path that it walks. The turtle both rotates to obtain a new direction and moves forwards( or backwards, left or right), but for now I will focus on the rotation, since it can be discussed somewhat free of L-Systems in general.
The rotation matrices for the rotation of the 3D turtle come in a form like this:
Here the angle is parameter and the RU is the TURN LEFT or TURN RIGHT of the turtle(LEFT=+, RIGHT = -). Also, there are symbols used for pitch, roll and turn-around: The RL is the PITCH of the turtle( & = pitch down , ^ = pitch up). The RH is the ROLL of the turtle(\ = roll left, /= roll right) and The TURN – around turtle( | = Turn-around(RU(180))).
The symbols inside the matrices are not to be confused with the symbols for the turtle movement. The
“-” inside the matrix means “minus”, while the turtle – symbol “-” means TURN RIGHT.
The way they work is that , for RU, the theoretical “x” axis remains as zero value, while left and right are calculated as values of cos(angle) and sin(angle) .
For RL, the pitch is calculated nearly the same, if you consider the UP and DOWN simply as another version of LEFT and RIGHT.
For RH, the calculation can be thought of as pitching the turtle 90 degrees, and then applying the RU matrix, just done all in the RH – matrix.
Of course this is just one set of notations out of many possible.
Going further into the math of the matrices:
The above mentioned matrices calculate states of a turtle, and this turtle in turn makes moves of a certain set distance . But how are the matrices calculated ?Well, first of all in computer Graphics we are dealing with the viewpoint in addition to the three dimensions, so what are we doing when we are playing with 3D software on the screen? Without giving it much thought we are actually constantly producing calculations of lengths and angles using trigonometry.
Consider rotating a 2D point (x,y) around the origin of a coordinate system by 90 degrees:
You would be given a matrix such as the one above. The new point (x’,y’) would be calculated by a matrix following the logic below.
or with circle trigonometry:
What you are seeing here is like saying :
When you are finished you should be left with the new point (x’,y’) rotated 90 degrees counter-clockwise about the origin.
To rotate a point around another point , you could use the matrix beneath. Of course in 3D we rotate about an axis.
This is then extended to 3 dimensions by adding another row and another column, like you see here where the rotation is around the x- axis:
Going back to the top of the post, what you are seeing are the matrices that calculate rotation for the three different axis x,y,z.
• roll being the angle of rotation about the z -axis
• pitchis the angle of rotation about the x -axis
• yaw is the angle of rotation about the y-axis.
All these can be combined into one matrix, together with a translate matrix(Move etc..) to make operations more effective. But first a note about axis terms. Remember that there will be difficulties if you mix right-handed and left-handed systems or which axis is up , when you program for a API. In Autodesk Maya, the default up – axis is ‘y’ and the coordinate system is right- handed by default.
So consider now translating and rotating a point into a new point:
What you see here is a rotation about an axis parallel with the z- axis.
What we will continue to explore is the way in which this relates to L-System notation. The reason I find it extremely important to describe this process in full is twofold.
The ways in which these matrices work may not be so obvious at first but they are extremely important, also when considering a creative perspective as an architectural designer.
Here I have just explained how a “turtle” in Turtle Graphics calculates how to rotate , through matrices. But the turtle also moves according to strings of letters in words – As in components of an L-system. This will be the subject of the next blog. The reason I start with matrices is that they are the technical foundation upon which you construct objects in a software like Autodesk Maya. Without knowledge of them you are simply lost..
Last time(Blog b2) I generated some diagrams of the software that is Genr8. Now It is time for some scrutiny of the elements of L-Systems and how they fit into that software
Keeping to the ‘A’ and ‘B’ parts of my blog I will here locate the files containing declarations and definitions of matrices in the Genr8 plugin, and later on I will find how it fits in the assembly of a generated object in Autodesk Maya.
First of all I need to find the files that are relevant for obtaining the necessary info on its dependencies, its inheritance, etc… In other words I have to start using the Diagrams that I generated for the last blogs(A2,B2).
In the case of the Genr8 plugin we are looking at Euler – rotations, which are rotations about the x,y and z axes that we are used to.
In the general project outline below ( Dependency diagram) you can see the mtransformationmatrix.h file encircled:
The next image shows files that are directly dependent on it, and the files which it is dependent on.
The purple nodes represent header files for Mvector and Mglobal, and they both include the MtransformationMatrix.h. Looking at the blue nodes, they represent Mstatus and Mtypes. A lot of these files are co – dependent, that is they include each other.
Now that we know what files are working together in this direct – relationship dependency, we can have a look at the code. Working with Visual studio this is never further than a click away.
Due to copyright laws this article can not reproduce the source code for the files. You can find them in the autodesk/maya/Include -folder.
MStatus:
The class takes care of error handling in the API.
MTypes:
File concerns version of Maya and consequently the version of plugin
MVector:
Provides access to Maya’s internal vector math library allowing vectors to be handled easily, and in a way compatible with internal Maya data structures.
MGlobal:
Provides methods for selection, 3D-views, time, model manipulation and MEL commands.
MGlobal is a static class which provides access to Maya’s model (3d graphical database). MGlobal provides methods for selection, 3d-views, setting the global time, adding to the DAG, and executing MEL commands from within the API. There are multiple methods provided in this class for executing MEL within the API. Plug-ins requiring the execution of MEL from the non-main Maya thread must use the executeCommandOnIdle() method to avoid program errors. MGlobal also provides methods for controlling error logging in the API.
MtransformationMatrix:(Linked PDF)
Now that we have a description of the headers, it is a good idea to look at the relationship between them.Making a diagram of the direct include dependency of these header files can look like this:
The arrows show which files depend on others directly.
Like I have described in the A3 blog post I will go on to look at the Lsystem, with its effect on the turtle and consequently generation of objects, but first cross- language issues have to be dealt with and understood.
Looking at our dependency diagram again; We can see that choosing incoming nodes shows us a first glimpse of the files dependent on our matrix – operations.
From the project files these are:
PolygonSurface.cpp, NurbsSurface.cpp,cmd.cpp, MelUtilities.h and Scaffold.cpp.
From the C/C++ Standard Library;
math.h
From the maya/include – library;
Mobject, Mstring, MvectorArray, MfnMesh, Mpoint, MfnNurbsSurface, MintArray, Mselectionmask and MstringArray.
Files are often interdependent of course but what we are looking for here is the usage of the transformation/translation matrices.
The interesting files are first of all the program – defined source files. It seems though that to appreciate the complexity of this code we will have to find a way to graph the calling of functions. That entails debbugging with tracing of function calls. The ways in which this could be done are quite a few, but I have already touched upon how I plan to do it. In addition I will show in detail how that is done.
So I am pondering on how to understand how the Genr8 plug-in works. But parallel to this I have to be able to work with the plug-in in the environment it was meant for, namely Autodesk Maya. Therefore, it is time to investigate what this piece of software actually does and how plug-ins are implemented in the Maya software.
First I must say( If not said before) that the main reason for choosing Autodesk Maya as 3D software was because of its flexibility and therein its possibility for extension.
If you are able to download one of the Genr8 plug-in executables from my website or any other place, you are probably able to run it. I am assuming a bit more than that though as I have already looked at compiling AND/or running the plug-in , so now we are moving on to the language implementation through the application programming interface(API), and how different computational tasks are handled in Autodesk Maya.
In Maya you can have a lot of control over the development of your 3d environment. Through nodes that represent functions or data you can interconnect however you see fit all the components of your development, or your software environment for that matter, and include new features to Maya if it doesn’t provide the functionality you want out – of – the – box. But there are restrictions as always in how you can implement either outside components or local material.
Remember that you are always working on an abstracted layer above the core of the Maya software. The designers of a commercial product would never let you take their software and turn it into something else while keeping their logo, so to speak. This is a good thing, because :
1) You would ruin or corrupt the software at some point for sure because of sheer complexity. There is no point in totally redesigning a perfectly good piece of software, so reap the benefits of what others have done for you.
2) It is easier to experiment with the software and resetting when/ if you are done.
There are restrictions in the API in that there is a translation between different computer languages, namely C++, the way that object oriented language “objects” are handled in Maya, and finally how actions are implemented in the environment of Maya that we know as The graphical user interface(GUI).
As a side note, the original author of Genr8 programmed the plugin so as to use Maya functions as little as possible. This was done to make the code more easily portable, but also because he was a C++ programmer and less familiar with the Autodesk Maya environment.
Just about everything that happens in Maya shows up in the Dependency Graph, which is a graphed presentation of the Maya database, through basic building blocks and the interaction that happens. The basic building blocks of Maya are represented as nodes -These are abstracted as rectangles that theoretically consist of everything needed to perform a task( Like black boxes). Small task or large, these nodes have the properties of input and output, and can be connected as a programmer sees fit to make an Autodesk Maya scene. Maya is based on C++ so inside these nodes theoretically you can implement code for calculating any computer task performable by your system and Maya software, but here also there are restrictions.
In C++ you generally mix data with functions that work on that data, in classes or structures. Maya separates data from functionality, or operations on data. That is , the only prerequisite for a node operation in Maya would be some piece of data to start with, operations on that data and finally a modified piece of data as a result. This is a design strategy based on the notion of flexibility, but also pretty rational if you take time to consider it. C++ is after all a multi purpose programming language. Autodesk Maya is a 3d design spesific environment. Ultimately you would like to add new features and functionality without needing to touch any of the existing modules, or nodes. (You would like the functionality to be there already, as much as possible). You would also like to change the functionality or interface in a given module without having to manually update all the dependent modules. So to change a 3d surface for example you would have a network of functionality nodes working on that surface data – node, and as a result – out of the other end of the “pipeline” comes a new modified surface. Considering this aspect, every node in a network has an input(data), an output(data) and a compute(operations on data). The way that the so called push-pull database model works in Maya is to update the node -dependent parts of the Dependency graph, and thereby the database, each time a change is made to a node.
Here is a network of nodes showing something like a modified Nurbs – sphere. This would normally be thought of like 1 piece of data. For flexibility, in Maya this is how the data actually is handled and which gives you as a developer much more control. The image shows the Hypergraph which is a visualization of the Dependency Graph. The important thing about this schematic at this point is the notion and layout of nodes in general.
Everything you implement through the Maya C++ API has to be compiled before it is run. Maya embedded language (MEL) is a scripted language and therefore more suited for rapid prototyping. Make sure to appreciate the difference of making a script versus making a plug-in – and why.
So there you have some basic information on how the Maya model handles the 3d environment that you actually work in. I hope therefore it will come as no surprise when I start to delve into C++ Maya API implementations without too much warning, although I will give notice as I do so. Going through the plug-in structure combining the following in parallel seems like the only really comprehensive way of describing my way to what is finally my goal : The construction, through “artificial growth”, of an architectural structure.
– C++ source code
– Programming through the API
– Implementation in Maya
– Plugin – in behavior
Sure, you have the L-system inference problem wherein you cannot know the outcome of your evolutions, but I really don’t see that as a problem because in Architecture you have such a strict system of manual censorship and critique. And by all means, in the case of a prototype that censorship would be absolutely necessary. Still the benefits for creative aspects of such evolution seem incredible to say the least.
SO……
Earlier in this posting I talked about starting with the transformation and translation matrices – That means those matrices that rotate and rotate elements. I am now expanding this to include the direct source files who trigger these. By expanding like that I move one set of peripherals into main focus, and get another set of peripherals so that I can start to form a perspective.
It seems there are two classes who handle the matrix operations in Autodesk Maya.
– MGlobal
It provides methods for selection, viewing and manipulation of the modelling(3d graphical database) + MEL commands. There are multiple methods provided here for executing MEL commands from the API. Also includes methods for controlling error logging from the API.
– Mvector
This class provides access to Maya’s internal vector math library allowing vectors to be handled easily, and in a manner compatible with Maya data structures.
Now it is easy to use the UML diagrams created in Visual studio to branch out, and we see that
PolygonSurface.cpp and NurbsSurface.cpp make use of mvector. There are no big surprises there and that’s the way it should be, everything stacking up in a logical virtual hierarchy. That doesn’t mean this is not a necessary process though. Without these schematics it would be impossible for most people to decipher the source code is my guess.
So to use true and trusted methods I will go ahead with the method of divide and conquer. This means that the way forward can be seen as splitting the plug-in up into different functional pieces, testing them for output and mechanisms of design, and evaluating from there on. At the same time what is interesting here is how c++ classes translate into Maya classes through the API.
The files mentioned above have been picked for a reason, but I would also like to find the classes and functions that actually operate on the axiom(Genome – the seed of the generated structure), seen in the broad context that these actually use the axiom as input to develop geometric surfaces in Autodesk Maya. As you can see below we can start singling out groups of classes easily through the UML diagrams:
– Field – Base class for the classes describing outside forces working on the structure.
Within it we have:
.Gravity
.Attractor
.Boundary
.Vertex
But with just knowledge of C++ language syntax most people would get stuck in an endless interpretation of single – file code. So we move on to what we promised last time( Blog B3) which was the function call hierachy in Microsoft Visual Studio, and also examining MEL output from the plug-in functions.
This means that we can start to see the big picture, as we can now know the functionality that binds the source files and the classes together. Some may argue that this is starting to look like analysis paralysis, but I am absolutely aware of this, and it is absolutely necessary to go through these steps.
Just a side note on C++ application development:
Since we are talking about redeveloping a present C++ program here, I am not starting by using CRC cards or similar as you maybe would in the creative process of designing from scratch. Neither do I have to construct my own UML diagrams as such, because I can generate them from existing code. The value in using this kind of generated UML material can to a great extent already be found in just accessing dependency – and class -diagrams produced from the base model of the plug-in source code.
Commencing with the call hierarchies, there are 3 cases which I personally am interested in as a start:
The classes that we have identified through the headers and implementation files through the recent posts.
– From the project files these are:
PolygonSurface.cpp(PolygonSurface.h), NurbsSurface.cpp(NurbsSurface.h),cmd.cpp(vector.h, world.h, melutilities.h, sentence.h, word.h, nonTerminal.h ), and Scaffold.cpp(sentence.h, word.h, edge.h, predecessor.h , successor.h, axiom.h, rewriterule.h, bnf.h, melutilities.h, world.h, scaffold.h).
– From the C/C++ Standard Library;
math.h ( I want to see how certain calculations are being done)
– From the maya/include – library;
Mobject, Mstring, MvectorArray, MfnMesh, Mpoint, MfnNurbsSurface, MintArray, Mselectionmask , MstringArray , Mglobal and Mvector.
– cmd.cpp issues commands in Autodesk Maya, and as is the virtual function a lens through which to view applications in C++, the cmd.cpp is the file through which to gain knowledge of implementation in Maya through MEL(Maya Embedded language). Both through attaching the visual studio application to the Autodesk environment and the Genr8 plugin in it, and through running sequences of functions through the API and to see results in MEL – In these ways I can really start to see what is going on.
– Which brings us to Virtual functions. Just by looking at the earlier diagrams we can see how they dictate the graphed structure of the application. Nevertheless, we can not blindly believe pure inheritance is been followed, and indeed composition is also used. This we will see clearer through the sequence diagrams.
– According to the environment factors of the plug-in we can see that a lot of files are somewhat decoupled from the growth of the L-System itself, but we will have to see how they interact. Force.cpp (force.h) hold base class declarations and definitions for functionality that makes the system context-sensitive in terms of L-systems. You can start to see a complex relationship as you consider that that the Field class as displayed above is parent class for all classes that use some kind of force acting on the system, while at the same time the force class keeps track of it.
I have settled on a way to decipher certain functionality by rewriting and recompiling the plug-in, through Microsoft Visual Studio 2012, for Autodesk Maya version 2013. I will go through writing the cmd.cpp – file first, the file that issues MEL scripting commands in Maya and through which all functionality can be traced, both to – and from. I will then use the “function call hierarchy” in visual studio on the old source code for seeing the full extent of what is happening where and when, and produce examples and tests along the way in the C – posts of this blog. This is for the purpose of visualizing.
Skyscrapers, or high rise buildings are basically very complex structures. The level of engineering and the size of these projects in real life make them mammoth tasks for even large international firms of architecture , engineering and entrepreneurship, no matter how big they are or how efficiently they may be organized.
I am not going to focus on all these details. I see a point in drawing parallels between the high- rise and geometrically visualizing a plant in nature. Especially I am interested in the way the plant conforms to its surroundings, and particularly how it originates and evolves by way of light from the sun through direct light, reflection and refraction. ( More on this can be found in blog-post B4)
Therefore my Architectural design will showcase some of the technical aspects of such a hybrid, such as spatial and structural organization of the architecton that I conveniently call the simplified skyscraper. Conditions being parameters of light angles, physical elevation, gravity and the context of the building. As stated in chapter 1.2 of the original Genr8 whitepaper ; ” One purpose of this thesis is to create a tool that is useful to a designer. It is certainly beyond the scope of this thesis to create a tool that takes all aspects of architectural design in consideration. The focus of GENR8 is on growth, and in particular we want to mimic biological growth. Architects are intrigued by natural form and they find organic qualities in design very compelling. Furthermore, the architects desire a growth process that takes place in a specific environment and reacts to the elements of the environment. To narrow it down even further, we decided to create a tool that generates surfaces. Surfaces are obviously very useful to a designer and they can be used in a wide range of contexts”
It seems fair to take this simplified approach for a masters degree, as it takes engineering firms years to figure out the statics and technical details of a complex structural project + similarly long time for designers to conform to the implementation. As such it is futile to try to do the work of all these people. The properties of newer materials have also paved the way for an easier conceptual design route , meaning it should be possible to envisage a construction without having to solve for every constructional detail, as materials can be used to implement a lot of different constructional concepts. That is of course true for each generation, as we conform to using what has worked for earlier generations without having to reinvent the wheel. That also becomes less interesting as the task is not so much that of making the building feasible constructively anymore, it is about functionality and the user-aspect. Additionally I am developing a concept of a structure, not from any pure imagination but from work done in computer programming, mathematics(Geometry), physics(optics), botany, language theory plus of course Architectural design.
Now before I move on I have to say that Architecture, and its industry has had a relatively limited scientific investigation of the topic of light compared to other scientific fields. Admittedly the masters of old designed great projects for harnessing the power and beauty of the sun, but compared to exact science in general, and especially technological advances, there seems to be a lot left to discover.
Light structure
Some years ago I did a limited and very simple project on a type of inverted architectural structure. It was inverted in the sense that the notion of maximizing the openings in the facade for the purpose of letting in as much light as possible, was now in fact inverted so that the structure facade had a minimal percentage of openings. The clue here being of course that inside, this structure had glass walls and floors where ever possible, letting light trough the facade by the short- end side of the glass rather like the principle of fiber optics. Here I refer to Huygens’s Principle. While light scatters circularly from an impact point between to mediums somewhat, it tends to follow a medium ,like glass, in a wave – like fashion, meaning it will pass through using the shortest way possible. Very interesting in this aspect becomes the concept of fiber-optics. Such concepts are in fact used not only for sending light but indeed also information. This of course opens up new possibilities in the functionality of a building.
Because of the limited time for the before mentioned project the structure had its origin in a simple plan drawing which was made for the purpose of showcasing the effect of the light as it was carried through the glass and projected onto an opposing surface.
In an urban setting with a very warm climate there would be an abundance of situations where large scale buildings like high – rises would benefit from having controlled lighting and therefore a kind of inverted facade. Of course the lighting of buildings in general is made beneficial nowadays through blenders and light control systems. But this is far from the purity of a Corbusier church, where the light is “molded” into the church room. There hasn’t really been focus on light in the same sense in post modern architecture. I believe the reason for this is the focus on construction technology and the advances in construction processes.
The big issue with thinking in lines like these , on a big scale would be the sheer complexity of the construction. That is why I started thinking about a automation process. I have through my earlier blog posts begun an investigation of a plug-in for Autodesk Maya called Genr8, and by now it should be obvious what it is and at least to some extent what it entails. One should also now begin to see the connection between this automated growth process that is Genr8 and the diversity that lies in the application of a system like that, onto an articulated axiom, like for example a plan drawing and further more on to something like a structure of a building. In the very nature of L – systems as used in the Genr8 plugin is this : self -avoiding, space filling, self- similar curves that make up surfaces. While these terms are not regularly used in Architectural design, that is not because they are not interesting in that context. Rather we are not used to describing our graphical notation in the same terms. But in fact Fractals as described as a mathematical description of a naturally occurring phenomenon describe very well the self-avoiding, space- filling and self- similar qualities that we appreciate in our Architectural drawings. Is that coincidental ?
So where do we start ? Well, considering the wide range of research being included through my literature list, I am now narrowing down to the city square block and the Architectural floor plan. I have started developing a partially user-defined system in that regard, where a visitor to my linked website could also visit the Skyscraper project page, choose a destination for the potential project, set the boundaries for it, choose environmental conditions and the values for their variables, settle on a base for the structure – and then set it off with the push of a button.
Somehow I would like to be able to develop a floor plan that would be capable of growing extensively upwards, keeping and further developing solutions to spacial problems or challenges. Is it possible ? Of course. Look at scripts you run through user interfaces of ex. Autocad/revit/Archicad etc. It is difficult however to be aware of what you are producing, and if what you produce serves the original purpose. For this I have settled on a technique which we often use in Architectural design which is sketch modeling. Using your hands and your thoughts to quickly produce a lot of different limited spacial models and molding your idea. What I want to do here though, is a bit different. While it is normal for limited models to come together into a coherent project, that simplified end product is not the ultimate goal in my case. Like reverse engineering I want to find the mechanisms that connect each spacial element, so that generic rules can be established and applied to other floor plans. The challenge would be many– fold:
Get an idea of a good floor plan for a tall building combined with the idea of my principle of organization and sunlight. A generalization or an average is a possibility, at least as a plan-drawing fitness tool.
Make the Genr8 plugin by Martin Hemberg work with plan drawings in the form of extended polygons or polylines.
Rework the plug-in accordingly. It seems to be possible to make grammars describe objects(genomes/axioms) more extensive than the simple polygon. The challenge there is to find these grammars.
Decoupling the growth process from the grammars. Make sure the grammars are not able to produce erroneous results(f.ex self – avoiding curve crashing with itself), and thereby being able to freely search an enormous amount of solutions. In this way the architectural process could then also return to “normal”, as you would be able to sit down and go through the chosen design, working out detailed solutions using more or less intuitive fitness assessment. Some research has been done in that particular respect ( See blog- post B4 on the topic of Rosenman, Schnier, Gero)
Now I’ve got an idea for how to attack this as an architectural design project. Using the thought of inheritance and composition in the c++ programming language which I have become accustomed to, I have also become a believer of the language’s UML idea of “Casting the solution in the same terms as the problem” as it is phrased in “Thinking in c++” ( Eckel, Bruce – Mindview, inc. , 2000)
Quote;
“tremendously beneficial because you don’t need a lot of intermediate models to get from a description of the problem to a description of the solution. ”
This in fact suggests to me that you have a balance which lets you more easily “sketch” out possible solutions while making sure they are valid for the actual problem. To me this is the “magic” that languages bring us, without getting to poetic : To be able to put into words what is too infinite to describe elsewhere. Being able to describe something in language or diagrammatically without worrying about it being interpreted as THE design itself is something architects and critics of architectural design struggle a lot with on a daily basis, and it is something of which you don’t learn in school.( The same can be said for most parts of this project of course).
Now begins a period of really pushing the limits of my intellect – very difficult analysis, implementation, testing and creative work in parallel that I have chosen to describe as :
Controlled desperation.
So with that I present a diagram of my Architectural project:
……Or, the complexities of developing the geometry and parametric properties of a self- evolving 2d Architectural design. Because keep in mind that although we are guiding the system here we are not DIRECTLY drawing the solution out on paper. We are in fact leaving a lot of the organizing ,calculation and discrimination to the system.
As the title indicates, it is indeed difficult for a designer or artist to find out exactly what makes a “viable Architectural concept”. And believe me when I say that this creative difficulty is something on the mind of most Architects on a regular basis. When it comes down to it, most people credit their ideas to a few different aspects but by far most people accredit their solution to an intuitive idea about the right concept in relation to a geographical, cultural or topological location.
Specifically I propose something that while it can not be said to be entirely different, can be said to introduce something new into the paradigm of Architectural Design.
This post is technical, and will introduce a lot of concepts that are not trivial. As described the B- types of blog posts WILL be technical, and so I will use ( and make reference to) a lot of software and specialized terminology. In parallel with displaying the process of my work I will here also display my technical endeavors, including web site, server and database functionality. This is because those are parts of my chosen expression, and because I believe in the temporary properties of digital data, this being a process- based blog. Feel free to jump back and forth between technical descriptions while reading as concepts can to a certain degree be enjoyed as autonomous exercises. (They were for me…).
Trying to find a rational starting point I propose finding the general specifics, the averages, of successful floor plans used in successful high- rises. I propose using these for fitness approximations for my own evolutions. My approach is based on combining the traits of “successful” solutions in floor plans in high – rises and putting a value on the traits that make them highly valued. This kind of fitness – ranking can be traced back to the research and literature of Rosenman, Gero & Schnier.(Sources) On the home pages of the Council on Tall Buildings and Urban Habitat there is a list of the tallest office high rises as of today. I will mainly base my early work on these projects although not all of these 100 will make up my average, as some of these buildings do not conform to the “one- body” restriction that I have chosen for my project. ( The building should be a single free- standing Architectural structure. This is for simplicity).
The elevators and the placement of them are examples of the traits that carry over from project to project. The spine of the building, they are usually situated in the middle of the building and make up the core structurally. Traditionally this is the case and it frees up space for the outer parts of the building. You could argue that this solution is sound both structurally and in regard to space layout planning and access to sunlight. This is a good example of the traits I talk about in former post when I propose superimposing all the high- rise plan drawings upon each other. Why ? Because they make for good averages/generalizations of what is out there in the built environment today, and the public and formal precedents that implicitly follow. If the perimeter of the buildings are roughly the same within city blocks and there are only small deviations in the plan layouts – what are the factors that account for the differences in high- rise building design ? The city block is one parameter, but there are more. In fact it is only the beginning. A beginning that will be a general starting point for evolving a large number of floor plans and from there, high rise proposals for an eventual manual evaluation.
It is very important here to clarify the connection between the heuristic approach of manually choosing and working with a certain set of floor plans and the fitness functions for the plan drawing generation. The whole point here is to make the computer focus in a manner similar to the human mind, while at the same making use of the extreme calculating advantage that “it” has. The way humans do that is by narrowing the field of interest like I am proposing here, while still trying to keep their options open to be creative. So using historical “successes” should be seen in the heuristic context and as an alibi for shrinking down the universe of possible solutions to a problem. Using Formal grammar language notation within the realm of evolutionary computation, simple plan elements or whole floor plans carry over and interpret into basic and evolved genes that can be used as fitness approximations and comparisons to my stochastically-populated individuals. (I do not use the word “random” here as it would be somewhat incorrect. While people in general would appreciate the value of the word, random entails selection of entities without prejudice. Stochastic selection holds traits of darwinian evolution, where certain entities are fitter and more prone to be chosen for selection). The way I will secure success in this process is by making “successful” existing floor plan drawings the targets for my evolution. If I can manage to reproduce them efficiently it stands to reason that I could thereby optimize them, approximate them mathematically and develop them further, by the hand of their own creators so to speak. How do we make sure that what we are producing are in fact valuable results ? Like I have mentioned above, one way is by heuristics; our common evaluation of what has already been accepted as successful, and indeed been built and used.
I introduce the idea here of shapes that are also aware of their placement within a perimeter of a city block or a floor plan.This is done in 3d software by using vertices or vectors. programmaticaly you use pointers between shapes/elements so that they can relate within a coordinate system. You move around the vertices as a point cloud and keep track of how they are connected using segments.
By trying to evolve copies of the generalized floor plans in as few generations as possible. (Think of the generations as concentric circles), you can optimize the evolutionary search according to the design problem. After some optimization is done we can then try to develop beyond the floor plan we had set as target, and see what comes from this. It is maybe easy to digress here but I will keep that digression to a minimum and propose something for later – namely that WHEN we later indeed move into 3 dimensional space we will be parameterizing in accordance to the 2dimensional evolution – that is for each time we evolve the plan, the elevation will change accordingly. Later I will start Introducing built High rise Projects in short, then their floor plans and their main plan/ elevation – elements. Then I will compare floor plans and their components. For now I include the idea so that the concept is somewhat more tangible.
What I want to do then in essence, is to develop a grammar that can take simple graphical elements like combined line segments and evolve them into my chosen floor plans, in as few steps as possible. Looking at the next animation, a way to visualize the development process I am talking about, can be seen. We start off with the simplest of right- angled elements , using simple grammar to develop. When we then hit “jackpot” with the completion of a heuristically chosen, successful “gene”( Floor plan element), that evolved gene is picked up “automatically” and brought into the next generation. The automation has to be programmed as a parallel running process of course, operating in between the generations of individuals(Populations). You can see the generations as different animations on the dial, and you can also see how the search spaces( numbered) are restructured for each generation. The search spaces are visualized here as concentric circles, moving from the start to the finish. While it takes a lot of generations to find the evolved gene in the first animation, the same result is produced much earlier after the “evolved genes” are detected. Like “unbreakable” chromosomes or atoms they retain their properties through evolution and make the search spaces and calculations smaller and simpler. You can clearly see below how simple notations can evolve into sophisticated ones. These are well known concepts from genetics which have been carried over into computation and “artificial life”. (Click the black space).
I would like to introduce also the operations of the Genr8 plugin, the software plugin introduced into Autodesk Maya 3d software through the C++ Application Programming Interface. The way in which I introduce it is by comparing its strategic and geometric calculations to those in genetics, and I go on to introduce these calculations and their significance into the realm of architecture. This is an extremely important point to make, because of the scientific significance that the work by the likes of A.Lindenmayer, Rosenman, Gero & Schnier.( lit. reference) have had on cross- professional studies. Growth of cells, plants and individuals in nature has influenced many an artist, as well as professionals in different sciences. What we are seeing in addition now however is the bilateral communication and exchange of knowledge between natural sciences like genetics, and the artificial environment of evolutionary computing(EC) and genetic algorithms(GA).
The way I move forward now is to describe geometric operations mathematically and their presentation within the C++ programming language.
By way of explaining what kind of synthetic construct I am trying to build here I re- present a class diagram from earlier posts, although now a bit more detailed.
An object in this system is instantiated in the World class. It is in essence well described by this word, but I will explain it here as it brings together all the elements of the L-Systems, how they are developed, and how Autodesk Maya represents the surfaces generated by these constructs. Scaffold is a big C++ class that handles the internal model of the surface being generated by the plugin. The internal model is basically a graph data structure, although a bit more complicated. It works like this:
The grammar operates on geometric segments(geometric curves or parts of curves), so you need to keep track of those segments to be able to apply the evolutionary productions. The parser(A parser is a software component that takes input data (frequently text) and builds a data structure – often some kind of parse tree, abstract syntax tree or other hierarchical structure – giving a structural representation of the input, checking for correct syntax in the process), uses a syntax similar to that used in a makefile for a programming language make build automation tool.
Getting to the point – I am making a connection between these kind of grammars, Turtle Graphics that I described in blog post B3 and lastly the development of basic algorithms for evolutionary systems. The whole idea here is to identify “genes”(decoded as turtle graphics movement described by grammars) that can be used to evolve floor- plan elements for high rises, and in turn be parameters for elevation into the third dimension. One of the special features of the human intelligence is the ability to focus. What this means is that the human mind focuses and refocuses as if to be able to search large “spaces” of solutions and find essential elements. Naturally Artificial Intelligence would want to do the same. The big difference being that the machine would potentially be able to do the pure calculating operations a lot faster. Rosenman, Gero and Schnier & Sivanandam & Deepa(2007) have theorized this in the cross- disciplinary domain of Architectural Design and genetics. There are differences in the notations of natural evolution genetics and Genetic Algorithms of course;
– The Chromosome in natural evolution is replaced in Evolutionary computation and Genetic Algorithms by the computer language bit string.
– The Gene is represented by the feature or character.
– The Allele is represented by the value of the feature.
– The locus is represented by the position of the string.
– The Genotype is represented by the structure or coded string.
– The Phenotype is represented by the parameter set/decoded structure.
My way of singling out “evolved genes” is not heuristic, but it singles out these genes by using heuristically developed fitness functions. I use more or less common sense to identify shapes that reoccur when superimposing large amounts of high rise floor plans upon each other. Starting with this form of case- based design, the process will be automated soon enough as the only interest in this manual enterprise is to find a sort of common ground upon which most people will have to agree. That common ground represents the floor plan elements that have indeed been developed and evolved by designers during the last centuries. As such my ideas are not radical. Speaking then in terms of genes, a genotype can be expressed in turtle graphic notation as a simple directed line/simple combination of directed lines, in geometrical space, and a phenotype can be described as its potential successor. A floor plan can indeed hold many of these.
As I have touched upon earlier and as you can clearly imagine from the drawing above, some elements in a floor plan like this stand out pretty clearly. You would have no problem imagining the simple description of e.g the elevator shafts as a quadratic element of its own.
So manually identifying some of them and decoding them is a form of reverse engineering them for sure. As long as a coherent combination of basic genes is then found to exist in a multitude of Architectural floor plans then I would personally see that as an exciting angle from which to proceed, in regards to evolving new floor plans. Theorizing, the evolved genes could then be isolated (more/less) as structural elements are in nature, to make calculations more efficient.
Anything you describe int the real world, when interpreted into a digital environment like a 3d software, most likely has to be described by vertices. For movement in the Autodesk Maya geometrical space we use points, i.e vertices. So the vertices are like a point cloud and we keep track of how they are connected using segments, like polygons. The reason I mention this is in reference to the generation of the surfaces of the original Genr8 Autodesk Maya plugin. My aim is to develop this system further.
While the Genr8 plugin makes surfaces of polygons, I want to evolve floor plans as the first step, before using a modified Genr8 plugin to evolve the third dimension.
Genr8 2011
Genr8 is a plug-in that was conceived and written at the start of the new millennium, and the software and hardware capabilities have developed since then. The plug-in can be implemented in new versions of Maya of course, but it has to be somewhat debugged and recompiled. The plug-in can be downloaded from the "plug-ins" page on this site. I made a debug version of the original plug-in in 2011 for Autodesk Maya 2010 & 2011. This Debug version was the start of my skyscraper project.
On this page I will be linking to my own progress through live blog - feeds of different kinds. The left sidebar shows main Categories and listed posts - Right sidebar shows live posts from the blog.
The basis for my personal obsession is the original plug-in written by Martin Hemberg at MIT. In essence what this software does is to help search a large universe of surfaces to find ones that are in coherence with the parameterized environment they are put in, that being a geometrical scenario in Autodesk Maya 3D software. Put simply it finds possible configurations of polygons according to an environment and a seed from which the construct grows by way of an algorithm. The way it does that is by substituting letters of a grammar string with graphical elements, and then the representation of this object can be checked for "fitness". How to check for fitness is of course one of the biggest challenges in making a tool like this because you have to put numeric value and weight to things that are difficult to assign quality to. Basically the curse of any complex program. Parameterized fitness functions can do that job but are not easy to implement. To conclude on the basic fundamentals for my work: Find a grammar that can grow a universe of self - avoiding, functional architectural plan drawings. This point of self- avoiding should be self- explanatory because Architects are naturally working with shaping their environment and leading people through Architectural space. Their drawings have to adhere to the real world and thus be adoptable by engineers and the construction business. The challenge lies in strictly regulating the grammar that decides the possible combinations of elements in something like a plan drawing. The way I propose to do that is to target a successful design with this kind of "evolution", and once grown, use the "recipe" to grow a plethora of alternatives, making use of computer calculating power. Then run fitness functions on the structures to "shape" the designs. I refer to this article for academical support concerning the matter. I also refer to the Buildings page for more on my methodology.
You can find comparent information in the blog posts on the left of the page but this text will go on to visualize in short the process of redeveloping the Genr8 plugin.
More to follow....