CPSC-334/gen-art at main · risxyang/CPSC-334
In planning the design for this six-paneled projection, I decided between creating continuity between panels (letting elements travel between them, possibly) and letting each panel function as a separate and unique component of the overall work. At the same time, I was also considering what it might mean to make something generative. To compose from a blank slate with a shape or color felt intimidating to me, and I gravitated towards the idea of starting with a photograph or a video, in order to use those existing frames as a basis for a decomposition into manipulable elements. I was ultimately interested in creating something abstract, even if I were to start with media that is a more mimetic representation of reality. I had the intention of working with images at the pixel-level in some way, possibly by sorting, or by applying an evolutionary algorithm.
I decided to let a photograph be the origin of the generation process for each panel. I wanted to be sure that if I were starting with existing media, that I would be using images I had taken myself, and that their meaning (in the context of processes of decomposition and abstraction) would contribute to the overall effect of the finished work.
In the film studies animation course I am taking this semester, one recurring concept has been the idea of the artist's hand— the impulse of self-figuration. Some early animated works would start with an artist's hand penciling out and inking the first frame of the film, before the viewer is able to enter this drawn world. We talked about the massive amounts of creative (and usually very physical) labor involved in creating complex works of art such as animation, and how this labor goes unseen by an uninformed audience. Self-figuration seemed at times, in part, to make the viewer attentive to the work behind the "magic" of animation— which added to the "wow" factor even more.
A week's planning for a single work of generative art is very different from a massive, collaborative endeavor like an animated film, though as a similarity, one of the videos in the readings for this module mentioned on the semi-invisibleness of the handiwork of live coders. While their work is seen as code on a screen by an audience, the physical process of inputting code is not always visible to other people — if they are programming on a laptop, the screen may hide their hands. Programming a work of generative art, relative to other forms of making, doesn't seem to foreground the "hand of the artist" as much. Rendering clean shapes in processing doesn't have a self-drawn quality, and the development of any sort of individual 'style' through a language like processing will likely take years of practice. I think my desire to create my first ever piece of generative art with images of my hands was a desire to self-figurate in some way, to create digital images which feel organic despite all these limitations. Ultimately, I think the coolness of generative art derives in part from the generation of organic-seeming images, starting from the abstract, without needing to begin with anything inherently realistic-looking. So, in future works of generative art, I'd want to begin somewhere else. But for now—
I decided to use Processing to generate my panels, as this seemed to be the most talked about language in the domain of gen. art, and I was curious. I was able to find a template (amidst others which came with the IDE download) for spawning child applet windows off of a parent program. Each child window could be set spawn at a certain position, with any specified dimensions. This made things pretty easy for me, but it also shaped the way in which I defined similarities and differences between each window.
In the "parent applet" portion of the program, I could specify some setup values that would influence all the children — such as loading images into an arraylist, where each unique image would be set as the background of a child window. This is also where I instantiated the child windows. Each child window runs the same code, and it only differs from the others in which image it uses as the basis for its generative process. Initially, I was using the parent window as one of the display panels, but this required the repetition of the same code in the parent draw() function as in the child panels, which was not convenient to maintain. The parent applet still generates a window (despite me removing the directions for its dimensions and position), but it does not map itself to a display.
The main generative processes in the finished piece were a repeating pixellation effect and a random-gradient-overlay, which colorpicked its values from the pixels underneath its corner edges. The pixellation effect was simply the averaging of a small neighborhood of pixels and setting every pixel in that neighborhood to that average value. The fill effects I used in these processes do not modify the image they draw color values from; they only layer on top of the original image. I initially planned on the recursive modification of the image, where any distortions such as pixellation and gradient overlays would become saved as part of the original image, so that successive effects would colorpick from those modified values — until ultimately, the image would become distorted beyond recognition of any real thing. However, the project timeline proved to be challenging, and I wasn't able to figure out in time how to successfully log these overlaid values into the original image.
The gradient and pixellation effects will successively overwrite each other. Additionally, there are global "parent" values for the x and y position which dictate which pixels become re-pixellated from the underlying image at any given moment. If I specified these values independently for each child window, the pixellation effect would simply wipe across each panel in a predictable and linear way. But with these global values, an interesting thing happened where the child applets would be updated in a random order, and the position of the next pixel group (out of all 6 panels) to become pixellated would be randomly chosen, depending on which child applet's turn it was to run draw(). This resulted in some more interesting textures. It was fun to have some unexpected output and to integrate that as a feature rather than a bug in my work.
As for why I worked in greyscale— given that I started with photographs, I felt it was a good strategy to reduce those images to just values, which would allow texture to be foregrounded. This went with my original idea to distort beyond recognition, to the point of only texture — but this is as far as I got.
More abstract in a way I like; I screenshotted this from one corner of a panel with a very blown up background image