Monday, September 8

Cloud Reef




Saturday, August 30

SWARM_01

A first study into particle swarm behavior, with the help of RealFlow and Python scripting.
This code adjusts each particles's velocity and direction to the average value among its neighbors (within a specified distance).
However, in this script, the movement of the particles becomes far too uniform after some frames
already. More to come...




#version: august 29th, 2008
#description: EVENTS SRIPT / basic swarm behaviour test:
#get speed and direction of neighboring particles,
#calculate average and adjust own

def onSimulationBegin():
emitter = scene.addEmitter("Circle")
emitter.setName("Emitter1")
emitter.setParameter("Type","Dumb")
emitter.setParameter("Point size",1.0)
emitter.setParameter("Max particles",0)
import random
for i in range(0,50):
emitter.addParticle(Vector.new(random.uniform(-1,1)*3,random.uniform(-1,1)*3,
random.uniform(-1,1)*3),Vector.new(random.uniform(-1,1)*5,
random.uniform(-1,1)*5,random.uniform(-1,1)*5))


def onSimulationStep():
scene.message("|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||")
emitter = scene.getEmitter("Emitter1")
particle = emitter.getFirstParticle()
while particle:
#scene.message("INITIAL velocity = " + str(particle.getVelocity().x) + " | " + str(particle.getVelocity().y) + " | " +
str(particle.getVelocity().z))
neighlist = particle.getNeighbors(2)
scene.message("neighbors: " + str(len(neighlist)))
velsum = Vector.new(0,0,0)
for i in range (0,len(neighlist)):
neighbor = neighlist[i]
velneigh = neighbor.getVelocity()
#scene.message("velneigh = " + str(velneigh.x) + " | " + str(velneigh.y) + " | " + str(velneigh.z))
velsum = velsum + velneigh
#scene.message("velsum = " + str(velsum.x) + " | " + str(velsum.y) + " | " + str(velsum.z))
velaverage = velsum / Vector.new(len(neighlist),len(neighlist),len(neighlist))
particle.setVelocity(velaverage)
#scene.message("UPDATED velocity = " + str(particle.getVelocity().x) + " | " + str(particle.getVelocity().y) + " | " +
str(particle.getVelocity().z))
scene.message("-----------------------------------------------------------------------------")
particle = particle.getNextParticle()


Wednesday, July 30

off

I didn't update this for quite a long time, but it'll go on very soonish! stay tuned...

Meanwhile, I worked on some other things, such as a proposal for the exhibition "Situated Technologies: Toward the Sentient City" (http://www.situatedtechnologies.net/).
Here is an excerpt from my text:


The notion of a Sentient City accomplishes to depict the increasingly dispersed technological intelligence incorporated in today's urban landscapes, which more and more pushes architecture to becoming a living organism in the city's network.
What interests me in this respect is the allusion to a kind of “breathing” urban environment, one that is able to spatially interact with its inhabitants, in a way giving us back a tactile relationship to our surroundings that we seem to have almost lost, as Richard Sennet remarks.
Sentient City points at the need for architecture to come up with ideas on how to develop a sensual-/-responsive relation to people. Exploring ways of bodily interaction between hybrid (actual/virtual) space and its users seems to be the key task at this point.

If we render visible the existing, fluctuating topography created by the movement patterns of mobile communication devices across the city, much in the sense that projects like Real Time Rome (Senseable City Lab, MIT) or Sky Ear (Usman Haque) do, we may see some kind of an urban radio-climate. Hybrid weather is the idea to translate this constantly changing 'hertzian space' into a semi-actual, semi-virtual weather that indirectly visualizes our presence and activity, as it is beeing increasingly paralleled by our mobile devices' presence and activity.
Working with this twofold condition of presence, on the side of the user (double existence as body and electronic extension) as well as on the side of the medium (real and virtual cloud), may be a promising approach to the development of a kind of sensitive urban environment.




And an initial proposition of research:

This project goes back to a design I did as a student at RWTH Aachen University. Cubic Cloud (see links), a winning entry to mind(21)factory ideas competition in 2007, explores space as an immersive medium of actual and virtual components. Here, architecture is conceived as a cloud of tiny radio-controlled foglets which float around to create constantly changing artificial atmospheres.
Cubic Cloud, largely inspired by Diller&Scofido's idea of the 'inhabitable medium', draws on a novel notion of architectural space that goes beyond the 1/0 concept of matter and void.
Several factors form the background for this concept, among them current tendencies of dematerialisation in architecture and the arts, corresponding to processes of dissolution throughout contemporary culture.
Related to this, the increasing technological intelligence incorporated into urban landscapes as well as notions of electromagnetic space that surrounds us and is gaining increasing importance in the description of space as we perceive it. Furthermore, nanotechnology and its both optimistic and scary projections onto the future of the city.

Taking Cubic Cloud as a point of origin, the proposed work imagines our future urban environment as a programmable particle system, creating a scenario where extensive parts of the physical world will have passed halfway into the virtual world. Essentially, the city wouldn't anymore consist of stone and glass, but of fields of clouds, the concept of the architectural object being abandoned in favor of the medium.

The key task then would be to explore how concepts of weather could be used as models for dealing with this projected condition of urban space, and to develop, through reverse engineering, an organisational code for its tectonics. Looking at the intricacies of urban space with its dynamics, moods, fluctuations, which all together make up a highly complex system of an extreme multitude of parts, notions of weather could turn out to be adequate models, discussing phenomena like currents, fronts, collisions and being able to understand urban dynamics in terms of an emergent life cycle.
Further, regarding the increasing technologically enhanced sensibility of our environment, are there notions of artificial, technological weather systems that could be useful to describe urban space? Given the increasing ubiquity of technologies, which more and more involve us in a bodily way, what would such techno-atmospheres be like?
In this regard, the exploration of hertzian space as an influencing or driving force my be an interesting aspect. What rules and what dynamics does it come up with?

In this way, the electromagnetic fields of both natural weather and urban wireless communication networks could eventually admix to create an urban second nature, while dissolving architecture into the natural weather system.
Hybrid Weather would be the cross between natural weather, pervasive technology, and the built environment.

This idea of an augmented cloud architecture interests me on a philosophical as welll as on a practical level.
The initial point of interest would be the very concept of a blurry space, exploring weather as a model for our perception and negotiation of space and for an aestetics of a possible future city, which will be marked both by dissolving boundaries and increased networking. Could one term an Atmospheric Turn, a parallel Spatial Turn giving consideration to the rising importance of fuzzy notions of space? Is there something like a blur paradigm in contemporary culture?
Deliberations like these also hint at the relationship between space and transparency, which becomes tremendously important in times of perfected location-based systems in conjuction with advanced surveillance techniques.
Hybrid Weather would offer interesting perspectives in this regard. Being able to take on different atmospheric states of aggregation, it would both make space more transparent (by visualizing spatial relations and dynamics) and at the same time, through blurring, may provide for visual indeterminacy and radio shelter.
Essentially, Hybrid Weather would conceive and seek to discuss virtually augmented space as a social medium, “as substance rather than just a void – something that needs a structure, a politics, and a poetics.” (Lev Manovich)

Furthermore, the possible construction of such a blurry space would be of special interest. Departing from the idea of a cloud structure, major focus would be put on issues of form and organisation.
Since I am specially concerned with the transitory capacities of form as well as with the relationship between model and reality, the reference to a current theoretical debate focusing on form in architecture may be interesting. Acting on the assumption of a subdivision into morphodynamical (e.g. Rem Koolhaas, Sanford Kwinter) and morphogenetic (e.g. Greg Lynn, Jeff Kipnis) tendencies, for example, what could weather architecture's contribution to the discussion be?
Effectively, it has the potential to situate itself somewhere in between, as it would be fundamentally marked by external influences as well as by its internal structure. Cloud architecture would bare a tectonics which references the outside and at the same time goes back to its very foundations on the nano scale, thus performing a constant oscillation between external and internal form.

Considering both notion and construction of Hybrid Weather, its theoretical and practical sides, what seems to be most fascinating are these ambiguous intrinsic qualities that I tried to point out here, and which I would like to investigate more deeply on.



Finally, a diagram I did earlier illustrating the project's contents and basic structuring:




















Thursday, May 1

Recursive Growth_01

It took me some time to understand how Recursion (link1, link2, thxs link3!) works, and to code a recursive version of the last script.
In the older version of the script, each element may only create one new element, so that one single path of growth is created. Yet, in the function below, elements are copied and moved as before, but each new element may trigger the creation of several new ones, meaning that the system grows in all directions, like a branching tree.

Since the recursive function has to be able to stop itself at some level of depth, I added an 'internal' generation counter G. Also, there is an internal element counter (n) that is necessary for the recursive algorithm to add elements in the right branch order of the growth tree.
However, in order to have all distributed elements stored in an array (and to be able to search for elements, like checking for occupied positions), there must be an “external” counter, in this case t, which counts the actual elements being added.


























































'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
Function functRecGrowth (n, t, arrVec, arrPoints, strVolume, arrFlakes, arrReloc, G)


Dim j

If G >= 20 Then Exit Function

For j = 0 To 5
ReDim Preserve arrVec(n)
ReDim Preserve arrFlakes(n)
ReDim Preserve arrPoints(t)
If (Rnd > 0.7) Then
arrVec(n) = PointAdd (arrVec(n-1), arrReloc(j))
arrPoints(t) = arrVec(n)
If functOccupied (arrPoints, t) = False And IsPointInSurface (strVolume, arrPoints(t))Then
arrFlakes(n) = CopyObject (arrFlakes(0), arrVec(0), arrVec(n))
t = t + 1
'Print ("t = " & t & ", n = " & n)
Call functRecGrowth (n+1, t, arrVec, arrPoints, strVolume, arrFlakes, arrReloc, G+1)
End If
End If
Next

End Function
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''


With a bunch of snowflakes (here abstracted),
the first experiments into fractal behaviour/
recursive division...







Friday, April 25

Koch Snowflake 3D_02

























The last script was built to assemble a one degree bigger 3D Koch Snowflake from a picked base flake. If you change the loop contained in it with this one here, you will have a randomly growing snowflake accumulation...! Also, I added a function preventing snowflakes from being copied in positions that are already occupied by other flakes.

If you'd like to try out increasing the max. i value, go ahead! - but I told you beware of your graphics RAM...

__
EnableRedraw (False)
'''''''''''''''''''''''''''''''''''''''''''''''
For i = 0 To 50
For j = 0 To 5
ReDim Preserve arrVec(n)
ReDim Preserve arrFlakes(n)
If i = 0 And (Rnd > 0.5) Then
arrVec(n) = PointAdd (arrFlakeBase, arrReloc(j))
arrFlakes(n) = CopyObject (strFlake0, arrFlakeBase, arrVec(n))
n = n + 1
ElseIf n >= 1 And (Rnd > 0.5) Then
arrVec(n) = PointAdd (arrVec(n-1), arrReloc(j))
If functOccupied (arrVec, n) = False Then
arrFlakes(n) = CopyObject (strFlake0, arrFlakeBase, arrVec(n))
n = n + 1
End If
End If
Next
Next
'''''''''''''''''''''''''''''''''''''''''''''''
EnableRedraw (True)


'''''''''''''''''''''''''''''''''''''''''''''''
Function functOccupied (arrVec, n)
Dim k
functOccupied = False

For k = 0 To Ubound (arrVec) - 1
If PointCompare (arrVec(k), arrVec(n)) = True Then
functOccupied = True
Exit For
End If
Next

End Function
'''''''''''''''''''''''''''''''''''''''''''''''


Monday, April 21

Koch Snowflake 3D_01


































Worked on a script that builds 3D Koch Snowflakes from a given Base-Flake (1°), here is what it looks like.
The key was to have the coordinates of the object's bounding box. The Flake fits perfectly in, it's extremities all touch the box at /2, /3 or /4 edge lengths... holy geometry!

There are some reasons why I decided to try the Koch Snowflake geometry:
It it sort of a 3D tiling pattern, it grows recursively, like a fractal, it consists of just one simple module (itself being built from 8 even tetrahedrons) and last but not least, I just loved the snowflake allusion!

___
Option Explicit
'written by cubic on April 21th, 2008
'pick 3D Koch Snowflake to build +1° bigger flake


Call Main
Sub Main

Dim strFlake0
Dim arrBBox
Dim BoxX, BoxY, BoxZ
Dim arrFlakeBase
Dim arrReloc(7)
Dim arrVec(7)
Dim arrFlakes(7)
Dim n : n = 0

strFlake0 = Rhino.GetObject ("Please pick a 3D Koch Snowflake")
arrBBox = Rhino.BoundingBox (strFlake0)


'''''''''''''''''''''''''''''''''''''''''''''''
'Calculate base point (arrFlakeBase) for picked strFlake0, from flake's Bounding Box.

BoxX = Rhino.Distance (arrBBox(0), arrBBox(1))
BoxY = Rhino.Distance (arrBBox(0), arrBBox(3))
BoxZ = Rhino.Distance (arrBBox(0), arrBBox(4))

arrFlakeBase = Rhino.PointAdd (arrBBox(0), Array(0, BoxY/4, BoxZ/3))


'''''''''''''''''''''''''''''''''''''''''''''''
'Calculate relocation vectors for copies of strFlake0.

arrReloc(0) = Array(BoxX, 0, 0)
arrReloc(1) = Array(BoxX/2, BoxY/4, BoxZ/1.5)
arrReloc(2) = Array(BoxX/2, -BoxY/4, BoxZ/3)
arrReloc(3) = Array(BoxX/2, BoxY*0.75, 0)
arrReloc(4) = Array(0, BoxY/2, BoxZ/3)
arrReloc(5) = Array(BoxX, BoxY/2, BoxZ/3)
arrReloc(6) = Array(BoxX/2, BoxY/4, -BoxZ/3)


'''''''''''''''''''''''''''''''''''''''''''''''
'Make copies of strFlake0 and move to new positions ...

For n = 0 To 6
arrVec(n) = Rhino.PointAdd (arrFlakeBase, arrReloc(n))
arrFlakes(n) = Rhino.CopyObject (strFlake0, arrFlakeBase, arrVec(n))
Next

End Sub

Friday, March 28

UPDATE: MACDOWELL COLONY - CUBICLOUD GOING STATESIDE!

From April 9th to June 5th, CUBICLOUD will be Artist-In-Residence at The MacDowell Colony, NH, USA.