so i found dropping SVG to disk is an easy and fun way to visualize or debug data structures. here’s all it takes in C:

FILE * fp = fopen("kdtree.svg", "w");
fprintf(fp, "<svg version=\"1.1\" width=\"1024\" height=\"1024\" xmlns=\"http://www.w3.org/2000/svg\">\n");
fprintf(fp, "<line stroke=\"#%06x\" stroke-width=\".1\" x1=\"%f\" y1=\"%f\" x2=\"%f\" y2=\"%f\"/>\n", ...);
fprintf(fp, "</svg>");

what’s nice is then you can load the file up in firefox or inkscape and zoom in. also you can easily draw in other data like triangles and circles or put nodes you’re interested in in different colors and what not.

here’s a 3d kd-tree seen from above subdividing space evenly

here’s a 3d kd-tree seen from above using surface area heuristic

our second teaser trailer is up! this one details the playable races in gw2 and shows more beautiful in-game environments plus some glimpses of combat! i can't wait for more to be revealed. :)

last night i had a great time with kirill, guybrush, and matt at microsoft testing out and playing with live music visualization stuff. guybrush and i will be doing the visuals for the portland, oregon and seattle, washington stops of the data beez tour! it's been a really fun experience for me so far as i've been introduced to some great musicians (whose tunes are drilled quite deep into my brain now as they've been looping for so many days XD), have picked up the programming environment processing, and given lots of thought to whole new aspects of sync and synesthesia outside of what i've previously toyed with in doing demoscene productions.

departing from what i think is the normal vj style and inspired by guybrush, paris and other visual artists on the tour, i've focused on creating a sort of visual instrument controlled by a laptop keyboard and a korg midi controller. it has five independently controlled layers: feedback, background, midground, foreground, and post process. each layer maps to a row on the laptop keyboard for switching between effects and a block of controls on the korg for controlling speed/amount, beat/kick, and either audio reactivity or transparency. it makes for an incredibly fun toy but i have to avoid some combinations that produce immediate eye cancer! ;)

this weekend i'm hoping to finish the bulk of the code, effects and visual content and also get in practice time 'playing' it as a complement to music. hopefully things turn out well and the musicians and audiences next week enjoy the results. :)

so i gave video strokerization a try and it turned out pretty cool. here you can see the nine inch nails march of the pigs music video strokerized:

nine inch nails march of the pigs strokerized! from blackpawn on Vimeo.

for this i told strokerizer it could only paint 64 brush strokes each frame so it didn't get much chance to fill in fine details with the camera always moving around like crazy. :) it wound up making for a nice loose look.

on the code side i managed some more optimizations and am finding my way around nVidia's CUDA visual profiler pretty well now. my laptop's 9600M GPU gets completely pegged now which is great. on my desktop the GTX280 though is just too fast that it's still finishing work faster than the CPU can feed it. i think i'll have to move more parts of the algorithm over to the GPU to fix that.

so previously i blogged about my glypherizer experiment to approximate images with a small number of font glyphs. unfortunately it didn't meet with the fantastic success i had hoped. :P the ideas were still a bit itchy though so i wound up working some more on it. this time around i used images instead of font glyphs so they could be brush strokes or other crazy stuff in addition to text. also i rewrote the code in CUDA so it runs on a 240 thread GPU instead of a measly 8 thread CPU. here you can see some of the strokerization tests:

you can see more of the full set on flickr if you like. thanks very much to kirill for the library of cool brush strokes!

this was my first real CUDA app and i was surprised just how quickly i was able to port everything over to GPU kernels. so getting it running on the GPU was pretty easy, but what turned out to be harder was making it fast. i had to optimize my kernels to reduce the register counts they needed quite a bit and use nvidia's occupancy calculator spreadsheet thing to work out good block sizes and thread counts. that along with using the async stream API helped get the speed about where i expected but i still think there are some things holding it back. i can't wait for more performance tools for tracking this stuff down.