"cloudy blobby", number 658332663
Black and white areas with unclearly defined edges wobbling to and fro, while individual pixels all over the image flicker on and off
I marked it as sensitive, because it's a bit flickery.
"column condensation", 2966027394
This one is bright blue on dark blue. A noisy image slowly turns into a collection of vertical columns, while glitchy portions travel upwards alongside or through them. Columns of two pixels wide release individual pixels upwards that attach to other areas in stair-like patterns. At the end, only a few pixels stay blinking.
"drying stripes", 3149341029
This one is in bright blue on dark blue again. An initially random image quickly splits into two regions of perfectly vertical stripes, which are either bright on even or on odd columns. The border between the two is amorphous and shrinks in a manner that seems to preserve horizontal and vertical edges, but anything diagonal "shrinks" towards the area's center.
"windy decay", number 3948850248
Patterns of white pixels flying from left to right, wrapping at the sides, pulling behind them a little glitchy trail, and decaying into individual bits that slowly disappear into the black background.
This one accidentally didn't end up in the "thread" i was making, so I posted it a second time …
I wrote the code to simulate and render them in #perl6 — there's two displays at the same time, one writes frames as PPM files to /tmp/frameXXXX.ppm and one displays them on the terminal using HALF BLOCK unicode characters and inverted display (because half blocks only have the lower being white and the upper being black, so to speak)
The calculation loop and each of the two display "frontends" all run on their own thread, with just a channel sending a "1" back and forth to signal to the other threads when they have finished. #perl6 made this really easy, and the current code can even be made simpler still.
I use PPM files because it's a tremendously simple format, literally just a whole bunch of numbers written in plain ASCII, and is supported by #ffmpeg.
Here's my commandline to generate the mp4 video files:
ffmpeg -y -r 33 -start_number 0 -i /tmp/frame%04d.ppm -pix_fmt yuv420p -vf scale=408:408:force_original_aspect_ratio=decrease,setsar=1 -sws_flags neighbor -c:v libx264 -preset veryslow -tune animation -profile:v baseline -crf 29 -r 33 -f mp4 drying_stripes.mp4
Explanations in the next toot
-y is there so that I don't have to manually say "yes, please overwrite the existing file"
both -r flags are for framerate
-start_number is probably not necessary
-i gives the filename pattern with syntax as understood by printf
-pix_fmt yuv420p is necessary because the default (maybe only for ppm?) is 444, which requires "advanced" h264 decoders on the receiving end, and twitter immediately rejects those files
-sws_flags neighbor makes sure pixels stay shark
-c:v sets the video codec to use
-vf scale=408:408:force_original_aspect_ratio=decrease,setsar=1 i basically stole this off the 'net, i think the aspect ratio one isn't needed here at all, but the first two numbers are the video dimensions (input files for this one were 102x102 pixels)
-preset veryslow just makes the encoder try a little harder to make the file smaller
-tune animation sets up a bunch of settings that make animations look better (they tend to have sharp edges and plain colors, whereas film doesn't tend to)
-profile:v baseline sets up the "baseline profile", which basically restricts features that are newer than the oldest devices that can handle h264 in hardware, or something like that? it's necessary for better compatibility in any case.
-crf 29 is a quality setting, the higher the number the lower the quality. I tried much higher numbers and got an actually bigger file for 40 than i got for 35. Though 40 is probably a nonsense value anyway.
-f mp4 sets the file ("container" format as mp4
"drying stripes with gaps", 3417940016
it's like drying stripes, but the vertical lines have a bunch of gaps in them!
@timotimo this is lovely what are you using to make these?
@timotimo oops nevermind I see the whole thread with all the information!
@wakest it's custom (but very simple) #perl6 code. It's a cellular automaton that takes every cell's value + the 4 neighbours up/down/right/left and the number, interpreted as a list of bits, tells which of the possible configurations of values in own and neighbour cells result in a 1 or 0 for the next round
Then on top of that, every cell has a 5% chance to just stay the same value for one frame.
It's very fun, and I'll make the code public soon-ish :)
@timotimo I am really interested in the patterns of Reaction/Diffusion. Have you played with them at all?
@wakest I have followed the stuff Tim Hutton made for a while (not sure if it was twitter or google+), and he's been doing a whole lot of cool reaction-diffusion stuff. He's working on a tool called "ready" and has been involved with golly, too.
I didn't actually make anything myself, though!
@wakest looking at tim hutton's stuff again reminded me he also worked on some Artificial Chemistry stuff, and there's a set of elements and rules that let you simulate a cell that has kind-of DNA in it that can split into two copies of itself, it's pretty rad!
@timotimo I was looking at stuff under their name since you posted it!
Follow friends and discover new ones. Publish anything you want: links, pictures, text, video. This server is run by the main developers of the Mastodon project. Everyone is welcome as long as you follow our code of conduct!