Insight VR

Here’s another crazy concept for odd Wiimote interaction.  Cover a whiffle ball in IR reflective material.  Set up two Wiimotes with IR emitters to “look” at the ball.  Then hit it with a golf club.  A real golf club.  You probably want to do this outside.

Since the Wiimotes track at 100 FPS you should be able to grab a 3D trajectory pretty accurately.  You can use the whiffle ball trajectory to estimate a real trajectory.  Set up a projector and a screen and you’ve got a reasonable virtual golf simulator that will work with real clubs.  You might even be able to do have a self-powered ball that emits IR on its own by suffing some IR LED throwies into it.

In other news I got the lightsaber concept working a week or two ago.  I want to build a better saber and shoot some video of it.  Hopefully I get to that soon enough.

A while back I detailed the problems I had getting DarwiinRemote’s WiiRemoteFramework to give my raw IR data in pythong. Well, a solution is at hand!

Ian Johnson has figured out the method signature that so many others could not figure out. That includes me. Here it is:

v@n^[4{IRData=iii}]

So go ahead and check out the new wrapper at Ian’s site. I plan to spend some time making my code work with this new wrapper and putting it up for download.

Looks like Obscura Digital has made their own version of Missile Command.  Instead of lasers and webcams their implementation uses a giant multi-touch screen.  It is very similar to the Insight VR missile command, but playing it looks like a different experience.  In terms of game play, both my implementation and Obsucra Digital’s are missing elements of the original arcade game.  Neither one limits the number of missiles you can launch.  Theirs is missing chain reaction effects.  Mine is missing the launching of your own missiles as an explosion occurs right where the laser was seen.

Given the similarity of the two projects, I really have to wonder if they came up with this idea after seeing or hearing about my demo.  But then again, if you sit down and try to think of a game that would be fun to play with either the laser or the multi-touch interface (which are very similar) Missile Command is the first thing that comes to mind…

So I did in fact present at Utah Code Camp. I happen to think that the presentation that I gave is, at its core, superior to the version that I gave at PyCon. It has most of what the PyCon presentation had plus:
Read the rest of this entry »

As I mentioned earlier I’ll be presenting at Utah Code Camp held at Neumont University in South Jordan, UT.  The schedule is out and I’m at 2:40 pm - 3:40 pm in room 201.  You can download the presentation here.  It should run about 45 minutes including short demos which will leave plenty of time for questions but perhaps not enough time for playing.

The new missiles, explosions, and collision detection stuff is pretty fun and should make the 3D demo all the more entertaining.

Utah Code Camp has been gracious enough to allow me to present at their Spring Code Camp on April 26, 2008.  It is held at Neumont University, which is just west of the 106th South exit of I-15 in Sandy, UT.  I’ll post more the exact time once I know it.

I’ll have a full hour to cover things which will allow for much more detail and demoing than the 30 minutes I had at PyCon.  The 3D app has seen some improvements (missiles, explosions) which I’ll show off there as well as discussing the details of NumPy laser tracking, wiiMote head tracking, and perhaps some OpenGL recursive picking as well.

In my PyCon presentation (video should be up shortly video is up!) I mentioned the difficultly of processing the pixels fast enough. In a 640×480 bitmap there are 307,200 pixels and the iSight is trying to pump them out at 30 frames per second. I did a few things to speed things up. For instance I limited the area of the bitmap that I scanned based on calibration data, I only scanned every fourth pixel (every other pixel of every other row) and I only processed every fifth frame. While this worked well enough, clearly it was not ideal.
Read the rest of this entry »

I’ve been asked to discuss both the details of both how headtracking works and how I used the DarwiinRemote library. I hope to accomplish both in this post.

I became aware of the concept of headtracking when I saw the Johnny Chung Lee video describing his wiiMote headtracking project, which is amazing, as are all his projects. I realized that it would solve the primary problem that was facing me in furthering the development of my laser games: it gave me a way to allow players to move in a game world while holding a laser gun with both hands.

Read the rest of this entry »

Hello, Matt here. I’m going to discuss the Linux port of the Missile Command game. I have a Logitech QuickCam Messenger. After I installed gspcav1 on Gentoo Linux, the webcam “just worked”. Now I needed to get it working with the game.

The main task in porting to linux is to poll the webcam and push a buffer of image data to the process function that looks for red. A simple enough task.

A month or so ago, I had looked for python wrappers to the v4l interface, and I thought I came across one for v4l2 (v4l v. 1 doesn’t work now), but alas I downloaded into my /tmp directory and it has now gone into the bit bucket, and my search-fu isn’t good enough to find it again. So after getting frustrating that I’m either losing my memory or just retarded, I started looking for other wrappers. I found one called Fluendo Halogen. Using their example code I soon had image data going to the process function. But when I tried to play the game there appeared to be some weird feedback loop going on and the laser had no effect. What to do?

Debugging here is a tiny bit different that normal debugging. How do I know if the webcam is seeing the laser? And if it is why is it not being detected? Turns out that PIL has a nice function to convert a data buffer to an image. So by converting the buffer to an image, I could see what the webcam was seeing. To make a long story short, instead of giving my back a stream of RGBA values, I was getting back BGRA values (red and blue were switched) and the image was upside down. I tried the naive method of rearranging the buffer, but it was prohibitivly slow. So my brother told me to alter the processing matrices that searched for red. I also added a flip Y coordinate argument and the game was off and running.

So if you are interesting in running under linux, make sure you have Fluendo Halogen installed (or in your PYTHONPATH). Good luck!