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.