Lumenarium Over the last three years, basically since I got back from the helping construct Radialumia, I have been working on a custom piece of software to bridge the gap between what we wanted to be able to do with Radialumia and what tools were available at the time. This is no slight on those tools - they were simply tuned to a different set of priorities than the ones we had (and honestly, over the last three years I’ve come to appreciate how much work they did to get them there). If you want to try Lumenarium out, it runs on Windows at the moment, and you can get the code on github here.



Handmade, from Scratch

I made a somewhat controversial decision early on in the process of building Lumenarium to build it in almost-C C++ (no classes, no templates, no RAII, no exceptions, but operator and function overloading). I also decided to build everything myself. That means the renderer, the network protocols, the interface library, profiler, etc are all hand-rolled specifically for this program. It links with the windows OS libraries it needs to access system hardware, and (I believe) the only other libraries are math.h and xmmintrin.h

Why do this? Partially as a learning journey for me. I became a much better programmer over the course of this project. I got experience doing things you don’t on the web: paralellism, graphics programming, meta-programming, plus I re-learned linear algebra, and got practice structuring a large codebase.

Ok, but really… Why from scratch?

When I sat down to write this, we had several priorities:

Given just fast iteration, we needed something in a language that compiled fast (goodbye Java), that had low level hardware access (in case we needed to go SIMD on complex patterns), gives manual access to memory (cache misses are important), and which had a flexible library loading model (DLLs). So I chose C++, but restricted myself to the subset of C++ that doesn’t bog down compile times:

Artist Control meant a complex interface that was fast to iterate on. This was the one place I considered using external code - IMGui is a great option. But I wanted to learn. And I really liked the idea of building an interface in the style of Blender that allowed a multimodal, flexible workspace. But beyond that, I’d also need custom widgets, a timeline, data inspectors, profiling tools - those aren’t going to come from a library. So at that point, I began working on the toolset from scratch too.

Finally file formats - I knew someday I’d want to try parsing an stl to extract LED strip positions. For that, I wanted a custom format, and so we begin writing a tokenizer, parser, serializer, etc.

And at this point, that’s almost the entire application. The only things left would be the actual SACN/ArtNet protocols and interfacing with the OS for USB/Network access, file IO, and graphics. So why not just roll it all?


This wasn’t arrived at ahead of time, but through a process of discovery.

Platform Layer
Exposes a common interface to the application. To port to a new platform, just need to create a os.h and os.c file for the platform.

The core of the application, handling animation and 3d layout.

User interface and sculpture renderer. Lets you preview animations and sculpture geometry before the sculpture is constructed.

User Space
A set of function prototypes that a user application can tie into to customize the application.

You can read more about the Platform Layer Separation in this blog post

And it works!

Its been through a number of iterations. There was a node based interface for a while (which I still dream of bringing back someday). I added a built in time and memory profiler. Lumenarium Here’s one of our latest tests, using it to run a new sculpture. Lumenarium

Lumenarium Today

A few months ago we constructed Foldhaus’ latest sculpture, Blumen Lumen, in Silver Spring Maryland. It is powered by Lumenarium, which has been running around the clock for the last several months. Lumenarium Lumenarium