New work in progress: “Recursive Polygon”. Also a working title, but they usually stick.
With generative graphics there is a moment that confirms the idea has some legs.
Most ideas actually never reach this moment. As the algorithm grows from dreamed visuals through to realised code, and the blurry region between, in early stages an algorithm often shares little similarity with the vision in the mind’s eye. A careful balance between persistence and vision is needed; persistence is needed to push through early failures and vision to realise when the idea or the particular approach is actually a lost cause.
Very timely feedback as this feature actually was hovering right near the summit of next up on the hot priority list of must do. The todo list is extensive.
The task was to create a preview of a chosen design on a chosen product.
To achieve this a few problems had to be solved. There are thousands of images, each of which has to have a defined printing zone… see the red zone below. For each image this zone is potentially different. Additionally, since it is a live API that is out of my control, new images could show up at any time. A system is required to easily define all the existing items’ printing zones, and accommodate new items and their respective printing zones.
The preliminary challenge in making FunkyVector was sourcing a printing solution, the whole project would never have been embarked upon if there was no suitable provider for API driven printing on demand. There are a number of options out there, but FunkyVector uses Printful for all print fulfilment. Their API makes it very easy to get started and is easy to work with. Unfortunately the API presents some holes, particularly for customers who might be dynamically generating artwork, which is the premise of FunkyVector. The missing information relates to ideal print resolutions required per product, and relative or absolute coordinates defining the positioning of the printable area on each product.
To render a mockup on screen, these holes would have to be filled with some data, in this case, my estimates.
The major problem was the sheer number of products (shirts, mugs, hoodies, etc.) available, within these, product variants (colour), and within these, sizes (S, M, L, XL, etc.).
I set on the task of making a tool running in a browser which incorporated a loader and a parser for consuming the API, and a makeshift editor for specifying the printable zones.
After a technically gorgeous load of all the products (read: iterating through the products API, nested ajax calls and the like) the possible product images were added to the DOM. Quite a few, coming in at more than four thousand!
As assumed, there were some duplicates: different product variants were sharing the same image. These would share the same coordinates, so a lookup table was created to inform the FunkyVector app of the relevant product’s mockup position. After removing these, there were 866 images.
The total number of images was still too great. Duplicates were easy to discover, they shared the same filename, but perhaps some images were visually identical whilst having different filenames, I ignored these for the moment. However, some images might be visually similar enough to share coordinates. Further optimisation was possible by identifying these similarities, and grouping these products together. Bring in canvas context’s globalCompositeOperation property. By setting this to “darken” and drawing all of a product’s variants to one canvas, I could eyeball the amount of variation of images within a variant range. For images that looked quite clear (e.g. bottom right image) it was obvious that one set of coordinates would do. For images that were more blurry (e.g. top left) it may be necessary to define coordinates separately. In many cases products shared no likeness between their images.
The final editor allowed me to:
toggle “share” mode (whether variants share coordinates or not),
draw the coordinates on each variant (define the printing zone),
export the data to JSON (make the data available to the main application).
You can see 1 and 2 in operation below:
And 3? Well, it’s quite a large wad of JSON, here’s an excerpt:
Back to the print fulfiller. I recommend Printful for their overall product. Their website, customer support, print quality, materials and delivery are all great. Their API is also good, but small things, including the subject of this post, would be awesome if solved and exposed to customers.
Hey Printful, do you want to use this data? I’d be happy to help out.
And a final image from the process. Apologies to the models and their parents, many other evil beasts emerged whilst working on this tool.
Funkyvector is an application that creates unique algorithmically generated graphics in a web browser at screen resolution that are reproduced on a server at print resolution for production.
Let’s break that down.
An “application” is simply a piece of software. The advent of the smartphone made the “app” all hip and accessible, but the savvy amongst us know that applications have been around for ages, such as Microsoft Office or Paint. Nowadays, and for quite a number of years, applications can be created to run in a web browser; websites like Gmail or Facebook are apps in their own right.
“Unique” means just that, more on this later.
“Algorithmically generated” means the images are created with mathematics. FunkyVector initially had the illustrious working title of “The infinite print project”, indeed it is still referred to as such. Since the graphics are generated with maths, each algorithm (and there are many algorithms with their own stylised output) can create an infinite set of permutations, with the end goal being a printable graphic. Hence infinite print!
The funkyvector.com domain had been used for various graphical experiments, but it wasn’t until late 2014 when a friend suggested that a reproducible version of these experiments be made using a seeded random, that the seed was sown. The content on said domain was replaced with the infinite print project.
“Graphics in a web browser at screen resolution” basically refers to images as you would see on any website, except on FunkyVector they are created using a canvas (a type of image that can be altered with code). Screen resolution means the images are created rather small (2000 pixels squared currently) so they render fast whilst remaining crisp and pleasing to the eye.
Being “reproduced on a server at print resolution” is the cool part of this project! FunkyVector renders any image generated in the web browser app on a server (another computer in a far away galaxy) using node and node-canvas. This means the image can be rendered at any size theoretically (10000 pixels squared currently). The server render is “pixel perfect” to the browser render – no it’s not actually, the pixels don’t match up since the resolutions differ, but since the canvas images are drawn with the canvas API which effectively consist of vector commands, the images are identical ignoring scale. In this case “pixel perfect” is actually “picture perfect” if you will, in so much as the human eye can not discern the difference.
And finally, “for production” is the icing on this funky cake; should you demand it, these pixels will arrive at your front door in around 30 days time, permanently printed on a t-shirt, poster or bag! A few clicks, some delivery details, some payment info, and a “unique” image shows up in the real world as a “unique” product.
That term “unique” again. So what is unique? It is risky describing any art as unique, but in this context it refers to mathematically unique. FunkyVector creates each image using a random seed. The possible range of seeds are large enough, that it creates a probability small enough, that for all intents and purposes, no one ever on this planet will see, let alone print, a design that you choose to print.
All up, it took a year to get to a working version, and longer to be satisfied enough to write this post. Into the nitty gritty: another post will be coming soon with a brief explanation of how FunkyVector was made.