
Solar rework
9 days ago
I have been working on a real-time version of the Solar piece from a couple years ago. Since it is going to be responding to people's voices and ambient noise instead of music, I started listening to podcasts while I was developing it. I made this video to commemorate my new found love for WNYC's RadioLab podcast. Thanks to Branden Hall and Bill Lindmeier for introducing me to it.
-
Vimeo: About / Blog / Developers / Jobs / Community Guidelines / Community Forums / Help Center / Site Map / Merchandise
/ Get Vimeo

Previous Week
The background is all happening on the shader. I have a few moving points and using the distances from each frag to the points to determine the texture coordinates. The texture is a dynamic texture based on the audio.
I don't understand your second question: how did I map the audio input into the system?
This project runs real-time, but since I had to render out a video (which cant happen in real-time), I cranked up the particle count for the smoke and haze. Its very close to what I can get in real-time on the PC with Nvidia GTX 260. The only thing happening on the shader right now is the background.
good stuff
UPDATE ---- As soon as I hit Post Comment, all the comments reappeared. Odd!
Firstly, thanks for the feedback and kind words!
Bryce: Its made with Processing (processing.org) and uses Amit Pitaru's audio analysis library Sonia, and Andrew Bell's convenience classes.
Syed: I use FFT on the incoming audio to get distinct frequencies. Each sphere 'listens' to a specific frequency and adjusts its mass and charge accordingly. There are also several thousand invisible particles who aid in coloring the sphere surface. I will likely write a blog post describing the process more thoroughly but it isn't that different from how I made the original piece. Read about it here: flight404.com/blog/?p=111
planete: It always seems to happen this way. I will start working on a piece, I will get it working at realtime fps, I decide to post a video and the best way for me to do that is to save out the frames one by one as it runs, which slows it down. So of course I think, "well, since it isn't rendering out in realtime, I might as well crank up the particle count and get more bang". I will probably shoot a video off the monitor to better show how it looks running realtime. Its not too different from this video, but much less haze effect.
James: Ended up staying with Processing. The next order of business, once this and Fuji are shipped, is to port both to Cinder/C++.
InsightVR: For the live version, using a USB microphone. For this rendering, I pulled the audio bit I wanted into the project and analyzed it 1/30th of a second at a time. For each of those blips, I save out the resulting image, then piece the images back together and paste in the original audio.
I think I'll actually take a crack at Processing now.
as a suggestion for creating videos of realtime/gpu applications, you can capture DVI output at 720P or 1080i using a DVI-HDMI lead and another pc with a BlackMagic intensity card. The card is cheap, your output runs unencumbered, you get a lossless recording.
Great scientific explanation.
I wish the video would have ended at 1:43 though.
But does it somehow connected to a speech on background? Or is it just a fancy visualization to keep viewer's attention in?
Its a shame this isn't linux based, it's really easy to use pipes to link two applications and so send the pixels from GL to an encoder app like mencoder and do the recording in real time as well...
On a decent PC I can record 720p at 30Hz :)
That's how I've recorded a load of my vimeo clips.