Origins and Process.
A few words on process, as requested by a Discord user at Anomalous Materials (where I have my #tsukamoto channel) which has (as usual) turned into quite a ramble.
Tech Art
My background is a mixture of disciplines mainly working in videogames where people who can be useful on multiple fronts are usually bundled into the ‘Tech Artist’ category — You’ll never meet two tech artists that describe their job the same way — for some its shader programming and tool development and for others it’s fixing animation rigs and messing around with texture compression. For me, it was some of this and slightly different.
Rarely do people set out to become a Tech Artist, more often — they emerge from either the art or code discipline. which creates a sort of spectrum on which a TA exists from those with more artistic backgrounds and those that moved into the work from the code team and a more technical perspective.
When asked where on that spectrum I exist, I’d usually reply with:
“I’m more ‘an artist who is technical’ than a traditional tech artist”.
For me, I am a creative first — I didn’t learn programming languages for any reason other than to generate a visual result.
Background
In the early 90’s one of my first jobs was modelling very low-poly 3D landscapes for (bad) VR helicopter simulations — there were no tools. Just Notepad — you defined a bunch of vertices by typing in rows and rows of co-ordinates <x, y, z> and these were rendered as triangles by the program to represent mountains or ground or whatever.
This was nightmarish. What should have been such a cool job just felt like to total, total waste of time, and there was several of us undertaking this ridiculous task.
So, using C (the programming language, which I now realise was really using a sledgehammer to crack a walnut) I wrote a small program to generate random landscapes computationally.
Once I’d done my bit, another ‘artist’ scattered a few boxes on top of the models to represent houses, a scattering of trees, and job done — The result looked much like the Lander demo on the Acorn Archimedes in 1987.
As an afterthought, the generation of the houses became part of the program too, and then the trees and soon there were no artists involved in the process at all — just my system, churning out landscapes. The issue was the data being generated was getting too large for the storage of multiple maps.
If you know how generative art works, you can probably tell where I’m going with this: The solution was not to generate maps and store them within the simulation application — It was to include my generation code within the system and generate specific maps at runtime using a seed.
I found this solution so utterly fascinating, that it has become the backbone of everything I have done ever since.
Seeded procedural generation.
So, you need a corridors for your dungeon computer game?
My answer would be procedural generation.
You need pipes down the side of your sci-fi corridor?
Procedural generation.
You need cables hanging between your telegraph poles?
Procedural generation.
You need leaves and rubbish distributed around a 3D city streets?
Procedural generation.
You need a bunch of different UI targeting reticules?
Procedural generation. (Cypher anyone?)
This process of building tools quickly became my day-to-day, writing small programs that enabled ‘traditional’ artists to generate stuff based on a seed which they could then refine and dress and use to make assets for games or that we could recall at runtime using a seed.
A process known as Generative Design.
Happily, my day to day job became a combination of writing shaders, and developing useful generative systems to be used by ‘traditional’ 3D game artists.
Process
This ridiculously long-winded and tangential pre-amble essentially serves to explain that I arrived at a love of the technical process of predictable outcomes from random algorithmic systems before I knew what I wanted to make with them.
Years of my spare time has been spent generating 3D worlds to explore. One example being a 3D dungeon in Unity — not because the artist in me had a particular dungeon in mind, but more because I found the idea of playing god, and exploring architectural spaces I had generated so utterly compelling.
My process for Singularity (for example) — was not “I must realise this black hole image I have in my minds eye” it was a desire to experiment with a procedural system driven by symmetry and turbulence and this led to something that depicts forms like turbulent black holes, and along the way I developed several other algorithms which I channelled to depict other creation and destruction events (the second of which was Fusion)
The way in which I chose to make these systems more interesting is by always opting to work within the confines of circles — developing systems who’s outputs that are notably circular. This is a self-imposed restriction which I enjoy — many of the ideas I have for my artwork come directly as a result of this restriction.
A simple concept I use frequently, is manipulating simple two dimensional distance fields as this ties in very well with the circular restriction. The work itself often comes from answering simple questions in visual fashion.
To dramatically over-simplify:
Singularity “What happens if turbulence increases as as the system draws further from the origin?”
Fusion “What happens if I perturb a straight line more/less, as we draw further from the origin, then rotate the entire coordinate system incrementally?”
Totality “What happens if we visualise the distance between the normalised and non-normalised position at which we’re drawing?”
In short: I set out to explore an algorithm or a system first, I’ll then steer it’s development towards a circular motif and then begin to visualise it in the most engaging and interesting way I can find — but the initial driving force, comes not from the desire to visualise a particular form, but from the exploration of an algorithm, whether it solves a problem or not.
This was just a quick ramble (I’m not an essay-writer) but I’m always happy to answer questions: ht@distancefields.io
