Let's sort colours!
You may also scoot over to https://www.openprocessing.org/sketch/586588 to see it in full HD action without the compression that comes along with .gifs. Once you are done over there, come back, and I'll try to explain the what, why and how.
What?
All of this is about sorting colours. What does this mean? While the idea is simple, the method is a bit more complicated. So let's just start with the idea.
We start out with a boring picture like:
Which you might recognise as simply being three layers of Perlin noise controlling Hue, Saturation and Brightness respectively.
Then, throughout about a million steps, we start sorting colours. We pick a random point on the screen and then a channel - red, green or blue. If we choose red, for instance, we compare the pixel with its neighbour to the right. If it is redder than its neighbour, we make the two switch places. This means that red pixels generally move right.
If we instead chose the green channel, we will not look right, but downwards. If the our pixel is more green than the one below, we switch places, so green pixels moves downwards.
Continuing this, we will get a neat, boring gradient from dark in the top left to yellow in the bottom right. But also, continuing this, what do we do with blue? We have already exhausted the x- and y-dimensions for red and green respectively. We could compare the pixel with its neighbour to the left, but then a purple pixel will want to move both right AND left, which is just a mess.
Or maybe that is what we want. Gradients are boring after all. Messes are more interesting.
Why?
I was doing some experimentations along these lines when I generated this series of images:
First the pixels start moving in the direction they are urged to, this makes sense. The sandy colours move upwards, the purple down, and the dark towards the bottom right corner. Most parts are not solid yet, though.
But here, we see something interesting. While the pixels are not done sorting, they still have formed a solid shape, which right now looks almost human.
Of course, later on, a more stable form has been reached. While this picture is kind of interesting too, it is too sorted. It would do us better to catch the pixels as they still are figuring themselves out, where strange, temporary structures emerge.
So why should we use colour sorting to generate pictures? It has several useful features that we can use. The first is, as explained above, that they create layers and sometimes shape structures. Procedural structures, that is. Nobody could have guessed they would turn out this way. These shapes are completely spontanously put together, also known as emergence.
The other is that they create gradients. Kind of obviously. But it is still a useful ability if we are to create interesting images with colour depth.
While here I am gloating and showing off the very best results, most often, this simple three-rule, three-channel approach does not create anything quite as interesting. So how do we go on to make something more reliably interesting?
How?
This is where the finer points of the method comes in. I have gone back to just doing two comparisons - right/left and up/down. However, the comparisons take into account all three colour channels with some custom rules.
The channels are combined by first multiplying each with a value generated from Perlin noise - of course Perlin noise would come to figure again. That means in one area of the map, perhaps blue pixels are sorted leftwards, and in another, rightwards. Between them, they are seperated by another current moving some pixels up, others down. And so forth.
Is this method good? I couldn't say. I am not smart enough - nobody is smart enough - to predict the emergent behaviours of random sorting of pixels within a random space. All that one can do is to look at the results:
And the results lead to me being impressed.
All in all, some quite complex structures are made from some simple rules, and isn't that what procedural generation is all about? Comparing this to my Convolutional Art Generator, maybe the pictures are not as sophisticated, but this also took one thousandth the time, and I can actually explain how this works.
Again, if you want to take a look at the generator yourself, here you are: https://www.openprocessing.org/sketch/586588
You may also scoot over to https://www.openprocessing.org/sketch/586588 to see it in full HD action without the compression that comes along with .gifs. Once you are done over there, come back, and I'll try to explain the what, why and how.
What?
All of this is about sorting colours. What does this mean? While the idea is simple, the method is a bit more complicated. So let's just start with the idea.
We start out with a boring picture like:
Which you might recognise as simply being three layers of Perlin noise controlling Hue, Saturation and Brightness respectively.
Then, throughout about a million steps, we start sorting colours. We pick a random point on the screen and then a channel - red, green or blue. If we choose red, for instance, we compare the pixel with its neighbour to the right. If it is redder than its neighbour, we make the two switch places. This means that red pixels generally move right.
If we instead chose the green channel, we will not look right, but downwards. If the our pixel is more green than the one below, we switch places, so green pixels moves downwards.
Continuing this, we will get a neat, boring gradient from dark in the top left to yellow in the bottom right. But also, continuing this, what do we do with blue? We have already exhausted the x- and y-dimensions for red and green respectively. We could compare the pixel with its neighbour to the left, but then a purple pixel will want to move both right AND left, which is just a mess.
Or maybe that is what we want. Gradients are boring after all. Messes are more interesting.
Why?
I was doing some experimentations along these lines when I generated this series of images:
So why should we use colour sorting to generate pictures? It has several useful features that we can use. The first is, as explained above, that they create layers and sometimes shape structures. Procedural structures, that is. Nobody could have guessed they would turn out this way. These shapes are completely spontanously put together, also known as emergence.
The other is that they create gradients. Kind of obviously. But it is still a useful ability if we are to create interesting images with colour depth.
While here I am gloating and showing off the very best results, most often, this simple three-rule, three-channel approach does not create anything quite as interesting. So how do we go on to make something more reliably interesting?
How?
This is where the finer points of the method comes in. I have gone back to just doing two comparisons - right/left and up/down. However, the comparisons take into account all three colour channels with some custom rules.
The channels are combined by first multiplying each with a value generated from Perlin noise - of course Perlin noise would come to figure again. That means in one area of the map, perhaps blue pixels are sorted leftwards, and in another, rightwards. Between them, they are seperated by another current moving some pixels up, others down. And so forth.
Is this method good? I couldn't say. I am not smart enough - nobody is smart enough - to predict the emergent behaviours of random sorting of pixels within a random space. All that one can do is to look at the results:
And the results lead to me being impressed.
All in all, some quite complex structures are made from some simple rules, and isn't that what procedural generation is all about? Comparing this to my Convolutional Art Generator, maybe the pictures are not as sophisticated, but this also took one thousandth the time, and I can actually explain how this works.
Again, if you want to take a look at the generator yourself, here you are: https://www.openprocessing.org/sketch/586588
Comments
Post a Comment