Posts tagged ‘algorithms’

Collection of Processing.org hacks

Its been quite a while since I last posted anything.

That doesn’t mean that i haven’t been coding small hacks, just that i haven’t posted them. But now is probably a good time to show some of the stuff.

As the title suggest it has something to do with processing.org. I have been using processing on and off for some time. Its is really nice when you want to make a quick hack, or as its called in processing a “sketch”.

In no particular order here is some of the fun stuff made using processing.

General remarks

The following sketches and their sourcecode have served as small hacks, hence don’t expect nice comments or optimal algorithms…

shrinkImage

It is possible to remove the line from a picture representing the least amount of information. The algorithm evaluates every pixels “weight” as the absolute difference between the different color channels (r,g,b). And then finds the “lightest path” from the bottom to the top.

This means that “prominent features” won’t be removed or change size when shrinking the image. Here the definition of “prominent features” is high difference in colors between the neighboring pixels.

Have a look at shrinkImage

Room for optimizations :

Eventhough its quite quick at calculating the weights and finding the lightest path, it does so in every iteration. Letting it use a bit more memory and just recalculate the changes when removing a line should speed it up. I found a huge speedup when just having an array with the weights from the last and current line, when calculation the path, so not only would saving all weights require a bit more memory it would also slow down the first calculation. But I’m sure it would give a significant speed up in the next iterations, and a lot of +-1 frustrations ūüėČ

helloFoo

There a some quick getting to know processing hacks, this is one off the. helloFoo

One of the very cool things about processing is the ability to use openGL, so originally this sketch uses openGL. But applets and openGL isn’t exactly the best combination. It can be done, but since it doesn’t work for me (firefox, linux openJDK JRE) i just converted it to standard java graphics. And the effort required to do this, is remove an import and don’t say setup(400,400, OPENGL) but just setup(400,400). This is trivially true the other way around. If you want to use openGL its quite easy.

The sketch is just bouncing balls, when going away from openGL I reduced the size and number of balls, in order to get a decent animation speed.

FooIII

Again used openGl originally FooIII

Some satellites rotating around some satellites rotating around some ….

sndHello

yes sketches tend to have silly names : sndHello

From Clifford Pickovers  book : Computers, Pattern, Chaos, and Beauty Рgraphics from an unseen world (p 39 section 4.3 snowflakes from   sound)
Draw symmetrically and in “polar form” the¬†fft of the sound, hence creating snowflakes based on the sound.
Music by David Rovics
Choppy sound I had some problems with the sound when run as an applet. You might have better luck using the jar directly or by downloading the sourcecode and running it with processing

Slit-scanning

The former applet relied on an external library for the sound, ther are quite a few libraries available. I did use GSvideo to hook up my crappy webcam and do some video effects. I experimented with slit-scanning in different ways.Unfortunately this won’t run as an applet and it might only run on Linux.

By creating a cube of the images, where the z-axis represents time, its possible to play back different parts of the movie from different layers in time. Which makes for some quite interesting and dizzing effects.

For example a time buble where playback is delayed around a “bulge in the timespace continuum” :s (a video of some guy playing with it (timebuble1.avi) some sourcecode for a similar effect where the mouse pointer moves the buble (TimeCube.pde) another more “traditional slitscan” (CamWarpTime.pde) .

In general there is plenty of room to fiddle with the code, there a functions like selectSlice or initQueues where its decided how to slice time. its great fun to play with..

xonix mobile edition

Having toyed around with J2ME for the freeVibes, I got a bit hooked on coding for the mobile phone.

So I started to recreate the classic oldskool game Xonix, it’s a game I really like. So simple and addictive. It’s not the first time I’m coding it, I have made it as an applet about a year ago (Xonix applet). As well as being a fun game to play I find it a fun game to code too. Though I have had my share of frustrations. The basic functionality is a fillalgorithm, that has to fill an area on both sides of the line / trail you make with the ‘pilot’. This has to be fast and efficient – nobody likes a game where you have to wait for updates.

xonix screenshot

Continue reading ‘xonix mobile edition’ »

Java Rippel applet

ripple apple screenshot

I had been messing around with creating a platform for experimenting with extended rules for “life-like-automata”, and although the code seemed to work just allright. I was horrible slow at rendering, and I decided that the next step were to optimize the rendering / drawing.

Well one thing lead to another – and i decided to make a small applet, were the drawing routines were optimized. Using a bufferedImage and setting the pixels one by one. And then I found this cool algorithm, for 2d water (Link).

It simulates water rippling, by using to buffer arrays with heights, and using them to calculate the speed and hence the distribution of ripples. There are a nice description of the algorithm at the link mentioned above. The short story is that you get an heightmap, and are able to calculate the next iteration of heights using the last height map, then you switch the buffers and repeat the procedure. And in between you render the heightmap. Unfortunately I’m not familiar with any algorithms for shading an refraction, so i just draw the heights using a simple gradient.

But the effect is really nice anyway. I didn’t include the applet in this page, as it cpu-intensive. It iterates through every pixel at each iteration, and just keeps on iterating. the nice thing about it, is that the speed doesn’t depend on how many ripples / activity there is.

small
normal
large

ripple source code