User:Tamas Bates/RWRM/HW1
< User:Tamas Bates | RWRM
Approximation of Triangular Crystal Growth
WHAT
- A small program written in Javascript to create fractal-like images made of triangles in a user's web browser. The sequence begins with a single "seed" triangle, created and positioned near the center of the viewer's screen as part of the program's initialization. From each of the triangle's corners a new, slightly smaller, triangle grows out along an axis which bisects the corner it was created from. This process is continued for each of the new "child" triangles and their resulting children, with care taken to avoid growing new triangles which overlap any existing triangles. After some time, the resulting final shape is approximately hexagonal (though not all sides are of equal length) and contains many pseudo-hexagonal pockets, some of which are filled with spiralling intrusions of ever-shrinking triangles.
HOW
- Rendering and computation of the necessary vector operations for positioning the triangles was handled by a vector graphics library called Paper.js. From each triangle, a child triangle was created at each available corner by duplicating the parent, scaling it down by a constant factor, and then rotating it around the corner it was created from. To avoid creating overlapping triangles every new triangle is inserted into an R-tree (a kind of 2D spatial data structure). Any triangle found to cause a collision in the R-tree is discarded. The program keeps a list of every triangle which has not produced any children and works through them one by one, creating as many children as possible from a triangle, adding them to the end of the list, then removing the parent from the list and moving on to the next triangle.
WHY
- The program was written to discover what the final shape would look like when following the growth rules mentioned above. Its sole purpose was to avoid going through the work of generating the shape by hand with a pencil and ruler. Paper.js was used primarily for its implementation of vector operations which are used to ensure each new triangle is correctly placed and oriented. The R-tree is used to optimize collision detection. Since the working set of triangles grows exponentially, it was necessary to use a spatial data structure to help filter out unnecessary comparisons when checking for collisions. Simple space partitioning was not fast enough, and quadtrees did not work well when inserting a new very small triangle near a previously-created large triangle (which often led to creating overlapping shapes). Using an R-tree doesn't solve the exponential growth problem, but does at least allow the program to run at a reasonable speed until the triangles reach a size of about 1-2 pixels wide, which is long enough.
Booze Bot
WHAT
- An Arduino Uno connected to a bank of relays wired up to the power switches on several small vacuum pumps. Each pump rests in a cardboard frame on top of a milk crate, which has the open side facing the user. A funnel beneath each pump routes fluid into the crate, depositing any liquid into a larger funnel balanced above a drinking glass. The input side of each pump is connected to a length of rubber tubing, which is inserted into a collection of liquors. Pressing a button connected to the Arduino activates the pumps and produces a cocktail for the user.
HOW
- The vacuum pumps were taken out of a set of breast pumps which ran on DC power. Each of them had their input voltage line soldered to a relay connected to the arduino. Through experimentation the speed at which liquor could be moved by the pumps was determined and hard coded on the arduino. To construct a cocktail the program loaded a file containing a list of the ingredients available at each pump, and how much of each was required for the drink. It would run each pump corresponding to the needed ingredients for a short interval which was computed from the pumps' measured flow rates to extract the correct amount of each liquid. The button was simply connected to a digital input pin on the arduino which the triggered the program to make a single drink.
WHY
- In my mind, there are three possible reasons to build a drink mixing robot: to make drinks faster than you can, to make drinks better than you can, or to make drinks in a way that is more entertaining than you are. This robot was primarily intended to satisfy the second criteria by mixing drinks as consistently as possible (though there were plans of eventually adding a speaker and microphone to make the bot entertaining as well). The breast pumps were used because they were a cheap source of food-safe vacuum pumps. An ideal solution would be peristaltic pumps, but these proved too expensive for the first iteration of the project. Due to time constraints, the bot was never updated to be able to make more than one kind of cocktail or to provide any visual feedback to the user (beyond fluids flowing through tubes).
Lightning Bolt Generator
WHAT
- A small program written in Lua. It begins by drawing a solid black background on the user's screen. At the top of the screen a clump of colored pixels forms, white at the center and fading to dark purple and black at the edges. These expand downward in an erratic fashion, carving out a jagged path toward the bottom of the screen, occasionally branching out into some smaller paths during the descent. The result is like watching lightning strike in slow motion. At any time the user can restart the process to generate a new and different lightning bolt.
HOW
- The lighting bolt is generated through a simple cellular automata process. The top center cell (which corresponds to the top center pixel of the image at the highest precision, but could encompass a larger block of pixels for faster computation at lower precision) is given an "energy" value of 255. This cell then activates each of its adjacent cells, which each compete for a portion of its energy. This is handled probabilistically by randomly distributing fractions of the energy among them(though the originating cell retains its original energy value, so the total energy of the system increases). Each of the cells which received energy then go on to activate any non-active adjacent cells which are either beside or below them (energy never flows upwards, only downwards and sideways) . Energy is then distributed to their adjacent active cells in the same manner as before, which may give energy to cells which previously had 0 energy or may add additional energy to a cell which had previously received energy from.another cell. The energy any given cell is allowed to hold is capped at 255. Once a cell has distributed energy to its neighbors it deactivates itself. To ensure the resulting shape is "lightning-like" a weighting is applied to the energy distribution step which causes cells to prefer to distribute energy to cells below them, and only occasionally hand large amounts of energy to cells at the same height (which would produce a sideways movement). Cells are colored by mapping their energy values (which range from 0-255) to a color palette which assigns white to values of 255, blue colors to values above 200, and dark purple colors to lower values (with the brightness of the color decreasing with the energy value).
WHY
- The program was an attempt to replicate the patterns seen in a slow-motion video of lightning striking. The resulting effect is not very similar, but turned out to be interesting in its own right. The original idea was to use cellular automata to simulate the ionization of particles in the air as lightning passed through them, which would provide for a single "lowest-resistance" path and the possibility for some "low resistance" branches. The probabilistic approach mentioned above was an attempt at an easy approximation of the ionization simulation without needing to track any real data.