small lightcube

At AHL, we recently started using lightcubes for data visualisation. A lightcube is a transparent box with a 3D grid arrangement of LEDs inside. Space between the LEDs allows seeing the lights on the inside throughout the volume. We began with a 8x8x8 lightcube made by Looking Glass and later added a 16x16x16 “Really Big Cube”. There is a lot of beautiful eye-candy available, but for the purposes of AHL, we wanted to find out if we could use lightcubes to get insight into data in a way that is not possible with 2D displays. Along the way, we encountered questions both of technical and design nature. This post is about some of them.

Below its blinking surface (or rather volume), the 8x8x8 cube behaves like a strip of 512 LEDs that has been folded into shape. The lights are controlled by a simple SoC, a “Photon” made by particle.io. To run an application on the cube, the C code is pre-compiled and flashed onto the SoC. For easy experimenting we started by writing an application that displays a series of “frames”, basically arrays of colour values, blending one frame to the next after a given time-interval. The SoC specs are very bare-bones (especially storage: 1MB flash storage, 128 kB RAM), which will hold about 17 frames – but that is enough to get started. With the application in place, the next question was: What content displays well on a lightcube?

Experience from creating complex visualisations on 2D screens did not get us very far. The resolution of 8 pixels in any direction would not be sufficient even to display the tiny Super Mario from the first GameBoy incarnation. Text characters are possible, but a single letter spans the entire width. So instead of thinking pixel graphics, it is more useful to think of each position as a “bin” similar to grouping of data in a histogram. The lights on the edges become “very low” and “very high”, their inner neighbours are “high” and “low”, further inside “quite high”/”quite low”, and so on. As the cube itself cannot display any labels or legends, colour coding different types of data as done with line-plots is not useful without some sort of external documentation. Choice of colours therefore needs to be intuitive, following an easy-to-recognize pattern (e.g. white for “neutral” or using a “traffic light pattern”).

It turns out that the lightcube is excellent for visualising scatter-plots, either surface elevations or point clouds (and with hindsight: Isn’t it obvious given how the LEDs themselves are scattered in the volume? Should have thought of it so much earlier!). With data that can be meaningfully sliced in three dimensions (or four, when including colour), the lightcube gives an immediate and intuitive overview of the data distribution. The shape of the point cloud – is it sphere-ish, stretched, split into multiple parts – yields information at first glance. A 3D-plot on a flat screen would only provide this information after quite a bit of scrolling and rotating. The perception of information from the lightcube is quite unique and unlike any flat 2D projection of the same data.

For example, to get an intuitive idea of the climate in a certain location, we can visualise temperature, precipitation and wind speed. We need to define 8 or 16 ranges for each value, which for temperature might be (for a 8x8x8 cube):

“very low” “low” “quite low” “a bit low” “a bit high” “quite high” “high” “very high”
< -10°C -10 to 0°C 0 to 10°C 10 to15°C 15 to 20°C 20 to25°C 35 to 25°C >35°C

To visualise climate data, we could calculate weekly averages of temperature, precipitation and wind speed, identify the interval in each category and use the interval number as x, y or z coordinate for a point that represents weather in a particular week. With respect to colour, we could use a rainbow scheme going from “blue” in winter, “green” in spring, “yellow” in summer and “red” in autumn. Or we could use a single colour and decrease intensity for weeks further back in the past. As multiple points might share the same coordinates, we can either sum up intensities as we overlay points or give precedence to the first or last point displayed. This way we can obtain a 3D fingerprint of the climate in a given location that is easily recognisable at first sight.

Encouraged by our experience in visualising cloud data, we went big and got the 16x16x16 Cube. At that resolution, this lightcube could display Super Mario and when switching on all 4096 LEDs it provides quite a bit of illumination. The addressing is very different from the 8x8x8 cube and it seems that 8 pairs of xy-planes each form a separate folded LED strip. This requires a different API-backend. And as the Big Cube relies on the same SoC as the smaller one, storing any data locally very quickly hits a limit. The same approach using frames is not usable and the visualisation must be dynamically created by the application deployed on the SoC. The increased resolution gives more detailed insight into the data clouds and helps with identifying e.g. local clusters. And the sheer number of lights is very impressive to look at.

Overall, we found that the lightcubes enable insight into data that is different from any flat plot or 2D-projection on a regular screen. The lightcubes are a distinct type of device and require a tailored approach to make useful data visualisations. While they are inspiring to look at, they can be made to be much more than just eye-candy.