Metaball Skinner: Update (Mar 24, 2017): I made this functionality into a blender add-on! Get it here: https://www.blendermarket.com/products/metaball-skinner
In the midst of working on evolving plant/coral thingmabobs, I am exploring 3d printing some of the earlier shapes I came up with, when I was writing the growth algorithms explicitly. To do this I need a reliable way to ‘skin’ the skeletons (or ‘thicken’ the wireframes). The skeletons consist of one dimensional line-segments, touching end-to-end, and occasionally branching. There are various way to do this.
In blender there is the ‘skin’ modifier, which works quite well, granted a few conditions. One such condition is that segments radiating from a branch point be sufficiently spaced out, otherwise branches interest each other (A). Another is that segments that branch away from connection points are not too short, relative to their neighbors (B). Finally, consecutive segments need to make a sufficiently obtuse angle between one another, otherwise a kink occurs in the mesh, causing self-intersection (C).
The issue with these resulting meshes is that they are often not 3d printable. Meshes that are 3d printable need to be water-tight, meaning that no faces are missing. Some 3d printing processing software also needs all the edges to be manifold. This means that each edge has exactly two faces connected to it. So in the general case of arbitrarily complex wire-frame skeletons, blenders skin modifier breaks down for 3d printing. The problem of skinning an arbitrary wire-frame skeleton so that it is 3d printable, with any number of small branch angles, tight turns, and tiny edges, is difficult. Some approaches, similar in effect to blender’s skin modifier, attempt to create a structured, orderly polygonal mesh composed of regular rods connected by joints. One such method is described in this paper, and has been used in this grasshopper plugin.
I found a work-around to this problem, that is guaranteed to always create water-tight, clean meshes. I made a script in blender that simply adds a metaball rod in place of each line-segment in the wire-frame (see https://en.wikipedia.org/wiki/Metaballs, for a description of metaballs). Where metaball rods overlap they have an additive effect, so this results in slight lumps at the connection points. For the time being this is fine, but it is easy to imagine a specially shaped unitary metaball rod that has a tappered ends, so that when overlap occurs the node region has the same diameter as the rest of the rod. Also conceivable is a more complex program which could alter the size of the ends, so that nodes with many incoming segments are not unnecessarily large. Regardless, this is a neat technique for easily generating 3d-printable structures from blender wire-frames!
Each descendent is connected to its parent or parents by a line. So individual 12 inherited genetic information from 11 and 10. In this run of the evolution there were 5 individuals in a generation and 4 generations. But there are not 20 individuals in the graph! That is because individuals that are selected to mate are kept in the next generation; their offspring replace all discarded individuals from the previous generation. So this graph doesn’t really give a good impression of which individuals consistently got selected. Still this is a starting point for visualizing an evolution. This sort of visualization makes it easier for me to understand what happened in the evolution and which individuals are interesting.
A next step might be to show each generation with the parents copied over. Or perhaps a separate table showing each generation and who got selected.
Here are the phenotypes, roughly laid-out (manually) according to the above graph:
Looks like the first two individuals produce roughly the ‘best’ phenotypes. (best is max number of nodes) So much for the evolution! I think its ok though; this was a small test run and it looks like I did something odd with the selection method. I used tournament selection with the size of each tournament as the population size. When looking at source code, it suggests to me that this means the next generation will consist solely of the highest fitness individual. At the moment I am using the algorithm eaSimple, a default genetic algorithm in the deap package. Anyway I’ll sort out the algorithm soon, the point is that now there can be genealogy trees!
Here is a close up on a phenotype from individual 10:
looks like some of the phenotypes are a little box-like. To avoid this I should make the ‘padding’ between the growing plant bounding box and the world-box a little bigger.
At this point it is pretty hard to see much relation between a child and its parents. The fitness criterion of max nodes makes this visually scrambled mess. Fingers crossed that more subtle fitness criteria lead to something more visually understandable. I don’t want to have to make another algorithm that ‘sees’ the structures! Although such an algorithm may be useful for fitness evaluation. Estimating fractal dimension seems like a natural one, although I don’t have the faintest idea of how I would go about doing it at the moment.
Ok I have had enough rambling. Sorry there is not much context explained for this post! For this to make more sense check out http://joshlopezbinder.com/randomly-generated-growth-rules/
Last post I was figuring out how to get a genetic programming package inside of a 3d modeling program called blender. Today I got the simplest use of the genetic programming package woking: generating random trees of functions, to make a sort of ‘processor.’ I took the randomly generated processor and plugged it into the plant/coral simulation I have been developing. In this simulation a bunch of spherical particles jitter downwards, roughly simulating the diffusion of nutrients in water or light in a forest. A point, or collection of points, acts as a ‘seed.’ When a sphere collides with the seed, it creates a new point and an edge. I will refer to the points as ‘nodes.’ Each node decides where to put the new node. For the moment this decision is based on the position of the collided sphere, and it’s relative position to its parent node.
The decision of where to put the new node is where the randomly generated processor comes in. Normally I would write the program or sub-routine that decides where to put the next node. Indeed I have been doing that for a bit. Shapes that are generated from my growth rules are in the renders portion of this website. But I am interested in making generative shapes that evolve! Presumably many of the plant, algae and coral shapes that we observe in the real world have growth rules that have evolved and been subjected to natural selection. Seeing all of that variation makes me want to experiment with virtual growth systems and simulated evolution. So anyway, this is the first step in that direction.
How it works
There is a set of ‘primitive functions’ that are sampled randomly to create a nested series of function calls. There is also a set of ‘terminals’ which are constants and variables that act as inputs to the innermost functions. Here is an example of a randomly generated processor:
mean_vec(mean_vec(rotate_vec_np(y, y, c1), rotate_vec_np(y, y, c1)), scale(rotate_vec_np(y, y, c1), dot(x, y)))
The primitive set included mean_vec, rotate_vec_np, scale and dot. The terminal set consists of the 3d vectors x,y and the constant scalar c1.
This is most easily visualized as a tree (I did not make the code to generate processor trees or visualize them. It is all from the python package deap):
This processor tree takes in two 3d vectors and outputs a new vector. This is intentionally designed to act as the ‘decision maker’ of the node! the vector x is the relative position of the sphere to the collided node. The vector y is the vector from the parent node to the collided node.
Clearly the functions available in the primitive set, and any constants in the terminal set, are going to have an important role in constraining the possible growth behaviors. So I have been playing around with different primitive sets.
Below: some pleasing shapes that resulted, with their associated processing tree on the right.
You might notice some terminals are numbers with alot of decimals. Those are ‘ephemeral constants,’ constants that are randomly picked, in some range, when the processor was generated. Also, some of the structures are a bit lopsided. I accidentally had a setting where particles were being spawned at a side plane of the box as well as the top. In all of these cases the ‘seed’ is a line segment. This way the top most node has a non-zero vector from the parent node. If there was only one node, the y vector would be zero, and more processor trees would result in no visible structure.
In my quest to make lots of different interesting shapes, I am attempting to use DEAP inside of blender. Deap stands for Distributed Evolutionary Algorithms in Python. Deap has a module for implementing genetic programming, which I am curious and excited to use as a way of automatically generating growth rules. Genetic programming evolves computer programs to perform some sort of task well. I am not really sure, at the moment, if it is important that the growing tree-structures perform some task well. However, the deap package includes an interface for easily generating random programs from a collection of predefined ‘primitves’ or basic functions. It also allows one to easily construct a genetic algorithm which uses the randomly generated programs as ‘genomes.’ Anyway, first I need to make the deap package available within blender!
1. Blender’s most current versions use python 3. Deap is written in python 2. So to covert I used the command 2to3 as follows (note I am on OSX):
$ 2to3 --output-dir=/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/deap -W -n /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/deap
2. The next step is to get blender’s version of python to be aware of deap. The quickest way I found to do this is to add the location of the python 3.5 site-packeges to blender’s path. This is done according to this thread. In blender’s console I did this:
>>> sys.path.append('/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/') >>> import deap.gp
It works! Of course this a bit of a hacky way of getting deap (or any third-party python module) into blender. More permanent ways of making the module available for import are described here.
Imagining fractal-like heat-transfer mechanisms. Combining ideas like
and my previous exploration:
I posted this sketch a while ago of an idea for a kinetic sculpture made of nested planetary gears. Which was a derivative of the log spiral gear thingy. These ideas are basically the same as, or extremely related to, this!:
and even better this:
These are interesting visually, and certainly could lead to some nice kinetic sculptures. But I also find them stimulating because they suggest fractal-motions, and maybe are even related to kinematics in organisms. The radius of curvature of the paths makes these wonderful crescendos and cascades. The motion actually reminds me of the counter balance (or counter torque) motions in slack-lining. (like tight rope-walking but on a not-so stiff strap) While trying out slack lining with a wonderfully happenstance acquaintance, I was informed that the best way to use the arms to counter-balance is to ‘loosen-up’ and move the arms in a smooth, graceful sort of way. Instead of holding the arms rigid and pivoting only at the shoulder, all the joints (shoulder, elbow, wrist, fingers!) get involved. These sort of motions may be similar to the tentical-like spiral kinetic sculpture I made and its analogous animation (above right). It did seem to help me balance better. While this is wild speculation, as I have been to lazy to try any real attempt at analysis, I wonder if these motions are somehow better for counter torquing while balancing? I wonder how the tails of various balancing creatures (cats, squirrels) behave.
There is something so nice about fractal trees. Here are some that I generated in rhinoPython using L-systems as described in the Algorithmic Beauty of Plants. L-systems are a really neat way of defining and creating various fractal and fractal-like geometry so that one does not need to write new code to make different fractals. Im thinking about making some little connector pieces so I can make models of these with dowels. I like them because they are highly regular and geometric in definition, yet somehow my eye sees them as rather organic from some angles, especially when the trees have certain branch angles (20 degrees seems quite nice).
I say nonUniform fractal because of Mandelbort, ch.16, Trees; Scaling Residues; Nonuniform fractals in The Fractal Geometry of Nature.
PIR, PUR insulation panels
Contour crafting is a layered additive manufacture technique, much like that of ABS or PLA 3d printers such as the makerbot, but with the addition of trowels which shape the extrusion to create a nice surface finish. Check out http://www.contourcrafting.org/. Also check out the projects that Behrokh Khoshnevis is working on. Pretty neat.
In one of his papers (contour crafting paper) he talks about the possible applications of contour crafting, especially the fabrication of building walls and roofs. It presents some pretty fascinating ideas about modular rebar, electrical and plumbing systems that are integrated into the wall-extruder.
One problem with these systems is the need for a giant gantry system to make something big. The aforementioned paper suggests mobile robots which move about to access various parts of the structure, much like a set of human workers moving about while working on a large building. I wonder if it would be possible to create mobile robots which are designed to move directly on the structure they have previously created. This is similar to the ‘termite robots‘ project, but with extrusion instead of discrete-unit deposition. (here is the termite robots paper, here is the self-organizing system research group). One problem with such a system would be feeding material to a robot that keeps moving around. One advantage would be the ability to make structures that are many times larger than the robot itself.
Another thing all this stuff makes me wonder about is dedicated extruders for specific cross sections. Like an extruder head which prints a circular cross section, so that it can make tubes. Mounted on a 3D robotic positioning system, like a multi-axis robotic arm, one could make tubes that follow complex space curves. That would be neat.