| SPXL.TVblog | contactgallery | videoflash | processingmyspace | facebook

Category / Physics

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);
        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);
        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)


New version: springpixel_02.swf

Original: springpixel_01.swf


Blackle holes? 24 April, 2008 at 7:13 am

I’ve been reading about black holes recently, you know, those things that Hawking eats for breakfast, but Blackle is something else: a rebadged Google search, painted black “to save energy”, because the white background of the usual Google search pages uses too much power.

What the?.. Sounds like the kind of pseudo-scientific slight of hand or turn of phrase that might make the writings of the Saturday-morning-doorknocking witnesses on evolution (or lack thereof) seem plausible.

An LCD panel uses less power than an equivalent CRT (well, let’s say most of the time – there may be some extreme examples where this is not the case, but not that I know about). LCD = good. LCD screens work with a backlight – a white light behind the (sub-)pixels, which produce the coloured display we see by blocking some of the white light: if you block the red and the green, you’re left with blue. As a side note, now that I think of it, it’s ironic that this ‘emissive’ colour mixing property we typically associate with screens is, in a sense, actually an absorptive colour mixing technology! Perhaps it is better to think of it as transmissive, as opposed to reflective colour mixing (eg CMYK printing). Actually, though, the LCD’s white backlight is separated into red, green, and blue subpixels before the ‘liquid crystal’ part, so each LC cell only deals with one of red, green, or blue light, and it is our eyes that do the actual mixing (this is called optical mixing), such as is with pointillism or divisionism (chromoluminarism) of the impressionists in the art world.

An LED display (think big, like an outdoor display) has red, green and blue lights (maybe white as well), so is an RGB(W) display, for which one might expect having less lights on (ie more black and dark colours) to require less power. A LCD screen (such as in most laptops and most flat-panel displays) is, in a sense, a minus-RGB, or anti-RGB device, but does blocking the light take more or less power than letting it through? That I wasn’t so sure of, so I had a quick read of the technology behind LCD displays before keying the following message to Blackle via their contact page:

On LCD technology…

“The optical effect of a twisted nematic device in the voltage-on state is far less dependent on variations in the device thickness than that in the voltage-off state. Because of this, these devices are usually operated between crossed polarizers such that they appear bright with no voltage (the eye is much more sensitive to variations in the dark state than the bright state).”

Given that most (if not all) LCD screens are probably twisted nematic devices, and producing black on such a device requires application of a voltage (, then surely displaying black instead of white u