I am loading a bunch of DisplayObjects and lining them up horizontally by grabbing their .width property and separating each by a certain margin. In doing so, I encountered a bizarre quirk in Flash. Sometimes, Sprites report a massively negative width ( -107373134.4, to be exact ). This occurs when I have attached a DisplayObject that has begun playing a NetStream but has not yet received metaData for the stream (a local .flv). My row gets all confused and places the next object at that massively negative location, which bungles up the rest of the view.
Okay, so the issue was coming from setting the position of the playhead based on the progress of the video before the video had made any progress. Rather than reporting the attempted access of an undefined value, flash decided to try to place the playhead in non-space. While theoretically cool, this prevents practical things from happening. A simple conditional statement fixed things if( video.progress > 0 ) position stuff.
Going back on my promise, I revisited my BitmapSmoke class and created something beyond cheesy. Move the mouse to position the heat/smoke source. Regardless, this one is all AS3 and was used primarily as a means to play around with displacement maps. The included Displacer class accepts a movie clip to displace and a map to displace it with, then updates the displacement every time you call run(). What's neat is that you can keep updating the map you passed in, thereby animating the displacement. Banners are looking better all the time.
Yesterday, I had to create a simple, versatile smoke effect in flash. The obvious choice was to use a BitmapData object as the drawing surface, since layering enough vector objects to obtain satisfying gradations of light and dark would eat all of the rendering power. As a solution to the problem, I created a simple BitmapSmoke class that accepts a container, dimensions, and any number of paired source shapes and emitters to generate the effect.
There are a few options for creating the effect. One is to successively apply a blur filter to the BitmapData (henceforth 'canvas'). This works quite well with only one emitter, as the background tends to dominate in successive blur passes (as demonstrated by Andy Zupko). However, when you have a lot of smoke occupying the canvas, you will overwhelm the background and blend everything up to your smoke colors. Instead of applying a blur filter, then, we can redraw the canvas onto itself with a transform on both position and color. By using a colorTransform to constantly reduce the alpha of the pixels in the image, we can guarantee we'll never encounter a whiteout. These techniques are not exclusive and I have taken advantage of both of them in generating my smoke effect. Included here are some randomly wandering particles that take advantage of a Vector3D class, the bitmap effects, and an .fla that implements them.
Unfortunately, the smoke effect was created for a banner and is consequently programmed in AS2. I'll post an AS3 version of the code if I can think of something that isn't completely cheeseball to use it for.
This Thursday, I will be giving the design team at Domani Studios an introduction to Processing as a design tool. This image is from a sketch I did today as a preparatory demo ( it uses for loops to draw a grid, getting colors per-square from an image ). I’ll post documentation of the introduction in the form of an expanded outline after Thursday.
I pulled together a quick design for the Ava Luna demo cd today, and we used the Hernandez’s printer to shoot it onto vellum that we lovingly inserted into the slim jewel cases by hand. Carlos is trying to get our name out among nyc bands so we can join up with them for shows around town (anyone interested can leave a comment…). There are more ava luna photos up on flickr, including one of carlos operating the paper-cutter.
The graphic was created using a two-dimensional l-system. Lindenmeyer systems are grammar-rewriting systems originally created to simulate plant growth. As one part of the plant, like a bud, will generally resolve into another part, like a flower (which in turn yields leaves), you can iteratively rewrite the description of the plant by following a set of rules at each step in the plant’s life. Instead of replacing young plant parts with mature ones, I replaced directions (like right, left, up and down) with lengthier directions at each step (like move left then turn around). You can read much more about l-systems and other recursive structures in The Algorithmic Beauty of Plants. I implemented the l-system interpreter and turtle renderer in processing. I’ll post source code if anyone is interested.