Hi, in my spare time I been working in a quite interesting project, it is related with publishing properties in the cold-rusty real estate market, slideshow tours, panorama tours and all of them fully interactive, the website is live.

At this moment there are many companies offering 360 panoramic online tours, some of them using quicktime player, others using java, other using flash and (papervision, away3d, etc)... Which one is the best? It depends on what you’re trying to achieve and how quick you want to develop it. I believe that all these people who are working with panoramas are doing their photography job really well (which is perhaps the most important part of a panorama tour) but many of them are forgetting one really important thing “PROTECT THEIR PICTURES ”, they make a huge effort taking pictures and investing in equipment and probably others are using their pictures with similar purposes and for free (it happens quite often in the real estate market), a bit unfair, where are the photographer rights? During my research process I found in some places duplicated panoramas, people are stealing pictures and reusing them in different websites, the question is: What is the most we can do to prevent that? put our name or company name as part of JPEG content? hmmmm… actually there is something even more interesting that we can do. Take a look on what we have done for protecting panoramas pictures on http://www.panoramastreet.com, there are not watermarks or content that could disturb the user’s view, even less advertising. Here is the link to the panorama tour demo http://www.panoramastreet.com/live/Demos/DEMO_VV1/ and take a look on one of the pictures how it looks like outside the tour: http://www.panoramastreet.com/live/Demos/DEMO_VV1/pics/lrfront.jpg

It is a quite complex algorithm for reconstructing image data on the fly, if you’re interested to find out more about how does it work just let me know, cheers!

Tomohiko explained that AR has been huge in Japan for the past few years, mainly on Nico Nico Douga, Japan’s answer to YouTube; unfortunately the previous incarnations of AR did not run in the browser, so Tomohiko set out to achieve browser-based AR. FLARToolkit is actually a port of a C++ framework called ARToolkit. ARToolkit was ported to Java, which in turn was ported to AS3 by Tomohiko and his friends at Katamari Inc. It can be used with a variety of popular Flash 3D engines, including Papervision, Away3D, and Sandy.

Tomohiko went into a quick code demo, showing how it’s extremely easy to code something up. He’s able to attach a cube in just two or three lines of code. Wow! I for one am definitely going to make some games out of this. You should too. You can download an English-language starter kit with everything you need at http://saqoosha.net/en/flartoolkit/start-up-guide/. FLARToolkit is available for free GPL license if your code is open source; otherwise there’s a (pricey) commercial license available from ARToolworks.

The other speaker was Yoshihiro Shindo, from BeInteractive. Yoshihiro is responsible for Spark Project, “Japan’s largest AS3 community.” Yoshihiro, 20 years old, was introduced as the youngest FITC speaker ever. He says that he would rather code ActionScript than eat.

Spark Project is an open-souce Flash community, public svn repositories and all, whose motto is, “Be happy by sharing source code and knowhow with everyone.” A nicer sentiment I did not encounter in all of FITC. Spark Project has over 200 open-source AS projects currently shared, which go all over the map in terms of functionality. FLARToolkit, for one, is on there. Yoshihiro also demoed Sazameki, a powerful-looking audio processing library that both generates and processes waveforms; Frocessing, an AS3 drawing library that behaves like Processing; and BetweenAS3, an impressive new tweening engine.

BetweenAS3 appears to be powerful, fast, and lightweight—the holy triad of tweening engines. BetweenAS3 offers tween processing (reverse, slice, faster/slower, parallel tweening), complete tween control (freely move beteeen “frames” of the tween), action integration (execute commands within a tween), great performance, and low memory usage. Yoshihiro demoed a particle tween simulation with tens of thousands of pixels tweening simultaneously, and BetweenAS3 blew the competition (Tweener, TweenMax, several others) out of the water, in terms of frame rate and memory. I salivated. Unfortunately, BetweenAS3 hasn’t quite released yet, but you are welcome to access the svn repository here. Check it out, branch it, check in fixes—all is encouraged! You gotta love that.

The talk starts out with several demos of “fake” 3D:

• For starters, a swf in which a light source follows the mouse and casts shadows from spheres. It looks 3D, but the swf is literally just rotating and scaling simple movie clips that represent the shadows, based on a simple calculation of the relative mouse position.
• Next, a simple game in which you toss fish to a polar bear. The fish and the polar bear are indeed 3D objects, rendered as static sprites, and placed into a non-3D environment. The illusion of depth is created by simply making the Polar bear (in the background) small relative to the fish (starting in the foreground). When the fish is tossed, its y-position follows a sine curve, and its size scales down, giving the illusion of 3D motion.

Pretty damn simple, and a hell of a lot less work than Papervision. Keep this in mind as you think about your own 3D projects.

The Firstborn guys then talked about a couple of different real 3D frameworks available to Flash developers. They emphasized that Papervision is not always the best tool for the job, contrary to the beliefs of a wide swath of intimidated Flash developers; it really depends on what you want to do. An alternative is FIVe3D,  which stands for Flash Interactive Vector 3D.

• You need a good accountant. This sentence was spoken by the various panelists at least 5 or 6 times. Even if you’re just getting started, you need to get serious and have an accountant. Otherwise you’ll either get burned, or do your taxes all wrong, or end up spending money that isn’t actually yours. Accountants can also give you advice on issues like whether or not to incorporate.
• How do you know if you have a good accountant? You won’t know, until there’s an accounting crisis. Hmmm.
• Contracts. Lots of talk about them. The panelists are in the convenient position of drafting up their own contracts, which I guess is the norm for most web development, though for me doing Flash games, my experience is that the contract usually comes in boilerplate form from the client. Either way you can always make changes to the contract. Here are some of their pointers:
• Pay close attention to the IP—who owns it? Who owns the code? If the client wants the IP or code, make sure you’re charging them extra for it. Otherwise, be clear that you’re keeping it.
• Add a clause about what your IP and assets can be used for. If you don’t want your art to be seen in print or on T-shirts, for example, make clear that it’s only to be used on the web in the context you delivered it.
• One thing you must always ask for a deposit up front. First the money, then the work. Based on the relationship you have with the company and how much you trust it, this deposit could be as low as 30-50%, or as high as the full 100%. Always be careful, and don’t work on spec.
• Add a cancellation clause. If, for example, the project gets cancelled at 90%, but you only got paid up front for 50%, make sure there’s a clause that gets you the extra money you deserve. One way to so this is to specify a cancellation fee, plus the right to invoice for work done.
• If you need to set up a set of boilerplate contracts for yourself, one great method is to hire a lawyer. Most lawyers can make you a solid contract that meets your requirements for about $500.
• Although none of the panelists has ever been sued by a client, they all seem vigilant about avoiding it. How do you prevent a client from deciding, a few months after your project is completed, that the work was insufficient and lost them money? One solution is to do a 30 day warranty—call the client back after 30 days and get them to sign a document saying they’re completely happy. Ideally, the client should be signing documents like this at every step of the dev cycle. Another option is “errors and omissions insurance,” which apparently exists in Canada, though it is very expensive.
• Marketing tips:
• Don’t pay attention to the competition; do your own thing, and it’ll be exactly what some clients want.
• The best marketing is word of mouth. So devote a lot of time to client relations and networking.

Brendan began his presentation, speaking about the past and future of Scaleform, in the form of what appeared to be a visually appealing Flash swf. But then… he backed up and looked around.

It turns out that his entire presentation was running inside a 3D level in the Unreal Engine, with the slides simply projected on a wall in the 3D environment. From time to time he moved away from the wall to demonstrate other Scaleform-driven toys in the environment. This on an ordinary-looking PC laptop, with a flawless framerate. Pretty amazing stuff.

Brendan was careful to point out that what Scaleform does, essentially, is create Flash players for specific platforms, including all the major game consoles. Because game developers typically need all the CPU cycles they can get for their gameplay, and systems like Wii and PSP don’t have a ton of horsepower to offer in any case, Scaleform’s task is optimization, optimization, optimization. From the 3D game engine’s perspective, once a simple interface is made with Scaleform’s API, Flash movies can be treated essentially as 2D textures to be applied to any surface in the 3D environment—walls, TV screens, spheres, anything. Brendan says he hopes someone will use it to create animated tattoos on characters.

The ultimate goal is to allow Flash designers to make pretty Flash content using the tools and tricks they’re accustomed to, and then integrate it into the game engine with a minimum of fuss. Brendan points out that his presentation engine was made by exactly two people: a Flash designer for the UI and other Flash bits, and a 3D modeler for the environment. Of course, ordinarily you’d also need a programmer to connect Scaleform with the gameplay engine, but Scaleform’s engineers have already nicely integrated Scaleform into Unreal Ed (the 3D editor for the Unreal engine), including integration with the Kismet visual scripting service.

As someone who does 3D game work and also does Flash, I’d really, really love to get my hands on this Unreal+Scaleform combo. This would be a hell of a lot of fun to play around with, if nothing else. Of course, Scaleform will not let anyone play around with its stuff, short of purchasing a license which costs thousands of dollars. Brendan mentioned that they’re thinking of setting up some sort of academic licensing in the future, but there are no details on that yet. Come on, Scaleform! Don’t you realize indies are making all the good stuff?

I had no idea how widespread the use of Scaleform is. I’d known it was something game developers use from time to time for UI work; little did I know that it’s pervading the industry, and being used for everything from studio logos, to UI, to entire HUD systems. In Mass Effect, for instance, all of the UI and HUD, including the targeting reticule and the sexy circular interfaces you use to do everything, is Flash. In retrospect, this makes sense—of course those beautiful interfaces were created in Flash! Other games that make extensive use of Scaleform include Crysis, Dawn of War II, Halo Wars, and the pub games in Fable II. Interesting note about those pub games: they were originally released on Xbox live (the Xbox 360’s downloadable content service) before Fable II itself was released. These games were done entirely in Flash with Scaleform. This means that Flash games were released on Xbox live arcade. I’ll say it again: Flash games on the Xbox 360. This is very interesting for us game developers who have been trained to believe that Xbox live arcade will never host Flash games. Again, once I get my hands on this technology, I’m gonna—oops, I forgot, Scaleform doesn’t offer indie licensing. I say again, come on, guys!

The three sessions in question are those of Alec Cove, Mario Klingemann, and Joshua Davis. These sessions were in some ways amazingly similar, invoking procedural repetition of elements to produce visually appealing output, but it is very interesting to compare and contrast the differences in the ways these three guys approach the task. What is the artist's role in algorithmic art? Should he be massaging the algorithm, or massaging the output? Well, apparently either way's fine.

Alec Cove's talk, “Beautiful Algorithms: Design from Nature and Mathematics,” centers on deterministic algorithms (containing no randomness) that transform minimal initial conditions into complex and beautiful output. This output often resembles patterns seen in natural organisms such as flowers and seashells, which, as Alec points out, is the result of algorithms in the DNA.

Alec's slides are available here. Here's a quick summary of what he went over:

• Repetition combined with geometric transformations (scale, rotation, translation) yields interesting patterns. Examples include corn, spikes on a cactus, mandalas in Darmic art, and plants in general.
• In a sunflower, for example, seeds are packed in a golden spiral pattern. This is actually the most efficient way to pack seeds into a limited space, and it looks beautiful to us; apparently there is some beauty in efficiency.
• Cellular automata – a conceptual simplification of biological cells, whose life or death depends in various ways on their neighbors. Manipulating the binary life/death rules yields tons of variety – unstable patterns, stable repeating patterns, and stable chaotic (non-repeating and non-dying) patterns. Examples of this include Conway's Game of Life, and Stephen Wolfram's opus, A New Kind of Science.
• Other examples: L-systems; reaction diffusion; sound vibrations; chaotic systems such as the Lorenz Attractor.

All of Alec's experiments involve deterministic systems—nothing is randomized. The complexity comes instead from the interplay of the algorithm with the initial conditions, yielding either a chaotic system or something that is complex but repetitive. Alec’s artistic method seems to center around picking the right algorithm: he plays with lots of different algorithms till he finds one that is pretty. Once he finds it, the next step is to find a good visualization by playing around with things like colors and alpha.

The overriding point of Alec's talk (or one of ‘em, at least) is that repetition + variation = beauty.

Mario Klingemann's talk, “The Tinkerer's Box,” explored algorithmic art from a different angle. Most of the algorithms in Mario’s talk rely on randomness for their variety, as opposed to the chaotic non-random systems from Alec’s talk.

Mario’s slides will soon be available here. Here’s a summary:

• The topic of this talk is the various algorithms Mario has been playing around with to generate interesting visuals. He starts off by describing why the iterative playing-around process is so important to him; he feels that tinkering is important even if the end result is not meaningful. If you manage to create something meaningful along the way, he says, that’s a bonus.
• Chapter 1 is subdivision—drawing lines within a polygon to break it into sub-polygons. Mario demonstrates how subdivisions can be evenly spaced, producing an even (and boring) output, versus random orientations, which produces more irregular (and interesting) output. Some of these are automatically generated, but in most examples Mario generates a subdivision by clicking in the area he wishes to subdivide. This allows him (the artist) to drive, or at least impact, the final output.
• Everything Mario shows is being generated live in swf’s, which is fun to watch. Most of his examples have a menagerie of sliders and buttons to manipulate the algorithm; most of the time Mario doesn’t remember what these controls do, since he neglected to label them after coding them up.
• As Mario’s examples of subdivision progress, the pictures gradually get prettier and prettier. As a grand finale to the subdivision chapter, Mario demonstrates a system in which a photo is obscured beneath a colored rectangle. Each time Mario clicks, a subdivision is generated, with each new polygon taking its fill color from the center of the underlying portion of the photo. The exact position and angle of each subdivision is randomized, leading to irregular output. As he clicks and clicks, generating successively tiny triangles which act like irregular pixels, details start to emerge. He clicks more for extra detail in important areas of the photo; other areas are left barren. When it’s done, it looks crazy and beautiful.
• Chapter 2 is stippling: using a distribution of dots to represent a grayscale image.
• Chapter 3 is convolution. Using a photo or other image as a base, simple convolution filters can be applied on the pixel level to determine the x and y component of nearby angles, generating an angular signature for the area.
• One of the things Mario does with convolution filters is draw little linear brushes on various spots in an image (generated randomly, of course), where the orientation of the brush is determined by one of these angular convolutions, and the color is sampled from the underlying pixels in the image. The result is a swirly Van Gogh-type effect. Mario points out that this, as well as lots of the other toys he’s been showing, is available in the free web-based tool he’s been working on at http://aviary.com/tools/peacock.
• One of the last points Mario makes is that all of the algorithms he uses—from convolutions, to line intersections and calculating new polygons, and everything else—come from outside sources, such as books on numerical algorithms in C, Wikipedia, and Mathworld. He also looks at proceedings from Siggraph; he claims that he only understands 10% of what he reads there, but it’s enough to get him started tinkering. He equates this whole process with playing Legos—finding formulas here, coding tricks there, and sticking them together in every which way till something good comes out.                                                                                                  

Rather than looking to nature for his algorithms, Mario looks anywhere and everywhere; he tinkers with these algorithms in an iterative process where nothing’s out of bounds, till they start producing interesting output. The artistic method here is much more deliberate than the one described in Alec’s talk. The choice of algorithm is arbitrary; additionally, in many of Mario’s examples, the artist drives the output itself by, for example, clicking to generate subdivisions. Quite opposite to Alec’s talk, here there’s randomness everywhere: in the code itself, in the complex initial conditions (an entire photo, for instance, as opposed to Alec’s single pixel or two chemical points), and in the artist’s choice of where to generate subdivisions.

Joshua Davis’s Talk, “Space,” recounted the trajectory of Joshua’s recent explorations in generative art, with several examples of algorithms he has used and the process he went through to massage beauty out of them. Sound familiar? Yeah, that’s how I felt. Of course, there are some critical intricacies to Joshua’s process that make it completely unique.

Here’s a summary of what Joshua talked about:

• Repeated reference to Red Bull, as Joshua attempts to fit 3 hours of material into 60 minutes.
• Quite like Mario, Joshua expounds the virtue of constantly giving himself new projects—new stuff to play around with and learn from, as if he’s constantly going to school. Recently, Joshua has been giving himself projects related to the concept of space, partly in order to address a convention themed around space he’ll be speaking at later this year.
• The first example Joshua demonstrates is an orbit system, which simulates orbits. The code randomizes initial conditions, such as planet mass, position, and velocity, then simulates a Newtonian orbit. To get something interesting out of this, Joshua simply throws some interesting visual pieces into it—these could be anything, but generally they tend to be little objects that he illustrates by hand. He sets these bits off in their random orbits, and sits back till he finds a good, artistically satisfying moment to snap off a screenshot. And there it is.
• Joshua points out that he is using OOP to re-use code and save a lot of time in his work. This example is his “Orbit” class, which he can plug in wherever he wants. Using Orbit in combination with different pieces of art and other classes, he can generate totally different pieces of art for diverse clients.
• Another experiment Joshua describes is his quest to make a good-looking kaleidoscope image. The important thing with any kaleidoscope is that it can work with any arbitrary set of visual data. So after coding up a Kaleidoscope class, he set about fiddling around with different inputs until he found something he liked. He ended up plugging in a set of little illustrated Christmas bulbs and snowflakes, which he has illustrated with a muted, earthy color palette. Lo and behold, the output of these was beautiful, and Joshua ended up giving away prints, each one unique, as Christmas gifts. Joshua is currently finishing up an iPhone app called “Reflect” which uses this kaleidoscope tech. He’ll probably make tons of money off of this—another example why you should build your algorithms as classes!
• The last experiment Joshua shares is based on Bezier curves. Like Mario, Joshua makes no attempt to memorize or even understand the math; in this case he simply took a simple Bezier tool someone else had helped him code up, and started messing around with it. Bezier curves require four points: start point, end point, and two anchors to define the curvature. Joshua realized that if he set up rectangles to define areas within which each of these points can be randomized, the result is a complex “flow” of particles. Joshua demonstrates moving shapes along the curves, then deforming the shapes along the curves, which looks cooler. He then shows that turning down the alpha has a huge effect, giving the flow a cloudy appearance. All of these manipulations were the result of Joshua dicking around, and the final result is breathtaking.

Joshua calls his artistic method “computational design.” As he puts it, “I write code to make design.” I imagine Alex and Mario feel the same way, at least as far as their sessions are concerned. All of these guys have demonstrated how a Flash developer can take a mathematical method and tweak it one way or another until he ends up with something that looks good. Joshua’s method of tweaking relies heavily on duplicating and manipulating artistic elements that were illustrated by hand. Mario’s method relies on lots of randomness, and control over where to apply the algorithm. And Alec’s method depends more on carefully constructing algorithms and initial conditions, in order to produce art in a completely deterministic manner.

Clearly, any of these methods works. The important thing is that all these techniques allow some form of artistic control—parameters, visualization, and simply the ability to choose when to take a screenshot in an evolving system. Lesson learned: repetition + variation + artistic control = beauty. At least, sometimes.

• Scripter (learning the language)
  
• Developer (learning structure)
  
• Architect (learning reasoning)