Andrew Hoyer

Building the Zoetrope

2011-09-28T00:00:00-07:00

Building a Zoetrope using web technologies was an idea that had been festering for many months. It wasn’t until I saw Google’s tribute to Jim Hensen that I actually decided to sit down and do it. The implimentation turned out to be relatively simple and allowed me to really play around with some of my favorite features of CSS3.

Construction

The basic structure of the Zoetrope is quite simple. The outer wrapper div (div.zoetrope) is only used to do things like rotate about the x-axis. The inner div (div.frames) is the container that actually does the rotation about the y-axis and facilitates the animation. All the divs inside of div.frames are the individual frames of the animation.

<div class="zoetrope">
    <div class="frames">
        <div></div>
        <!-- 22 other divs left out for brevity -->
        <div></div>
    </div>
</div>

Building the ring

The idea behind the ring shape was actually taken from one of surfin’ safari’s CSS3 examples. The basic idea is that you take a single div, rotate it about the y-axis and then translate it out of the page slightly. You then continue to do this until you have a complete circle.

In my case I wanted to be able to create some pretty smooth animations so I decided to go with 24 frames, which meant 24 divs all rotated slightly. This as it turned out was extremely tedious and boring, so I ended up writing a small ruby script that generated a css (I could have also done it with a SASS function or two) file that contained something like this:

.frames > div:nth-child(1) {
    transform: rotateY(0deg) translateZ(380px);
}

/* 22 other declarations left out */

.frames > div:nth-child(24) {
    transform: rotateY(345deg) translateZ(380px);
}

The gist of it is that each div inside of the frames container is rotated 15 degrees, then translated out of the page 380 pixels. Doing this 24 times results in a complete circle:

Different colors on different sides

A key feature of the zoetrope is that the inside of the ring contains the animation while the outside is generally plain. I assume this is done so that the eye can focus on the frames flipping by when it begins rotating. There were two obvious options to do this.

The first would be to just add a bunch more html such that every frame div had a corresponding “outer” div. This would work fine, but would also require a ton more html and css. The second approach, which I ended up using, was to just use a :before selector and position a pseudo element slightly away from the original div which actually houses the animation frame.

/* Shared Styles */
.frames > div, .frames > div:before {
    position: absolute;
    height: 100px;
    width: 100px;
}

/* Animation frame (inside the ring) */
.frames > div {
    background-color: white;
    background-image: url("../images/muybridge.jpg");
    backface-visibility: visible;
}

/* Outside the ring) */
.frames > div:before {
    content: "";
    background: black;
    width: 102px;
    /* HACK getting the :before positioned outside the wheel... */
    transform: translateZ(1px);
}

At this point we would end up with something looking like this:

The slits

The slits used a similar approach as the outer dark ring. Although this time it was just an :after selector with a couple special properties set.

.frames > div:after {
    content: "";
    top: -98px;
    width: 102px;
    height: 100px;
    border-left: 35px solid black;
    border-right: 35px solid black;
    border-top: 15px solid black;
    border-bottom: 15px solid black;
    box-sizing: border-box;
    transform: translateZ(1px);
}

The key thing to note here is the box-sizing property. This switches the way that the size of an element is calculated. Normally the size is calculated independantly of things like padding and borders. By setting box-sizing: border-box we’re telling the browser to include borders and padding in the width calculation. This allows me to then set a really thick border on the sides and top in order to make the center of the element open.

That is pretty much it as far as the construction goes, at this point you essentially have the Zoetrope as seen in the experiment:

If you’re interested in more details, or just have questions, as always feel free to email me. Also, all the source of the experiment is up on GitHub, so feel free to peruse and hack things up.

Making It Rain

2011-02-14T00:00:00-08:00

If you haven’t already seen my CSS/HTML Rain experiment I highly suggest you check it out before reading more. Or if you’re stuck using an older browser, you can just watch the video below.

Basically I built a rain simulation using only HTML, CSS and Javascript. No canvas, no images. Just a webpage.

Over the last few months I had been racking my brain for an idea worth fully implementing. I went through several iterations of this one, including ideas of having live twitter data flow over a waterfall or turning paragraphs of a novel into some kind of bound fluid simulation. It wasn’t until about two weeks ago that I actually decided to take a big step back and just try to create something simple. In doing so, I found that the simpler idea would not only be easier to implement, but also probably look a lot better than something complicated.

Y U NO Use Canvas?

Lately I’ve been kinda tired of the canvas. I know you can do some amazing things with it, but when it comes down to it, all you’re doing is painting a flat image over and over again. I think when I started with this experiment I was interested in creating a simulation that would use actual objects as particles, not just circles or letters drawn to a surface that I would manually have to repaint every iteration.

Another major reason for doing this, is that I wanted to play around with inserting and removing large amounts of elements to and from the DOM and manipulating them via css transforms in realtime.

The physics of it:

When this idea first started brewing, I spent quite a bit of time reading papers on how to do realtime fluid/waterfall simulations. This, as it would turn out, would all be in vain.

The calculations to accurately model a fluid, as you might guess, are extremely complicated. Each particle has to somehow interact with its surrounding particles, be it slightly tugging or pushing apart. This is what makes the effects of surface tension and viscosity look realistic. But what this also means, is that for every frame of your animation/simulation, you’re expending a huge amount of computing power calculating things like distances and forces between all of the particles.

Doing that kind of computation is not really feasible in the current browser environment, as not only do I have to deal with Javascript not being as fast a C or C++ implementations, but I also have to worry about the cost of the DOM repainting. So instead of doing a full blown, completely accurate simulation, I opted to take a much simpler approach such that each particle (or drop as I call them in my code) acts independently of every other particle and only interacts with the mouse.

Each rain drop really only has two constraints then, one equation to govern how the particle moves over time, and another that make sure particles don’t pass through the users cursor.

To do the updating of each particle, I employed a small amount of vector math in the following code:

update: function(acceleration){
    var temp = this.current;
    
    // basically new_position = (current_position * 2) - previous_position + acceleration
    // where the acceleration is actually a gravity constant scaled by some factor.
    this.current = this.current.scale(2).subtract(this.previous).add(acceleration);
    this.previous = temp;
    
    // rotation is completely independent of everything and just
    // does whatever it wants based on random initial conditions.
    this.rotation += this.rotation_step;
    
    // apply the position and rotation we just calculated
    this.style();
    
    return this;
},

If you’ve seen some of my other work on things like the cloth and particle simulation, you know that I’m a fan of Verlet integration in my simulations. What Verlet gives you over Euler, is that you no longer need to store information about an objects velocity. Instead you can easily calculate a similar metric using the object’s current and previous positions.

Lastly to take care of the mouse interaction I added the following method to my Cursor object, such that it can take a particle and move it if it happens to intersect with the cursors radius. The following code has been modified slightly from what is actually in the source, just for readabilities sake.

adjustParticle: function(particle){
    // current position of the mouse.
    var position = this.position;
    
    // find out the distance between the cursor and the given particle.
    var diff = particle.current.subtract(position),
        distance = diff.length();
    
    if (distance < this.radius){
        
        // if the particle is inside the radius of the mouse, set the
        // current position of the particle so that it is some distance
        // in the opposite direction of entrance.
        particle.current = position.add(diff.scale(this.radius / distance));
    }
}

The above code is actually quite neat as it adds a tiny bit of bounce whenever a particle hits the cursor. This is because I change the position of conflicting particle so that it is reflected back on the direction it was coming from. If you watch the youtube video above, you can see me using this to bounce particles up and down.

DOM Optimizations:

One problem that I was concerned about from the start, was how to deal with actually generating the rain drops. The general idea was that I would have some set number of drops in the simulation at any given iteration, then I could simply loop over this list to move the simulation ahead each time step.

My first approach was the simplest. The basic idea was: keep adding drops (read: keep dumping divs into the DOM) until I reach the at set limit. If a given drop is past some threshold (generally some distance off the page) then actually remove that drop from the DOM and generate a brand new one in it’s place. This method actually got me pretty far in terms of getting the look and feel of the physics right, but it certainly wasn’t all that efficient. The problems started when I tried adding more than 50 drops. Basically, the cost of updating the DOM was actually starting to slow down my simulation.

There were quite a few intermediate solutions that each provided their own benefits. But the final solution was actually quite similar to the first. Just like before I would keep adding elements to DOM until I reached my limit, I also used the same threshold idea for when elements fell out of sight. But instead of removing the element from the DOM, I would just hide it (with display:none), reset its position to the top, then show it at the start of the next iteration. This way, once the simulation is up and running with a lot of particles, there is no further DOM manipulation, just CSS updates.

You can actually see this when you drop the simulation down to very few particles, you’ll see the same small subset of letters appearing over and over again. I also fade the drops out as they go down the page, so it’s not obvious that I’m recycling.

Another thing I had to optimize was the generation of the clouds. Initially I was just going to draw up an image of a cloud and slap it on top of the simulation, but quickly realized it would be so much cooler if I could do it with text. The problem with that is that I would like to make sure it reasonably covers up the generation area, but doesn’t slow down the page load time or overall simulation.

The basic idea behind the clouds, is that I strategically chose a set of points that I would like to have covered up, then generate a bunch of random letters in a circle around that point. In the end, I decided there were 15 points that I would like to be covered up. For each of these points I would then generate 25 random letters and inject them into a document fragment, before finally injecting that fragment into the actual DOM.

The speed of this is actually quite striking. Seeing as at every page load I’m dynamically creating and inserting 375 divs in just a few milliseconds. Pretty neat.

CSS Optimizations:

Optimizing the CSS turned out to be a bit of a gong show.

One of the first ideas I had toyed around with, was using css transitions to tween between animation frames. The hope of this, was that I would be able to cram in more expensive computation at a lower frame rate while still maintaining smooth animations. In theory this could have been awesome, but instead it turned out to be the opposite.

It wasn’t until I read an article from a developer at facebook that I realized I was doing it wrong. Basically the article goes through different ways of optimizing HTML5 games. One of the things they mention is that on desktop browsers, it is actually more efficient to turn off transitions and just manually move things on the page. I guess this kinda makes sense, as the browser probably has to do some serious math to try and tween something. Where as if I just tell it what to do, it doesn’t really have to figure anything out. The down side of this approach is that you’ll be killing performance on mobile devices, which are generally pretty good at transitions on certain properties, while not being good at executing javascript quickly.

The other relatively big struggle I had to deal with was figuring out what css transformations worked in which browsers. Initially I had been using the tranform translate3d(x, y, 0), but that would cause Firefox 4 to barf. So instead I switched to using just the regular translate(x, y) which appeared to work. But when I went back to test in Safari, the performance was now horrible. I know this was mentioned in the above facebook article, but I didn’t realize how big of an impact it would have.

Eventually I just fell to the level of writing another feature sniffer that would check if a browser supported 3d transforms. I should also note, that I learned that chrome pretends that it has support for 3d transforms, so it uses the translate3d(x, y, z) transform, but basically has the same performance of translate(x, y).

The last little optimization I employed, was to use integer values in my transforms. I was honestly quite surprised by this. Simply truncating my numbers using value | 0 made an actual significant difference in the overall performance.

What I learned:

The biggest thing I took away from this experiment, is that it is most certainly possible to build interesting simulations using the DOM and css transforms. That being said, at the end of all this, I’m not terribly thrilled with how all the browsers are currently handling css transformations (with the exception of Safari).

All the browsers seem to have a lot of work to do in order to make developing easier. But when that day comes, I’m sure we’ll see some really interesting and beautiful experiments.

By the way, if you’re planning on delving into an experiment using some of the latest technologies, I highly suggest you take a look at some feature detection libraries (personally I think modernizr is pretty cool). I didn’t use one for this experiment as I was only dealing with a small subset of features, plus I was interested in learning how to do it myself.

Function.prototype.bind

2011-02-02T00:00:00-08:00

In my day job I spend all of my time rolling around in the warmth of Mootools. But lately I’ve been feeling kinda weird. With all of the things Mootools provides, I began feeling sort of disconnected from the vanilla javascript community. The line between what was native js and what Mootools provided was beginning to blur.

So I decided that for my next side project (which should be up in a week or two), I would take a step back and write a full experiment using only vanilla js. No libraries. I know that some people think this is a silly decision, as Mootools not only provides handy extensions to natives, but also patches over the differences between the various states of browsers. I fully recognize and agree with that fact, but I was just curious what could be done with the latest version of the browsers.

One of my favorite parts of Mootools, is that it has taught me to love passing functions around all over the place, but as we all know maintaining this can be a tricky task. A classic example and solution to this problem (har har), would look like:

var Mouse = function(){
    // assign this to that.
    var that = this;
    
    this.position = [0, 0];
    
    document.addEventListener('mousemove', function(event){
        that.move(event);
    });
};

Mouse.prototype.move = function(){
    this.position = [event.pageX, event.pageY];
    this.log();
},

Mouse.prototype.log = function(){
    console.log(this.position);
};

new Mouse();

What I’ve done here, is just assigned this, which is a reference to the mouse class, to a variable and then referenced it inside of an anonymous function which will be called whenever the mouse moves. Although this works, I personally find it looks quite gross. Thankfully there is a better solution.

Poking around the Function documentation on MDC, I recently discovered that JavaScript 1.8.5 implements a new bind method. This methods takes the current function, wraps it up in a closure and returns a new function that will maintain the passed in binding. Basically, it does something like this:

var bind = function(fn, binding){
    return function(){
        fn.apply(binding, arguments);
    };
};

var myFunction = function(arg){
    console.log(this.message);
};

var wrappedUp = bind(myFunction, { message: 'hello world' });

myFunction(); // logs 'undefined'
wrappedUp(); // logs 'hello world'

This to me is a godsend, as it was one of my most missed ‘features’ provided my Mootools. The Mouse class can now be simplified a little:

var Mouse = function(){
    // Look! no that = this!
    this.position = [0, 0];
    document.addEventListener('mousemove', this.move.bind(this));
};

Mouse.prototype.move = function(){
    this.position = position = [event.pageX, event.pageY];
    this.log();
},

Mouse.prototype.log = function(){
    console.log(this.position);
};

new Mouse();

Unfortunately though, the bind method doesn’t seem to be supported yet in the Webkit Nightlies or Safari. But if you do want to check it out, just open up the most recent version of Chrome or Firefox 4 and start natively binding your functions!

All in all, I’m quite happy with how working with native JS has been going, sure I miss some of the nicer array methods from Mootools (invoke, erase etc.), but seeing just how many of them (most of the iterators) have made their way in to browser implementations makes me incredibly happy.

For browsers that don’t support bind natively, be sure to try out Mootools or at least steal their implementation (but show them some love of course).

How I Learned to Walk

2010-10-21T00:00:00-07:00

Over the last couple weeks in my spare time, I decided to seriously mess around with CSS3. In particular webkit animations and transformations.

Go to the experiment!

Idea(s) and Inspiration:

The walking experiment came from the need to work on something other than javascript for a while. Initially I thought I would do some kind of hybrid experiment mixing css animations and very minimal javascript, but eventually settled on using only CSS3 and html.

I threw around ideas of doing some kind of chaotic pendulum, or maybe a cleaner implementation of the robotic arm. The idea of doing the arm again, reminded me of the CSS3 AT-AT I saw a while ago. I remembered the first time I saw it, thinking, “This is incredible”, before realizing just how limited the animation was. I thought maybe I could take it further and create something a little more extreme.

Structure:

When I first started working on the walking man, I didn’t really know where it was going to go so I ended up going through several iterations of markup for the actual skeleton. But in each iteration the css and overall structure of the man got better and better, so I think it worked out for the best.

The key idea behind all of this is the fact that a css transformation applied to an element also applies to all of its children. Without this, I would have had to use all kinds of math to figure out how to make the joints match up. Instead all that work is done for me, all I had to do was animate each limb independently.

Ultimately, I landed more or less on the structure below:

<div class="torso">

    <div class="left bicep">
        <div class="left forearm"></div>
    </div> <!-- left arm -->

    <div class="right bicep">
        <div class="right forearm"></div>
    </div> <!-- right arm -->

    <div class="left thigh">
        <div class="left shin">
            <div class="left foot">
                <div class="left toes"></div>
            </div>
        </div>
    </div> <!-- left leg -->

    <div class="right thigh">
        <div class="right shin">
            <div class="right foot">
                <div class="right toes"></div>
            </div>
        </div>
    </div> <!-- right leg -->

</div> <!-- torso -->

As you can see from the html above, I would need to use z-indexes to push the left arm as well as the legs behind the torso, as well as move the shins and forearms behind the thighs and biceps, respectively. Z-Indexes turned out to be my biggest source of grief, and almost pushed me to aborting this experiment all together. First off, I’ll completely admit that I had only a vague understanding of stacking contexts when I first set out.

With my limited knowledge, I thought I could just give negative z-indexes to things I wanted floated behind… But as it turns out, you can only push a child element behind its parent if its parent does not have a z-index set. This means if I set the z-index of the left bicep to -1, I would never be able to move the left forearm behind the left bicep. The other problem that I found was that the moment I started animating anything, webkit would basically destroy the stacking contexts.

In the end, I found that if I added a little more markup, not only would it make more semantic sense, but also solve all of the above problems:

<div class='me'>
    <div class="torso">

        <div class="left leg">
            <div class="left thigh">
                <div class="left shin">
                    <div class="left foot">
                        <div class="left toes"></div>
                    </div>
                </div>
            </div>
        </div> <!-- left leg -->

        <div class="right leg">
            <div class="right thigh">
                <div class="right shin">
                    <div class="right foot">
                        <div class="right toes"></div>
                    </div>
                </div>
            </div>
        </div> <!-- right leg -->

        <div class="left arm">
            <div class="left bicep">
                <div class="left forearm"></div>
            </div>
        </div> <!-- left arm -->

        <div class="right arm">
            <div class="right bicep">
                <div class="right forearm"></div>
            </div>
        </div> <!-- right arm -->
    
    </div> <!-- torso -->
</div> <!-- me -->

Note that I only really changed two things. First I wrapped each limb in another div, this was the main solution. I also moved the definition of the arms to be below the legs. I had originally done this in order to make sure that the arms would always display above the legs thus saving me a little bit of css (but not really).

Animating:

One goal of this experiment was to create something that would work extremely well on iPhones, iPads and iPods. To do this, all I needed to do was make sure I animated only a certain subset of properties. The key one being -webkit-transform (for rotation and translation), as it has been optimized in mobile safari.

When I first started animating, I thought that the only option was to create two separate animations for every type of appendage. So I set to work just trying to animate one side at a time (eg, the right side), and then translating it over to the other, such that the animation was offset by 50%. So for example, I would animate the right leg such that it would start out in front, then define a second nearly identical animation for the left side that would start the leg in the back position.

This became troublesome when I started using keyframes at strange percentages (20%, 40%, 70%). Translating this offset by 50% was sometimes difficult, and would often look awful when I was playing around with different timing functions.

Eventually I discovered that the -webkit-animation-delay property accepted negative values that would basically start an animation at some arbitrary point. So for example if I had the right arm swinging with a duration of 2 seconds, I could use that same animation for the left arm, but just specify the -webkit-animation-delay to be -1 second. Worked like a charm. Kinda.

Unfortunately, mobile safari apparently is not as well equipped as its desktop sibling. Namely my clever -webkit-animation-delay solution did not work at all and both arms and legs would animate in unison…

So after all that work to get things working so beautifully as a single animation, I reverted back to doing separate animations for the left and right sides. Although this time, to maintain my sanity, I decided to use only 0%, 25%, 50%, 75% and 100% as my keyframes. This made things nice and easy to offset.

Little Tidbit:

Just to kind of show off the fact that everything in the experiment is a div, I decided at one point that I would like to add a little feature to show this off. The easy solution would be to add a little bit of javascript that would add a border or background color to every div in the “canvas”. But I thought this would be cheating a little on my goal of keeping the experiment free of javascript. The solution to this actually came from my coworker Scott Kyle (www.appden.com).

At the bottom of the page, you can see that there are two links to show and hide the element borders. One simply has an href of “#canvas” and the other “#”, respectively. Then leveraging the target pseudo selector, I could just add a few more lines of css. This is what it looks like:

<style type="text/css" media="screen">

    #canvas:target div:not(.overlay) {
        border: 1px solid black;
    }

    #canvas:target div.me div{
        background: rgba(255, 255, 255, 0.25);
    }

</style>

<p style='text-align: center'>
    <a href='#canvas'>Show</a> / 
    <a href="#">Hide</a> 
    Element Borders.
</p>

Final Thoughts:

Thats more or less it. In the end its quite amazing to see something with so much motion in a browser, yet not having any code. I also find it to be pretty incredible that it works just as well on my iPhone 3G as on my iPad or laptop.

In case you’re interested, here is the complete source of the experiment:

<style type="text/css" media="screen">
    #canvas {
        height: 600px;
        margin: 0;
        padding: 0;
        position: relative;
        overflow: hidden;
    }

    #canvas div {
        position: absolute;
        -webkit-animation-iteration-count: infinite;
        -webkit-animation-timing-function: linear;
    }

    #canvas:target div:not(.overlay) {
        border: 1px solid black;
    }

    #canvas:target div.me div{
        background: rgba(255, 255, 255, 0.25);
    }

    .me {
        top: 50px; left: 350px;
        -webkit-animation-name: me;
    }

    .me, .me div {
        background-repeat: no-repeat;
        -webkit-animation-duration: 1750ms;
    }

    .torso {
        width: 86px; height: 275px;
        background-image: url(me/torso.png);
    }

    .arm {
        left: 12px;
        -webkit-transform-origin: 20px 10px;
    }

    .right.arm {
        top: 93px;
        -webkit-animation-name: right-bicep;
    }
    .left.arm {
        top: 87px;
        -webkit-animation-name: left-bicep;
    }

    .bicep {
        height: 124px; width: 51px;
    }

    .right.bicep { background-image: url(me/right-bicep.png); }
    .left.bicep { background-image: url(me/left-bicep.png); }

    .forearm {
        top: 108px; left: 14px;
        width: 36px; height: 121px;
        -webkit-transform-origin: 3px 7px;
    }

    .right.forearm {
        background-image: url(me/right-forearm.png);
        -webkit-animation-name: right-forearm;
    }

    .left.forearm {
        background-image: url(me/left-forearm.png);
        -webkit-animation-name: left-forearm;
    }

    .leg {
        left: 6px;
        -webkit-transform-origin: 30px 20px;
        -webkit-animation-name: thigh;
    }

    .right.leg {
        top: 235px;
        -webkit-animation-name: right-thigh;
    }

    .left.leg {
        top: 225px;
        -webkit-animation-name: left-thigh;
    }

    .thigh {
        width: 70px; height: 145px;
    }

    .left.thigh { background-image: url(me/left-thigh.png); }
    .right.thigh { background-image: url(me/right-thigh.png); }

    .shin {
        top: 115px;
        width: 50px; height: 170px;
        background-image: url(me/shin.png);
        -webkit-transform-origin: 30px 25px;
    }

    .right.shin { -webkit-animation-name: right-shin; }
    .left.shin { -webkit-animation-name: left-shin; }

    .foot {
        top: 155px; left: 2px;
        width: 67px; height: 34px;
        background-image: url(me/foot.png);
        -webkit-transform-origin: 0 50%;
    }

    .right.foot { -webkit-animation-name: right-foot; }
    .left.foot { -webkit-animation-name: left-foot; }

    .toes {
        top: 9px; left: 66px;
        width: 28px; height: 25px;
        background-image: url(me/toes.png);
        -webkit-transform-origin: 0% 100%;
    }

    .right.toes { -webkit-animation-name: right-toes; }
    .left.toes { -webkit-animation-name: left-toes; }

    .shadow {
        width: 200px; height: 70px;
        left: 270px; bottom: 5px;
        background-image: url(misc/shadow.png);
        -webkit-animation-name: shadow;
    }

    /* setting proper z-indexes so that limbs show up correctly */

    div.right.arm { z-index: 1; }
    div.left.arm { z-index: -3; }
    div.arm > div.bicep > div.forearm { z-index: -1; }

    div.right.leg { z-index: -1; }
    div.left.leg { z-index: -2; }
    div.leg > div.thigh > div.shin { z-index: -1; }

    /* animations */

    @-webkit-keyframes me {
        0% { -webkit-transform:   rotate(5deg) translate( 5px,   0px); }
        25% { -webkit-transform:  rotate(5deg) translate(-5px, -14px); }
        50% { -webkit-transform:  rotate(5deg) translate( 5px,   0px); }
        75% { -webkit-transform:  rotate(5deg) translate(-5px, -14px); }
        100% { -webkit-transform: rotate(5deg) translate( 5px,   0px); }
    }

    @-webkit-keyframes right-bicep {
        0%   { -webkit-transform: rotate(26deg); }
        50%  { -webkit-transform: rotate(-20deg); }
        100% { -webkit-transform: rotate(26deg); }
    }

    @-webkit-keyframes left-bicep {
        0%   { -webkit-transform: rotate(-20deg); }
        50%  { -webkit-transform: rotate(26deg); }
        100% { -webkit-transform: rotate(-20deg); }
    }

    @-webkit-keyframes right-forearm {
        0%   { -webkit-transform: rotate(-10deg); }
        50%  { -webkit-transform: rotate(-45deg); }
        100% { -webkit-transform: rotate(-10deg); }
    }

    @-webkit-keyframes left-forearm {
        0%   { -webkit-transform: rotate(-45deg); }
        50%  { -webkit-transform: rotate(-10deg); }
        100% { -webkit-transform: rotate(-45deg); }
    }

    @-webkit-keyframes right-thigh {
        0%   { -webkit-transform: rotate(-45deg); }
        50%  { -webkit-transform: rotate(10deg); }
        100% { -webkit-transform: rotate(-45deg); }
    }

    @-webkit-keyframes left-thigh {
        0%   { -webkit-transform: rotate(10deg); }
        50%  { -webkit-transform: rotate(-45deg); }
        100% { -webkit-transform: rotate(10deg); }
    }

    @-webkit-keyframes right-shin {
        0%   { -webkit-transform: rotate(30deg); }
        25%  { -webkit-transform: rotate(20deg); }
        50%  { -webkit-transform: rotate(20deg); }
        75%  { -webkit-transform: rotate(85deg); }
        100% { -webkit-transform: rotate(30deg); }
    }

    @-webkit-keyframes left-shin {
        0%   { -webkit-transform: rotate(20deg); }
        25%  { -webkit-transform: rotate(85deg); }
        50%  { -webkit-transform: rotate(30deg); }
        75%  { -webkit-transform: rotate(20deg); }
        100% { -webkit-transform: rotate(20deg); }
    }

    @-webkit-keyframes right-foot {
        0%   { -webkit-transform: rotate(-5deg); }
        25%  { -webkit-transform: rotate(-7deg); }
        50%  { -webkit-transform: rotate(-16deg); }
        75%  { -webkit-transform: rotate(-10deg); }
        100% { -webkit-transform: rotate(-5deg); }
    }

    @-webkit-keyframes left-foot {
        0%   { -webkit-transform: rotate(-16deg); }
        25%  { -webkit-transform: rotate(-10deg); }
        50%  { -webkit-transform: rotate(-5deg); }
        75%  { -webkit-transform: rotate(-7deg); }
        100% { -webkit-transform: rotate(-16deg); }
    }

    @-webkit-keyframes right-toes {
        0%   { -webkit-transform: rotate(0deg); }
        25%  { -webkit-transform: rotate(-10deg); }
        50%  { -webkit-transform: rotate(-10deg); }
        75%  { -webkit-transform: rotate(-25deg); }
        100% { -webkit-transform: rotate(0deg); }
    }

    @-webkit-keyframes left-toes {
        0%   { -webkit-transform: rotate(-10deg); }
        25%  { -webkit-transform: rotate(-25deg); }
        50%  { -webkit-transform: rotate(0deg); }
        75%  { -webkit-transform: rotate(-10deg); }
        100% { -webkit-transform: rotate(-10deg); }
    }

    @-webkit-keyframes shadow {
        0%   { opacity: 1; }
        25%  { opacity: 0.75; }
        50%  { opacity: 1; }
        75%  { opacity: 0.75; }
        100% { opacity: 1; }
    }

    .overlay {
        width: 100%; height: 100%;
        background: url(misc/gradient-left.png) repeat-y top left,
                    url(misc/gradient-right.png) repeat-y top right;
    }

    .sky div {
        background-repeat: no-repeat;
        -webkit-animation-name: prop-1200;
    }

    .cloud-1, .cloud-2 {
        width: 82px; height: 90px;
        background-image: url(clouds/1.png);
        -webkit-animation-duration: 120s;
    }

    .cloud-3, .cloud-4 {
        top: 70px;
        width: 159px; height: 90px;
        background-image: url(clouds/2.png);
        -webkit-animation-duration: 80s;
    }

    .cloud-5, .cloud-6 {
        top: 30px;
        width: 287px; height: 62px;
        background-image: url(clouds/3.png);
        -webkit-animation-duration: 140s;
    }
    
    .cloud-7, .cloud-8 {
        top: 100px;
        width: 94px; height: 81px;
        background-image: url(clouds/4.png);
        -webkit-animation-duration: 90s;
    }
    
    
    .cloud-1 { left: 0px; }
    .cloud-2 { left: 1200px; }
    
    .cloud-3 { left: 250px; }
    .cloud-4 { left: 1450px; }
    
    .cloud-5 { left: 500px; }
    .cloud-6 { left: 1700px; }
    
    .cloud-7 { left: 950px; }
    .cloud-8 { left: 2150px; }

    .horizon {
        top: 350px;
        width: 1800px; height: 50px;
        background: url(misc/horizon.png) repeat-x;
        -webkit-animation-name: prop-600;
        -webkit-animation-duration: 40s;
    }

    .ground div {
        background-repeat: no-repeat;
        -webkit-animation-name: prop-2000;
    }

    .sign-all-css {
        width: 160px; height: 188px;
        top: 325px; left: 1600px;
        background-image: url(signs/all-css.png);
        -webkit-animation-duration: 35s;
    }

    .sign-lots-of-divs {
        width: 102px; height: 120px;
        top: 345px; left: 1150px;
        background-image: url(signs/lots-of-divs.png);
        -webkit-animation-duration: 56s;
    }

    .sign-no-js {
        width: 65px; height: 77px;
        top: 348px; left: 1150px;
        background-image: url(signs/no-js.png);
        -webkit-animation-duration: 71s;
    }

    .sign-best {
        width: 43px; height: 50px;
        top: 350px; left: 1000px;
        background-image: url(signs/best.png);
        -webkit-animation-duration: 95s;
    }

    @-webkit-keyframes prop-600 {
        0%   { -webkit-transform: translateX(0px); }
        100% { -webkit-transform: translateX(-600px); }
    }

    @-webkit-keyframes prop-1200 {
        0%   { -webkit-transform: translateX(0px); }
        100% { -webkit-transform: translateX(-1200px); }
    }
    
    @-webkit-keyframes prop-2000 {
        0%   { -webkit-transform: translateX(0px); }
        100% { -webkit-transform: translateX(-2000px); }
    }

</style>

<p style="text-align: center">This experiment is only designed to work <b>only in webkit browsers</b> (chrome and safari).</p>

<div id="canvas">
    <div class="sky">
        <div class="cloud-1"></div>
        <div class="cloud-2"></div>
        <div class="cloud-3"></div>
        <div class="cloud-4"></div>
        <div class="cloud-5"></div>
        <div class="cloud-6"></div>
        <div class="cloud-7"></div>
        <div class="cloud-8"></div>
    </div>

    <div class="horizon"></div>

    <div class="ground">
        <div class="sign-best"></div>
        <div class="sign-no-js"></div>
        <div class="sign-lots-of-divs"></div>
        <div class="sign-all-css"></div>
    </div>

    <!-- skeleton and shadow -->
    <div class='shadow'></div>

    <div class='me'>

        <div class="torso">
            <div class="left leg">
                <div class="left thigh">
                    <div class="left shin">
                        <div class="left foot">
                            <div class="left toes"></div>
                        </div>
                    </div>
                </div>
            </div> <!-- left leg -->

            <div class="right leg">
                <div class="right thigh">
                    <div class="right shin">
                        <div class="right foot">
                            <div class="right toes"></div>
                        </div>
                    </div>
                </div>
            </div> <!-- right leg -->

            <div class="left arm">
                <div class="left bicep">
                    <div class="left forearm"></div>
                </div>
            </div> <!-- left arm -->

            <div class="right arm">
                <div class="right bicep">
                    <div class="right forearm"></div>
                </div>
            </div> <!-- right arm -->

        </div> <!-- torso -->
    </div> <!-- me -->

    <div class="overlay"></div>

</div> <!-- canvas -->

<p style='text-align: center'><a href='#canvas'>Show</a> / <a href="#">Hide</a> Element Borders.</p>

Go to the experiment!

Look Ma', No Rails!

2010-08-27T00:00:00-07:00

I used to be in love with Rails. Coming from PHP, Rails made it so incredibly easy to layout, build and eventually extend websites. But there were also lots of things that made me really uneasy about Rails. Things like:

Newer versions breaking my website when my host updated their servers (I eventually froze my site so that Rails wouldn’t upgrade).
The fact that I had to depend on my host for Rails support (I know could always buy a slice somewhere, but I really hate server configuration).
The overall complexity and weight of Rails.

It wasn’t until I came to work at Inkling that a coworker, Scott Kyle, introduced me to Jekyll.

Jekyll, for those who don’t know, is a static site generator. Using a simple yaml front-matter (and tiny configuration files), Jekyll can infer the structure of your website and generate static html pages that can be served from nearly any server. In other words, it’s awesome.

I feel a million times more free with Jekyll than I ever did with Rails…

The State of Things

2010-08-10T00:00:00-07:00

In re-implementing my website I had several moments of, “My god, this code is awful!” or “I used to be proud of this?!”, and quickly came to the conclusion that I should either:

rewrite the program from scratch or…
completely remove it and forget it ever happened.

For the most part, I was of the mindset to do the latter with anything that gave me the slightest bit of shame. With a few things I actually started recoding them, trying to make them more correct and have better code style, but I always found myself about half way through this process going, “Why am I wasting my time on this?!”. This would then result in me giving up and going back to plan B of just scrapping the experiment.

After several nights of going through this process I had a bit of a revelation. Namely that I should just post all of the old experiments in all their horrible glory, just as a reminder of where I started and proof that I’m always growing and improving.

One of the first experiments that was originally on the chopping block was the robotic arm. The code for this experiment is all kinds of horrible… Global variables all over the place, named functions, awful use of timeouts and on top of that I was using my first draft of my old math library (Bacon and Eggs) which added another layer of terribleness to everything. Further more, the experiment doesn’t even work correctly (many people have emailed me about the violent flailing that it sometimes does).

With my new mentality of posting for the sake of memory, I can definitely say the robot arm is in fact one of my favorite experiments. Even with its buggy behavior and code that would make any competent javascript programmer want to throw up, it was my first dive into the world of programming for the browser. If nothing else, I should be proud of that.

The Sudoku Solver

2010-06-28T00:00:00-07:00

After a bad run of making mistakes while marking up sudokus I thought I would try my hand at creating something to do the marking up for me. But as it turns out, I ended up writing something that would not only mark up the puzzles, but would more often than not entirely solve them.

Which strategies does the solver use?

I like my sudokus to be tricky, but not impossible. This means I don’t believe you should ever have to guess a number to solve a sudoku. I also don’t like all of the exotic named strategies that only work once in a million puzzles (jellyfish, swordfish, &c.). That in mind, I wrote this program to use only the strategies that I would use to solve a puzzle:

Row, Column or Block Singles
Naked Pairs
Naked Triples
Hidden Pairs
Hidden Triples
Pointing Pairs (or triples)

As I said before, I have absolutely no intention of implementing the silly named strategies.

Hasn’t this been done before?

Oh definitely! Everyone and their dog appears to have written one (a quick google search will reveal this). What I feel like other solvers don’t provide is an easy to use interface. So even though other solvers may be more powerful, mine is at least easy to use.

Updates:

Pretty much rewrote the entire application:
- Switched from jquery to mootools.
- Now uses sets instead of strings to represent candidates.
- Consolidated state information.
- Improved efficiency across the board by throttling the amount of looping for most strategies.
- Fixed the horrible bugginess when demoing.
Added hidden pairs/triples strategies.
Slight (in looks) interface change.

Implementing Fractals

2010-05-17T00:00:00-07:00

This experiment is something I had been thinking about for quite some time, but it was only recently that I decided to finally dive in and try implementing it. One the the biggest things encountered with this was trying to make the fractals responsive but still detailed.

One thing about generating fractals is that it is very very repetitive… On top of that, it is often easiest to generate them recursively, meaning using the same idea over and over again to tackle smaller and smaller problems until you find a solution or meet some condition. Using this idea makes programming the fractals a trivial matter, but if there are any expensive operations they could be executed hundreds of times every time the fractal is updated.

That being said, some of the most expensive operations involve using math libraries. To cut down the number computations per update I decided that instead of recalculating angles and sizes every time something needed to be drawn, I would calculate all of the angles and sizes before actually delving into the recursion. These calculations are then stored in an array that can just be referenced.

As a quick example we can look at a simplified version of the Pythagoras tree. Say, every time we needed to draw a branch (square) we needed to perform only a single calculation (the new size of the square for example). In my first implementation, all the calculations were done inside in the recursion used to draw the fractal. Doing it this way meant about 1024 calculations, but by moving them outside of the recursion, the number of calculations is reduced to about 9. Thats a pretty big difference…

The last thing that I wanted to talk about was the Sierpinski Carpet. This is the only fractal here that is not drawn recursively. This is simply because the problem size grows very rapidly and the recursion would begin to bog things down. Instead everything (the spacing between the squares, the size of the squares etc) is calculated ahead of time, so that when it comes time to draw it is just a matter using a couple really simple loops.