d.c.Holth

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.

As promised, you can now download the code used for my web spinning projects. There is one fla, and four classes.

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.

Made a few small technical changes… May not be noticeable to most. In the previous example, each particle received a random Y axis based gravity. When gravity was negative, it forced the particle up, and positive gravity made it go down. I’ve also added an X axis based gravity to this example, increasing the curvature and randomness of the webs.