|Posted by David - February 8, 2007 - 0:23|
Grant me the grace of infrared video
I applied for a grant for our project. Whether or not we get that fat wad of cash, we're going to need some hardware for this project and we're going to need it soon. That which separates Cosmosis from a glorified screensaver is interactivity (through vision hardware of one sort or another), so our goal is to get input working.
I'll quote my own grant application:
"...ACAD's VR Lab has a good setup of computers, projectors, and a sound system. We have mounted a webcam over the screen at the longest string of USB extension cables that the signal can support. When we attempt to run the system with the ceiling lights off (so that the projected images can be seen clearly) the webcam cannot pick up enough light to make any kind of image. Minimal lighting directed away from the screen but kind-of [did I really write "kind-of" in a grant application!?] on the viewers works poorly because only highlighted edges of people can be seen, and the light from a directed lamp is blindingly bright in a dark space. ...Also, software image enhancement[/interpretation] of the very dark images creates far too much video noise to be of use.
We need to illuminate the viewers so that their motion can be sampled, but we need to do it without visible light."
The solution is light that cannot be seen, infra-red!
The sensors of digital cameras of all types, including webcams, actually can pick up IR, but IR is unwanted for most applications which aim to replicate images in visual-light. So webcams and digital cameras have been built with IR filters to block IR light. For our purposes we need to remove the IR filter and replace it with a visible light filter that allows IR to pass and blocks visible light.
A good site on modifying webcams for infrared use is the aptly-titled 'How to make a webcam work in infra red'. Choosing from the list of working webcams on the above page, I ordered two "Logitech quickcam messenger" cameras from Memory Express. They were especially cheap and I wouldn't want to saw apart an expensive webcam; too much pressure.
Reading IR light is only half the story - the space needs to be illuminated with IR light for anything to be "seen".
IR Illumination: dark light?
The market for IR illumination is geared toward security, outdoors-adventurism, and a few scientific applications. People who have something important enough to protect with infrared security cameras seem to be rich enough to pay outrageous prices for pre-built LED arrays with nice mountings. We are students; artists; scientists! And can afford no such luxury.
IR LEDs can be bought per-piece quite cheaply but they must be soldered together with resistors and other little bits of electronic hardware that are lost on me. I'm no electrical engineer and we've got quite enough tangential subject-areas on this project to last years, so I found some small pre-built yet relatively inexpensive IR LED arrays here; I hope five of them will produce sufficient illumination for our purposes. If you look closely at the picture you may note that the array's power cable ends in bare wires. After some freaking out then a brief online chat with a friend who has built electronics, I found some appropriate AC/DC power supplies and jacks from his favorite parts-supplier that will work quite nicely with the IR LED arrays.
Everything should come in over the next couple weeks, and any other of sundry cables, hubs, connectors, and mountings we can surely purchase locally.
Render me this
There are two new forms above which I've called "circles" (poetic, no?) and "urchin". Maybe the first should be "crystal spheres"; that'd be nice. The complex lines produce a very different aesthetic look than the cloudy-blobs do, and we shall want to combine all of these rendering functions with others, dynamically, to produce yet more novel effects. Especially pertinent is re-structuring the program to allow for Andrew's "megagents". I do worry about looking like an OpenGL graphics demo, though. And there's only so much we can do, I guess, and the appeal of this project shall lie in the behaviour and interaction, not the graphics themselves. Enough said.
Grid Collision Detection
While discussing the problem of collision detection in Banff we threw a lot of seemingly crazy ideas back and forth, and for a time at least dismissed most and settled for filtering the set of agents which would attempt collisions at all. Then, over our discussion-over-tea two weeks ago, Andrew pointed out that Kaye Mason had used a collision method that we had dismissed as too ridiculous to use.
From Kaye Mason's paper, Negotiating Gestalt: Artistic Expression by Coalition Formation Between Agents:
"When an agent is placed or moves, it registers with the grid. Each grid cell keeps a list of registered agents in its territory. An agent can query its own cell or neighbouring cells for a list of registered agents."
As Sheelagh pointed out during our presentation, this grid collision method keeps the size of collision detection process more-or-less uniform over a space/set filled with any number of agents. A conceptual illustration of this process appears below: The viewport is divided into a 20x20 matrix of cells with which agents register. We then consider agents which share a cell to have collided - the "collision radius" is the (adjustable) cell size. This actually works, contrary to our expectations, because it gives the impression of physical simulation, but doesn't require the processing expense of performing a complex and more "realistic" collision detection.
It still needs working-on and optimization, of course; would you believe that we're iterating through the agent list rather than the grid? Madness! And surely it can act as more than just a grid (to address Paul's concern). David O. suggested we use a quad tree, which is roughly equivalent to an adjustable grid, but is much more clever, and kindly sent us a lengthy explanation. We shall see how far we need to take this for our application. (I'll say it again: This project has so many applicable areas that we could work for a long time on just collision detection, just agent rendering, or just video input. As is, we've got to jump from place to place to try to put together a coherant and operable whole that works well-enough.)
It isn't working yet. It's hard work, especially dealing with the large image-data arrays efficiently (and getting the stupid Numeric module to work properly with everything). And we're going to work on it.
I show this next image because I labored far too long to code a random "video" generator that would give ever-changing shapes for interpretation by our image-analyzer in lieu of input from EyesWeb (curse its inscrutable network-transmission format!). It works with a motion reminiscent of Cosmosis, actually. The raw values of the pixels from the image surface can be seen displayed in the console in the background there.
"You! Yes, you. I shall see you producing useful information to input to the virtual ecosystem. Soon."