Introduction

Meow Wolf is a 400 person strong entertainment arts company based in Santa Fe, NM that is a leader in designing mind-melting immersive experiences. Their first permanent exhibit The House of Eternal Return invites visitors to explore a full-sized two story Victorian house which they built inside of an abandoned bowling alley in 2016. Inside the house, visitors find portals through everyday objects: the refrigerator, the fireplace, the dryer and so on that lead into multidimensional worlds. Visitors are encouraged to touch, listen, and in all other ways investigate the spaces they encounter, manipulating interactive elements which respond to their actions and bring the mysterious story of one very strange family to life.

At Meow Wolf, I held the position of Senior Designer and Developer of Interactivity- a role which required me to wear many hats ranging from overseeing a team of Designer / Developers in creating and implementing designs for interactive sculptures, experiences, and spaces to producing my own projects for our upcoming exhibits in Las Vegas and Denver, slated to open Fall 2020 and Spring 2021. As a member of a start up working on a demanding production timeline, I often found I had to be equal parts flexible and efficient, whenever possible identifying solutions that might be applicable not just to the problem in front of me, but to problems which might present themselves down the line. Below is an example of one such family of problems and how I worked my way towards a solution.

The Problem

For most exhibition spaces, lighting is essential for drawing attention, suggesting avenues for way-finding, and at the bare minimum illuminating content so that it’s visible to the visitor. At Meow Wolf, lighting played an essential role in creating the character of a sculpture, space, or experience. As a result, most of our lighting was responsive and reactive, based on sensor input (such as touch or proximity) or linked to other interactive elements (such as sound). Programming lighting, however, is no easy task, often requiring expensive lighting software, equally expensive and difficult to setup hardware systems, and a knowledge of lighting design and development which professional lighting designers train years to achieve. As a small team of six Designer / Developers and two Lighting Designers, it quickly became apparent that the demand from our artists for highly specific lighting animations grossly outweighed our ability to accommodate these demands. Additionally, artists felt frustrated with their inability to explain the lighting designs they had envisioned due to a lack of lighting design vocabulary and knowledge of the equipment. Lastly, we didn’t have enough technical fabricators with a knowledge of lighting systems to go around setting up lighting rigs all over the place. My solution? Create an interface for artists and other staff which would allow them to manipulate lighting effects in real time including pre-visualization of animations.

Who Is It a Problem For?

Meow Wolf is a company of 400 employees, predominately populated by artists of various skill sets ranging from sculpture to 3D animation. Projects were often guided by a lead artist who rarely had knowledge of lighting design or how to work with electronics, although most had knowledge of graphic design software such as Photoshop, ZBrush, etc. Artists demonstrated a desire for extremely specific animations (ex: “I want this pixel to do this at this time but then on the second loop, can you have it do this? And then maybe we can do something random?”) They also expressed a desire to learn more about the relationship between sensors, microcontroller programming and lighting design.

The Process

Ask the Artists What They Want

I began by asking artists about their design process to see what features they might request, what tools they were already familiar with, and where the hiccups were for them in terms of lighting design. The interview process was casual but thorough and included looking into both in-production and completed projects to see if there were similar requirements for lighting design as well as similar points of success / failure. I collected these and my own observations from working with these artists in a doc and sorted them for similarities.

Ask the Techies Who Are Doing It

Next, I asked the members of the tech team what their experiences had been working with artists on lighting design. What did they spend the majority of their time on when it came to programming? Was there anything that took up a huge chunk of their time that seemed unnecessary? Was there any programming that they found they needed to repeat each project? Was there anything that was trickier to do in code that could be accomplished more easily with an interface? Again, I collected these and my own observations in a doc and sorted them for similarities, then compared them to the requests from the artists.

Interview Findings

While I can’t share the docs in question because the vast majority of Meow Wolf projects are protected under NDA, I can share that the gist of the findings were that artists wanted:

• At a bare minimum a way to change color including color temperature (shades of white).
• Ideally a way to program patterns including different patterns for different modes of interactivity (for example one animation when the sculpture is touched, another when it is touched for 30 seconds, and so on).
• To be able to see what they are doing live or in an editor.
• To make their own animations using a specific palette or existing artwork (the more I asked about this last one, the more I realized what they really wanted was to make their own video files and moving gradients).

There were many similarities and overlaps with the desire of the needs from the developer’s standpoint with some additional insights and requests:

• The number one ask of techies was to develop a controller that could simply make white light happen. Techies were spending an appalling amount of time running around illuminating LED strips in various shades of white.
• Techies also wanted a way for artists to interface with our actual lighting control software (predominately TouchDesigner), so they wouldn’t need to reprogram designs artists had created or worse be unable to do so because of inconsistencies between the GUI and the constraints of the software!

Research Existing Solutions

Although I thought it very unlikely considering the uniqueness of Meow Wolf’s projects in terms of the demands for lighting design, I did a bit of research to see if a ready-made solution already existed. In this case, I found potential solutions could be found in:

1. A DMX to FastLED converter that a techie had posted in a TouchDesigner forum. This solution was not viable because it would only work for FastLED, but it did give me the idea of using video files as input for an animation.
2. Geopix: a software we were already using which allows designers to specify pixel layouts for 3D mapping of large and small fixtures. This solution was not viable because Geopix takes a good deal of time to learn how to use as well as an existing knowledge of lighting design and development. Geopix did prove a solution for Designer / Developers for many other projects involving complex 3D pixel mapping.
3. Madrix, Martin Show Designer, or other WYSIWYG lighting control software. This was not a solution because this kind of software is expensive and sometimes requires training of DMX, sACN, ArtNet, and other lighting control protocols and equipment such as boards. Additionally, it did not meet the asks of the Designer / Developers which were to make sure whatever approach we took would not require re-programming.

Work From Where You Are

Because we were already in production with numerous projects and I didn’t have the bandwidth to dedicate myself to designing a complex controller from scratch, I decided to start with making tweaks to some of my existing projects that would allow greater control for artists. I began by positioning elements of TouchDesigner networks that controlled animation so that they could be easily accessible to artists, and hiding other elements that might be technologically overwhelming. The resulting network would use TouchDesigner’s existing node-based elements such as constants, ramps, video files, and geometries to translate animations into DMX and output to the controller / fixture. Changes to animations could be triggered based on sensor input which was performed in Python. While this presented a decent solution for some artists who were more enthusiastic about learning new software, it was overwhelming for other artists who wanted something more stripped down and top level.

Results

I used the insights gained from watching artists use the TouchDesigner network to create top level GUIs for projects which allowed artists to tweak those hidden parameters without having to know the ins and outs of programming. In most cases, I added elements specific to each project to allow for precise control over sensor input or animation modes and sequencing. GUIs might also include OSC communication tools for interfacing with other programs such as Processing, Max MSP, Unity, and Ableton LIVE. Because of NDA restrictions, I cannot share the projects or the GUIs in question, but below is an example of a mock GUI which allows artists to: design and output an animation based on a single-color (static), gradient (moving or static), video file (moving or static) or shared texture (shared from Unity, etc.). Additionally, the use can set an animation sequence based on timing or an event (such as changes in sensor input). They can also output this animation in the visualizer and the physical fixture declaring the precise pixel count and matrix dimensions. Lastly, for troubleshooting and calibration issues, changes can be made to the networking information such as the controller IP and port as well as the ability to reset the microcontrollers should they fall asleep or mysteriously go quiet (a problem frequently encountered and annoying to adjust inside the network).

Other Benefits

A few other benefits came about from designing the lighting control GUIs. For starters, other teams could use it! For example, our fabrication team often wanted to test lighting in the physical install. With the software, they could do some testing without need of a tech team member. Additionally, the software could be used by front of house in communication with our show controller to design for different lighting modes such as Christmas or Halloween programming or simply to turn the lights off (set to full black). Finally, our tech maintenance staff could use the software for maintenance purposes by using the GUI to turn the LEDs to full white to test power consumption, reset the microcontroller units, or observe sensor values while making adjustments to hardware placement.