I have to say, reviewing this really makes me think bottom-up approaches are being too disregarded in favour ‘the expert centred’ approach, what a shame!!!!

enjoy!

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 UK: England & Wales License.

You can get the PDF here
enjoy!

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 UK: England & Wales License.

I’ve been busy, very busy indeed, so I haven’t had time to post anything. In fact I haven’t had much time to sit down and code except for a quick test for the new Igeo text object.

Anyway, I posted a few examples on the igeowiki blog but in the end I’ve decided to post them here to keep all examples and code in the same blog.

This is the first of a few post relating to multi-agent systems. For start a rough implementation of the game of life as devised by John Conway:

Conway’s Game of Life – illustrates how simple rules can lead to complex system behaviors   

 The universe of the Game of Life is an infinite two-dimensional orthogonal grid of square cells, each of which is in one of two possible states, alive or dead. Every cell interacts with its eight neighbours, which are the cells that are horizontally, vertically, or diagonally adjacent. At each step in time, the following transitions occur:

1. Any live cell with fewer than two live neighbours dies, as if caused by under-population.
2. Any live cell with two or three live neighbours lives on to the next generation.
3. Any live cell with more than three live neighbours dies, as if by overcrowding.
4. Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction.

The initial pattern constitutes the seed of the system. The first generation is created by applying the above rules simultaneously to every cell in the seed—births and deaths occur simultaneously, and the discrete moment at which this happens is sometimes called a tick (in other words, each generation is a pure function of the preceding one). The rules continue to be applied repeatedly to create further generations.

You can download a PDF with the code here and the processing sketch there.

enjoy!

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 UK: England & Wales License.

Si crees que sirve hazmelo saber dejando un comentario.

Saludos

Oprime aqui!

Since two or maybe three releases ago, igeo incorporates a tracker class that allows you to attach geometry to particles so I though about implementing collisions attaching spheres to particles.

I started with one of Satoru’s examples on bouncing particles on the ground. He suggested to me an algorithm to first move the overlapping bit first, of the spheres and then reflect their velocities on a plane to simulate collisions.

I thought it was nice but if a particle was on the floor an another bumped into it, the particle at rest wouldn’t move when it should, so I had a look at how to transfer force between particles related to their velocities and mass. Luckily I found a formula that takes initial velocities and masses and returns final velocities.

The sketch is working much better but surely it’s not like the real thing and there is behaviour missing, so I’ll keep looking.

What I found interesting though, is the fact that in the end the spheres keep bouncing until there is  a gap big enough for them to rest in the ground away from other spheres. This could be the basis for a sphere packing sketch which would be nice!!

The video below is not hi-res, I’ll try to make it better.

enjoy!

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 UK: England & Wales License.

*b*****, s*****, f******

It will be on the food4rhino service soon (I hope!) in the meantime you can get it here

enjoy!

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 UK: England & Wales License.

I started with a simple surface subdivision evaluating subsurface panels to see how many were  flat.

Then I explored the idea of creating particles attached to rail curves and then keep moving the particles randomly along their rail until all the vertices of one panel had a position that allowed the panel to be flat, so I implemented it with quads where they are all linked with each other. An important parameter is the length of the rail curve as this gives more room for the particles to move, but the bigger this is, the lower the smoothness of the surface.

This is what you get after 1000 iterations:

Then I thought about using Laga (Libreria de Algoritmos Geneticos para Arquitectura), being developed by Carlos de la Barrera to see if the GA could do a better work. I got this after 1000 iterations:

So I need to go and learn about Ga’s so I adjust the parameters to get a better result!   8(

I then though about implementing the same algorithm with hexagonal panels this time, with the vertices for each panel independent of other panels, due to my solution to link them all not working as planned!

I noticed that after just one iteration all panels changed their colour to white that mean that they were planar, looking into why in the end I concluded it has to do with the way igeo creates the hexagonal surface, but I haven’t had a chance to look at the source code or ask Satoru, in any case this is great news as depending on the sampling number in U and V the gaps between the panels get smaller.

I’m after creating a watertight surface/mesh with flat panels so I’ll keep looking, in the mean time I thought about posting this before I forget!

You can get the sketch here if you want to join the mission!

The images below are some of the results, the first one shows the flat panels, the rail curves, the particles and the polyline linking the points on the surface.

enjoy!

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 UK: England & Wales License.

I’ve finally had a chance of creating an open source igeo resources blog here . At present it has got the examples we looked at the AAG2012 workshop held in Paris two weeks ago.

If you want to contribute pelase let me know and I’ll give you the login details.

enjoy!

I modified my original sketch and came up with this!

nice!! (not the image but the possibilities)

code:

import processing.opengl.*;
import igeo.*;

size( 1200, 822, IG.GL );
IG.bg(255,255,255);

IG.open(“eaBaseSurface.3dm”); //input geometry from 3dm file

ISurface[] surfs = IG.surfaces();

for (ISurface surf : surfs)
{
float stp = PI / 3;
int Hex_uCount = 12;
int Hex_vCount = 12;

double uLength = Hex_uCount * (3 * cos(stp)) + cos(stp);
double vLength = Hex_vCount * (2 * sin(stp)) + sin(stp);
double dUspacing = (1 / uLength);
double dVspacing = (1 / vLength);

for (int v = 0; v <= Hex_vCount – 1; v++)
{
for (int u = 0; u <= Hex_uCount – 1; u++)
{
double x;
double y;
double dx;
double dy;

ArrayList< IVec > pts = new ArrayList< IVec>();
for (float t = 0; t <= 2 * PI; t = t + stp)
{

x = u + u * cos(stp) + 2 * cos(stp) + cos(t);
y = (2 * v * sin(stp)) + (sin(stp) * (pow((0), (u % 2)))) + sin(stp) + sin(t);

dx = x * dUspacing;
dy = y * dVspacing;

pts.add( new IVec( surf.pt(dx, dy)));
//new IPoint( surf.pt(dx, dy)).clr(1., 0, 0);

}
IVec[] fixedArray = pts.toArray( new IVec[ pts.size() ] );
new ICurve(fixedArray).clr(u*dUspacing, v*dVspacing, 0);
new IMesh(fixedArray).clr(u*dUspacing, v*dVspacing, 0);

}
}
surf.del();
}

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 UK: England & Wales License.

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 UK: England & Wales License.