Holiday Cheers from Animoto
November 30th, 2011 mosesoakCheers!
I've been toiling in the video player mines again, upgrading animoto's player to a new design that supports HD and resolution switching. Our player was originally based on the popular Jeroen Wigering Media Player, but has been branched and rewritten 101 times since. Still, the architecture of that player was solid enough way back when that it's more or less still intact at some level.
Check out this animoto of our crew partying in the sun last summer, a nice pick-me-up for an ugly slushy February.
A remarkable piece of research from university labs in Vermont has cut the length of time for robots to learn to walk on their own from hours to just a few minutes by asking them to learn to crawl first.
From the fantastic GizMag.
Perhaps it's atypical to send empty POSTs (is it?), but on a recent project we were simply leaving the contents for later until we'd proven that Flash could properly send headers. There are a number of header types that the player blocks, clearly listed in the URLRequestHeader docs, however we couldn't figure out why non-blocked and custom headers were failing to send at all. It was not a security issue, our crossdomain.xml was temporarily changed to include allow-http-request-headers-from domain="*" headers="*" secure="false". (For testing only, that's certainly not recommended for deployment!)
After lots of hair-pulling, hand-wringing and tooth-gnashing we realized: you have to include data in your POST or Flash Player simply discards all of your headers! Flash Player bug? Or just one more annoying, undocumented idiosyncrasy? Anyway I hope this post saves someone else some of the time our team lost today.
(By the way, I highly recommend the Charles Debugging Proxy which provides a really nice detailed look at network requests and responses.)
I'm no expert in professional-grade motion blur, but the FilmStrip library for Flash has let me toy around with it a little. I noticed that when both a scene's subjects and its camera are animated, the motion of the camera can impact blurs in sometimes unwanted ways. For example, an object might be moving very fast in one direction, but then if the camera swivels in the opposite direction it can actually reverse the blur of the subject.
As I've described in earlier posts, FilmStrip generates motion blur by generating a series of subframe captures within the real animation flow. If the camera is also animating, this will affect the perspective of the subframes as well as the primary frame. Since allowing the camera to animate normally turned up some unnatural-looking results (like the swivel example I mentioned), the next thing I tried was to entirely cut out camera animation. This had the effect of completely restoring the blurs of the animation subjects, but it also didn't really look natural to the eye. I suppose we've all grown up watching the particular way TV and film cameras capture things that it's pretty ingrained, things either read as fake or natural even if we don't know the exact reasons.
So next I tried an in-between: allowing the camera to animate during subframe captures, but just not as much as it normally would, which looked a lot better. I achieved this by applying a multiplier to the camera animation. By dampening camera motion during subframe animation, but not cutting it entirely, camera motion can still have some interplay without fully overpowering the blur of the subjects.
I've added a property to the MotionBlurSettings class called cameraBlurPercent, which now defaults to CAMERA_BLUR_NATURAL (0.5), cutting the influence of camera motion in half. Two other constants added to the class, CAMERA_BLUR_NONE (0), CAMERA_BLUR_ABSOLUTE (1) allow you to toggle camera influence based on your particular animation. You can also fine-tune it to another percentage such as 0.25, or do crazy experiments by setting it above 1 to magnify camera motion.
Once again here's my little x-wing clip which I think shows a really natural interplay of camera motion and subject motion. (This MP4 doesn't seem to work in Chrome for Mac, try it in Safari instead.)
A fun little side project of mine has been to write a rendering utility for Flash called FilmStrip. It lets you process a Flash 2D or Papervision3D animated scene into a filmic-looking frame sequence with natural motion-blur, that can then be converted into real video. The motion blur that I'm talking about here is not basic horizontal/vertical 'box' blur, it's created by drawing a series of subframes of the actual animation within each frame capture, so that blurs follow the trajectory and exact shape of the subjects very realistically. Filmic motion blur can be simulated in other ways but this is the easiest and most common, and can yield movie-camera-like results.
To achieve the most natural-looking blurs in complex scenes, FilmStrip blurs each object individually. By default the captureMode property of a FilmStrip is set to EACH_OBJECT. Under the hood this gets a lot more involved than the alternative mode WHOLE_SCENE, which recaptures the entire frame for each blur subframe. There are some very distinct differences and advantages to each that I'll describe here.
First, let's take a look at a frame generated using object-based blur:

You'll notice that the blurs of the two dice are totally independent of one another and actually overlap pretty nicely. You can even see the blur on the back one through the blur on the front one. I'm pretty amazed that Flash can produce such a high-quality result.
Aside: So why are there hard edges? Well, FilmStrip currently only animates blur subframes either before or after the primary frame, which often leaves portions of the primary frame's edges exposed as the blur pulls back across the object. A 'leading' or 'trailing' blur like this can look pretty good in motion, but I eventually hope to add a blur-both-ways or 'shutter angle' option.
In object mode, we can calculate a generalized delta value for each die's motion and then apply a different number of subframes to each one. This is great because processing power ends up allocated to the portions that need it the most in each frame. Fast-moving objects can draw many subframes, while ones with little motion can simply be captured once. In fact, I was surprised to find that in many cases object mode is actually quite a bit more efficient than frame mode, because of that ability to vary the number of captures per object.
Now let's take a look at a sequence of frame-based blurs. For this sequence I set the capture to use a fixed 12 subframes, and I exaggerated their visibility to clarify the next point. Look closely (click each image to enlarge it), and you'll see some strange problems where the dice actually seem to be partially intersecting each other as well as the green table surface:

Why does this happen? It's easiest to understand if you visualize a stack of old-fashioned animation cels with the dice painted on plastic transparencies. To build one frame in the object-based capture mode, we would paint a cel showing die 1, then stack a number of additional die 1 cels on top of it to simulate the motion blur, then on top of that stack we'd do the same thing for die2. (That is, blur subframes are localized to the z-depth of each object.) But in frame-based mode we've drawn both dice onto a cel, then laid another cel containing both dice over that, and so on. What happens is that when objects are moving in different directions, the overlapping of those objects reveals new areas of the dice edges on each cel, resulting in a sort of interwoven pattern. (Z-depths of all objects in the scene are repeated cyclically.)
Keep in mind that for the sake of this example I've increased subframe opacity and spread using the FilmStrip settings peakAlpha and subframeDuration. When subframes are blended back more and the final video is in motion, this z-depth problem is normally not noticeable. So unless you're worried about stills from the final video looking completely correct, frame-based blur can look pretty good.
SInce this is just old-fashioned, single-threaded, non-GPU-capable ActionScript, all we have to work with is a sequential series of steps, including actually updating the animation many times per frame to simulate a blur. This results in object mode sometimes beating frame mode for efficiency, although full-frame mode is still a heck of a lot simpler.
I stuck with object-based blur to create a short video snippet of a classic John Grden xwing fighter being nailed by a laser beam and really like how it cleanly separates the content:

I decided to make object blur the default setting to err toward quality over speed, figuring that if FilmStrip were ever actually used, it would be to pre-render portions of a Flash scene to video, since it's nowhere near realtime rendering. I've made similar decisions at other points, such as deciding to make FilmStrip tween-engine-agnostic (you can plug it into TweenLite, Tweener, etc. pretty easily), whereas if it were being built for speed it would probably include its own custom animation system.
For the time being, FilmStrip provides a nice simple way to tinker with rendering and see some of the complexities involved in seemingly simple things like motion blur.
I'd been admiring those Flip video cameras and can now proudly say I nabbed one in a company costume contest -- Thanks, Animoto! Competition was tough: a Duff Man who came complete with branded cans velcroed to his belt, and a hilarious take on the company president's dog Bruce Lee featuring a hand-made head-to-toe fur suit, a cone of shame, and even a miniature replica of the other office dog clinging to him. Too funny. In the year I've been with them, Animoto has thrown us a ton of amazing karaoke parties (one of which involved a fast exit when things got a little out of control), outrageous bowling parties, and dinners at Mario Batali joints -- what a great place to work!
But while I did bag this contest and one other - a company chili cookoff a few months ago - I was severely trounced by our ass-kicking CTO Nate at our 80's night party. Nate can pretty much never be topped for his outrageous Webby Award acceptance speech leveraging the same getup. Rock on, Animotos, and thanks again!
(PS: Keyboard cat has now also entered the Wired costume contest on Facebook. Vote here!)
The Making of Keyboard Cat video
http://twitter.com/Papervision3D
http://github.com/Papervision3D/Papervision3D
To get started, install Git (http://code.google.com/p/git-osx-installer/), open Terminal and navigate to the parent folder you'd like to put papervision, e.g. your general actionscript workspace folder. (Hint: you can type 'cd ' then drag and drop the folder from a finder window onto the Terminal window to instantly get the path.)
Now enter the clone url listed at their Github page followed by the name of the new folder you'd like it to appear in, like so:
git clone git://github.com/Papervision3D/Papervision3D.git Papervision3D3
Instantly, it will create a directory called Papervision3D3, automatically git-initialize it, and pull the entire repository in a matter of seconds. That's right, using Git you get to work in the entire repository locally, create branches and so forth. Unlike SVN git works from a single .git folder within the main folder, instead of polluting all subfolders with .svn garbage -- you can even move the initialized folder wherever you like and it will still work fine.
You can't push any changes you make directly back to the official Papervision3D repository. To set up a public or private fork of their project get a Github account and click the button at their project that says "fork". Now you have a working copy at your own hosted page and can pull, commit, and push to your heart's content! Later it's easy to do diffs and merges with their project, and if you write something worth keeping they can do the same, easily bringing portions of code from around the community into their build selectively.
They call this "social coding".
Unless you have ambitious plans to contribute to their project right away though, to get started just do a clone as described above, which is more like checking something out of a googlecode public svn. You can import the folder into Flash Builder, Flex or FDT and run the file called Main to see a wireframe 3D example scene that already works. Go team!
I'm proud to present FilmStrip, an AS3.0 library that lets you process code-based animations to video with natural-looking motion blur. Please read the full article at Animoto Labs.
Animoto nabbed a real-life 2009 Webby folks, under Services and Applications -- and we won the People's Voice award as well so thanks for your votes!