Trust me

I finally made the tracker and the particle bit of my program into separate classes, thus making it much easier to handle, adjust and tune. Now I can concentrate on the details of some more specific details, like how to move the particle in a way that it does not drift off of the screen ... The problem of that lies in the fact that an angle is measured from 0 to 2 PI, or -PI to PI, which is in all practical matters the same. This is a problem because it is not linear, but circular(!) ... I.e. it means that at some point, an angle switches from being close to 0, to 2*PI! So, even though an angle only just changes slightly, its value changes drastically. This gives me a problem when it comes to comparing two angles, trying to adjust one angle to the other, especially in a 'fluid' way ... I still haven't found a solution to this, but I'm not giving up! :) If you look at the applet now (http://www.rsd.no/ExperimentalAnimation/) you will see that the particles slowly drifts away to the left. This is directly related to this problem. I'm not sure how to solve this yet, but I hope I will manage to in the near future.

Also, I hope that the applet will work in other people's browsers. There is this issue with trust ... Since I'm accessing other people's web-cams, it is treated as a potential security issue by Java (which is what Processing is based on) and therefor requires certificates. I managed to make it work in my own browser, but I'm not sure if it will work for all. Oh, by the way, this is an applet that uses video stream from your camera on the computer, so unless you have one, this applet won't do much good for you.

Edit: I did find a solution to it. I had to implement a counter/timer to the function that was comparing the two angles, so that at least one of the angles did not stay at the zero/TWO_PI point. It is a hack, and I still do not know of any better way to solve this. My solution works well for this applet, especially because it involves some randomness, but what if one requires 100% accuracy? To reiterate the problem: how do you compare two angles that might be very close to each other, and one of them is varying slightly, thus making its value shift from close to zero to close to 2*PI?

Coding it right ...

As always, when getting into programming as part of an art project, there are always the problem with getting too technical, too advanced, too complex etc. There will always be a big part of a project that will involve learning something new, and pushing your knowledge further to new places. This time, I decided that some of that knowledge I was seeking was to be used towards better programming techniques. As a consequence of being more and more daring in terms of programming, the programs themselves can grow more or less out of proportions. They become very hard to maintain, as they grow bigger and bigger. One solution to this, however, is not to program less, even though that too can be one way to do it, but to implement to fine art of OOP, aka Object Oriented Programming. By doing that, you can split up your files in a bunch of smaller chunks, and Processing will let you have small tabs where each class resides. There are multiple things to gain by this: Firstly, as I said, you keep your program smaller. Secondly you should get a more 'logic' structure of your program, and lastly, it is much easier to re-use to code you are making. There is no doubt, however, that there are many ways to make bad programming, even though the concept of OOP is used. But, starting to implement it, is in my opinion a good idea, so that I eventually, one day, can make clean, logical, reusable code that can be revisited later, even by myself, and make sense.

As far as my project goes, I think it works pretty well, and it goes in the right direction. I have made some pretty good bits of code that works well, but I still have a lot of work to do, to make it all stick together. So far I have made a 'tracker' that works well. That is, I am analyzing a video feed, frame by fram, pixel by pixel, looking for where the pixels differ, thus indicating movement. I am also working on another approach, where the pixels are being compared with a stored image (i.e. background), and thus not sensing movement, but a change over time.

Interactive applet

I've started working on the project that hopefully will end up with an interesting interactive piece. Any programmed application can have a number of different uses, and my idea is absolutely not ground-breaking when it comes to the programming part, or the use of it for that matter. It is very much a basic idea, with a pretty common use, but that is not to say that it can't be fun or interesting. We'll see how goes. I have always been interested (at least since I learned how to incorporate video in my programming apps) in interaction. That the viewer is not merely a (passive) consumer of impressions standing in front of some piece of art. By using a camera (or some other sensing equipment) makes it possible to let the viewer participate more, and even be a vital part of the art piece. We have seen lots of examples of this already. But, even if it has been seen before, it has an almost infinte number of ways to be deployed. I will see if I can take advantage of that.

My applet is based on one of the examples in Processing, readily available for all to use, and is called "Background Subtraction." It is found under Processing --> File --> Examples --> Libraries --> Video Capture --> Background Subtracting

I have changed it alot, but it is (almost) always easier to start out with one of the examples in Processing, especially if it is very related to what you will make.

This is not a finished product by far, but it works pretty well so far. The goal was to detect motion, and to figure out _where_ in the picture this motion took place. I'm therefore collecting all the coords where changes happen, and then average those coords to one specific place. This will definitevily work best against a bright, monochromatic background, with as much contrast as possible to the moving object. I don't think that will be too hard to accomplish. I will work more on this to make the movement of the 'blob' (the averaged coords) more smooth. As for now, it always jumps to the place with most movement, and that can be rather jumpy. Here is a link to the applet itself. PS You need a video camera on your PC/mac to make this work. Also, since it involves using the camera, you need to download the file (a .zip file) and run it from your computer. This is a java mac-application. I hope it will be playable, please inform me if it does not work. The source code can also be downloaded if desired.

Processing Processing ...

Since it has been quite a while since I played with Processing, I need to freshen up my skills. One of the first things I always forget how to do, is to handle many objects effectively. But, with some searching around in the reference, and various examples on the web, I found back to it. It is a pretty useful thing to utilize, since it can give you precise control over any given number of objects (those objects might for example be of pixel-size or large-scale graphics of some sort) ...

The image on top is made using the object method. Every box has individual properties, and in this case they are given a random x-, y- , and z-position, plus a random depth (or hight if you like). By changing any of these properties, the output could be drastically different. The image below is thus an example where everything is based on order, but the program is basically the same, it is just a matter of giving each box other properties.