In the end ...

Conclusion Experimental Animation:

[link to video from show: http://www.rsd.no/documenta_web/ ]

My last effort was to have a public showing of my interactive animation pieces, with the help from the local high school and a teacher I happen to know over there. There was a couple of useful lessons to be learnt from that experience. First of all, do not trust what other people say, at least if it is of great importance to you. I was hoping that some of the art students would come and visit my show and maybe ask some questions either about what I was showing, or about how it was to be an art student abroad, or possibly both. The teacher I had contacted promised me to inform the students about my presence, but being in the midst of their final exams, and him personally being very busy with other private things as well (he told me), I guess he just forgot to mention it. If not that, they have some students with a very strange attitude towards digital art, studying abroad, and higher education. I think the former was the reason.

In any case, my primary goal was not to have an audience for what I was doing, but to try out new equipment in a gallery-like setting, and to document my work from the present term. The new equipment I was going to test out, was a projector (instead of the good, old computer screen). Simple enough, one should think. But, there was a lesson the be learned. Part of my concept was to use a camera to capture a video stream of the viewer, thus making the viewer not only a passive viewer, but an active participant in the piece (by very simple means, of course). This concept of making an active viewer was also utilized through the use of a panel of four knobs, giving the viewer a certain amount of control over the piece shown on the screen. The problem with the whole thing, though, was that the room I was given was a class room with very poor possibilities of making it dark inside, thus being very poor conditions for a good projection of the image (which in my case must be said to be of major importance). This made me think of what would have happened if the room was totally dark, and I was to try to use a video camera there? Well, I guess that would have been difficult, but not impossible. It would probably be necessary to use some sort of spotlight to light up the area (i.e. the viewer/spectator) that was to be filmed. It would probably have yielded a much better result than what was the case for me now, in a very light room. To conclude this, the projection came out lousy, so my documentation of the whole thing, is really not much to look at. All of the applications can be tested and evaluated on a computer with a camera connected to it though, but that was not the point of this exercise.

In general, I spent a lot of time lately to 'convert' my applications to be able to use with my potentiometer panel, and to tweak them to work as good as possible. Although being very different, they are all based on a fundamental principle, namely that of elasticity. My latest piece, the 'elastic video player' to give it a name, uses the elasticity principle to make an interesting twitch on the idea of watching a movie. I have seen this idea before, but then without the user controlled interface, and I am not sure if that was real time either. The thing with elasticity, though, is that it is very hard to control, as it is in real life. Sometimes the velocity and the forces involved goes a little crazy, making you loose control, but there are also means of getting the control back. Another, and bigger problem, is that Processing is not built to handle video in this way. The people behind Processing explains that it is Java that is not built for it, and since Processing is built on Java, that is how it is. I found it really interesting to work with video in this way, so it would be nice to find a (preferably open source) software that could be used for it ... I downloaded an old b/w movie, "The man with the golden arm" with Frank Sinatra as the main character, from Archive.org. It worked very well for this kind of project, having a lot of clean shots, and long cuts. It is also in the public domain.

I found myself spending a lot of time tweaking the Seaweed application as well, making it move in very realistic ways, again utilizing the elasticity code. It is pretty amazing to see how naturalistic a 'computer designed' thing can behave, with relatively simple methods.

I always ask myself, though, if programming is the way to go to make interesting art, finding myself actually spending a whole lot of time trying to achieve exactly that. And the answer is that I still do not know ...

Elastic Pixels

So here is a movie of the Elastic Pixels effect I have been working on. It is easy to tweak the effect in many ways, and though one setting might work under some circumstances, it might not work under others. This can be as simple as the room I am sitting in is getting darker. So, I tried capturing a the real time video effect as it was happening, and it worked to a certain degree. The thing is that the applet's frame rate is dropping quite a bit when doing capturing at the same time. This is not so strange, since both capturing and doing the video effect are processor intensive tasks, thus slowing the computer down. Still, I think this movie 'captured' some of what I think is a pretty neat real time effect. The effect is, in my opinion, very dependent on having enough processor power/speed to be successful. It might also be the case that this is something only I happen to like, and no one else, but that is kind of hard to know on beforehand ... :)

Digital Sea Plant

Well, at least I think it resembles something similar to a sea plant. I really enjoy seeing how some relatively simple (everything is relative, right?) code can resemble something organic and life like. This 'plant' is only using an ellipse and a rectangle as its basic building material as well, and still it looks pretty cool if you ask me. I have been exploring the elastic class (which can be found with some explanation here: ( http://www.bit-101.com/tutorials/elasticity.html ) and also in my source code for the applet which can be found here: ( http://www.rsd.no/ExperimentalAnimation/ )

I was thinking I might hook it up to my 'pix reader' class, which is being used to detect movement in front of a camera, and then let it react to that movement, but I found that it was not really necessary at this point. I mean, I think it works well as a sketch at least, but maybe I test it with movement detection later. A really nice thing would be to have a touch screen attached to it, and then let it react (by withdrawing back in its shell) to touching. Unfortunately, a touch-screen is not cheap, and I do not know any people owing one either.

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.