Experiment #1: http://blog.dcholth.com/beta/RotTester/RotTester.html

The images are laid out in a grid, with each image’s rotations (XY & Z) being set to the values of the numeric sliders at the top.  As you can see, each image’s perspective looks different, because they are placed in a 3D environment with the ‘camera’ being set to a specific point.  I had a heck of a time figuring out how to set that camera!

If you look at http://livedocs.adobe.com/flex/3/langref/flash/display/DisplayObject.html#rotationX  it says “Indicates the x-axis rotation of the DisplayObject instance, in degrees, from its original orientation relative to the 3D parent container.”

Well, in the example above, each image is placed in its own Canvas - my best guess was that the parent canvas should be its ‘3D Container’ so the rotation should be based off of that, but clearly it was basing off some other point at the Application level.

I posted my frustrations with this a few places, and finally fellow Universal Minder, Ryan Graff came to the rescue, with the missing piece:  PerspectiveProjection

Setting the PerspectiveProjection of your target’s Transform will give you the results I believe most developers will be looking for.

Experiment 2: http://blog.dcholth.com/files/PanelTest/PanelTest.html

The image in the TitleWindow on the left has its PerspectiveProjection set to be the center of the TitleWindow, where as the image in the TitleWindow on the right has the default properties.  Notice that dragging the TitleWindow on the right around the screen results in distortion of the image, where the image on the left remains tilted exactly how we want.

Experiment 3: http://blog.dcholth.com/files/RotatorTest/RotatorTest.html

Back to our grid of images, here we set the images PerspectiveProjection to point towards the red dot.  Drag it around the screen to see how it effects how each image is percieved.

In conclusion, I believe that most developers will want to take advantage of the PerspectiveProjection’s properties when working  rotations of UIComponents in 3dSpace.

I started to build out my activity component using states. One state for when you enter the activity, one for each of the three phases, a cleanup state and finally an exiting state. As I developed the components and created their enterState and exitState functions, as well as many functions only used while in a specific state, I realized that my component was getting to be well over a thousand lines of code and a bit unmanageable. To find the logic pertaining to the current section I was working on, I had to sift through hundreds of lines of code. I decided there had to be a better way… and there was!

I started by creating an AbstractActivityState that extended the State class. This had had any common properties and logic, as well as a bindable “Activity” object. This worked well for accessing the public variables of the activity. The problem came with private variables. While I would have had access to these if I had written all my logic within the Activity MXML, since I was passing the Activity object into my states, they were inaccessible.

There were three solutions I found for this problem:

1. Make all the properties you need access to within the state public, and break encapsulation rules.
2. Add additional Bindable properties to the the custom state classes and pass in the bindable private variables.
3. Create a StateMiniModel that had all the bindable properties I needed and simply pass it to the custom state. This is handy if you don’t want to break encapsulation but have a great many common private variables to be passed to all your custom classes.

To make things even more simple, I added some listeners and protected ‘enter/exit’ classes to be called from within the AbstractActivityState so I when declaring my states in MXML I didn’t need to give it anything other than a name.

I’m very excited about the MapQuest API and all the possibilities it offeres developers for creating mapping applications. I wanted to test the API and sharpen my own skills, so over the past few days I’ve been working on a Facebook geocoding application that will put any of your friends with current locations set on a Mapquest map.

It may be because I’m using a free developers license key, but I’ve noticed a few of the locations aren’t geocoding properly. For example, Roseville MN is turning up Roseville California.

I haven’t submitted the application to the Facebook library yet, but feel free to try it out and post any feedback you have either here or on the application about page.

The talk will include information on building application using the MapQuest Advantage API, AIR and Flex Builder 3.

While I think flash could have handled having that many MovieClips on screen pretty easily on its own, I wanted to see if I could make it more efficient. The solution I came up with was to use two BitmapData layers, one for moving the stars on the screen and creating the ‘twinkling trails’ and the other for housing all the stars in their final resting place.

The two layers of BitmapData (trailsCanvasBmp, and finalBallCanvasBmp) and a ParticleManager class to track the movement of the stars and slowly fades out the trailsCanvasBmp to give the twinkling effect while its moving. A star is created in the center of the screen, then shoots off to its random location. When the tween is complete the star is drawn to the top finalBallCanvasBmp class which is never cleared.

On each frame a random pixel is chosen from the finalBallCanvasBmp and if that pixel is NOT black (0×000000), then it attaches an mcTwinkle MovieClip which destroys itself upon finishing its animation.

The effect is really quite cool! You get the sense that each star is operating under its own principles, but its actually just two BitmapData objects interacting with the ParticleManager.

You will notice some major performance hits if you tell it to make too many stars at one time, or if the screen gets literally filled with stars, their may be more twinkling than your computer can handle. We’re on some beefy machines here at work, and I have had over 20,000 stars and haven’t noticed a performance hit. So your movies can truly be “Full of Stars”. ($1 to who ever can name the movie reference*)

There are a few other things going on here that I can elaborate on if requested. The background is generated using Perlin noise (so really there are 3 Bitmaps). Each star is colored using my Pallet class I can upload if desired. Full code for this project can be uploaded.

I made some modifications to Grant Skinner’s grid based proximity manager to take advantage of an IProximityDetectable interface. For a full explanation on how grid based proximity management works, check out Grant’s original post on the subject. The IProximityDetectable interface has only two methods:

interface IProximityDetectable {
public function getPosX():Number;
public function getPosY():Number;
}

As might be assumed, they retrieve the ‘x’ and ‘y’ position of an object. Why implement this? Well, the original ProximityManager used the _x and _y values of a MovieClip, but my spider web particles don’t actually have any MovieClips. Its just adjusting x and y values of an object in memory, and drawing lines to the new distance. The ProximityManager is used for drawing the lines between particles based on how close they are to each other.

So how do the particles move? Each onEnterFrame the ParticleManager calls the tick function for each particle.

public function tick():Void {
canvas.moveTo(x,y);
x += xVel;
y += yVel;

xVel *= drag;
yVel *= drag;

yVel += yGravity;
xVel += xGravity;

var f:Number = Math.abs(xVel) + Math.abs(yVel);
alpha -= f/__lifeSpan;
canvas.lineStyle(2, rgb, alpha);
canvas.lineTo(x,y);

if(alpha <= 0){
manager.removeSpark(this);
}

var n:Array = pm.getNeighbours(this);
var l:Number = n.length;
for(var i:Number = 0; i < l; i++){
canvas.lineStyle(1, rgb, alpha);
canvas.moveTo(x, y);
canvas.lineTo(n[i].getPosX(), n[i].getPosY());
}
}

Each particle starts out with random velocities for x and y. These velocities are added to the x and y position of the particle. Drag is applied to the velocities to slow them down. The drag is set to such a small value in this particular instance that it really doesn’t have much of an effect. Gravity along the x and y axis is then applied to the particle The gravity values are generated randomly when the particle is first created and unlike the velocities, has no baring on its parents value (in the instance of a branched particle). Since gravity is random, it may pull particles up, down, left or right. After all moving is done, the particle uses asks who its neighbors are and draws lines to them.

Speaking of branching, the ParticleManager does a probability calculation for each particle during the onEnterFrame which determines if a particle will branch. Each particle has a chance to branch, so growth can occur exponentially. To keep particles from branching too much, this calculation is ignored if the maximum number of particles has been reached (default to 40).

Once each particle has been moved and had its connections drawn, the entire image is drawn to a Bitmap and color/alpha adjusted to fade away slowly. All and all a pretty neat little effect.

I’d like to move this to AS3 eventually to see if I get crazy speed increases! I’ve put one last experiment below which allows you some control over different variables in the spider webs. Be careful when making adjustments… You can easily give your computer a heart attack.

Seb Lee-Delisle gave a great presentation on Particles for the Non-Physicist. I have worked a bit with particles on my own, but never really understood the possibilities of what a particle system could do. Seb pointed out all the spots on the Plug-in Media website that have particles - way more systems going on there than I expected.

I had a chance to speak with Seb after the session as to how he made the merging borders around the cartoon smoke effects and dripping ooze (from the Plug-in Media main page). He said you needed to have multiple layers of particles. So, when I got home, I downloaded the demonstration files and got to work. Below you can see the results. Its a really cool effect.

The important thing when creating the two layers of particles, is that each layers of particles must have matching properties - only the linked movieclip is changed. You can see that the background particle is darker and larger than the foreground, but they move and grow in unison. This allows the background particle to be the border around the lighter front particles and merge together seamlessly.

My next step is to figure out how to use a particle system to make a MovieClip appear on fire. If you’ve seen my fire effect code, it uses a computationally-heavy method of duplicating, distorting, coloring and fading the MovieClip. I think the particle-system effects could be used to create the fire instead.