mg-styles-15: fifteen motion design styles, each rendered from code

Every film is a web page that draws any frame you ask for

The central technical idea is compact enough to state in one line, and everything else follows from it. Each of the fifteen films is a web page that can draw the frame for any time value you give it, through a `window.renderAt(t)` function. That single abstraction is what makes the whole pipeline deterministic. A video is not recorded in real time, it is computed, so the renderer can jump to frame 143, ask the page to draw it, and capture exactly that. Frame by frame cel animation and a flat vector explainer end up in the same repository because the same calling convention covers both, even though one imitates hand drawn line boil and the other imitates pop art shapes. The picture is code throughout, and the documentation says there is no image or video generation involved at all. The drawing surfaces are SVG, Canvas, WebGL and Three.js, with a few films using CC0 or public domain photographs as source photographs. The 3D film is the one exception to the rule, where Blender renders the picture and a web page adds the type and grain on top of it.

Headless Chrome captures frames, ffmpeg muxes the result

The rendering step is the part that turns a page into a deliverable. The renderer drives headless Chrome, captures each frame of the page, and ffmpeg then joins the frames with the soundtrack into an exact 10 second MP4. Working in the browser and rendering offscreen is an unusual choice compared with a conventional animation pipeline, and it has a specific payoff: the visual vocabulary of the web is available, including CSS, SVG filters and canvas drawing, and the same page can be opened in a browser and watched interactively with sound. The site published from the repository does exactly that, offering all fifteen films with sound on one page. The cost is a dependency stack that sits across two ecosystems. The JavaScript side is pinned in `package.json` with `d3` at 7.9.0, `opentype.js` at 2.0.0, `puppeteer-core` at 25.12.0, `simplex-noise` at 4.0.3, `three` at 0.186.1 and `topojson-client` at 3.1.0. The audio side needs a separate Python environment, and the pinned versions there are strict.

The soundtrack is synthesised in audio.py from 103 samples

The audio is code as well, and this is the part of the project that is hardest to imitate. Each film has an `audio.py` that synthesises its music and its sound effects, and the fifteen soundtracks together draw on 103 recorded instrument samples. Synthesising a score is a different problem from generating a picture, and the approach here is sample based: recorded instruments are the audio source, and Python code arranges them into cues. The documentation is explicit that the synthesiser works on the same cues as the animation, so the sound lands with the motion rather than being laid over it afterwards. The Python dependency list for that path is long and fully pinned, including `numpy==2.4.6`, `scipy==1.16.3`, `soundfile==0.14.0`, `numba==0.66.0`, `pedalboard==0.9.25`, `pyloudnorm==0.2.0`, `librosa==0.11.0` and `matplotlib==3.9.1`. A separate group of packages handles the asset generation scripts, including `pillow`, `fonttools`, `scikit-image`, `opencv-python` and `rembg`, which is a background removal library and a plausible reason a cut out style film needs it.

Two review rounds and a rubric that scored the films

The films were not shipped on the first pass. Each one went through two rounds of review and revision, and the process involved a second AI reviewing the finished film against a rubric that lives in the repository as `rubric.md`. The final scores from that jury are published, and they run from 7.57 to 8.21 out of 10 across the fifteen films. Publishing the scores alongside the films is unusual and useful, because it gives a reader the project's own quality bar rather than a vague claim. It also shows the ceiling of the method. A score of 8.21 out of 10 is not a claim of finished professional work, and no score reaches 9. Reading the rubric is a better way to judge the collection than reading the average, and the repository also ships a `template.md` that appears to serve as the structure a film follows. Each film has its own prompt file under `prompts/` and its own source under `demos/`, with names that line up, for example `prompts/05-cel-boil.md` and `demos/05-cel-boil`.

Ten named styles from line boil to a 9:16 variety show

The fifteen films are meant to be read as a set of distinct looks rather than fifteen variations of one. The named styles include Frame by Frame with Line Boil, described as hand made, Isometric 2.5D with a title that reads Let the City Grow, Flat Vector with the title One Dot, Line Art titled One Line, a 3D Render styled as a Cinema 4D and Blender look, Shape Morph titled One Shape Every Story, a Sticker Explainer about how many elements hide in a phone, a Cyberpunk HUD or FUI piece called Target Acquired, a Collage or Cut-out style called NOGGIN Quarterly, and an Aurora and Glassmorphism piece titled Think in Light. Several films carry a mock brand or studio name, which is the convention that makes a style legible in a few seconds. The last of the listed styles is described as a 9:16 variety show edit, which is a useful signal about the intended output format. The site built from the repository lets a visitor click a film to watch it with sound, and the readme table links each style to both its prompt and its source, so a visitor can move from watching to reading to copying without leaving the project.

Reading the project as a reference, not as a library

There is no package to install and no API to call, and the `package.json` says so, marking the project as `private` and describing it as fifteen motion design films rendered from code with source, prompts and renderer. The single script it exposes is the renderer, and the harness lives in `harness/` with `render.mjs` at its centre. A first run therefore looks like this, from the repository root.

npm install
npm run render

The install step pulls the pinned JavaScript dependencies listed above, and the render script invokes the harness entry point. The Python side is separate and is installed from the pinned `requirements.txt` file, which is where the audio and asset generation work happens. A reader who wants to reproduce a film rather than watch it is expected to read the `demos/` source, since each demo is a self contained implementation of one style. The repository also carries `assets/`, `videos/`, `site/`, `lib/` and `docs/` directories, and the `site/` and `docs/` trees are what the GitHub Pages site is built from, with `index.html` and a `.nojekyll` file at the top level.

What the collection does not settle

Two limits are worth stating plainly. The first is that the format is narrow. Every film is 10 seconds, every film is a single shot built around one idea, and the prompts are written for that shape, so a prompt from this collection is a style reference rather than a reusable instruction for a longer piece. The second is that the evaluation is self administered. The scores come from an AI jury working from `rubric.md`, with no external reviewer, no audience data and no comparison against work produced by other means, so 7.57 to 8.21 measures agreement with the rubric rather than agreement with a market. The licences are the third point. The project is MIT, and the `LICENSE` file sits at the repository root, which covers the code. Whether the same terms extend to the 103 recorded instrument samples, the CC0 and public domain photographs, and the rendered films is a question the documentation does not answer, and for anyone planning to reuse the audio or the pictures commercially that is a question to raise before shipping anything. There are no tagged releases either, so the repository is a snapshot rather than a series of versions you can pin.

Where a code driven film pipeline beats a clip library

The alternative to a repository like this is a stock clip library or a template pack, and the difference in approach is about what you own afterwards. A clip library gives you finished footage, which is fast and reliable but fixed, and the style cannot be reparameterised, recoloured or extended without returning to the vendor. A prompt and a code source give you the mechanism instead of the artefact. The style here is a function of parameters, so a colour, a timing or a composition can be changed and re-rendered, and the film is reproducible because the frame is a pure function of time. The cost is real and it is why this approach suits a fifteen second title card rather than a campaign. A 10 second film at 30 frames a second is 300 frames to render, each one a headless browser capture, and the audio needs a pinned Python scientific stack on top. That is a fast cycle for a short piece and a slow one for anything longer. For a studio that needs many variations of one look, the source is worth more than the film, and for anyone who needs one good 10 second clip, a stock library is the cheaper answer.

Editorial conclusion

mg-styles-15 fits a motion designer or developer who wants fifteen concrete references for a look, plus the prompt and the source behind each one, and it is a good source of working examples for rendering code driven animation from a headless browser. It is not a tool you adopt, and it is not a general prompt library, since the fifteen prompts are written for one 10 second format. Before using anything from it, check three things: whether the MIT licence in the `LICENSE` file covers the assets and the recorded instrument samples as well as the code, whether the `demos/` and `prompts/` directories carry the same terms, and whether the `requirements.txt` and `package.json` dependencies install cleanly on your platform, since the audio path needs a specific pinned Python stack. The last push was on 2026-10-05 and there are no tagged releases, so the repository is a moving snapshot.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. Vincentwei1021/mg-styles-15 on GitHub