Gradient vodka soda is vodka soda with a novel twist – each bottle has a different amount of alcohol, allowing you to easily taper off your consumption through the night – which they call modern moderation. Check them out if you’re in the market for that sort of thing (and are of legal drinking age).

I programmed their teaser website, which had a bunch of interesting technical requirements. In this post I will go over a few of the more interesting tests I wrote. Most will work best if you have hardware acceleration enabled.

Rotating cans

The website revolves around a 3d can (see what I did there?). To accomplish this, I used, as I do given whatever excuses I can find, the programming language Haxe. And this time in particular, Heaps.

I got a 3d cylinder rotating, and applied a material to it. (It’s not really a cylinder, I made a model to account for the inset near the top.)

I ended up rendering each can to 2D, and positioning it that way. It made it easier to line everything up and prevented skewing from the camera’s perspective. This allowed the overlays to fit consistently. (The metal of the can, and the shadows on it are overlays.) The actual 3D can is just an ambiently lit label applied to the model.

But I couldn’t find an easy way to switch the labels on it; so I ended up writing a shader to do that. And so it went for so many more things –

But what if it was a shader?

I wrote a bunch of these to accomplish neat graphical effects. Heaps actually makes it pretty easy. Though, in most cases, I ended up moving away from the shader solutions to better support visitors without hardware acceleration enabled.

Ever moving blobs

The client wanted some subtle blobs floating around in the background, so I thought to myself, high on my recent shader successes, why not do it as a shader too?

I made a quick proof-of-concept, and it looked kind of neat, almost like a lava lamp. The blobs ended up getting cut in favour of a background video, which then also got cut.

Different sized dots

I tried dots a few different ways to see what which worked best. First I tested moving a small canvas with the mouse, and that worked fairly well. Unfortunately, requirements shifted so I tested drawing dots over a large canvas.

Performance wasn’t great, so I ended up using a small canvas to draw the dot at the appropriate size (the sizes change as you scroll), and used that as a pattern to fill in the larger, screen-sized, canvas.

That seemed to work fairly well, except that iOS apparently doesn’t send mouse events while scrolling, which interacts poorly when you’re making a scroll-based website.

Scroll-based flash animations

As you get to the bottom of the page, there is a box that the cans slide into. It was meant to close, spin around, and settle onto the ground, as you scrolled down. Unfortunately, we didn’t get the rotating box assets in time, so Sheldon amended the animation concept.

I figured it would be a pain to do in code, and animations are exactly the sort of thing Adobe Animate (formerly Flash) was made for. All I had to do was hack their JS to animation to progress through the timeline on vertical scroll rather than time. I wrote a quick proof of concept (and ran into a bunch of issues with more complicated, nested animations), but overall it worked really well.

So well that it got me wondering if that’s already a thing people do. If not, it seems perfect for this sort of website. Adobe should consider adding as an option to their JS output. Or maybe I should just release a library for it.

As an added bonus, using Adobe Animate let Sheldon prepare the animation himself, which meant less work for me!

There were so many problems

Most to do with different devices and browsers, and the different values between them. It took forever to track down and deal with these, but in most cases we managed to get the numbers to line up.

But one thing that kept cropping up was the matter of hardware acceleration.

I kept it turned off for my tests, but apparently some Macbooks have it enabled by default, but disable it when unplugged. This caused a number of surprises when people tested it, many to do with a feature I had implemented for just this purpose.

Framerate scaledown

All of these things going on could be quite a load on a slower system, at times making it painful to use. No matter what, I wanted the website to be useable – responsive design, but along the dimension of framerate rather than browser width.

To help with this, I implemented a system of framerate scaledown. Basically, the browser would check your framerate, and if it was too low too many times, it progressively disabled features.

I was pretty happy with this system. In a lot of cases it would just turn off interactions (remove the background video, make the dots non-responsive to mouse position, etc.). It worked really well, but in conjunction with the above it lead to some confusion. Sometimes the dots resizing under your mouse would work, and sometimes they wouldn’t (they wouldn’t work if they’d been disabled).

If you want to checkout the website, you can find it at drinkgradient.com