Hello and welcome to my talk. My name is Prasav, and today I'm going to talk about a different side of the could language, one that will hopefully inspire you to search for the artist within yourselves. While preparing for this talk, I thought a lot about how to approach the subject. I could just sit and talk about art theory for hours, but no one would stay here and listen. I could also just dive straight into coding. That wouldn't make it quite either. Beyond the basics, much of the real creative work is just sitting alone and trying things for hours, failing and trying again and over and over and over again, trying different things, until they suddenly click. So I figure I could just tell a story instead, one that approaches the subject through the prism of my own experience. A story that, interestingly enough, starts at the end. At the end of our story, there has a book, an actually different kind of book. It had none of the usual suspects in it. There would be no web servers, that there would be no networks, no containers even. The book wasn't even supposed to teach the goal language. Instead, it was more meant to inspire people to try new things. Interestingly enough, it was also the first quote unquote product that I released after jumping into the unknown waters of solopreneurship at the start of this year. And yet, this book is only a byproduct of a long journey. Therefore, it's the journey that the rest of the story will focus upon. It's a story about finding new sources of inspiration, about picking up the goal language later in my career, and last but not least, about rediscovering the joy of programming through the language. My story with graphics began in the early 2000s. Like many kids at the time, I also wanted to make video games. So I started with can Pascal, but quickly realized that those weren't really helping me make the flashy stuff as fast as I wanted. So somewhere around that time, a new language called processing appeared. It caught my attention, and I immediately started playing with it. Processing was born at MIT. It wasn't meant so much targeting professional programmers, but more towards non experts, especially people with an artistic background. This was really the first time that I saw a language that was meant two really help people deal with graphics and such. So processing took the basics of Java, but it really simplified them. It also came with a really nice library that was helping people to work with graphics. Many of the processing works would occupy just a single file. They were called sketches at the time, and one of them would look something like this. So actually, this sketch on the left is one of the first sketches that I wrote in processing, and later on, it was the one that actually inspired me to write the book. As you can see, there's really nothing too complex and fancy about those sketches. It's essentially just a few lines of code that would, at the beginning, would just a nice color palette from a source image, and then would use those colors to basically randomly spread rectangles around in various degrees of opacity. And this would create this nice sort of overlay effect. But most of the processing sketches are something like that. They're quite simple. My obsession with the language even met me later on with one of the forefathers of the computer graphics field, the german guy called fidanaki. I was a student of his during my masters, and it was about that time when I really started reading more deeply about the philosophy behind those randomly scattered squiggly lines. But in a typical fashion, life took over, so I had to move on with it. I jumped out of university, and I made the career as a Java developer. It was about until late 2018 when I was introduced to go as actually a part of a job switch. This was a pivotal moment, and probably one of the few moments that was going to define my future trajectory. I has so hooked up on the simplistic nature of the language that I started using it for other things. Has. Well, at some point, I figured I could just grab my old processing sketches and translate them two go, would that work? And the answer is yes. And as people say, the rest was just history. One thing led to another. But how does generative art really relate? Two law. To go into that, I will first have two define what generative art really is. And that's a difficult subject by itself, because you're probably about to find as many definitions of generative art as there are people dealing with it. And of course, none of them would fit the context of the goal image. So I had to come up with my own explanation. Allow me to share it with you. Generative heart is a balance between procedure and randomness. It's the result of simple steps multiplied many times over a complex organism of tiny actors interacting sequentially and concurrently with one another. Think about it. A lot of this actually applies to go, doesn't it? Actually a fun fact, this animation on the right was completely made with the goal language. I think it really exemplifies what I mean with this definition. It's a bunch of tiny actors, each of them taking simple and seemingly random steps. But in a combination, these lead two the breeding of new behavior, of complex behaviors. And this is one of the postulates of generative art as well. It's like you don't have to write complex code to achieve complexity. You just have to write simple things and multiply them over and over and over again, stepping on the product of the previous step, essentially. All right, let's look at some of the basic building blocks that the go standard library provides as well. As is usual for the go language, you're provided with only a bare set of basics. However, these basics are so well designed as it is usual for the language, we're provided with only a bare set of basics. In fact, most of the code types can really fit on one slide. It's just these three interfaces that you see on this slide that you need two know about, and you can pretty much say that you know most of the graphics fundamentals provided by the go standard library. Those basics are extremely well designed. They hold a minimum set of requirements, and that's it. For a type to qualify as an image, for example, it only needs to implement three simple methods, the same for the color you can think of. Those has essentially as the reader and the writer interfaces of the graphics domain. It's really this idea of composability and swapping that makes this whole thing so easy and so interesting. As we'll see later, this allows for other libraries to build up on those basics. All right, let's look at one example. I think there's no better way to speak about composition than the concept of image filters. A filter can be an image too, wrapping its source in itself. If we implement all the methods that satisfy the image interface, we could then use our filter in any other place that accepts an image. Another example, cutting a circle out of an image. I think this was actually featured in the Go documentation tool. Again, we can achieve the same effect by wrapping can existing source and telling it how to render each pixel. Unlike the previous example, here we selectively play with the opacity of the pixels and not just the color hue and saturation. So in a way, we achieve the creating of the circle by saying any pixel that's not in the circumference of the circle will have an opacity of zero, essentially meaning that it will be completely transparent. This leads to the perfect circular cutout we can see on the right hand side. Implementing all of those things by ourselves will be an overkill. Thankfully, there is a number of great libraries out there that provide us with what we need. Thanks to the composability and lack of deep abstractions. Those are also extremely easy to integrate or learn from. I could say perhaps one of the most widely used libraries when it comes to drawing 2d graphics in Go is called GG, and it's really simple to use. It's one of the main libraries that also feature in my book, and it's been essentially an indispensable tool in my work ever since I started working with graphics and go. What I really like about it is the fact that it has the same procedural API and look and feel of many of the functions that exist in the processing programming language. So those who have played with it would expect to find the same basic primitives to work with, essentially shapes and rectangles and fonts and basic image filters and such. It's extremely useful, and I can totally recommend using it. All right, before we go into a short demo session, here are a couple of notable mentions that didn't make it into this talk. The first one is webassembly. It's something that I've dedicated the whole bonus chapter and part of my book, and it's something that I would definitely want to expand further upon, and we might have a slight chance to see this into the demo. Although I'm not going two go into the code, I'm still going to show you how webassembly can be useful in producing graphics generators for the web. For example, the second thing is genetic algorithms. It's something that I'm currently working on, and it will definitely be one of my sources for future content for expansions of the book, and why not future topics for talks. So definitely expect to see more to come in the next year or so. And the third one is a book recommendation. I have to say it's one of the few books that I would definitely recommend for people wanting to start with graphics engineering programming ego. The book is called the Nature of Code by Daniel Shipman, and it's actually about processing, but it's so well written and so easy to follow that many of the things would be easily sort of transferable and applicable to go. And I should say there are a lot of interesting concepts going back to math and statistics and sort of different fields also, like talking about different aspects of the graphics and art. So definitely something to check out. All right, so the next portion of this talk will be a demo session in which I'm going to show one of my early sketches, and in parallel I wanted to demonstrate how go applications can be compiled to webassembly and drive interactive applications on the web. Let's jump right in. One of the subjects that I at least wanted to show in the demo. Unfortunately, it's quite a complex topic of its own, so I'm not going to be able to talk so much in detail about it is the compiling of go applications to webassembly and using them inside a web browser. So at least I wanted to show how I took one of my sketches and basically put it inside of a website. So what this website here, and this is the URL, what this website here does is it allows anyone to just go there and generate graphics, basically randomly generated graphics of their own. So I can definitely advise anyone to just go there and try it. It's completely live and I will make sure to put all the relevant URLs and addresses inside of the slides. So without further ado, I just wanted to start rendering and in parallel move to my other demo because this might take a little bit of time. Right. Okay. Loaded the wasm file and it starts drawing. So we could be able to see some results in a couple of, not more than a couple of minutes. In the meantime, I wanted to switch to a very simple sample sketch. It's actually the sketch that I'm speaking about in my book, and as one can see, setting up the whole sketch and the sketch itself, they're not really complex. They shouldn't be complex at all. Actually, I just wanted to show you a sample output of the sketch. So this is what it's supposed to render. It's essentially a reinterpretation of the processing sketch that you saw above, but with a little bit of addition. And since I actually like playing with random color palettes most of the time, I don't even start with predefined images of my own, but actually source random images from the Internet. And one of the things that I wanted to show you is how I do that. Not many people know, but the popular image sharing service unsplash, it has an API and it allows people to essentially go there and say, give me a random image. In our case, we don't even want to book at it, we just want to use it as a color palette source. Then once we have this image, we essentially create a sketch, and I will go in a couple of seconds into what this sketch entails. We give it a bunch of parameters, which I totally understand that not everyone will really understand what they mean. Sometimes I don't either. These are just meant to essentially drive the generation of every next step of every next iteration. So as you can see there, some of them will stay the same throughout the whole destination width, destination height, or others are essentially what the initial alpha of the rendering is, and minimum edge count and maximum edge count of the polygons that we're drawing and stuff like that. So with that done, what we do essentially is we go through a bunch of iterations. That's one of the things that make generative art what it is. It's essentially a bunch of iterations on top of simple steps. And on every iteration, we call the sketch update, the sketches update method. So let's take a quick look into the sketch itself. Again, super procedural. Nothing too fancy, nothing too complex. It's setting up a canvas under the hood using the library that I mentioned, Gg. It's extremely helpful for allowing us to set those things and draw primitives on top and mix and match with varying opacities and stuff like that. It's extremely simple and nice to start with. And then the actual update method is also not super computer. What's happening is unlike we draw a random pixel from source, transpose it over to the destination using this super complex, super complex formula of just finding the corresponding pixel into the destination and essentially saying, draw a polygon depending on the configuration, with a certain number of edges at this location. To make things even more interesting, I added these two parameters. So one is like this stroke inversion threshold, which says well beyond a certain size, since these polygons are expected to get smaller and smaller over time, start adding something like a border, so that the smaller the polygons are, the more sketchy they look like. So it looks like a graphic. So one is this, and the other is basically the one that's called stroke jitter. Again, something that I invented. It's completely up to the people who create the sketch to come up with naming conventions that sort of mean something to them. So the stroke jitter will just say, we don't want this particular color to appear in that exact spot based on the source. You can just as well add a little bit of a randomness to it. And that's what this stroke jitter will do. It just go through, we'll just say, take the pixel and give it a varying amount of distance from the original source. And yeah, on every iteration, we'll make sure to reduce the stroke size, and we'll also increase the alpha so that we create this sort of effect of reducing the polygon size. And at the same time, I'll just explain it as building up or sort of a kept effect of the drawing. So without further ado, I'll just say, let's go and try it. And as I was saying, based on the fact that it loads a completely random image, I have no clue what the actual output will look like. So this will be a bit of a surprise for me too. One thing you'll notice is that the smaller the polygons, respectively, the smaller the brushes at the end. It will get progressively faster and faster until eventually just finishes in a couple of milliseconds. So let's see the output. All right. Completely different image. Not sure if you like it or not. A bit dark to my taste. Maybe we'll just, you know, we'll just generate another one, but it will basically follow the same pattern image. Few more iterations and beyond the thousand, it will speed up. And there we go. Black and white. Interesting. All right, now let's switch back to the browser and see what we've. Okay, this is a new sketch. It's based on a concept called Perla Noise. It's very well explained in the Daniel Schiffman book, and it's something that I want to definitely emphasize more on in future talks and in future chapters of the book. So, as you can see, this one is also quite nice. And essentially, this sketch follows a similar approach in that it will etc. A sort of a random image from the Internet, and we'll use it as a color palette, but instead of randomly distributing polygons and triangles and whatnot, it will just use a concept called perlin noise to imitate randomly scattered brushes. So, yeah, again, this looks quite nice to me, but I leave it to the interpretation of the viewer at the end. So, yeah, with this beautiful picture, I just wanted to say thank you once again for choosing my talk today and definitely looking forward to seeing more and more people taking the goal language for a spin and seeing what else could be done with it beyond the usual aspects of its application. Thank you.