blake - Tuesday, December 1st, 2009
There’s been a lot of negative talk about Flash AR executions lately, and it’s deserved. Too many brands are using development houses that have no more understanding of the FLARToolkit than throwing a 3D model on a marker, let alone how to use it for successful product promotion. So, I completely understand why some of my peers, mainly those in the mobile AR realm, are rolling their eyes at the title of this post. Hopefully, I’ll make a good case for my claim, which is that Flash is the best breeding ground for new AR concepts that can then be brought to a wide array of other platforms.
_________________________________________________________________________________________
Mobile, Location based AR is the star of the moment. Many developers in the genre state that it’s what Augmented Reality is all about, but these GPS and compass based applications are only a small fraction of the types of engines being created and even already readily available. This has led to a rift in the AR developer community, causing the term, “True AR,” to be regularly used.
What is True AR? It’s the real time calculation of camera data being fed by the device to create an AR experience. Almost all web AR executions are True AR, although most of them right now are just True Gimmicky AR.
The limitations of GPS and compass units on mobile devices makes current mobile AR apps light on usability. The developer community has coined the melding of True AR with this genre to provide more accuracy, “Hyper-location AR.”
Unfortunately, there’s a problem with Hyper-location AR and any other True AR experience on mobile devices: processing constraints. It takes a whole lot of calculation to process camera data into a virtual construct, and while native applications on desktop computers are handling it well, mobile devices are still a little sketchy. This brings me to my first point:
Flash’s processing restrictions are a good thing for AR
Eye rolls again, I’m sure. Here’s the thing – if an algorithm runs well in Flash, you can be sure that it will run brilliantly on any mobile platform. Flash’s processing restrictions keep it running about the same, or just under, the iPhone, Android, and Symbian devices, when it comes to computation. An algorithm that allows me to track a hundred separate points in an image, per frame, might work out to 125 to 150 points on a mobile device (admittedly a guestimate). Meanwhile, an algorithm working in Java on Android might work a little slower in Objective C on the iPhone, or vice versa. When you start with Flash, you’re always moving up.
Flash is a very easy language to port
Yes, Flash is my favorite platform, so take this with a grain of salt. I didn’t get my start programming in ActionScript, though, and I’m well familiar with c++, Java, and Objective C, which run Symbian, Android, and the iPhone, respectively. Let me use c++ as an example, since it’s the primary language being used to create high-end AR engines.
If you take apart a large c++ library like bazAR, a feature recognition engine, it can be like reading Klingon. That’s because of how c++ variable naming has an effect on the processing of an application. In an engine like bazAR, that’s performing a huge amount of calculations, keeping your variable names as small as possible makes a huge difference in the final product. Problem is, it makes it a pain in the neck to figure out what’s going on when every step isn’t completely commented by the developer (99.9% of engineers barely comment at all).
If you’re a development house that’s created an AR engine in c++, but want it to work on a wide variety of devices, either you’re lucky enough that the creator is familiar with every single mobile platform, or you’re going to have to bring in an outside developer to port it. Having cryptic code, which is almost unavoidable in heavy c++ libraries, adds a good amount of man-hours to that work, which translates to more money spent than necessary.
Why more than necessary? Because Flash variable naming has no determination on processing. I could name a variable public var thisVariableIsReallyCoolAndIThinkYouWillAllLikeIt and it would take the same amount of processing as public var i. While a c++ engine would likely have a function with a dozen single letter variables, that require someone reviewing the code to decipher the calculations just to get a sense of what’s happening at all, a Flash one could have a descriptive name for each variable that makes the function easy to understand. Basically, Flash is the closest to pseudo-code a full-featured language gets. It can be the Rosetta Stone for your AR engines.
I know that some folks are thinking, “But you can just write a wrapper for c++,” but if you do that, you’re adding extra processing in an already processor intensive app. It only makes sense to port to the native language of the device.
Flash has an ease of development not offered by other languages
You might think I’m gushing on Flash again with this, but it’s the absolute truth. ActionScript takes the developer from idea to proof of concept faster than any other language. Many of the back end calculations that need multiple third party libraries for other platforms are built into Flash and are extremely simple to utilize. I’ve had an idea about a body recognition algorithm at 10am and had it running relatively smooth in Flash by noon, ready to show as a new proprietary library. Try that on a mobile platform.
Also, Flash has, arguably, the most vibrant developer community online. The barriers to entry are low – sometimes too low, as is demonstrated by gimmicky AR – but it’s simply the easiest language for a seasoned developer to learn. You can Google the answer to just about any specific Flash programming question imaginable.
Accessibility, Accessibility, Accessibility!
So you’ve created an experimental AR algorithm and you need people to test it for you, break it down, and help you squash any bugs or weaknesses. Let’s say you wrote it for Symbian. How many people in your office, let alone your QA department, have Symbian phones? Translation: potentially thousands of dollars of investment for something that’s experimental.
Now, say that you built it in Flash. Try to name someone at your office that doesn’t have a computer with Flash installed. Sure, you might have to pay for webcams, but they cost a whole lot less than smartphones. Plus it’s ridiculously easier to do a public beta test with Flash, where someone will just navigate to a site, rather than having to manage users downloading a regularly updated app to their phone. Once the kinks are worked out in a Flash build, port it to Symbian or any other device, where your test time and budget are a fraction of what they would have been if you went the other route. That and you have a working demo that doesn’t require a potential client to have a special device.
Full User Interaction
If using GPS and compass input is AR, and using camera data is True AR, then adding motion capture and body recognition to the mix is Really True AR. The algorithms that run body recognition in current AR will be the basis for the so called “Terminator Vision” that tech bloggers love to talk about lately. Nowhere is it easier to construct and test these algorithms for mobile use than in Flash.
Something as simple as drawing vector body outlines for results testing, or parsing bitmap data for motion recognition, could potentially take hours or days with any other platform, but is done in minutes in Flash. Why spend any more time than is necessary when experimenting with one of many hypotheses? I couldn’t tell you how many of my ideas went bust within an hour or two with ActionScript, when it would have taken me a whole day or more to reach the same conclusion in another language.
The most important thing is money
Less money spent, to be exact. Go the Flash route and you can have an AR algorithm ready to be ported to any platform without hassle, free of device specific features, guaranteed to run smoothly, at a fraction of the effort and cost of other methods.
Now, let the text based eye rolling begin in the comments section. 
Follow me on Twitter @blakecallens
