# conye – Interruptions

The final result:

Observations:

1. About 50 – 60 on each side.
2. The lines tend to “flow” in a certain direction, either horizontally or vertically.
3. There are 3 – 5 interrupted areas of varying intensity and width.
4. Most of the lines in the non-interrupted areas appear to intersect with other lines.
5. These intersections usually appear only near the endpoints of both lines.
6. The shapes made by the negative space between the lines all have about the same area (except for the holes).
7. The lines all have about the same length but different angles.
8. The angles of the lines look like they’re related to the angle of the lines around them.
9. The lines fit together, kind of like a puzzle.
10. There are a lot of angles between 40 degrees and 60 degrees.

Also, this was definitely not my own observation unfortunately, but a few days ago I was struggling with the assignment and was curious to see how close other people had gotten. I noticed that josin said that the lines were all centered in a grid pattern and holy moly, they were right. I ended up using that observation for my code, but I can’t take credit for noticing that (Also, wow, josin did an amazing job so props to whoever josin is!!).

The process:

At first, all I did was generate a grid of about 50 by 50 random lines:

Obviously, mine is on the left and Vera Molnar’s is on the right. I soon realized that randomly generating lines wouldn’t be anywhere near enough. I was using a fixed (x,y) start point with a vector for angles. I tried to start angling my vectors upwards, but it still looked unsatisfactory. Then, I added the randomGaussian() function to make angles with an average value of 90, which made it look much better, but still not good enough. During the studio time, I first added perlin noise to make the holes, which was incredibly easy.

After talking to Golan, I tried to use the intersection() function to make the line endpoints end up near each other. The idea was that every time I created a new line, I would test its endpoint against nearby endpoints to see if it intersected the endpoint of another line. I thought it looked good until I got back from the studio and realized that I wrote my “if” statement for the endpoint testing in a way that made it always true (ua > -1.7 || ua < 1.7)!!!! So the only reason it had looked noticeably better was because of a) placebo effect?? desperation?? b) I had also been tweaking the numbers. I fixed it, but am not quite sure if it made a huge difference. Below is an image of the process:

On the left is with the randomGaussian and nothing else. On the middle is the tweaked and fake fixed version. On the right is an image of the program with the actual endpoint testing implemented. I think there is a noticeable improvement, although it’s not quite perfect just yet.

What could be better:

Right now the endpoints testing will put down a line as soon as a line is generated that has an endpoint near any of the lines above or to the left of it. However, a problem arises: this leaves it open to intersect other lines accidentally, which Molnar’s artwork never does. Hers fits together smoothly, like a puzzle. The program could be improved to check for and avoid “bad” (90 degrees, in the center X shaped) intersections. I think there must also be a way to make the result more aesthetically pleasing to look at, perhaps with the placement of the holes or the specific angles.

What I learned:

I learned that art is really hard, especially computational art. Vera Molnar is amazing for creating something so orderly yet natural, especially with the technical limitations of her time! I also learned that computational art requires more than pure coding because the aesthetics of the result matter.