Springback 21 May, 2008 at 7:01 am
If you don’t do technical, you probably want to tune out right about now. Follow the link to play with things on springs, and press space to randomise the configuration. *boing!*
Flash Link: springpixel_02.swf
I spent some time over the weekend reacquainting myself with the spring simulation Flash project I displayed in an earlier post. I wanted to try out a new effect from the next part of the book, but ended up getting heavily bogged down in trying to work out how to make an object (a class) have it’s presentation (a MovieClip) as a member, rather than have the class itself inherit from the MovieClip class. Up to this point, all of the little balls and boxes were instantated at design time in the Flash editor, which is clearly not The Way Things Should Be, and was seriously limiting my options for creating arbitrary (randomised) configurations.
Other soon started to pop up, such as how to access configuration information for the simulation, such as the acceleration due to gravity and the friction constant. The original design allowed my spring items (things on the end of springs) and springs to ‘globally’ access that information by virtue of them being static class members, but I decided that the SpringSimulation objects should be allowed to vary these values between instances… not that I really expect to be running multiple separate simulations, but it could be interesting for “side by side” type comparisons.
One of the main reasons I wanted to see if I could get this to work without having to inherit from MovieClip is the question: how do you instantiate an object of a MovieClip subclass? MovieClip objects come to life by using the attachMovie() method, not by calling a constructor. Hang on a minute… hold the phones, Batman! Maybe the answer is to just override the attachMovie() method in the subclass! D’oh! I will have to try that later! For now, on with my solution, which was to create a new, simple subclass of MovieClip, with the single added member, handle (of type Object), which can be used to refer back to the main object for which the MovieClip derivative is the “display” of. I needed that because when I started wanting to do things like add an onClick() handler to drag items around, the handler had no way of otherwise referring back to the object it needed to update – big problem!
Here are some snips of code (note: numerous details not related to the issues discussed, such as the physics calculations, are left out):
class SpringItem
{
public var dragging:Boolean;
public var sim:SpringSimulation; // Parent simulation
public var mc:SpxlMovieClip; // Visual depiction of item
public function init(simulation:SpringSimulation, movie:SpxlMovieClip, ...)
{
sim = simulation;
mc = movie;
dragging = false;
mc.onPress = doDrag;
mc.onRelease = mc.onReleaseOutside = doDrop;
mc.handle = this;
}
public function doDrag():Void
{
//NOTE: "this" is the movieclip instance, not the SpringItem object.
var mc:SpxlMovieClip = SpxlMovieClip(this);
mc.startDrag();
var si:SpringItem = SpringItem(mc.handle);
si.dragging = true;
si.vx = 0;
si.vy = 0;
}
public function doDrop():Void
{
//NOTE: "this" is the movieclip instance, not the SpringItem object.
var mc:SpxlMovieClip = SpxlMovieClip(this);
mc.stopDrag();
var si:SpringItem = SpringItem(mc.handle);
si.dragging = false;
si.vx = si.sim.vxm; // The SpringSimulation object has vxm and vym members
si.vy = si.sim.vym; // ..that are updated with "mouse velocity" for each frame
}
}
It seems like a lot of hassle, but it works. There is probably a better way! The SpringItems don’t update themselves, the SpringSimulation object is in control – it processes all the springs in one pass (adding per-component accelerations to each involved SpringObject’s vx and vy values), then updates the positions of the items in a second pass, ‘all at once’, as it were.
The MovieClips (eg the red balls) need a reference to the parent SrpingItem object, and each SpringItem needs a reference to the SpringSimulation object for various constants, and the SpringSimulation object actively manages the SpringItems. Curiously, the Spring class has no dependency on the SpringSimulation object: for it’s calculations it needs only the the two ends (SpringItem objects, which do contain references to the SpringSimulation, but these are not used or required), the relaxed spring length and the spring constant. I guess that means I could have two separate “simulation” environments running with a spring connecting across both of them… Synchronisation will likely be an issue, but I’m sure it always is when you are affecting objects in parallel universes! ;o)
Anyhow, the new version likely behaves similarly (if not identically) to the original, so it might seem that a major refit of the plumbing was a waste… only now I can generate objects on springs from code (yay!) and easily create randomised arrangements and “chains” (springs made out of lots of little springs) which have some pretty cool play-with factors, though I think the nature of the simulation means things are far from smooth, and changing some settings (like making the masses quite small) really makes the simulation wig out with unacceptable crazy highspeed superwobbles (yeah, that’s the scientific term!). I didn’t quite get around to implementing the next effect/idea from the book, but maybe that, too, will be easier now that some things have been fixed up.
In any case, space resets, only now with a completely new set of spring connections instead of only varying the strengths, weights, item locations, etc, up and down arrow keys increase and decrease the gravitational effect, and z sets “zero-G”. :o)
Enjoy!
New version: springpixel_02.swf
Original: springpixel_01.swf
-G.
