Honestly, this is exactly what you were looking for. You were looking at your $1500 copy of Maya, and thinking: why can't I control this with my $20 USB Xenon controller? Wonder no more: ControllerServer is here!

This is a little one-off that I did for Steve the other day that's kinda fun. It allows you to connect your 360 controller to Maya as a Motion Capture device. The inspiration for this was Joystick Server, by Jorge Luis Imperial-Sosa. Sadly, Steve wasn't able to contact the author, and there were some limitations in the program that couldn't be worked around without the source (e.g., Joystick Server doesn't expose buttons or analog triggers), so I banged this out for him, and cleaned it up for release.

Pushed into the public domain, for the 2 other crazy people that want to prototype game controls in Maya. Should be easy to modify to use general purpose DirectInput devices, or multiple controller inputs. Just think, with 2 controllers, you could use Maya to play the world's most overpriced game of Pong!

/projects | permalink (2007/06/01 22:27)

The incomprehensible little screenshot at the right is my first GJK implementation running in test mode. I'm actually kind of disappointed in how straightforward the algorithm is once you drill past some poor notation in the standard papers. I remember that I put off playing around with GJK a couple years ago because I had the impression that it was High Voodoo. Apparently, not so. Gino van den Bergen's paper is a comprehensive account of what you need to know to implement the core of the algorithm, especially when augmented by examination of FreeSOLID, but the notation makes me groan.

Once you get past that, the idea is really quite elegant and straightforward. I especially like the way the underlying representation of the hull is completely opaque to the inner loop. Quadrics, boxes, polymeshes, whatever. If it's convex, toss it in and it Just Works. Sweet. Want to sweep out linear motion? Twiddle the return value of one of the support points based on the dot product of the direction of motion and the support vector. Done.

The depressing part, of course with all object interference detection is the messy reality of implementing such a nice, clean, algorithm in dirty, nasty, single-precision floats. This stuff isn't currently very robustinated against precision problems, I'll eventually do that if I ever figure out what I'm going to use this for.

/projects | permalink (2005/03/18 01:14)

I've been playing around with KD-trees at home, trying to come up with something novel. I started out trying to fit an Oddworld style "loose-kdtree" (a concept too boringly esoteric to get into here) into 4 bytes per node, but I can't convince myself that the tree can handle large models with only 14 bits of offset for the child pointers, so that's right out. It may be possible to do this with a short/long offset approach, but that's a test for another day. It requires a more convoluted packing process, and an extra conditional inside the node-traversal loop, which is definitely A Bad Thing. Still, the gains in cache-efficiency and tree size might be worth it, there should be only a small subset of nodes that have child offsets that exceed 16k.

Next up, cache-efficient subtrees, as outlined by Crister Ericson (in this talk). I was trying 3 element subtrees, so 3 nodes of the KD-tree would be packed into 16 bytes. This turns out to be a royal PITA to code nicely, dealing with internal nodes in a way to preserves traversal orders while not requiring explicit recursive function calling is too annoying for my tastes. The capper was that when I looked at the average memory cost of an internal tree node for some real test models, it wound up being almost exactly 8 bytes. So much for subtrees, I can write much easier to deal with traversal code for simple 8-byte non-packed nodes.

It's possible that I'd get proper space savings and better cache-efficiency for 7-element subtrees, but the hassle simply doesn't seem to be worth it at this point. We'll see how the 8-byte nodes turn out, I think it should be comparable in cache-efficiency, so long as the layout process is sensible. The builder is generating some fun images at this point at least, the image to the right is a section of the KD-tree built for the Bunny. (Stop groaning back there!) Click for the full deal...

/projects | permalink (2005/02/20 12:16)

Small update uploaded for perforce_rss to fix a bug in the GMT date calculation. Also adds a new parameter for the output location of the tempfiles used in creating the feed document.

/projects | permalink (2004/11/01 16:08)

Presented for your approval, perforce_rss, a small Perl script to publish changelist events from a Perforce source control depot as an RSS channel. It's pretty braindead right now, but it's nifty enough at this point to throw up on the site. I'm releasing it to the public domain, so do with it as you will. There are still quite a few todos though, so this is presented "as-is".

/projects | permalink (2004/10/30 12:12)