For the Nature of Code midterm, we were asked to do the following:
Develop a proposal and a prototype for a "midterm" project. The scope of the project can be quite large (trial idea for a final, for example), however, you will not be expected to implement the entire project. For the proposal, include a description, relevant links, and a quick Processing sketch of the first step towards the idea. Link your proposal from the wiki. Next week, we will look at a selection of proposals and then on Mar 2/3, the results for all midterm projects will be presented.
As such, I've decided to continue my work on modeling popcorn using the Box2D library. While the original attempt was moderately successful, there are a number of aspects that I'd like to modify and enhance so that the simulation will be more realistic. Specifically, they are to:
Enhance the geometry of the popcorn so that the kernels and popped corns are not uniform in shape and size.
Work with density variables to create more realistic behavior as the corn pops and expands out of the kettle.
Work with kernel placement and velocity so that the kernels don't breach the kettle walls upon popping.
Allow for user interaction and variability with the simulation, including: amount of popcorn, turning the kettle on an off,
Create more realistic visualizations to associate with the simulation as a whole.
These changes will also serve to further familiarize me with the Box2d library, and its ramifications for geometry and particle systems in a modeling context. The project will not be the prototype for a final project, but rather the final iteration of an earlier project before I embark on a final.
This week in Nature Of Code, we were asked to use the Box2D library to implement a model of some real world phenomena. Box2D is a physics system that manages the physics of a given system, which you can add various physical "bodies" to. This allows you to create a realistic physics model for a given 2D system with very little coding overhead. For whatever reason, when I heard this, my mind immediately went to popcorn.
For a smaller number (100) of kernels, my model (with a small amount of tweaking) actually works quite well. The kernels pop somewhat naturally, and the system generally handles the physics of the situation how you would expect it might: just like a real popcorn popper! You can see the effect of 100 kernels in the first two illustrations of this post.
However, from there I started adding more kernels, and got into some trouble. At 150 kernels (above) the physics started behaving a bit erratically, and areas with a lot of popping density would cause kernels to move through solid objects.
When I increased the number of kernels even further, to 300, this behavior became almost ubiquitous in the system. Kernels were popping out of the kettle left and right, and the walls of the kettle seemed almost meaningless.
I have yet to discover what the cause of this behavior is, but my guess is that it's an inability of Box2D to handle the sudden transition from kernel to popped kernel. A few ideas I've had include increasing the time of the "pop" from one step of the physics engine to say, 3 or 4. This might allow the engine to handle the change more intuitively.
One of the challenges of Box 2D is that it has no graphical output, so everything you draw is based upon a Box2D object, but isn't actually a Box2D object. What this means is that errors in one's graphics code can appear to be Box2D errors, when in fact they are coding errors on the users end. This is unquestionably one of the downsides of using a "black box" engine, but hardly enough of a problem to avoid using such a versatile tool.
The image above is a screen grab of the third revision of my flower-based physics model, last mentioned here. Since then, the model has gone through a number of iterations. The first modified the graphics to be slightly more refined, and more successfully integrated a wind force, as well as a flower "wobble". The initial issues I had with the wind being too uniform were resolved by putting a limit on the force vector, as opposed to the resulting velocity vector. The velocity limit had been causing all of the flowers to share velocity and direction. I intriduced the "wobble" in an effort to give each flower its own movement, in spite of the shared wind vectors.
This revision, the third, takes the second revision and adds the concept of thermals. The thermals can be seen in the regions defined by white lines above. These thermals provide a third, largely upward, force that is defined by the developer. When blooms cross them, the addition of the thermals can result in spontaneous upward movement, ostensibly due to air current resulting in difference from temperature. From here, I think the next logical step is transferring the wind force from a single shared force screen-wide into an array of wind vectors, varying based on screen location.
For our first week in Nature Of Code, we were asked to do the following:
Find an example of real-world "natural" motion and develop a set of rules for moving the Walker. Can you do it without using any random whatsoever? Without changing how the square looks at all (changing size or rotation is ok), can you give it a personality or make it appear to have an emotional quality? Create a second version with the same behavior, but with your own non-square design. Feel free to design an environment for the Walker to live in as well. We'll compare the versions in class next week. Can we create something natural through algorithmic behaviors alone? How much does visual design play a part?
Inspiration.
I took my inspiration from the PlayStation 3 game Flower (see video above), and attempted to model flowers (namely, dandelions) being detached and floating in the wind. As per the request, I created two versions, one that used pure geometrics, and one with more visualization.
Implementation.
The first visualization uses squares and lines (along with modeled wind) to gradually harvest the dandelion buds from their stems. While the representation is geometric, I actually think the visualization has enough clarity, or familiar layout, that it's pretty clear what's happening.
The second animation uses the same code, but with color and small dandelion gifs to create a better sense of what's going on. While the original visualization creates a semi-clear representation, the second implementation unquestionably does a slightly better job. The colors and gifs create and animated, cartoony feel that successfully portrays the objects in question.
Challenges.
Both implementations use the same modeling for the wind, which uses vectors and random numbers to specify when buds disconnect, and how they move once disconnected. Coding the disconnect was simply a matter of randomly disconnecting at a pace that was seldom enough to feel natural.
The wind was far more of a challenge, and required figuring a pace of wind change that didn't seem too fast, or too slow. I eventually managed to stumble upon a combination of changing acceleration, changing direction, and avoidance of downward wind, that seemed to grasp the idea well.
My main challenge (which I still have yet to solve) is that the iteration over the flower array to update each vector results in an occasional pause in the motion which is highly unnatural, and definitely not desirable. I need to investigate this further, and determine if there's a more efficient way to update the objects, or if I need to reduce something algorithmically within the update.
Takeaway.
Short version: making things move naturally is hard.
Long version: I had difficulty implementing any kind of movement that felt natural without using randoms. Even once I started using randoms, the implementation was largely one of trial and error, seeing what looked and "felt" natural, and elaborating on that.
Source Code: Zip File with Source Code and gif (Please note that the sketch is done in eclipse, and will not work in a regular Processing environment.)
This week for Visualizing Data we were given a "mystery" data set, along with some hints that the set (wink, wink) might contain x-y coordinates. This was an exercise in not only parsing CSV's, but also in taking in data and deriving meaning from it.
A quick parse of the code revealed the x-y coordinates, and quickly demonstrated them to represent a map of the world. The third (data) value was indeterminate, but appeared to represent some sort of variable (population, energy consumption?) associated with more populous areas. When used as a pixel's alpha value, the picture came to quickly represent the well known maps of earth from space at night.
While this was all well and good, it didn't seem to reveal anything about the data, other than that it was exactly what it appeared to be, and that there was world wide trending. However, in an effort to possibly determine slightly more about it, I decided to project the data values into the y axis, and the y axis into z space. This meant that the map was being rendered horizontally, with the height of the map representing data at a given point.
Once this was done, it revealed a few more interesting facts about the data:
1) Despite the "hot spots", there's not a particular are of the world that doesn't have high data points. The points are universally high and low across the breadth of the map.
2) The data appears to be highly stratified across the map, resulting in data "rows" on the y-axis. While I can't be sure why this might be, it seems likely that these "rows" are the result of estimates or rounding employed in the data collection.
Overall, this exercise allowed me to parse CSV's, which is relatively trivial. However, it also forced me to look at the data a little more closely, and in doing so revealed some facts that might have been otherwise overlooked in the 2D model.
