volatile prototypes

Closing Down + Moving!!

2011-03-15T03:16:00.000+02:00

The Short Version:

This blog has permanently moved to a proper site. The new address is:

www.volatileprototypes.com

The --ramblings-enabled version:

Almost three years ago, at a time when I was bringing my first works and thoughts on computational art and design online, blogging now and then about relevant and not so relevant stuff seemed quite fun. However, as time went by my engagement with computation in design got a little bit more serious. And then a little bit more and more, until I realized that the blog as a medium was unable to "hold my thoughts" in an efficient manner, simply because they were no more frequent minute posts but mostly sparse and organized entities. Blogging became quite clunky, unable to respond well to large chunks of info posted from time to time. Not from a technical viewpoint, but from a structural one, long-lasting information becoming hidden in the blog's continuous 'stream of events', masked by the tiniest updates and news, and therefore turning essentially inaccessible.

In view of this situation I began a proper, structured site about half a year ago. Recently it has been redesigned and now is central to my research and experimentation on computation and design.

Therefore, I'm ultimately putting this blog to bed. Thanks all for participating and I hope to meet you at the new site: www.volatileprototypes.com And if you're still not bored and have some time, check out my design portfolio too.
Thanks! (';

-Yiannis

ps. Blogs closing down are kinda funny and sad at the same time. And there are so many. Maybe someone could set up a gallery of abandoned/ inactive/ shut down blogs. Just sayin.

(picture is from this flickr set)

fvlib update and Github repo

2011-01-20T23:58:00.000+02:00

fvlib has been updated with a solver that may be of use when visualizing 3d pointsets/graphs. It allows the separation of coinciding points from a specific user-defined viewpoint. More info at the fvlib page, or head directly to the Github repo.

Configurations, fin

2010-12-03T17:27:00.002+02:00

Below is an abstract of the project I've been working on as part of my graduation at TU Delft for the past three months.

In architectural design, the process of designing an efficient spatial configuration that reflects the project’s essence is a crucial part of the design process of almost every project. This holds true especially when it comes to projects with complex building programs, featuring a large number of discrete spaces, as well as complex configurational requirements. Lately, there is increasing interest to employ computational methods for the analysis and synthesis of spatial configurations.

The aim of this study is to introduce a computation-based analysis and optimization process, and it’s implementation into a digital design tool, with the goal of suggesting potentially efficient spatial configurations, based on the input of configurational information and a range of performance parameters by the designer.

A generative method is proposed, based on a 3D data structure to encode spatial configurations, a compositional method for the generation of configurations and the use of heuristics for the evaluation and evolution of solutions according to conformance with the designer’s requirements. The implementation of this method into a digital design tool aims to be easily accessible by designers, utilizing a simple interface and expressive visualizations of results, so that usage along the design process becomes feasible.

More info and images can be found at the bocskit page.

A compiled version of bocskit is available for download, however source code will be released at a later time.

Generative Arts 2010

2010-11-21T16:50:00.000+02:00

A paper with the title "Computational Optimization as means for exploring structurally efficient surfaces" will be presented at the 13th Generative Art conference Politecnico di Milano, Italy, 15-17 December. The paper is closely related to the development of 'surfkit', a tool whose function is to optimize user-defined, self-supported surfaces by distributing their thickness in order to minimize deflection.

More info about surfkit...

Configurations, Part 5

2010-10-28T13:34:00.002+03:00

Just a quick update of what's going on with the current project...

fvlib release 4, surfkit release 2

2010-10-25T13:14:00.001+03:00

fvlib has been updated to it's fourth release. More info and downloads here. Also available as a Google Code project.

surfkit has been updated to it's second release. More info and Downloads here.

Configurations, Part 4

2010-10-19T14:09:00.020+03:00

I've so far performed a series of elementary tests, mostly to validate functionality and out of curiosity for the first results. Each image is shortly explained.

Please note that the interface and visualization of the application are in a totally initial stage and therefore not polished at all.

Test 1, 2: Connectivity

In the first test, the goal was set to achieve as many of the connections specified in the original matrix as possible. The original matrix was semi-randomly generated, by filling a percentage of 3 randomly selected rows/columns while leaving the rest blank. This arrangement corresponds to a centralized circulation layout with a few spaces being having the role of a "hub", and the rest being passive in terms of circulation.
The first test resulted into a solution with very high fitness value, satisfying all connection requirements except two. In order to validate this, a second test with the same parameters was performed. However, in the second test fitness did not turn out as high as in the first. This can be attributed to two reasons:
The evolutionary process is in it's early stage and needs further study to increase the effectiveness of the search for optimal solutions.
An optimal solution is not achievable with the specific connectivity scheme

Results

In the images below you can seen the original fittest and final (after evolution) fittest solutions. Next to the arrangements is a bar displaying the fitness value and an overlay of the required and actual connectivity matrices.

Test 1: Initial Fittest Solution

Test 1: Fittest Solution after approx. 10000 generations of 239 members (10 min runtime)

Test 1: Parameters

Test 2: Initial Fittest Solution

Test 2: Fittest Solution after approx. 10000 generations of 239 members (10 min runtime)

Test 2: Fittest Solution, alternate viewpoint

Discussion of the Results

It is clear in the first test that, while most connectivity requirements are satisfied, spaces with irrational characteristics appear. To satisfy their connectivity, some spaces have gained so much height that the solution is no realistic. Moreover, there are spaces with no adjacency whatsoever to the outside, a feature which further decreases the feasibility of the solution.

Test 3, 4: Connectivity + Adjacency to Surface

A second performance factor has been added to thess tests, which requires at least one block of every different space to be in contact with the surface of the building volume. Again, the connectivity matrix was semi-randomly generated as in the first test.

Test 4: Initial Fittest Solution

Test 4: Fittest Solution after approx. 10000 generations of 250 members (10 min runtime)

Test 4: Fittest Solution, alternate viewpoint.

Discussion of the Results

While it seems again that the solution found is performing very well, spaces outside the allowable height range still appear. Essentially, all spaces that are required to have a large number of connections are oriented vertically, so that they can be in contact with as many other spaces as possible.

Test 5, 6: Connectivity + Adjacency to Surface + Height Limit

In the last two tests the aim was to produce solutions that adhere to height restrictions for each space. The representation used so far is dimensionless, therefore "floor" has been chosen as the height unit in this case. This equals roughly 3 meters for a typical office floor. Once again, test was performed using a semi-random connectivity matrix.

Test 5: Initial Fittest Solution

Test 5: Fittest Solution after approx. 10000 generations of 252 members (10 min runtime)

Test 5: Initial Parameters

Discussion of the Results

It is evident that much more feasible solutions begin to appear with the introduction of the height limitation via penalization. Still, probably due to the number of unique spaces and the intense connectivity requirements of some of them, the connectivity satisfaction is impossible to achieve in it's entirety.

Next tests will be after a basic data input interface is implemented, so that working on actual configuration data becomes possible.

Check back soon!

Configurations, Part 3

2010-10-16T17:50:00.004+03:00

I have so far been able to implement the code required for storing Constructor Graphs, Connectivity Grids and Integration Matrices. The necessary routines for constructing Grids from Constructor Graphs, evaluating, generating matrices and evolving according to a simple GA is also there. These data structures and processes are described in greater detail in my previous post.

The Organization Scheme that reflects the programmatic organization of the project can be seen in Fig. 1.

Fig. 1: Organization Scheme of the project

The process begins with a fixed-length chromosome that determines the order and orientation of the combination process that produces the final volume. From the chromosome and via the Constructor Graph emerges the Connectivity Grid, which is the essential specification of the building's connectivity, ignoring dimensions of spaces. From the Connectivity Grid, various "profiling" data can be synthesized, such as the Connectivity Matrix or the Integration Matrix, both of which describe the connectivity between all different spaces within the building volume, the former being a simplified version of the latter.

At this point, I'm still using comparisons between Connectivity Matrices as an evaluation scheme. I shall use this instead of the full-fledged Integration Matrix for the meantime, till I can test all functionality and make sure that all methods and processes are implemented correctly.

The selection happens by means of multiple deterministic tournaments or predefined size, until a fixed-size mating pool is established.

The evolutionary process utilizes a crossover function between two members and two types of mutation functions (a simple point mutation and a swap mutation, each with it's own adjustable probability).

In order to preserve best solutions across generations, a simple rule was added that automatically passes the best solution of each generation to the next, without any modification. Of course, there is still chance that this solution will participate in selection tournaments.

Initial test results will be posted shortly.

Fig. 2: Screenshot of the program in operation, showing 20 population members

Configurations, Part 2

2010-09-28T16:15:00.017+03:00

As mentioned earlier, this study will introduce an analysis-generation tool aiming to suggest alternatives to user-specified spatial configurations, variants that maintain some of its properties and possibly have the potential to improve on others. While the main interest of this project is architectural design, the same process can be expanded (at least in principle) to other fields of design where spatial configuration of elements is of importance.

1. Variants

A variant is a form or version of something that differs in some respect from other forms of the same thing. One systematic process to produce a variant, is to keep part of the information of the original to form a more ʻabstractʼ representation. This procedure produces a 1:many relationship between the original and the representation. The information can then be used to evaluate other objects: If their relevant properties are close enough, then they can be classified as variants of the original.
Depending on the information that is kept, variants that share different properties are produced.
Representation of the information is critical because it dictates what types of properties should be kept and how easy it is to make efficient and meaningful changes, in combination with the process of generation.

In the case of this project spaces within a building volume and relations between them are of primary significance. Therefore, variants produced by the tool should primarily be close to the original in terms of spatial character. How exactly 'spatial character' is interpreted will be discussed further later on.

2. Process

The process is two-fold, separated into analysis and generation:

First, user input is abstracted to form a profile of it's significant properties. This step requires that either the input data is presented to the computer in a recognizable format, or that a recognition engine is built in, e.g. since we are concerned with volumes, if a volume or connection-specific diagram is presented no further processing is required, the profile can be derived immediately, however, if a floor plan or other form of representation is used, a recognition engine should be used to extract the significant volume and connection-specific properties.

Steps of the Analysis Process

Following this step, an iterative generation-evaluation process begins. Based on a generation algorithm, populations of spatial configurations are put together and their profile is evaluated against the original. If the pattern is similar, the candidate receives a good fitness value. Additional performance factors may be considered at this stage, in order to enable possible improvement of an aspect of the building/arrangement.

Steps of the Generative Process

3. Encoding and Representation

The fundamental representative entity is a 3D grid. Each cell of this grid references a different space. Therefore, spaces may correspond to one or more grid cells. Depending on the outcome of the analysis and generative processes, spatial entities may appear on the grid in different forms, e.g. if a volumetric representation is chosen the number of grid cells referencing a single space is equal to the space's volume, however if a connective representation is chosen, the number of grid cells is the minimum required to satisfy the space's connections. So, in the second case, if a space has at most one connection per side, it's mostly possible that it will be referenced by only one cell within the grid.
The 3D grid is therefore the 'meeting point' between analysis and generation. From this grid further information can be extracted, forming a profile of each configuration that can be used as an evaluation index.
From the generative part, each grid is produced from a 'constructive' graph, which dictates the orientation of the combination actions between spaces and their sequence. In turn, the graph is encoded as a string of integer numbers, a suitable form to apply evolutionary operators onto.

4. Generation

For the generation of population members (connective grids, volumetric grids and profiles) a GA-based approach is chosen. GA seems suitable for a case like this one because it requires no knowledge of the topography of the solution space. Other approaches sharing this characteristic (such as Particle Swarm Optimization) may also be suitable and will be investigated in the future.

5. Evaluation consists of:

A core that comprises of spatial analysis techniques and specifically techniques related to Space Syntax. Space syntax, according to Hillier "is a set of techniques for the representation, quantification, and inter- pretation of spatial configuration in buildings and settlements. Configuration is defined in general as, at least, the relation between two spaces taking into account a third, and, at most, as the relations among spaces in a complex taking into account all other spaces in the complex. Spatial configuration is thus a more complex idea than spatial relation, which need invoke no more than a pair of related spaces."

Supplementary/ Plugin evaluators that may refer to various building properties e.g. energy, daylight, view, privacy, building envelope.

The basic evaluation profile, which is used to compare the original and the variants, consists of an Integration Matrix. An integration matrix for n different spaces it is a n*n symmetric matrix that contains, for each space, values holding the number of spaces that an agent has to walk, to get to another.

Example of how an Integration Matrix would look like

6. Extensions

One principle of the project should be that it's various methods and algorithms should be interchangeable, i.e. while the basic process outline may remain the same, the various modules performing generation, evaluation, translation from encoding to representation etc. should be interchangeable. In order for that to be accomplished, the process should be implemented into a 'framework' of sorts, with basic structure built-in and plugin additions that affect functionality.

The basic structure will be implemented into a series of JAVA library classes, on top of which interaction and secondary classes will be implemented in Processing.

Configurations, Part 1

2010-09-14T18:38:00.004+03:00

I began working on a project that is part of my graduation program at the Computation & Performance track at TU Delft. The project is related to the study of configurations of spaces within a building.

Architectural design begins by generating ideas and continues by transforming them to concrete spatial formations. During this process, the specifications of the project are manifested into a spatial configuration and by the end of it (which takes place rather late in the overall design process) the architectural artefact has obtained most of it's ultimate features and properties.

While the abstract process of combining spaces or shapes together can be broken down to a series of geometrical transformations, in architectural design there is no precise methodology for that matter, at least not one accepted universally. The process of designing a building is often as fuzzy and unclear as its goals.

Architects learn about the design problem by creating alternatives and testing them in order to gain desired spatial formations. In the absence of a concrete theory or a specific design methodology, examples and references become then the designer's most frequently used tools.

Examples are indeed of great importance: A designer will systematically utilize references of configurations, images, inspirations, as well as alternatives already investigated for the project itself, all put together in a complex combinatorial design process. Therefore, the availability of resources during this process is critical, as it allows for the domain of possible solutions to be broadened.

That being said, the project will revolve around introducing a spatial analysis-generation tool aiming to suggest alternatives to user-specified configurations, alternatives that maintain some of its properties and possibly have the potential to improve on others. Specifically, analysis methods based on established spatial analysis theories, such as the Space Syntax group of theories will be used to create 'profiles' of the user-specified configurations, an abstraction of certain spatial qualities of the design. Based on this profile and using a generative, evolution-based method, new configurations will be generated, in order to explore alternate configurations that are similar to the configuration profile extracted from analysis.

The workflow of the tool should be such that promotes the use of examples. This is best suited to the architectural design process. Therefore, the input should be formulated into recognizable architectural arrangements (e.g. floorplans or models), and the output (the alternative configurations) should also follow this paradigm.

Transition to a new site!

2010-08-26T13:45:00.001+03:00

Being generally disappointed by Google Sites and the flexibility it offers, I decided to switch to a custom content management platform, so I gave Indexhibit a shot last night.

Well, its really nice, but switching hosts, updating DNS etc gave me a terrible time. So everything is not done yet and file access maybe limited for a few days as I move files to the new server.

To sum up:

http://prototy.blogspot.com points to this blog (will be merged with the new site soon).
http://blog.volatileprototypes.com points to the new site (again will incorporate blog soon).
http://www.volatileprototypes.com points to the new site.

So, go ahead and visit the new site and tell me what you think! Thanks!

eerkit release 2 and fvlib release 3

2010-08-09T22:49:00.001+03:00

fvlib's structure was completely rewritten. This resulted in a highly modular class structure that will allow the easy expansion of the library’s functionality. Some extra functionality has been also implemented, namely the simulation of “charged” Particles Interaction Solvers.
Furthermore, most property-setting methods of classes implement the return of the instance itself so that adjustments can be chained together in one line, therefore saving some typing and promoting ease of reading.

fvlib is released under the terms of the BSD License.

Download(library, source, documentation, examples)

More info about fvlib here.

eerkit has been enriched with a lot of functionality. It is now possible to edit most of the properties of the flex elements, add and delete linear and point elements etc.

eerkit is released under the terms of the BSD License.

Download(Windows, OS X, Linux, source)

More info about eerkit here.

A new look / a new mapping

2010-08-01T19:36:00.003+03:00

Volatile Prototypes has been updated and modified in a couple of ways:

There is a new domain name, www.volatileprototypes.com, within which you can find an extensive site with all the projects previously exhibited here, organized in a systematic fashion.
This blog has also a new address, blog.volatileprototypes.com. It is though still accessible through the old address, prototy.blogspot.com.
Most of the features of this blog such as links and sidebar content have been moved to separate pages accesible through the sidebar menu.

Please note that some features of the new site structure are not yet ready and updates are being made on a daily basis.

Events

2010-06-27T02:51:00.006+03:00

Inprocessing is "an open forum for sharing creative coding and practice", initiated by Lewis Sykes of Cybersonica and Dave Mee of MadLab. Every month Inprocessing organizes open sessions at MadLab where people can show their work and introduce their latest discoveries related to digitally enabled art, performance and design. There are also presentations by artists and practitioners of the field, so, for last month's event I was kindly asked by Lewis to talk about some of my work telematically. Telematic presentations are a great idea that enables small communities to host or participate in events regardless of their location. Indeed the session ended up as a wonderful event, with contributions from Sam Meech and Lewis.

Videos and resources from each event are posted on the website so its gradually turning into a sort of "indie mediatheque", with videos, texts, presentations and code from contributors.

So, take some time and pay a visit, it's really worth it. And look forward for more events.

For those of you that have an interest in design and computational media and plan on being around Athens, Greece this summer, there is an interesting workshop going on, titled "apomechanes":

"apomechanes is an intensive 3 week computational design studio held each summer in Athens, Greece. The studio is devoted to furthering techniques and concepts of algorithmic processes as means for design and fabrication. apomechanes brings together individuals from diverse backgrounds and fields of study to discuss, exchange and collaborate on projects that investigate modes of algorithmic and machinic processes in architectural design."

Force Directed Bundling / eerkit

2010-06-06T00:56:00.022+03:00

Update: There is a new version of eerkit and the underlying fvlib. You can find it here and here (blog post here)

I recently came upon an interesting paper by Danny Holten and Jarke van Wijk of TU Eindhoven (paper at visualcomplexity.com), regarding edge bundling in graphs in order to reduce visual clutter. Their method is based on the use of flexible graph edges that visually group neighboring links. The edges are modeled as point-spring systems that are attracted to each other based on a set of relevancy criteria.

This gave me the idea to implement a similar technique of defining attract-repulse relations between graph links in 3D space as a method to generate spatial arrangements diagrams (e.g. form finding or circulation diagrams) that adhere to proximity constraints. I've implemented an alternative approach using agent flows (ribonkit) in the past, but this approach looks equally, if not even more promising.

The outcome so far is a simple interactive applet (eerkit) that allows one to draw edges in space, which are subsequently grouped or separated depending on their direction, distance from each other etc.

Use shift-click or ctrl-click to generate new nodes. Between two subsequent nodes an edge is automatically drawn. Hit 'R' to start over.

eerkit was developed using Processing 1.1, peasycam and a new version of fvlib which I will release soon.

The fact that 'bundling' methods are based more or less on the simulation of forces renders them interesting in yet another way: Their result can be modeled quite easily in reality as a maquette. The following photos contain aspects of the result of such an effort.

I modeled those using flexible cylindrical plastic elements (the ones used for architectural model-making) and cyanacrylate adhesive. There are 7 nodes and about 20 edges connecting the nodes. The form of the object was quite easy to achieve using temporary fasteners in order to simulate the attractive forces between the links. The flexibility and linear stiffness of the plastic elements did the rest of the job by itself. I'm planning on repeating the 'experiment' with elements of different thicknesses, in order to simulate edge stiffness.

Inprocess:ing v.1.3 - Exploring Designs via Computational Tools

2010-05-15T14:07:00.025+03:00

Thursday, 20th May 7-10pm(and third Thursday – or thereabouts – of the month thereafter)
Madlab (Manchester Digital Laboratory)

36-40 Edge Street, Manchester M4 1HN
(Between Thomas St and the Craft Centre, opposite A Bar Called Common)
madlab.org.uk

inprocessing.cybersonica.org

Telematic presentation by Delft based architect Yiannis Chatzikonstantinou - exploring designs via computational tools;
‘In-the-flesh’ presentation by Liverpool based digital ‘videosmith’ Sam Meech;
Informal ‘show-and-tell’ and ‘open-laptop’ sessions (go on... bring some of your own work along).

InProcess:ing focuses on the Processing language, environment and community (though not exclusively) as a vehicle to support and encourage creative collaboration and meaningful exchange between a diverse group of practitioners, creatives and hobbyists. It aims to create a playful, experimental space and a supportive framework in which people can share their work, realise new technological ideas, be inspired, challenged and stretched.
Join us at the next session to see Processing in action, meet other interested and like-minded people and find out more about the project and how to get involved;
Visit the InProcess:ing website to catch up with developments and future plans, watch past presentations and follow up on interesting links;
Join the forum and share your favourite Processing sketches, suggest practitioners/work for future presentations, offer useful techniques and online resources and tell us what you’d like to see from the project.

For full biogs, photos and links visit the InProcess:ing website.

Visualizing Flows

2010-05-08T01:10:00.016+03:00

The rendered sculptures above are an interpretation of fluid flows around objects. Specifically, they represent heightfields of velocities of fluids forced into a constant horizontal flow. The models have been generated with the program TN7.

TN7 is a project I started about a year ago (also named TN6) that was aimed towards developing a "virtual wind tunnel" for artistic visualizations of fluid flows. It is based on the library MSAFluid by Memo Akten, a fluid solver based on Jos Stam's programmatic implementation of the Navier-Stokes equiations describing the motion of fluid substances.

I updated TN7 recently, fixed a few issues and included a more intuitive interface. Therefore, release 2 is available for download.

Please note that this release is based an a 'hacked' version of MSAFluid. I arbitrarily changed a few parameters in the source code just experimenting with the realism of the visual outcome. Therefore these hacks are really program-specific and really based on intuition. This hacked version is included in the download package. The exact changes are mentioned in the source file. However, you can re-compile TN7 (or export with processing) to work with the original MSAFluid, just with a minor change in it's source code which can very easily be done with processing.

TN7 has been developed in Processing 1.1 using MSAFluid and peasycam.

It is released under the BSD License.

TN7 release 2 (Windows, Linux, OS X, Source, MSAFluid 'hacked' version)

fvlib, release 2: A (faster!) point-spring solver library for Processing

2010-04-26T22:42:00.008+03:00

fvlib release 2 adds support for parallel processing of points and links, via the java.util.concurrent framework. It offers an increase in performance of about 50% from the previous release, given that a dual-core computer is used. Performance figures can be even higher for more than two processors.

This library is released under the terms of the BSD License.

You can find out more in the manual, included in the download package.

Read about the library in the original post.

Download (Library+Source+Minimal Reference+Example)
(silent updates: file was initially inaccessible, it is ok now. also fixed a few comments in the source)

standup #7

2010-04-07T21:53:00.006+03:00

1. surfkit

"surfkit" is the end result of an effort I undertook as part of the "Stand-Up Architecture" course for the last months. The goal was to develop a performance-based, multi-parameter form and structure optimization design environment, that can be useful during the early stages of the architectural or product design process, in that it can quickly and with minimal effort suggest alternatives to user-defined forms according conformance to structural and lighting parameters.
Given it's realtime, interactive nature, it can also be of use as an educational tool, demonstrating the process of optimization.

I'm posting today the most recent snapshot of the project, which could be considered as a 'final' one for the moment. I plan on continuing to develop surfkit in the near future, but not immediately.

The program functions to an acceptable degree, though many things need a bit of re-thinking or optimizing.

Development took place in processing, using a couple of useful libraries: peasycam and SuperCAD.
The program is released under the terms of the BSD License.

UPDATE: The file that was initially released contained a serious bug that in some cases yielded highly inaccurate results. This has now been fixed. If you've already downloaded this release, please download the file again.

Download (Windows, OS X, Linux, Source)
A few meshes are included in the .zip file as examples. Apart from the default mesh, you can import these meshes and experiment on them. Or you can import most of your .obj files.

There is still no documentation, but in the near future I'll try to document the internals of the program as well as write a short tutorial on it's usage.

2. eye candy

A few of the case studies I did in order to get a better look at the results of using surfkit:

fvlib release 1, Point-Spring Solver Library

2010-03-31T17:56:00.005+03:00

While working on the StandUp Architecture course project, I had to implement an efficient and simple way of calculating displacements for a given mesh. I chose to do this using Dynamic Relaxation, a method that is relatively fast, although not precise enough for reliable structural calculations.

Nevertheless, the result was a fairly efficient point-spring solver based on the paper "Advanced Character Physics" by Thomas Jakobsen. I decided that this could have some use as a library, so I wrapped up some of it's basic features and created one for Processing, fvlib.

fvlib is essentially a minimalistic 3D point-spring solver library, built with high-performance in mind. It uses Verlet Integration for the calculation of point trajectories and Dynamic Relaxation for the calculation of constraints.

Using the 'fast' option, the library has been tested on a set of 9800 points and 58779 links. Using 15 steps, each iteration was measured to 20-24 msec (using java's System.currentTimeMillis()), on a 2.2GHz Intel Core 2 Duo. In other words, about a million point and spring loops can be performed in realtime on a typical contemporary computer. This test application is included in the download (please note that the example is 2D, z-coordinates flattened, but the library works in 3D).

Screenshot of the test application in operation.

Of course, further optimization (such as multi-threading) is possible. Furthermore, there are surely some glitches in there that have not been discovered yet.

A JavaDoc should be created too at some point...but not yet :P

This library is released under the terms of the BSD License.

Download

Library+Source+Minimal Reference+Example
(Hint: The thread in the example does end at some point!)

Installation

Unzip and move the extracted folder to Processing's libraries folder. Use Sketch>Import Library>fvlib from within Processing.

Classes/Constructors

Solv : The class that holds the points and links array and performs the calculations.

  Solv(ArrayList points, ArrayList links)
  Solv(Point[] pointsin, Link[] linksin)

Point : The point class. Has properties to define weight and fix it to a position(unyielding).

  Point(float x, float y, float z, float weight)
  Point(PVector v, float weight)

Link : The link class. Takes two points as arguments. Properties are it's length and it's stiffness.

  Link(Point p1, Point p2,float stiffness)
  Stiffness should be between 0.0 and 0.5

Methods

In Solv :

void step()
Steps the simulation.

void setF(float f)
Set the Friction constant (0-1, default 0.99).

void setFast(boolean fast)
Set whether to use the fast (but less accurate) solver. Default false.

void setP(Point[] points)
Re-set the array of points in use.

void setL(Link[] links)
Re-set the array of links in use.

Point[] getP()
Return the array of points in use.

Link[] getL()
Return the array of links in use.

In Point :

Point copy()
Return a copy of this point.

void setW(float weight)
Set the weight of this point. Default 1.

float getW()
Return the weight of this point.

void setU(boolean u)
Set whether this point is Unyielding.

boolean getU()
Return whether this point is Unyielding.

In Link :

float updateC()
Update original length (C) and current length (L) to reflect the current distance between points.

void setC(float cin)
Set the original length.

float getC()
Get the original length.

float updateL()
Update the current length(L) to reflect the current distance between points. This should be used whenever the current length should be queried, since during normal operation the current length is not updated.

void setP1(Point p)
Set Point 1.

void setP2(Point p)
Set Point 2.

Point getP1()
Get Point 1.

Point getP2()
Get Point 2.

standup #6

2010-03-25T22:38:00.006+02:00

A preliminary test was performed using Finite Element Analysis for a flat rectangular structure. It seems that results are encouraging: Maximum displacement has been reduced by approximately 75%, as well as peak stresses. It seems also that in the optimized version stresses are more evenly distributed. The only weak spot is the area to the right, where a lot of inclined elements exist: This area shows significant displacement, possibly resulting from the inclination of the otherwise vertical structure.

It is also noteworthy that in the analysis all three supports were specified as hinges. This is to match the setting of the optimization process. In the future there is going to be an option before optimization to select between hinges and rollers.

Software: iDIANA Version 9.3 Release 01
Triangular mesh, element family: TR6, element type: CT30F

Results summary below:
(please note that in stress diagrams contours of original and optimized versions are on different scales)

in other news...

2010-03-23T03:39:00.003+02:00

..it seems sometimes interesting spatial arrangements are design-free:

(suppose credit goes to Google?)

Standup #5

2010-03-22T04:56:00.003+02:00

Been working on import export functionality, which at this point seems to be working without any major flaws. I experimented on building a few case studies of small arbitrary structures for demonstration and plan to start testing of optimized vs. original in a FEM program immediately. Also the realization of a physical scaled prototype is in the works.

I won't release a new update to the Environment yet, there are still a few things that need to be sorted out.

Some eye candy:

Structural optimization running.

Specifying support location.

Standup #4

2010-03-12T21:03:00.008+02:00

(please note: All posts related to this project or the standup architecture course now have their own tag description. You can look them up here or click the appropriate link in the side menu)

During the last two weeks I've been working on implementing the features that have been discussed previously, as well as performing a few changes related to the fundamental structure of the optimization environment.
There are two parts to the optimization process: One that improves material distribution based on structural efficiency and one that improves element alignment based on shading/daylight preferences set by the user. These two have been isolated in previous versions and their results were subject to an averaging superposition in order to determine a final result. This has been changed and now the two components work on a common mesh, the elements of which are continuously and in parallel altered by both components. This makes it more probable that a solution closer to an optimal one can be found, since it allows the optimization process to take into account conformance to each performance factor. A schematic representation of the mode of operation can be seen in Fig. 1.

Fig. 1: A schematic of the operation and interaction between optimization modules.

The shading/daylight module works by measuring the coverage ratio of the elements vs. the whole surface and then comparing it to a user-supplied target ratio. This is then used to accordingly align the elements: If the measured shading ratio is higher than the target, the elements will align to the light source in order to decrease their coverage; in the opposite case they will turn away, therefore casting wider shadows.
Furthermore, an optimization routine has been added to the structural module: Using an approximate bending moment diagram calculated by Dynamic Relaxation and a Finite Difference Method (the so called Verlet Integration), the routine attempts to transfer thickness from the least stressed to the most stressed areas of the structure. Apart from being more effective (at least in theory), it triggers the emergence of surface patterns that are quite unexpected.
Some examples of architectural arrangements put together to demonstrate the result are shown in Fig. 2 and Fig. 3. The supports in the second example have been added manually, conforming to the positions of the supports specified during the generation of the canopy.

Fig. 2: Example compositions. Black dots show support positions.

Fig. 3: A canopy developed as a demonstration of the optimization process. Supports have been added manually according to supports positions set for the simulation/optimization.

As for the progress of the project, some elements still need a bit of tuning: There are stability problems with various element sizes, but I guess I'll have a look at those later on. The most urgent issue right now is to implement communication with "the outside world". Export functionality using .DXF has been implemented, but more formats and import functionality should be added too.

As usual, a snapshot of the current state of the project can be downloaded. Please note that this is an early experimental version of the program and may contain serious bugs.

Still no documentation so you'll have to experiment ;)

This prototype has been developed with Processing, uses the peasycam library for camera manipulation and is released under the BSD License.

References

Topology Optimization, Wikipedia
Vector Projection, Wikipedia
Jakobsen, Thomas, Advanced Character Physics
Carranza, Pablo M., Self-Designed structures. Prototype 1
TopOpt Group

Standup #3

2010-02-24T02:03:00.003+02:00

(to find out what this is about, please check this post)

The past week I worked extensively on formulating a concrete, final outline of the Design Component's features and structure as well as specifics of the design case, which will be briefly presented here.

1. Case

The design case has been simplified in some ways and extended in others. Out of the performance factors involved, daylight handling and structural efficiency will be incorporated. These factors have been evaluated as significant and future work will focus on them. So far I've implemented a fairly efficient although simple structural solver (which is explained later) and still have to work on the daylight solver.

On the contrary, the Design Component has been extended to support importing of forms, so that the shape of each design case can be extended beyond rectangles, therefore enabling an additional degree of freedom for the designer.

Fig.1: Example diaram produced with Design Component and based on load distribution and deformation.

2. Components/Representation

I've decided that, instead of developing separate design components for each performance factor, a single, unified environment could be beneficial in the sense that it combines different performance diagrams easily and the level of information exchange between different modules happens in realtime and is therefore broader.

Essentially, this environment will act like a 'switchbox' of sorts, allowing the user to specify to what degree the diagrams produced by each performance component will affect the final diagram.

The interface and basic component logic is complete and, as said, I'm currently working on the individual performance modules (Daylight, Structure). Still, there are two important issues that need further investigation: Communication with other design programs (Import/Export) and visual representation.

The issue of communication should be investigated so that exported data can easily interface with parametric design software and imported shapes could be translated to match the Component's geometrical/topological data structure.

Representation is a less critical but still quite important aspect, in that different methods of representation disseminate particular "tectonic strains" to the user/designer: A wireframe representation could refer to spaceframe construction, while a solids-based one could refer to concrete construction. Given that the diagram produced should be as flexible and 'neutral' as possible, this issue should be figured out.

Fig. 2: The mesh used for the point-spring solver

3.Performance

I've managed to incorporate a simple point-spring physics solver into the Design Component. With a suitable plate model, as the one shown in Fig. 2, fairly accurate results of moments distributions have been achieved (although this is not an effort to produce an actual FEM solver of course).

The physics solver used to calculate the deformation of the shell is based on a simple numerical method that is frequently used in interactive applications, known as Verlet Integration Method. The shell is modeled as a mesh of points and springs. On the points act forces of gravity which alter the distances between them and therefore cause the springs to react. The overall balance achieved after many iterations results into the deformation of the shell. Reading and comparing the strain on each spring can therefore provide an indication of the internal reactions of the shell. I'm really intrigued to try and compare the results with an actual FEM solver to see what is the deviation of this model. Of course this will happen as a part of the design recursion later on, when an actual model corresponding to the design case has been produced.

The daylight-based performance solver is not yet complete but should be easier to implement since it will function mostly based on approximations and information from actual daylight programs (e.g.. DiaLux) and raytracers.

Fig. 3: Another example diagram, multiple views

4. Outcome

Of course the most interesting part of the whole effort is to actually complete a design case to the point that it reaches the scale of construction. I suppose that, as soon as I figure out some of the main issues of the Design Component, I will start working on a final design using parametric software.

The Design Component in it's current state is available for download.

No documentation is available, so you can experiment with it for the time being.

Try selecting "Supports" and clicking on a few nodes on the mesh.

Adjust the result by moving the sliders that affect each component's effect on the final diagram.

Please be aware that this is a highly experimental version and may therefore contain serious bugs.

Design Component release 1 (Windows, OS X, Linux, Source Code)

It has been developed using Processing 1.0.9, using the peasycam library for camera manipulation.

It is released under the terms of the BSD License.

standup #2

2010-02-19T03:47:00.005+02:00

I haven't posted on my progress regarding the StandUp course for some time. I've been working on finalizing the definition and structure of the Design Components that will be developed and at the same time working on the actual code. I must say that I'm quite satisfied with the progress. I will post soon the specifics of my recent investigation.

Max Eekhout's blog is online too. Check it out.

standup #1

2010-02-09T17:32:00.013+02:00

Yesterday the first presentation for the "Stand Up Architecture" Course took place. In this presentation, the general research direction of each participant was laid out and the research topic was more or less formulated. There were some very interesting presentations, updates or summaries of which you can find on each participant's weblog:

Tim Castelijn

Jaap Overal

My research will focus around the general topic that is defined by the question of how to employ computation and computation-enabled tools/environments in the early stages of design, in order to enrich the design process, explore alternative design possibilities and integrate heterogenous design factors, while still maintaining flexibility and adherence to performance.

In other words, how can computational design practices interface with the activity of the designer/architect in a non-intrusive way and be flexible enough to follow the decisions made on an abstract level and based on heterogenous information.

Based on this general direction, I proposed that research should focus on a specific, simple, well formulated design case, in order to have a result that is as much as possible exhaustive of the design space and at the same time as transparent and simple so as to be completed within the course's timeframe of 8 weeks.

I proposed for the design case a rectangular shelter, essentially a horizontal surface whose form and structure is the object of design. The shelter can be thought of as functioning on its own or as part of a larger complex of buildings.

Performance parameters will be related to structural efficiency, daylight and sunlight handling, as well as rainfall/rainwater disposal. These three performance factors will be used to construct simple "design environments" which will propose performance-based alternatives in order to augment and expand the designer's solution space and possibly introduce unexpected possibilities.

Fig. 1: Design Case

The design environments will be manifested as simple Processing programs, with the ability to communicate design iterations between them. In this way, a "Network of Design-Informing Components" could be formed: each of the programs will inform the current model with its own parameters, the result, therefore, being a product of each program's behavior and logic, as much as of the manner and order of communication between them.

The intent is to design the programs so that they produce models that are as abstract as possible within the scope of the design case, so that their interpretation can be left to the designer. For example, a model produced by interpreting forces acting on it (Fig. 2) could be directly translated to geometric form, but it could also be interpreted as a graph that dictates the width of the canopy, or even as a table of values that can be further processed by the designer.

Fig.2: Shell deformed approximately according to moments developed on the surface by its own weight

Final design proposals will result beginning with these abstract forms and using parametric design software in order to evaluate different structures and construction principles. For example, an abstract form could be translated into a steel spaceframe, a monolithic concrete construction, a canopy constructed out of a folding surface.

The evaluation of these finalized designs by analysis software and/or physical models will provide feedback for the optimization of the final model or the reconfiguration of the design environments: In order to improve on a weak point, he designer may choose to improve on the final model or the design process, and this decision becomes a design choice.

Rudi Stouffs commented that it would be interesting to see how this process ends up not only with a design proposal, but also as a sort of 'documentation' of itself: A detailed description, in the form of computer code as well as mapping of the process. The series of connections between components, the detailed designs, the parametric models, the decisions and the alterations to the models and the design tools. It is an extremely interesting aspect that hasn't occurred to me and I plan on investigating and implementing further on.

The presentation file is available here (pdf)

The first prototype of a component that produces graphs similar to those of moment distribution on a rectangular, flat surface can be found here. (Binary for Windows, OS X, Linux as well as Source Code[messy:P])

The prototype has been built with Processing, uses the peasycam library and is released under the BSD License.

I will work on this a bit more and post back. Chack back for more!

standuparchitecture - spring '10

2010-02-03T23:47:00.003+02:00

I'm excited to announce that this weblog will host for the next few months my work progress in the Stand Up Architecture Course, at BK/BT TU Delft, as well as interesting ideas, discussions and other things that take place during the course.

Look forward to more updates!

ribonkit prototype 2

2010-01-09T04:13:00.008+02:00

Happy new year.

ribonkit can be thought of as an experiment that attempts an interpretation of abstract networks of relationships and swarm behavior, to potentially corresponding materials organizations.

In ribonkit, agents spawn near predefined points (nodes) with another given node as a destination. Agents are being attracted to the destination, but are also attracted or repelled by other nearby agents. The result of this swarm behavior is that, depending on the proximity of others, an agent may choose not the shortest route to it's destination, but one that is commonly agreed upon with other agents.

In this way, a path is created that recursively evolves as agent concentration patterns and objectives change because of it's spatial configuration.

Apart from being abstract curves in space, the traces of each agent's travel can be thought of as indications of a physical object's material concentrations in space. In this sense, the agent's "socially-enabled" goal seeking can be interpreted as a form of "economy" of material usage: In an object with linear elements, coinciding paths of agents do not count multiple times towards the total length of the object's elements.

The second prototype of ribonkit implements non-specific relations between nodes. In other words, the members of the swarm can have any potential destination, instead of a predefined one. This approach is less specific than the original one.

Applet here

ribonkit prototype 2 has been developed in Processing 1.0.6 and uses the peasycam library for camera manipulation.

It is released under the BSD license.

ribonkit prototype 1

2009-11-29T18:13:00.002+02:00

ribonkit can be thought of as an experiment that attempts a interpretation of abstract networks of relationships, which in the case of ribonkit are graphs, to potentially corresponding materials organizations.

Based on this principle, ribonkit attempts to draw from optimization theories such as Particle Swarm Optimization and Ant Colony Optimization with an aim of:

1. Exploring the properties of their spatial manifestations, in a purely abstract relationship-based implementation.

2. Investigating and evaluating different possibilities of employing such approaches for the design optimization of physical objects.

3. Coming up with a design environment that is well defined yet abstract enough to allow users/designers to conceive and visualize materials organizations and products which are based on the manipulation of their defining relationships.

ribonkit is still in very early prototype stage. The fundamental workings of it's swarm engine are still being figured out.

You can check out a (non-interactive) prototype here (applet).

ribonkit prototype 1 has been developed in Processing 1.0.6 and uses the peasycam library for camera manipulation.

It is released under the BSD license.

aab, release 2

2009-11-05T05:39:00.008+02:00

artificial landscape, form compositing with aab

aab release 2 improves on some functionality of the original version, which allows for a wider variety of arrangements to be composed. Release 2 is also available as a web applet here (please note that the applet version cannot export compositions to DXF).

For the description please check this post.

aab was developed in Processing and uses the peasycam library.

Download

(Windows, OS X, Linux, Source)

aab renders

2009-09-23T21:51:00.002+03:00

I decided to upload a few (proper) renderings of arrangements composed by aab (description just below vvv)

aab - Processing, release 1

2009-09-17T17:01:00.009+03:00

aab - Processing is a remake of an old program I built a while ago, which was also a forerunner for the development of LPacker. It is an automatic composer of forms vaguely and loosely reminiscent of engineering aesthetics.

The program simply assumes a solid rectangular volume which it recursively and randomly subdivides in parallel planes (like an L-System) or grids, removing random volumes in the process.

Afterwards, it does a little bit of post-processing, creating holes and gaps between the volumes and presents the result on screen.

The user can specify the initial volume's dimensions and export the result in .DXF.

Here is the original program's page from my old site, and the -slightly inaccurate- description.

aab - Processing was developed in processing 1.07 and uses the peasycam library for camera manipulation.

aab - Processing is released under the BSD License.

Download

(Windows, OS X, Linux, Source)

fib release 3

2009-08-06T22:36:00.008+03:00

fib is a cloth and sheet simulator whose goal is to aid the conceptual realization of tensile structures and support experimentation wih free-form structures in general. In fib, form creation is based on the manipulation of a surface in 3-dimensional space, which conforms to geometrical constraints of real world cloth or sheet materials.
In fib, the flexible surface is modeled as a 2-D isostatic frame, represented by nodes and springs between nodes. Nodes can be moved and fixed to any position. The model reacts to interaction by adapting to loads applied by the user, in order to maintain its integrity. The physics solver is based on an implementation of the Verlet Integration Method.

fib uses the peasycam library for nice camera manipulation.
fib is released under the terms of the GNU General Public License.

Download

(Windows, OS X, Linux, Source, PDF with description and controls included)

TN7 (TN6 Release 3)

2009-07-02T20:26:00.005+03:00

The third release of TN6, named "TN7", adds the following features:

- A 3D visualization mode that presents a 3D landscape of the velocity field.

- The ability to export the 3D landscape as a DXF model.

- The ability to add thrust segments in the simulation.

It also improves on the following:

-Speed & Realism of the simulation.

-Various User Interface enhancements.

For the original description of TN6, see this post.

TN6 & TN7 are released under the terms of the BSD License.

Download

(Windows, OS X, Linux, Source)

TN6, release 2

2009-06-11T00:58:00.006+03:00

Release 2 of TN6 improves on the accuracy of the visualization. By default, velocity lines are visualized. Hit '1' to switch to particle view, '2' to return to field view.

For a description of TN6, see this post.

Download

(Windows, OS X, Linux)

TN6, release 1

2009-05-31T14:40:00.007+03:00

MSAFluid is a fluid simulation library by Memo Akten. Based on this library and Memo's visualization examples, I put together a simulator that looks like a wind tunnel. While it is far from being accurate, it often produces interesting, dynamic visual forms.

Release 1 can be considered as an alpha state of the program.

Controls:

Click-click to create linear objects

Space - Toggle flow

1 - Particle visualization

2 - Velocity Field visualization

3 - Toggle drawing of objects

TN6 has been developed in Processing 0135.

Thanks to Memo Akten for the library and examples, Peter Bourke for Distance calculation examples and Pieter Iserbeyt for JAVA source code.

TN6 is released under the BSD License.

Portions of the program are under the Copyright of their respective authors/developers.

Download

(Windows, OS X, Linux)

fib, beta 2

2009-04-15T00:43:00.018+03:00

fib is a basic real time cloth simulator, aimed at the design of tensile structures. Beta 2 improves on the following:

- Faster display, finer textile resolution

- Perspective mode added

- Export to a folder of your choice: Drag and Drop onto Main Window

Usage:

Click and Drag to move points

Shift + Drag to fix/unfix and move points

Ctrl+ Drag to pan

Q,A to zoom in/out

1 to enter Edit Mode, 2 to enter Perspective Mode

R to reset

The viewport in Edit Mode displays left/top views simultaneously.

made in processing 0135b

fib is released under the terms of the GNU General Public License.

fib uses controlP5 for displaying text and sDrop for Drag and Drop functionality. Big Thanks goes to their developer, Andreas Schlegel.

Download:

fib, beta 2

(Windows, OS X, Linux, Source Code)

Change! ! !

2009-03-09T21:21:00.003+02:00

This blog's transition to the new URL is complete ;)

fib, beta

2009-02-25T17:46:00.011+02:00

fib is a basic real time cloth simulator, aimed at the design of tensile structures. Beta features basic functionality and .DXF export.

Usage:

Click and Drag to move points

Shift + Drag to fix/unfix and move points

Ctrl+ Drag to pan

Q,A to zoom in/out

X to export

R to reset

The viewport displays left/top views simultaneously.

made in processing 0135b

fib is released under the terms of the GNU General Public License.

Download:

fib, beta

(Windows, OS X, Linux, Source Code)

elclok

2009-01-01T17:43:00.010+02:00

Happy new year!

This small application is a clock that features a discussion between two extremely selfish Eliza bots. No, really - the dialogue is an utmost disaster. Every minute, a new part of the dialogue is revealed along with the time and date. It is possible to edit or replace the script that directs the bot's responses in order to induce user-defined behaviors.

UPDATE(04/02/2010): Fixed some issues, letters, variety in responses...should be a bit more fun now :P

Developed in processing and released under the GNU General Public License.

elclok uses Andreas Colubri's implementation of Eliza in Processing, for which I am thankful.

Download:

elclok

(Windows, Os X, Linux, Source)

Lnk

2008-10-23T20:26:00.013+03:00

A fairly comprehensive list of links to websites of similar interest has been compiled so far, ranging from portals related to architecture and construction, to repositories of source code, tutorials and ideas. It sould be stated that this list reflects more or less a personal preference, as I myself quite often use it as a starting point for my journey throughout the web. I hope that it will prove to be informative as well as inspirational for everyone.

(The image above is a scaled down and cropped version of the Internet Map, from Chris Harrison's excellent website)

Updates?

2008-09-27T17:44:00.004+03:00

Since I'm currently in a state of not-being-able-to-do-anything-except-what-I'm-supposed-to (aka serving in the army), I'm having a tough time updating this site. My next planned step in transitioning from the old site to the new blog format would be to clean up older projects and update them here. However, given that this is taking like forever, I will post a temporary link to the old site. Please pay a visit and check out some of my earlier design tools/toys.

Packing up: LPacker

2008-08-03T13:52:00.017+03:00

LPacker is an effort towards the development of a special design tool aimed at the design and realization of simple planar storage systems. LPacker serves as an experiment and exercise in the development of computation-assisted design environments.

The general concept is to produce an efficient spatial arrangement for a series of user-specified items with arbitrary dimensions. In the program, any item is represented by it's bounding box. The packing process is performed by solving a two-dimensional rectangle packing problem.

The "bin packing problem", whose derivative is the 2D rectangle packing problem, is a combinatorial NP-hard problem, with many variations and applications in various industrial fields. The goal is to fit as many items as possible into a specified area, or to fit a given set of items into the least area possible. Such problems are approached by the use of heuristic algorithms, many of which yield near optimal solutions.

The algorithm used in LPacker is primarily based on guides, tutorials and studies at

http://www.blackpawn.com/texts/lightmaps/default.html

http://www.csc.liv.ac.uk/~epa/surveyhtml.html#bib.9

http://www.devx.com/dotnet/Article/36005/0/page/1

The result of the packing process is an arrangement of the specified items in 2D space, in a way that is considered by the algorithm as efficient. The user may intervene on the proposed arrangement in order to improve space usage or impose additional parameters, such as, for example, proximity between certain items or specific positioning in the arrangement.

The abstract spatial arrangement is then translated into components that can be used to realize a physical storage system, with spatial organization identical to that of the abstract arrangement. The ability to simply and efficiently realize a physical object from the abstract arrangement was a critical parameter in determining the nature of the packing process. In order to later on achieve simplicity in the assembly of the physical structure, the arrangement produced by the packing algorithm had to satisfy a special condition commonly referred to as 'guillotinable' packing. An arrangement of rectanglular sheets is said to be guillotinable when, for example, given a sheet of material with dimensions equal to the arrangement's dimensions, it is possible to cut out the original rectangular pieces exclusively by means of straight, uninterrupted sections parallel to one of the rectangular sheet's sides. In this way, the effort required to obtain the pieces is minimized. In the case of LPacker, the 'cuts' on the supposed sheet correspond to physical planar partitions that will eventually form the physical storage system. Guillotinable packing helps minimize the number of partitions, in this way simplifying the assembly process of the supposed physical structure.

The spatial arrangement is encoded by means of a tree structure, with every individual item being a 'leaf', separated by others by using 'branches'. These branches will later on correspond to the physical planar partitions mentioned above, that will form the physical storage system.

LPacker is released under the terms of the GNU General Public License

Operation:

The program operates in four modes:

1. Drawing Mode

In this mode, the user specifies the dimensions of the rectangles to be considered as bounding boxes for the items to be packed.

2. Packing Mode

Upon entering this mode, the collection of items is automatically packed into a mostly efficient spatial arrangement. At this point, there are some editing capabilities that help optimize the arrangement.

3. Perspective mode

In this mode, a 3D representation of the physical structure is offered, along with the ability to visualize the volume of the initial items.

4. Blueprint Mode (Unimplemented)

In this mode the planar partitions that form the supposed physical structure are laid out on the screen.

Download:

LPacker

Windows, OS X, Linux. Source Code Included.

To be Implemented:

- 4th Mode

- The ability to export the structure arrangement for manufacturing.

- A feature to save and export in various formats.

- A little bit of tweaking the user interface.

Visual Toys: ln, gpuls

2008-06-10T23:26:00.005+03:00

gpuls is a visual toy that produces patterns as a result of tracing the trajectory of a population of pulsating dots trying to survive against each other.

Download gpuls (binary + source code)

ln is a simple experiment in processing that benefits from the environment's simplicity in creating graphics in 3-dimensional space.

Download ln (binary + source code)

StructurL is born!

2008-05-19T21:21:00.004+03:00

(edit: At the time of creation, this weblog was named "StructurL".)

With much excitement this blog has been created.

It should, first of all, be mentioned that this site will act as an effort to continue and expand the author's existing web site at

http://xconst.freeshell.org

If you already took the time to visit the above link, then you should be more or less aware of what this is about. If not, let there be a short description.

StructurL aims to become a means of publication of the author's experimentation on spatial structures (as in, structures manifested mainly via computer programming, that manipulate and create spatial configurations), with strong emphasis on issues of realization (such as, construction and issues of materials and technology). Whenever possible, StructurL will also try to serve as a point of information and discussion about the ongoing research in the aforementioned area.

And since there are people apparently more capable of formulating precise and concrete definitions, at this point there should be a quote from The Emergent Design Group of MIT(http://mit.edu/edgsrc/www/), a quote which is considered by the author to accurately outline this site's area of interest.

"[...]design at the intersection of architecture, engineering, artificial intelligence and materials science."

That's it for now! I hope that in the future you will find this blog to be inspirational.