If you're one of those crazy kids who I've heard about who like to follow my internet adventures and laugh at me, you've probably been duped into trying the original FSH or HSL. Well, here's FSH updated for the future, in three dimensions! (Colour, size and quality of dimensions may vary.)

After Snowdon, Dr. Kain and Blast Arena Advance, I felt ready to try my C mojo out on that oft-mentioned beast of modern graphics: OpenGL. Once again, I dived into the net, grilled some of my more knowledgeable, electronic literature savvy contacts and prepared a sizeable pile of indescribably unreadable tutorials for myself.

After working through the NeHe tutorials (Ya can't just copy these things from the source archives, you know. You gotta read the interesting words, too! ^-^) and some other stuff, I picked the first thing I could think of, FSH, and set to work giving it a 3D workover.

The Handkerchief is now rendered in OpenGL-n00b-tastic 3D! There's three points you can control, but it's a little different this time. I had some trouble trying to get the handkerchief to thrust around all floaty like in the original HSL, so you control the points differently.

When the simulation starts, the handkerchief will begin to fall, but will hang from a single point. This point is point 3, and is controlled by the right hand side of the keyboard. On the opposite side of point 3 is point 1, which is controlled by the left hand side of the keyboard. Another point, point 2 is controlled by the middle of the keyboard.

Point 1: W, A, S and D move the point up, left, down and right relative to the original camera position. Q and E move it backwards and forwards into and out of the screen relative to the original camera position. Press X to toggle fixing the point in space.

Point 2: T, F, G and H move the point up, left, down and right relative to the original camera position. R and Y move it backwards and forwards into and out of the screen relative to the original camera position. Press B to toggle fixing the point in space.

Point 3: I, J, K and L move the point up, left, down and right relative to the original camera position. U and O move it backwards and forwards into and out of the screen relative to the original camera position. Press , to toggle fixing the point in space.

Camera: Use the left and right cursor keys to rotate the camera about in space around the centre. Use the up and down cursor keys to swoop the camera up and in and out. (Just try it, okay? :D) Use Page Up and Page Down to move the camera in and out.

You can toggle the texture mapping detail (nearest, or smooth) by pressing Home, and you can switch between fully bright and badly lit modes by pressing Delete. Press End to toggle the size of the floor. You might notice some of the tiles lighting up when you press keys... that's because I was using the floor to report scancodes. (I couldn't find out how to detect the comma key :() Hopefully, this should make a little more sense...

It looks pants, but it's my first non-tutorial OpenGL gadget, so give me a break. Before I start doing neat crap like trying to subdivide the 'chief (or just the visual representation of it) to make it smoother, I'd like to give internal collision detection a shot. You may have noticed that the free corner of the handkerchief seems to spin about and sometimes fly through the rest of the 'chief when the other three points are fixed. I think I can fix this by checking each point's motion against each triangle of the FSH, comparing before and after values against the equation of the plane described by the triangle, denying motion if it crossed the sign boundary. However, that wouldn't stop the handkerchief swooping down on top of loose points. (Imagine dropping a handkerchief on top of a pyramid, and the top of the pyramid simply schmoozing through the 'chief.)

OpenGL is... odd. I'm sure I'm missing something with the way this whole thing works. until I figure out what that is exactly, I'm going to keep at it and see what happens.

HSL and FSH are particle spring experiments I wrote in Blitz Basic in the summer of 2003. FSH stands for 'Floating Space Handkerchief' whereas HSL doesn't stand for anything.

During my work experience in Year 10 (Which must've been around May 2002) I was introduced to a freeware bridge building game, going by the moniker of Bridge Builder. The DT teacher was using it to teach kids about strong and weak structures and I, as usual, was roped in to help. Fascinated by the games mechanics, I researched the game and it's creators, Chronic Logic. Eager to assist me in my endeavors to be cool, Chronic Logic gave me a few leads on how to create a similar engine, which they referred to as a 'Particle Spring' system.

My initial research into particle spring systems led to a mangled mess of an engine, so I researched further. Later, I stumbled across Paul Bourke's site, which discussed all manner of complicated mathematical modelling and visualisation techniques, among which I found detailed fun on particle spring systems.

From his explainations and a heck of a lot more research and extrapolation, I came up with the first working Blitz Basic version of FSH, a basic particle spring simulation of a grid of nodes connected by springs, the finished model resembling a free-floating wireframe handkerchief. Later, I implemented breakable springs and wall collisions, calling this second iteration of the system HSL.

When you start FSH, you can move the top-left particle about using the cursor keys.
Holding the left mouse button will change the cursor key control to the bottom-right particle.
Tapping X will sap all momentum in the system.
Escape lets you quit.

There's no objective to FSH, just fling that thing about! It'll respond to fast jerks, or prolonged dragging, and you can also spin it.

Here's where it gets interesting! ^.^

The cursor keys will control the particle in the top left. W, A, S and D will control the one in the bottom-right.
Tapping X will sap all the movement in the system.
4 and 6 on the numerical keypad will control the speed of the simulation.
* on the numerical keypad will switch between SPRING and DAMPING constant selection.
+ and - on the numerical keypad will increase or decrease the currently selected constant.
Right mouse button resets the game.
Escape lets you quit.

The system in HSL takes on a more 'solid form' than in FSH: you're in control of a wireframe box. Your objective is simple: smash that box to pieces. Smash it into the floor! Smash it into the walls! Spin it around and watch the forces on it tear it to shreds! Spin it around and grind off the corners on the confines of the window!

The three numbers in the top left of the window are your score: Percent Liberated Nodes : Percent Broken Links : Average (Your actual score). Try to get 100% : 100% : 100%!

Manipulating the constants will alter the behaviour of the box:
Spring Constant : Incrementing this constant will cause the box to become stiffer as the springs holding the box together become more powerful in reacting to deformations. Increasing this beyond 0.5 will cause the box to vibrate itself into oblivion as it tries to over-compensate for any deformations inflicted on it.
Damping Constant : Incrementing this constant will cause the box to become stiffer, altering the way the spring reacts to nodes moving at velocity. Increasing this beyond 0.13 will cause various springs to vibrate erratically, sometimes causing the centre of the box to spontaneously disintergrate.

Everybody loves little toys like this, don't they? While creating these, I learned all sorts of neat tricks using dynamics and integrators, so I can create more cool stuff in the future!

As I went back to do these programs up a little, I realised how crap they really were, programatically. Proper simulations would have proper intergrators taking arguments for 'length of simulation per step' and 'steps to take per shown frame' but HSL and FSH simply calculate the motion of the particles per shown frame arbitrarily. This means that they're hideously inaccurate and totally unsuitable for any real modelling purpose. This doesn't mean it's not fun to watch a springy thing bounce about like mad!

It's interesting to note that effects such as fabric rippling and centrifugal deformation are simply side-effects in the implementation of this system: no special code was added to cause a spinning box to tear to pieces.

During the programming of the engine, some truly bizarre errors were produced, causing the box to spin, vibrate, explode, or simply to morph into a different shape spontaneously. Some of the more weird situations caused the box to 'chomp' like a jaw, or to oscillate between different regular shapes.

You might want to look into Sodaplay, which is a similar doodad written in Java. (I think) Sodaplay implements connections which can be programmed to vary in length, allowing for walking and rotating structures to be built.

Also, sometime in 2005, Kyle Gabler created a similar, cooler game called Tower of Goo as part of the Experimental Gameplay Project. Y'all should check that out. As in right now. Immediately. (But make sure you've got a quite big monitor, because the game window is tall and non-resizable!)