We Built a Tesla
Light Show Studio
in the Browser.

Tesla's light-show ecosystem already has powerful tools. Its official creation guide uses xLights, which gives experienced creators detailed control over sequences, effects, and vehicle channels.

Our question was not how to replace that expertise. It was how to make the creative process more approachable for someone arriving with a song and an idea.

In Shaka Lights, that journey has four parts:

The generated show is a starting point, not a locked answer. Creators can keep the parts they like and change the parts they do not.

That decision shaped both the interface and the engineering underneath it. Generation, editing, preview, and export could not be four disconnected features. They had to describe the same show.

Flashing lights on every beat can produce synchronization without producing much personality.

We wanted the car to feel as though it was responding to the music: holding something back before a drop, answering a phrase from the other side, or letting a quieter passage breathe.

To support that direction, the analysis pipeline looks beyond tempo. It derives beat timing, onsets, frequency-band energy, sections, builds, drops, silence windows, and musical-layer features from the recording. Those features are measurements and estimates—not a claim that the system has perfectly separated every instrument.

When AI choreography is enabled, the model receives a bounded summary of those features and the creator's settings. It proposes abstract behaviors: which musical layers to follow, how dense a section should feel, when to use symmetry, and where variation or a blackout might belong.

It does not write the vehicle's export bytes or directly command its moving parts.

Application code turns that plan into events, resolves competing requests, applies timing and command constraints, and compiles the sequence. A deterministic generator provides a fallback when the AI path cannot produce an acceptable plan.

This gives the model room to contribute creatively without making it responsible for the rules the output must obey.

It also leaves a separate question for review: does the show actually look good? A valid file and a compelling performance are different achievements.

The preview made that same distinction impossible to ignore.

A convincing image can still be a misleading model. Illuminate the wrong region of a headlight assembly and the preview may look impressive while teaching the creator something the vehicle does not actually do.

We had to separate three things that are easy to confuse.

The logical channel is the instruction in the show. The physical output is the lamp or shared circuit that responds. The optical representation is how that response appears in a particular camera view.

They are not always one-to-one.

On the legacy Model 3/Y mapping, for example, Channels 4–6 share an output on each side, while Channel 4 supplies the ramp timing. Drawing three independent lights would make the interface look more capable while making it less faithful to the underlying behavior.

The renderer therefore needs more than a collection of attractive assets. It needs vehicle-specific mapping, time-dependent intensity, correctly aligned light imagery, and clear rules about which visual elements respond together.

Our legacy Model Y work became a useful reference case, not the definition of the entire product. Different model years and lighting assemblies require their own treatment.

We were not making a Tesla-themed animation. We were building a visual representation of a physical system.

Generative imagery helped us develop the vehicle visuals. It also exposed a problem: an image model can produce a beautiful answer to the wrong question.

A slightly different lamp shape, an illuminated neighboring strip, or a small shift in the vehicle's position may be acceptable in an illustration. In a layered preview, those changes can break the relationship between the base image and the light being activated.

The answer was not to stop using generated imagery. It was to stop treating a generated image as an authoritative runtime state.

We start with lights-off and lights-on references of the same scene. Before subtraction can be useful, their geometry and exposure need to agree. Otherwise, a shifted edge or a brighter background can masquerade as a light turning on.

The shared extractor subtracts OFF from ON for each RGB channel, discards negative changes, and uses the largest remaining channel change at each pixel. That gives us a candidate change signal—not a finished mask and not a measurement of physical light output.

Thresholds, a brightness check, region boundaries, noise cleanup, and optional color filters isolate the intended light. We then feather the measured opacity edge and save an RGBA layer: the ON donor’s color plus a separate alpha channel controlling where, and how strongly, it appears.

That distinction matters. An alpha mask is a map of opacity; a transparent light layer contains color as well as that opacity. The browser combines the layer with the base using the blend mode assigned to that output. It does not simply add a raw difference image to the car.

The boundaries around a lamp help identify which pixels belong to it; they are not an excuse to paint in a guessed glow.

One concrete correction involved the legacy Model Y's Signature light. The extraction workflow reprojected a close-up donor image onto the locked front-view canvas so that the Signature output would not be confused with the much longer front-turn strip.

That is a less glamorous task than generating a dramatic car render. It is also much closer to what makes the product useful.

At runtime, the application is not asking an image model to imagine the next frame. It is applying defined behavior to prepared assets. That makes the preview repeatable and inspectable, with physical-vehicle comparison remaining a separate acceptance step.

AI-assisted development was a separate workflow. Models and coding agents helped with research, implementation, debugging, and iteration. Their output still needed to survive the same checks as any other contribution: correct mapping, aligned assets, and consistent behavior.

AI became more useful once we defined what it was—and was not—allowed to decide.

An animation can assume time moves forward. An editor cannot.

A creator might jump into the chorus, drag backward into a build, change an event, and resume halfway through a fade. The preview must show the state at that timestamp—not whatever happens to remain from the previous frame.

Ramps make this especially interesting. A light fading out may begin from the partial brightness reached during a previous fade-in. It cannot simply restart at full intensity every time the playhead moves.

A test in our signal interpreter captures the problem precisely. An inner-beam event starts a two-second ramp upward, then reverses after one second. On the export's 20-millisecond grid, the expected intensity is 50% at 00:00.980, 25% at 00:01.480, and zero at 00:01.980.

Now jump backward from 00:01.480 to 00:00.980. The preview needs to return to 50%, regardless of the direction of travel.

These timestamps come from a software regression-test fixture, not a photometric measurement of a car.

Our implementation compiles physical signal tracks from the same command frames used for export. The renderer reads the state at the current playback time, rather than relying on an animation that can only be played from the beginning.

That connects a small interaction—dragging a playhead—to a larger promise: the editor and export should not quietly disagree about the show.

Music introduced another set of design decisions.

For the upload workflow, recordings live in user-scoped private storage and are accessed through short-lived signed URLs. They are not automatically published or added to a marketplace.

We also built a browser-local audio path. The browser analyzes a selected recording, retains the normalized audio locally, and sends bounded analysis data to the generation service. The final ZIP is assembled in the browser from the generated sequence and the locally retained audio.

That lets the system generate choreography without receiving the source recording in that workflow.

It also creates practical requirements. Returning on another device, for example, means re-linking the matching local file rather than pretending the recording is available everywhere.

The Apple Music integration respects that boundary: catalog discovery and listening are distinct from the local recording used for synchronized preview and export. It does not extract the subscription stream.

The distinction is straightforward: private server storage for the upload path; locally retained audio for the browser-local path.

The same precision matters with AI. The choreography request uses derived musical information, not the raw recording. Privacy is part of what each component is allowed to receive.

The browser is where a show takes shape. It is not the finish line.

Our legacy export pipeline compiles events into 48-channel, 20-millisecond frames, writes an uncompressed FSEQ V2 sequence, and pairs it with normalized 44.1 kHz WAV audio. Validation checks the result before packaging.

Manual edits go back through the rebuild and validation path. A change on the timeline must affect the exported sequence, not merely the on-screen visualization.

Compatibility needs equally careful treatment. The build includes ten authored model/year preview variants, but preview coverage is not the same as verified vehicle export support.

Current compatibility: the structurally validated export path is the 2020–2024 Model Y 48-channel profile. Other authored variants are preview-only by default, with explicitly experimental exports available only when enabled. Structural validation is not vehicle certification or a guarantee of behavior on every configuration.

We treat those boundaries as product information, not fine print. A more impressive compatibility claim would not make the software more capable.

The goal is the whole journey: music becomes timing, timing becomes choreography, and choreography becomes a sequence prepared for the car.

The preview is where you shape the performance. The vehicle is where it ultimately has to work.

Shaka Lights brought together work that is often discussed separately: the interface people use, the rules that make it reliable, the handling of private information, and the output they came to create.

The useful result is not a longer technology list. It is a connected workflow in which a creator can generate an idea, inspect it, change it, and take it further.

For SiteMilk, this is a particularly visible example of a familiar challenge. A business website may need to help someone request a quote, choose a service, or move through a more involved customer journey. The interface should make that next step clear, while the implementation handles what must happen behind it.

Shaka Lights gave us an unusual place to push that discipline: browser graphics that mean something, AI assistance with explicit limits, and a creative interface backed by testable behavior.

The difficult parts should make the experience better. They should not become the customer's homework.