Colourblind

So I've been messing with fractals. More specifically Buddhabrots, which are an alternative approach to rendering the Mandelbrot set, care of the brain of Melinda Green.

Github repository

There are a few tweakable parameters you can pass in from the command line. Typically, increasing the maximum number of interations increases the level of detail and the amount of 'features' (for want of a better word) in the final image, and increasing the number of samples per pixel makes the final image smoother and less grainy. I probably didn't explain that too well. Your best bet is going to be to download it and have a play around.

The contrast of the final images is defined by some half-arsed finger-in-the-air divined voodoo-method algorithm. I wish I could say some craftiness went into it, but in reality it started from a point arrived at through rational thought and ended up somewhere completely different based on observation, random tweaks and guesswork. Manual genetic programming, I guess.

Since I can write my buffer to a PNG at any point in the process it seemed like a fairly natural progression to animate the whole shebang.

You won't find the animation stuff in the GitHub repository simply because it was unspeakably vile and hacky, but it should be simple enough to work out for yourself. The only change to the algorithm was to change the x loop so that it started at the extremes and ping-ponged back and forth, tending towards the centre of the area. So:

   1:  for (x = 0; x < samples; x ++)

   2:  {

   3:      for (y = 0; y < samples; y ++)

   4:      {

   5:          /* Do stuff */

   6:      }

   7:  }

becomes:

   1:  x = 0;

   2:  for (w = 0; w < samples; w ++)

   3:  {

   4:      for (y = 0; y < samples; y ++)

   5:      {

   6:          /* Do stuff */

   7:      }

   8:      

   9:      if (w % 2 == 0)

  10:          x += (samples - w);

  11:      else

  12:          x -= (samples - w);

  13:  }

This just means that the animation has an interesting ending, or you spend the last third watching very little happen as the columns to the far right of the region don't have much of an influence on the final result.

Every now and then I dabble with making my own screensavers. I was one of the 5 people who were shaking their fists in the direction of Redmond when it became apparent that the version of ScrnSave.dll packaged with Visual Studio 2008 depended on Vista. As is so often the case the last round when belly-up when I got distracted, magpie-like, by some other glittering object. I had quite a decent piece of boilerplate code I could use to reduce the spool-up time and get straight to the fun bit. I was considering tidying it up and opening the source. But then I stumbled across Cinder. I spent a few hours prodding around it, then promptly threw out all of my code because it's just so, so bad by comparison.

Curse you Cinder, you Magnificent Bastard

Cinder sell itself as library for 'creative coding' and it delivers in spades. It provides code for window creation, management and tedium, input, sound, loaders for a healthy selection of image formats and a wrapper for OpenGL which goes a decent way to alleviating the, uh, idiosyncrasies of the library. And it makes writing screensavers a breeze. It's even cross-platform enough to work on a Mac if you're that way inclined.

TTIUWP

As such I was able to knock off the following fairly quickly.

FillrateNomNomNom - a simple particle system

Churn - avoid when drunk

TimeForBedSaidZebedee - hierarchically organised spinning circles

Cubesplosion - Cubes that subdivide and scatter

But yeah, I'm pretty happy with how it came out. They're all very much work in progress and I'm not finished yet. This kind of thing is like code doodling for me. I love it. Expect more in the future.

Yoink

Source on github
Download the binaries

Due to the aforementioned VS2008 ScrnSave.dll SNAFU, there are different binaries for XP and Vista/Win7. Likewise if you download the source you'll find several different build targets: standalone app, XP screensaver and Win7 screensaver, with debug and release for each. Build configurations galore.

And as a passing thought: I wonder how it would work as a game library? It removes a lot of the bullshit (windowing, input, sound, resource loading, message pump) that can be a hindrance when starting out, while still allowing you to get low-level with the fun bits (graphics, game logic, physics). I'd have a crack myself if I wasn't working on my own game library already (STOP TAKING MY LUNCH MONEY, CINDER).

I've always had an interest in new and curious methods of visualising data. As a fully paid-up member of the geek fraternity I am required to read xkcd or they'd take my membership card away, and the episodes that really tickle my fancy are the ones that show information in fascinating ways. Since I'm still dabbling with Python in my spare time and I know my way around OpenGL already, I thought I'd try my hand at some visualisation apps.

To begin with I need some data. Subversion logs provide a rich seam of information:

svn log --xml -v [directory] > log.xml

That gives us quite a few properties to present to the user. I decided to graph revision against each object in the repository (either a file or a directory), but instead of slapping it on some boring old orthogonal axes I decided to go radial and then make it garish. That's just the way I roll. So, each 'spoke' on the wheel represents a file or directory in the repository. The files are sorted alphabetically, starting at the top and continuing clockwise. The centre of the wheel is revision 0 and the outside is the last revision found in the log file. Each of the change to that file would be represented by a white blob. But enough description.

You can run the code using:

python svnwheel.py log.xml

And yea, this will result in eye-candy.

Compares Favourably revision 45

This very blogging system

Track and zoom

In terms of practicality it ranks somewhere between a chocolate fireguard and a solar powered torch, but I like it. While I'm sure it will only keep me distracted long enough for the next technological muse to get her claws in it makes for some fun new stuff to learn, I imagine I'll come back and add different visualisations at some point in the future. Something with animation, perhaps.

Anyway, if you want to have a look at the source yourself the project is on github:

http://github.com/colourblind/define_irony

Left-click and drag moves the viewport and right-click and drag will zoom in and out. To reset the view at any time just hit 'r'. Windowing and OpenGL is provided by pyglet and apart from that it's pretty straight-forward. This also represents my first foray into git. The over-powering smugness of the git community had me heading towards Mercurial, but I figured that there's so much good stuff on github these days that I'd need it installed anyway. Curse you, network effect!

While surfing the intertubes recently I came across a link to allrgb (it was probably through proggit). The concept is simple and delicious, like good pasta. A 4096 by 4096 image with one pixel of each colour it is possible to represent in 24 bits - all 16,777,216 of them.

I like me a bit of eye-candy, and I'm enjoying the Python at the moment (after the brief false start), so I saw this as a good excuse to get my script on.

You can click on any of the below for a larger image. And when I say large I mean large. Only click on any of the below if you really, really mean it. The average image size is around 30MB.

If you've got an algorithmic eye you can probably infer what's being done in each of the examples above. To be honest all of this is pretty underwhelming compared to some of the submitted images. There's some frankly amazing stuff over there, and they've been getting progressively more awesome. Back before it became popular it was all nested loops, and I can follow it pretty easily. The best-fit image matching stuff I could have a stab at some algorithms. I even know what a Hilbert Curve is. But now? Now it just makes me feel uneducated. I have no idea what simulated annealing is, but it sure makes pretty pictures.

Anyhoo, here's the source used to generate my paltry efforts above. PNG functionality is provided by the sultry PyPNG, and apart from that there's nothing particularly special going on. I am still very much starting out, so this was a good way of cutting my teeth.

ZIP containing all the relevant bits

Caveat: The memory usage can get a little crazy. With 4GB in Windows 7 I have no problems. With 2GB in Windows XP there was some slight wackiness (where 'slight wackiness' can mean anything from heavy slowdown to so-boned-you-need-to-hard-reset). I got better results using arrays (which I understand are wrappers around C arrays, so pack a lot smaller) but left the code on another machine. Whoops. Also, I don't know what I'm doing in Python - so don't use this as an example of how to do it. As usual, The Disclaimer applies.

Increasingly traditional random link: Egads. If this isn't a harbinger of the eschaton then I don't know what is.

So the plan was it open this weblog with a deep and illuminating post. Something .NETty and architectural in nature. But then I got distracted by shiny things and so instead I bring you something completely different: silly baubles.

The <canvas> element is introduced in HTML 5 and has a very simple premise: it gives you a surface you can draw to on the client side using Javascript. Slinging one of these into your HTML is easy enough.

<canvas id="MainCanvas" width="300" height="300" />

But of course the fun really starts outside the markup, where the wild things are.

var canvas = document.getElementById('MainCanvas');
var context = canvas.getContext('2d');

The canvas object is the access to the canvas element in the DOM, and does little else beyond exposing the attributes of the canvas tag. The fun really starts when you get your grubby little mits on the context. You get some simple vector drawing functions, allowing you to draw lines, rectangles, arcs, and bezier curves if you're nasty, along with a series of fill options such as gradient and patterns. I'll not go into the details because I can't be bothered and you can just look it up here. Time for shinys!

Balls . . . heh heh

I love particle systems to an almost unhealthy degree so here's a load of bouncing balls. I was going to make this a lot more involved in terms of using the features of canvas, but then I got distracted by mechanics and took a sharp left at the junction of Newton and Collision Response and ended up in the bad side of town where the physicists hang out. Dang.

So yeah, not a lot to be said for this one. It's mostly badly faked collision model and you could actually do this in non-canvas, venerable DHTML really easily. This one is mostly an exercise in how to set up the animation using setInterval and the like.

The only real thing of some note in here is some cheap motion blur. Rather than clear the frame every time I'm simply drawing over the entire canvas with a rectangle that's the same colour as the background but with a low alpha (or opacity, if that terminology seems more familiar to you.) This will work fine unless you're using the draw order to depth-cue your objects (if you need an object to look like it's 'behind' another by drawing the further object before the nearer one).

This second one is a lot more feature-filled, since it touches on transformations and the transformation stack and patterns and multiple canvas and alpha blending and stuff.

First the blocky image is drawn into a canvas, and a pattern is created from it. This can then be passed into the fillStyle property of the context and will be tiled across any filled object you want to render. In this case a BIG DAMN SQUARE, because I'm interesting like that.

Also on this one you can see an example of transformations. The transformation are cumulative and non-associative - so a rotation of X followed by a translation of Y is not the same as a translation of Y followed by a rotation of X. A transformation stack is available and the concept will be familiar to anyone whose has used a graphics API in the past. If you can't see a use for one then I wouldn't sweat it at the moment. Suffice to say that the stack allows you to save the current set of transformations, and retrieve them again to roll the transformation back to a previous state.

So what?

It's a valid question.

Canvas is interesting stuff, but one thing it's not is a 'Flash killer'. Flash's strength lies in its animations and its vector drawing, whereas canvas will only give you the most primitive of primitives. (it's got support for the Javascript Image object, but that's hardly the same thing.) Oh, at some point some crazy awesome loon with too much time on their hands will create some magical things with it - because we're geeks and we're prone to do crap like that, but it's a poor fit for any real drawing or animation work. Odd little games are fun and all but it's always a shame to have something this slick and not have an excuse to use it at work. Maybe I'm being horrifically myopic (it wouldn't be the first time,) but I am struggling to think of practical things to do with it besides dynamic graphs. It's a Monday though, and I've had no bourbon, so I'm not feeling too creative.

But there could well be more - the astute among you will have noticed that we're passing an argument to the getContext call. The fact that you have to ask for '2d' now implies that '3d' may be available later. It's not part of the spec, but that hasn't stopped people running with it. Firefox currently has an extension that ties to OpenGL ES 2.0 (shaders and everything!) and Opera has included their own take on the 3D canvas natively. Could well be an interesting time for browser games in the next couple of years.

Finally, if you want to see some genuinely dazzling work in this realm, one doyen I was introduced to on my travels is Mathieu 'P01' Henri, who can make Javascript dance like Fred Astaire on a hot plate. You should really do yourself a favour and have a look.

Generic arse-covering: The code itself is probably not great. I know enough Javascript to get by but have no idea, for example, how much overhead is associated with creating objects via literal notation inside a loop. Also some of it is just plain, common-or-garden laziness. There's no checks for divide-by-zeros and there's bound to be other things I haven't tested thoroughly. It illustrates the point though. As always, use at your own risk and don't treat is the paragon of Javascript or anything.