Over winter break, I decided that this semester I would finally be ready to create the first installment of a film called Digitalis, which I’ve been developing for the past few years. With four months, an 8-core Mac Pro and a lot of work, I’ve learned a ton and have created a short film, called “Digitalis: An Introduction to DEcomp,” as well as the software I used to make the film, DEcomp Visual Toolkit 4.
“Digitalis: An Introduction to DEcomp” will premiere at the ITP Spring Show on May 9, 2010 @ 2PM.
April 2: (nearing final draft)
This image requires a side-by-side stereo viewer. Test render for the Digitalis set.
I wrote a simple implementation of Conway’s Game of Life. Available here:
You can toggle between setup and run modes by pressing the ‘r’ key. The program will open in setup mode. Begin by drawing some initial state on the board (see Wikipedia for ideas), then press ‘r’ to bring the world to life. The ‘c’ key clears the board.
Here is a Gosper glider gun, created with the above software:
When two objects collide with one another in the physical world, nature doesn’t require a different procedure to calculate the collision’s effect upon each possible shape – rectangle, triangle, ellipse and so forth. Computationally, it is much more straightforward to calculate whether a regular shape such as those listed above has experienced a collision than it is to do so for an irregular shape. Yet, any procedure that works for irregular shapes should also work for regular ones.
As a starting place, I envisioned a dynamic scenario that involved both regular and irregular geometries: a cloth bag filled with marbles being dropped from some height onto the ground. In an attempt to deal with this scenario in a “universal” manner, I decided to think of all parts of this system being composed of the same type of thing, which we will call particles. The size of a particle can vary and it can either exist freely or be constrained to other particles. So the marbles are large, unconstrained particles and points along the bag’s surface are small particles, which are tied to one another in the sense that one particle and the next cannot be more than a certain distance apart. This constraint can be extended to include the property of stretchiness. From here, we apply any forces – gravity, air turbulence, etc – to all particles and scale the effect of each force based on the mass of each particle. So far, I have implemented the bag portion of this simulation. Next I will add the marbles. Without the marbles, the bag feels more like a chain necklace. More to come.
Here is a video of the bag in action:
Here is the source code:
In the process of creating the particle bag, I did a few tests to get the hang of using polar coordinates. To initialize the bag, I set the particles around the circumference of a circle using polar coordinates to do so. This way of representing coordinates is ideal for this purpose and I can’t think of an easy or efficient way to achieve the same effect without them. So for the purpose of meeting the oscillation goals of this week’s assignment, I wrote the following:
Over the past two years, I have been developing a 3D environment application from the ground up to address certain possibilities in computer modeling, which cannot be achieved through any pre-existing 3D environment. My software is called DEcomp and it takes what I think of as a “perspective-centric” approach to 3D modeling. Some details and visual examples may be found at the non-blog portion of this site: hebali.com
DEcomp (which stands for “Decompositional Environment Composer”) has been designed for the construction of large-scale, photorealistic cinema projects – namely my several year work-in-progress, called Digitalis. DEcomp’s emphasis, therefore, is dealing with elaborate CG sets, which contain millions of vertices.
Yet, somehow in the several years I’ve been working on this project, I have not built any physical models from DEcomp’s output. This is largely because my intent for this project is a cinematic one. But it also because creating a physical model of the type of objects I create in this environment would be exceedingly difficult to get right.
For this Pixel By Pixel assignment, I thought I would try making a physical model of the simplest geometry that could possibly be exported from DEcomp – a few simple squares. I soon saw just how difficult it really is to get a perspectivized model just right in the physical world. If any angles or distances are even slightly incorrect, the visual effect will be almost completely lost. In these first attempts, I don’t think I managed to achieve truly satisfactory results. It seems a 3D printer would most likely be required to achieve the proper effect on anything but the simplest of geometries.
Here are a few videos of the CG models:
Here are the physical models:
The question of whether anything in nature is truly random is a daunting one – perhaps unanswerable in the terms of our present understanding. Yet, many things in nature appear random so much as we can apprehend them. For this assignment, the goal was to visually represent a natural phenomenon without using any programmatically generated “randomness.” This was a difficult challenge, which made clear how readily we look to the notion of randomness in our consideration of the characteristics of the natural world. In answer to this challenge, I created the Particle Walker, which combines some conceptual elements of cellular automata with a simulation of the physical dynamics of elastic collisions.
The Particle Walker procedure:
Upon startup, the user is presented with a motionless walker (a gray square). The user clicks somewhere inside of the walker, drags to another point inside the walker and then releases the mouse to instantiate a single “particle,” which is represented by a small circle. The particle’s initial position is constituted by the coordinates of the initial mouse click. The difference between this point and the location where the mouse button was released constitutes the particle’s velocity vector. The particles have been programmed to have dynamic collisions with the boundaries of the walker and with one another. The particle-particle collision procedure incorporates Conservation of Momentum equations, making the interaction between particles something like that between real-world billiard balls. The user may add as many particles to the walker as he or she wishes and may also change their radii and maximum velocities as well as the size of the walker itself.
The image below presents a relatively small group of particles bouncing around a walker: (For demonstration purposes, a particle is filled with red if it has had a collision within a certain number of frames – in this case ten – and is otherwise gray.)
The key to the Particle Walker is that when a particle collides with one of the walker boundaries, it moves the entire walker by a single pixel in one of four directions: up, down, left or right depending on which boundary is hit. So, if there were only one particle in the system and it were bouncing back and forth between the left and right boundaries, the walker would simply move back and forth by one pixel along the horizontal axis. But with a large number of particles instantiated, the walker’s movement will not be as regular. We may assume that for a large number of particles viewed over many frames, there is likely to be a more or less equal distribution in the number of collisions that each of the four boundaries experiences. Yet, over the course of a few frames, an even balance is by no means assured. For example, it is possible that four particles will hit the left wall before any hit the right. From this, some quite irregular starts to emerge, something which feels a lot like Brownian Motion. Of course, there is nothing random about the Particle Walker’s motion, it is entirely deterministic. For any particular time value, we could extract the position and dimension of the walker as well as the positions, velocity vectors and radii of the particles and calculate any future state of the system from these datapoints. The irregularity of the walker’s motion can therefore be attributed to the complexity of the initial state – the position(/velocity) of the particles and walker at the time of their instantiation – being repeatedly compounded by the dynamics simulation over many successive states.
The two images below were generated by drawing the walker’s path (as represented by the 2D position of its center) over the course of many frames. The characteristics of the generated image will be affected by the size of the walker and particles as well as the maximum velocity and number of particles in the system. The line has been shaded to show its temporal path – a darker portion represents an earlier frame and bright green represents a later one.
An image generated by the Particle Walker.
A question that arises from this is even though the system is entirely deterministic and so all future states can be calculated from the complete knowledge of any previous state, can a particular state be calculated from a previous state in fewer steps than it would take to solve each state between the two in question? I believe the answer is no.