Week 6: Simulation Project

Fluid Simulation

The p5.js fluid simulation example has really poor performance, and based on my research it seems that Processing or openFrameworks are the way to go. Processing seems like the easiest transition compared to openFrameworks (which is a C language).

My research read me to the PixelFlow library created by Thomas Diewald.

Thomas Diewald appears to be a programmer of some renown when it comes to fluid dynamics. Here are some examples of his Processing using his library.

I ended up adding Thomas Diewald’s PixelFlow library and (which utilizes the GLGraphics library for performance) to support my fluid dynamics endeavors.

Week 4: Oscillators and Particle Systems

This week I got caught up with the oscillator exercises and explored particle systems. This sketch (link here) is based off of the very straightforward particle system inheritance / polymorphism example from Nature of Code. As an exercise, I added a new inherited class, the “star” class. I also used a super constructor in that class, and was able to adjust the parameters a little bit of the stars by changing their direction, rotation and speed, while still being a child class of the original particle system.

Also here is the code for my “start and stop” buttons if anyone finds it useful. I wrote them as a standalone function. The reason for the start and stop buttons is really just for web site performance. In ICM it wasn’t such a big deal letting all my sketches just run on a web page, but once you introduce particle systems it starts getting pretty performance intensive.

In this sketch (link here), I was just playing with the parameters of the exploding firework example, tweaking some of the physics to explore how the particle system works.

Here is a link to the above sketch. I was a little behind on assignments so I also went back and played with the oscillator exercises and Fourier transform series. I have to say that my mind was truly blown when I learned how the fourier transform works. Pretty wicked stuff. Watch this video if you feel like having your mind blown.

This sketch is another play on creating square waves from a Fourier Transform series. Link to sketch here

Week 3: Exploring Forces

Our assignment this week was to explore oscillating patterns, but I was kind of struggling with vectors still, so I decided to go back and revisit the first two weeks of material more thoroughly. This sketch is based off of Dan Shiffman’s “Mutual Attraction” sketch (link here).

I realized that I was having a hard time with how vectors operate. After carefully revisiting the core principles of how they behave, however, I now feel more comfortable to move on to more complex systems interactions. In this sketch, I mapped the fill of the circles to hue values based on their X-coordinates. I also tweaked the attraction force and the number of iterations from the original mutual attraction sketch. I also confined their movement to roughly 20% outside the canvas.

In this sketch (link here) I combined the concept of fluid forces with the mutual attraction sketch. As you can see, the result is pretty bizarre. I had a hard time containing the “movers.” I was trying to figure out how to get the movers to disperse more in water while still keeping the fluid dynamics in place. Because their force is limited in water, it is harder for them to get far enough away from each other to generate more force, which is why they initially end up in a blob when you first run the sketch. It’s pretty fun to watch at any rate.

Week 2: Revisiting Vectors with Force

Drag your mouse across the sketch to influence the Levy Flight

Here is a link to the above sketch.

This week I revisited my previous sketches by fixing some of their flaws, and creating some new experiments as well. My intention was to create a sort of visceral, vascular system using Perlin Noise, but I think that experiment will have to wait for next week, because life stuff.

In the above sketch I mapped the X of the Levy walker (not sure if Levy walker is a legitimate phrase, but I’m using it anyway) to mouse X, and I also mapped the velocity of the vector to mouse X.

I spent most of my time this week trying to wrap my brain around the Diffusion Limited Aggregation examples. So, while my sketches may seem lackluster, know that I spent a good part of my week trying to keep my brain from imploding while trying to write the DLA sketches from the ground up. Shiffman makes it look very easy.

Dan Shiffman's Diffusion Limited Aggregation Sketch

I’m still having a hard time navigating object-based coding. I’ve booked hours with Shiffman this week, so hopefully I’ll get there. Probably I just need to log more hours working through the examples. 🤷‍♂️

I also remade my more classic rainbow walker (sans Levy flight) using proper vectors (link to sketch here).

Inaugural Post! Random Walkers and Vectors!

Click here for a link to the above sketch.

I wrote this post before looking at the Diffusion-Limited Aggregation exercise, and now I realize that everything I was playing with to constrain the walker could be solved by literally doing what I just said: “constrain.” So, I’m leaving my original post below, because some of the artifacts were cool and weird, but in the end, simply calling “constrain” was a very straight-forward way to keep the walker inside the box. The above sketch does exactly that. And here were all my previous attempts and experiments with vectors and walkers.

First experiments

This is my first assignment from my first class with the one-and-only Dan Shiffman (applause). In our first session, Mr. Shiffman explained that vectors will more or less be the foundation of everything we do in the Nature of Code. I should also mention what the Nature of Code fundamentally is, which is basically recreating physical behaviors from the natural world through coding.

Our first assignment was to create a random walker. I made a few, but my first walker (shown above) I whipped up from scratch mostly to re-familiarize myself with .p5js after our long break (Here is a link to the code).This one does not use vectors, but it’s a random walker nonetheless. In this sketch, I spent a lot of time trying to figure out how to constrain the walker within the canvas bounds, but I’m realizing that it’s actually kind of complicated to do.

First, I tried reversing the values when the walker reached an edge, so “posx” would become “-posx",” and the same goes with Y. This definitely increases the likelihood that the walker will come back, but not by much. In the end, I found that you have to fundamentally change the probability of the walker once it reaches and edge in order to favor the likelihood that it will move away from the edge, which is actually pretty annoying to write out case by case. I also mapped the walker to a rainbow using HSB values, because why not a rainbow?

This sketch (click here for link) uses vectors to create the “levy flight,” which sort of mimics the way animals forage by manipulating the probability of randomness. I tried implementing my quick-and-dirty method of confining the walker and it had some pretty strange and awesome consequences.

If you give it enough time, the walker will draw lines across the entire canvas. Click here to see the sketch. It’s actually pretty cool. I’m trying to wrap my brain around exactly what’s happening in the math of these lines. In this sketch, I created the condition of making “posx” into “-posx” if the walker goes to the canvas edge, but I swapped it for “pos.x” and “pos.y" because I’m using vectors. At a glance I would say it has something to do with the relationship between “pos.x” and “prev.pos.”

And then I made when where I inverted “pos.x” and “pos.y” in the first coordinates of the line being drawn. Also weird and cool. Link here. See below: