Lars Wander and Mixing Paint With Code

Lars Wander is a visual artist and programmer, who creates his art exclusively with code.

When Lars was young, his father taught him a valuable lesson; "a computer always does exactly what you tell it to do." Despite this, there are moments when the computer still surprises him, almost as if by magic. As an artist, his goal is to capture those moments of unexpected beauty.

how you see me #14, 2022

"My process is always very centered around implementing a single 'idea' in the form of a program, which I then use to explore and play with that idea from various angles. I find that once an idea is implemented as code, it’s possible to push and explore that idea in ways that can’t be done simply on paper."

We spoke with Lars to get a better understanding of his approach to creating art with a computer.

Can you walk us through your creative process?

What’s common to my process in each project I’ve done so far is that it begins with a lot of time spent thinking and doodling about systems that would be interesting to implement in software. Usually, after a few weeks of thinking, I spend a few days writing code with little visual feedback until the core system is implemented. During that process, I almost always encounter a series of questions that I don’t know the answer to (e.g. what should the average paint blob size be? or how many light rays should be collected per pixel when tracing the scene?) which I encode as parameters to be fiddled with later.

FULL_SPECTRUM #27, 2023

FULL_SPECTRUM #19, 2023

Once the code is ready, I spend weeks or months playing with the parameters and making code changes as I guide the system towards what I think will be both visually beautiful while still representing the core idea that inspired me in the first place. When it comes to how my code is structured, I try to maintain 'good' engineering practices for libraries and functionality that I share between projects – the idea is that these bits of code will stick around for a long time, and I want them to remain reliable and understandable above anything else. But the rest of the code and the code that’s unique to each project is usually far messier and more experimental. I find that if I allow myself to be messy and chase the behavior of the system, the end result is almost always far better than if I tried to write 'clean' code throughout.

Given that generative art brings 'process' to the foreground, it’s very important to me that my works are as conceptually simple and beautiful as they are visually appealing, so I try my hardest not to hide the core idea of a piece in visual decoration. My process is always very centered around implementing a single 'idea' in the form of a program, which I then use to explore and play with that idea from various angles. I find that once an idea is implemented as code, it’s possible to push and explore that idea in ways that can’t be done simply on paper. However, more often than not, I find that once an idea is translated into code it actually isn’t quite as exciting as I hoped – I have a large graveyard of projects that simply didn’t capture the magic I was hoping for.

Light Doesn't Bend That Way #1, 2023

What is your background as a programmer?

I studied Computer Science at Carnegie Mellon and then worked as a Software Engineer at Google for 7.5 years across a range of teams spanning cloud deployments, AI-based speech-to-text transcription, storage systems, and visualization.

At what point did you transition to creating computer art - or has it always been something you’ve been interested in the side?

It wasn’t until I started work on visualization in 2020 that I realized the creative potential of code-based art. Seeing the visualizations created by my manager at the time, Wim De Pauw, was a huge part of that realization. He captured the intrinsic behavior of these large, complicated, almost organic-seeming systems but the results were still beautiful to look at (and something I would gladly hang on my walls given the chance).

Could you describe the earliest piece of computer-generated art that had a significant impact on you?

The first time I remember being seriously moved was when I found the artwork of Jonathan McCabe. At this time I had barely begun making my own computer artwork, but thanks to my programming background I generally had a pretty good sense of how most computer artworks I’d seen so far were created. However, seeing McCabe’s work really opened my eyes to the depth of this field – it was like getting a peek decades into the future of computer artwork. His process and tools are still an absolute mystery to me, and the results are beautiful and mesmerizing. What really moves me is the sense of exploration and curiosity I feel when looking at his works: they play with basic principles found in biology, but push these concepts in a direction that’s completely alien yet stunningly beautiful. I hope to create such wonderful works myself someday.

Jonathan McCabe, Cellularity, 2020

What are your go-to tools when creating or does it vary per project?

I always try to use tools that are as simple as possible, and (when possible) are built by myself. I find that the tools we use have such a huge impact on the way we think about our process and, in turn, the actual works we produce, so I find it very important to produce and maintain my own tools. I also happen to really enjoy building tools, especially tools where I’m the only user (haha).

More concretely, all my recent work was generated with vanilla Javascript and WebGL2. For simplicity’s sake, I serve unbundled Javascript using a local HTTP server and symlink in some libraries that I share and develop upon, between projects. I do all my development on Linux, as I find it’s the most programmer-friendly environment to work in. When it comes to my plotter projects, I started off doing everything in Python but eventually became frustrated with the performance. For the sake of speed, while keeping development easy, I switched to Julia, a high-performance language with nice ergonomics developed at MIT for scientific computing.

What are your thoughts around open-sourcing your codebase?

That’s a great question and something I’ve wrestled with quite a bit. My first inclination was to open-source everything as it felt right to share and foster community collaboration around the practice. However, I realized that, unlike other forms of art, it’s possible to completely recreate another artist’s work, pixel-for-pixel, by knowing their process. Once I saw how common 'copy-minting' was on fxhash (the act of copying and selling another’s code either through impersonation or deception), I knew that sharing all of my codebase would only result in people getting scammed. Still, sharing what I learn for others to grow is important to me. I try to share techniques like my 'Centering and Scaling', or my pigment mixing Kubelka Munk code (with proprietary data removed) for others to benefit from.

When did you first come across plotters?

I was introduced to the plotter through a video on Reddit, which had a link to the AxiDraw webpage. Once I learned that it could be controlled by sending X/Y coordinates and up/down commands, I knew I had to have one to play with. This was towards the start of the shelter-in-place period of the Covid-19 pandemic, and it turned out to be a great source of entertainment. I made hundreds of pieces during this time and only shared a small fraction of them on my Instagram. I was later really fortunate to have Verse exhibit some of the other pieces in my first solo show, 'Perry, Mary, and Lars'.

Perry, Mary, and Lars, Verse, 2022

When I ordered the plotter I was incredibly excited for it to arrive, so rather than obsessively refresh the FedEx tracking page I spent my time writing a little Python library to generate plots, visualize them, and send them to the plotter using the AxiDraw’s interactive API. To test the library, I wrote a little three-body simulation, and connected pairs of the bodies with lines, tracing out their trajectories over time. When the plotter finally arrived, to my amazement, I was able to plug it in and get it plotting almost immediately, rendering one of these three-body simulations. This feedback loop of writing code, seeing it visualized on my screen, and then making it physical with the plotter was immensely satisfying, and ultimately was what got me hooked.

RHYTHM & THE MACHINE #390

RHYTHM & THE MACHINE #390

Can you speak about some of the various methods and materials you've employed to create art with the plotter?

One of the most enjoyable parts of plotting for me was exploring the different options for materials and processes. I started off with printer paper and a fountain pen, but quickly started running to the local art supply store on almost a weekly basis looking for more supplies and ways to take advantage of the plotter.

Early on I decided that I didn’t want to use the plotter to try and replicate the human hand, as it seemed like it was missing the point of the practice (if you want to replicate human drawing, why not just draw yourself?). So through the various materials and methods I tried, I was always cognizant of exposing some element of the machine that was involved in creating the piece. I found this most interesting when using watercolor and graphite. Both of these materials impart a beautiful texture, but can be very fickle and hard to control. This juxtaposition between the inhuman precision of the pen-plotter and the inherent difficulty of using these materials is one of the things that really appeals to me.

Lines Walking - Blue #1, 2021

Ribbons - Two Sheets in Black #1, 2022

How do you conceptualize the difference between creating works for a plotter versus a natively digital platform?

The transition from producing plotted works to purely digital ones is a very difficult one. Taking a piece intended for the plotter from its digital representation to its plotted, physical representation is really wonderful in how much it adds depth and beauty to a piece. The subtle physical imperfections that are inevitable in this translation add so much to a work that it really forces you to rethink your approach when creating digital-only works. That said, I strongly believe that creating digital-only works which try to mimic physical imperfections is unimaginative, and is missing the point of the digital-only medium. After all, is something really 'imperfect' when you’ve created it by describing it precisely in code? Telling a machine exactly how to reproduce an 'imperfection' seems to go counter to the idea. Instead, I try to find ways to explore a 'digital' aesthetic when making works intended for digital platforms, like the flat colors of 'how you see me', or the noise visible in the sampling-based convergence of color in 'Light Doesn’t Bend That Way'.

how you see me #12, 2022

Light Doesn't Bend that Way #6, 2023

What was your ultimate goal when creating Light Doesn't Bend That Way?

That’s an interesting question, I guess if I had to assign an 'ultimate goal' it would be to explore the otherworldly. A sense of curiosity and desire to explore is what drives most of my work, and given my background, writing programs is the most natural way for me to do so.

I strongly feel that sharing explorations like these needs to be grounded in reality somehow for them to be interesting and to connect with an audience. It becomes an interesting question to decide where that connection to reality should be made. For Light Doesn’t Bend That Way, I chose to implement that at the level of human perception of light, by writing a ray tracer that converts Spectral Power Distributions to RGB colors. What’s interesting to me, is that this conversion is carried out using data that is empirically collected by experimenting on human sensitivity to various frequencies of visible light. With that empirical data, it is possible to mathematically describe a relationship between wavelengths and the subjective experience of color.

Light Doesn't Bend that Way #3, 2023

This concept is almost magical to me, as it represents a bridge between a purely subjective experience and a mathematical framework. Using visual perception as the connection to reality, Light Doesn’t Bend That Way explores different ways of casting light through a scene with altered equations governing the path of the light as it disperses and refracts through the environment. The results are images that are rendered with light and perceived as though they exist in our world but ultimately are impossible to recreate without this creative use of computation.

Can you talk about the conception and development of your first long-form generative art project, Gossamer?

Gossamer was based on a technique that I had developed while plotting and was one of my first attempts to make generative artwork that wasn’t rendered with a plotter. Its heavy use of overlapping lines to create texture was clearly born from my plotter practice, but the resulting images would be nearly impossible to recreate with a pen plotter due to the line density.

Gossamer #8, 2021

Gossamer #12, 2021

Creating Gossamer was an important departure from plotter artwork for me, and an important learning experience in how to create long-form generative art. While it was the first long-form project that I published, I was already working on 'Lines Walking' before discovering fxhash, after approaching plottables.io for an opportunity to publish on their platform. I took a lot of what I learned from my early fxhash projects to refine and prepare for this plottables release.

Lines Walking #0, 2022

Lines Walking #33, 2022

A plot of Lines Walking testnet mint #0

What are your opinions on the display of digital art?

While I believe that digital art should be resolution-independent wherever possible, I don’t believe that it should be entirely scale-independent. As a result, it’s frustrating when pieces are mostly seen and shown as thumbnails in a grid among many other pieces on some online marketplace. I guess this is inevitable, but I would encourage folks to look at my pieces full-screen when possible. When it comes to displaying works on a screen, I also prefer that, where possible, the code itself is run live to generate the piece. There is something special to me about the idea that code is running as a part of the performance of the piece.

Where do you see yourself in 10 years?

I’m glad you’re asking so that I can look back in 10 years! I know I’ll still be making art. Most likely I’ll keep playing with new tools and techniques, and will likely produce works across a range of mediums and styles. I have no clue what it will look like (or if it will even be visual), but I know I’ll be having fun making it!

As far as generative art at large goes, I imagine that there will be more and more crossover with physical media as artists continue to explore and push boundaries beyond the screen. Companies like Artmatr are really interesting in this regard as they are helping bridge the digital-to-physical gap in all sorts of interesting ways with custom robotics.

For inquiries, please contact hello@artxcode.io