Rabbit Ear encodes origami as FOLD graphs and renders them in SVG and WebGL

FOLD is the data model, and everything else is a view onto it

Rabbit Ear assists in encoding, modifying, and rendering origami models. The key architectural decision is that origami models are encoded in FOLD format, which is a mesh based data structure.

That choice does a lot of work. Because the model is a graph rather than a bespoke object tree, the library can offer methods for modifying FOLD graphs directly, and any tool that already speaks FOLD can read what Rabbit Ear produces. The project points at the FOLD validator and viewer at foldfile.com as the way to validate and visualize a FOLD file, described as the mesh file format used by this library.

Around that core sit four other areas. There is a math library, an SVG rendering library, a WebGL rendering library, and various methods for making origami-related calculations.

The rendering split is the part most people will feel first. SVG is the right choice for line art, which is what a crease pattern is: vertices, edges, faces and folds, drawn as strokes. WebGL is the right choice when you have thousands of polygons or want shaded, three dimensional views of a folded model. A library that ships both means the same FOLD graph can go into a printable diagram or into a rendered scene without conversion.

For a designer, that is the difference between a modelling tool and a rendering tool. You change the graph once and both outputs follow.

One package, four distribution shapes, and the ES6 versus UMD decision

The Rabbit Ear library is distributed as a single package which contains an ES6 module for NodeJS, Bun, and module scripts, and as a UMD and CommonJS single file bundle for traditional html scripts.

The package manifest makes the entry points explicit. The main export resolves to the module build on import, the bundled file on require, and the TypeScript declarations for types. There is also a wildcard export mapping ./* so that submodules can be imported directly, each with its own import path and type definitions.

Installation is a normal package manager operation, and both major JavaScript runners are listed:

bun install rabbit-ear

npm install rabbit-ear

For browser use without a build step, there are two CDN URLs. The UMD and CommonJS build lives at https://rabbit-ear.github.io/rabbit-ear/rabbit-ear.js, and the ES6 module build at https://rabbit-ear.github.io/rabbit-ear/src/index.js. The distinction matters: the first drops into a traditional script tag, the second needs a module-aware page.

Manual download is also offered, as a zip on the releases page for each release.

The author is Amber Kraft, and the project is licensed GPLv3.

The build is rollup plus a Python shader bundler plus typedoc plus tsc

Building from source requires a few tools, and the build script shows exactly which.

The development flow is: clone the repository, run bun i or npm i to install dev dependencies, then build the project, which requires rollup. The build command is:

bun run build

What that single command expands to is the interesting part, because it is a chain of four separate steps:

		"build": "bun run clean && python3 ./scripts/bundle-shaders.py && rollup -c && bun run types && bun run docs",

Clean first, which runs bun run tests/clean.js. Then python3 ./scripts/bundle-shaders.py, a Python script that bundles the WebGL shaders into the build, which is why the project needs Python on the path as well as Node or Bun. Then rollup -c, which produces the bundles. Then bun run types, which is tsc, generating the TypeScript declarations. Finally bun run docs, which runs typedoc with typedoc.config.json to build the API reference.

Two things follow. The shader bundling being Python means a JS-only CI image will not build this without adding Python, which is a small but real setup cost. And generating the documentation as part of the build means the docs cannot drift from the code, since they are regenerated from typedoc comments rather than written by hand.

The project also carries a note that packages.json holds the build script and that it is currently hard-coded to bun instead of node, so contributors should know that the npm path is not the primary build path right now.

Version 0.9.41 alpha, with releases that stopped being tagged years ago

The version story needs reading carefully, because the numbers alone are misleading.

The current version is 0.9.41 alpha, released 2026.10.16, with a changelog published on the project site. The package manifest confirms the version string of 0.9.41, the description of origami design library, and a keywords list that includes origami, design, geometry, paper, fold, foldability, generative, parametric, diagram, architecture, creative and art.

Now look at the tagged releases. There is v0.9.41-alpha from 2026-10-19, which is current, but before that v0.9.4-alpha from 2024-05-12 and v0.9.32-alpha from 2022-07-29.

That sequence is out of order, and it tells you the tagging is not systematic. A version number of 0.9.41 sitting between a 0.9.4 and a 0.9.32 in the release list means the numbering is not comparable across tags. Anyone automating a dependency update based on semver will get confused here, and anyone reasoning about how old a given release is has to read dates rather than versions.

The last push was on 2026-10-19, so the code is being worked on daily. The problem is the version number, not the activity. Nothing in this project is 0.9.41 stable, because there is no such thing, and the package is published as an alpha. If your build pipeline refuses prerelease versions, this dependency will need an explicit decision.

Types and tests are wired into the same command set

The package manifest is unusually complete about its own tooling, which makes it a good guide to how a JavaScript library should be set up in 2026.

TypeScript is first class. The types entry is ./types/index.d.ts, the main export carries a types field alongside import and require, and the wildcard export maps types for every submodule. The types script is simply tsc, and the config is a tsconfig.json at the top level. Typedoc handles the reference documentation, with a typedoc.config.json, the typedoc package, a GitHub wiki theme, and a markdown plugin.

Tests run on vitest, and the test script creates its temporary directory before running:

		"test": "mkdir -p ./tests/tmp && vitest",

That mkdir is a small detail that says something. The test suite writes into ./tests/tmp, which means the suite touches the filesystem, and the script makes sure the directory exists first rather than assuming it is checked in.

Linting and formatting are handled by eslint with the airbnb-base config, the import plugin, and eslint-config-prettier to keep eslint and prettier from fighting, and there is a .prettierrc alongside a .prettierignore and an .eslintrc.json. The dev dependency list also includes earcut, which is a polygon triangulation library, which tells you something about how the renderer turns faces into renderable geometry, and @xmldom/xmldom, which is used for XML handling in the FOLD format.

The top level also has a .travis.yml and a .github directory, so the older CI configuration and the newer one coexist.

What the project does not tell you, and where the edges are

Several things a would-be user would want are not stated, and their absence tells you something about the project's current shape.

There is no stated stability guarantee for the API, no compatibility matrix across browsers, and no documentation of which origami calculation methods are implemented. The project description says it provides various methods for making origami-related calculations, which is accurate and also vague. The docs at rabbitear.org/docs are described as containing technical references, and they are the place to look, but the top level does not enumerate them.

The renderer choice is also a real decision rather than an implementation detail. SVG and WebGL are separate subsystems with different strengths, and choosing between them means choosing between crisp stroke rendering for a crease diagram and GPU throughput for large scenes. The library ships both, which is generous, but it also means you have to pick one and you have to accept that some features may exist in one and not the other.

The last push date of 2026-10-19 and the alpha tag from the same day tell you the project is in heavy development. There is a changelog file at the top level and another published on the site, so change tracking is possible, but for an alpha at 0.9.41, expect the API to move between versions.

One more constraint worth naming: the build requires Python for the shader bundling script and rollup for the bundle itself. That is a two language toolchain, which is not a blocker but is a deviation from the single runtime most JavaScript libraries ask for.

Where Rabbit Ear sits against a general purpose geometry library

The comparison that matters for this project is not with other origami tools, it is with general purpose 3D or geometry libraries.

A general purpose library gives you vectors, matrices, meshes, maybe triangulation, and leaves you to build the domain concepts yourself. Rabbit Ear gives you a domain model. The FOLD graph already knows what a vertex, an edge, a face, a crease assignment and a layer order are, and the origami calculation methods operate on that model. If your problem is fold patterns, flat folding, or the geometry of a specific crease assignment, that domain knowledge is the expensive part, and it is what this library provides.

The difference in approach is encoding versus computation. A general purpose library computes over whatever data structure you hand it. Rabbit Ear commits to one structure, FOLD, which means interoperation with the FOLD ecosystem, including the separate validator and viewer at foldfile.com, is free. The cost of that commitment is that if your data is not FOLD, you have to get it into FOLD first.

The GPLv3 licence sharpens that trade for commercial use. The package manifest declares the licence as GPLv3 and the project ships a license file, so embedding this library in a closed source product carries the usual copyleft obligations. For a design tool, a generative art script, or an open project, that is not a problem. For a proprietary product, it is a decision that has to be made deliberately rather than discovered later.

The author is a designer as much as a programmer, and the keyword list shows it: paper, diagram, architecture, art, and generative. That positioning explains the priorities. This is a tool for making origami, and the modelling and rendering are what it is built around.

Editorial conclusion

Rabbit Ear fits a designer or graphics programmer who needs to generate, modify and render origami crease patterns in the browser or in a Node script, and who is willing to work in the FOLD format as the data model. It does not fit someone who needs a stable release, since the current version is an alpha and the published alpha tags are old even though commits are recent. Before adopting it, load a FOLD file into the FOLD validator and viewer first, because that tool is the fastest way to see whether your geometry survives the round trip, and check that your build can run the rollup pipeline that bundles the shaders.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. rabbit-ear/rabbit-ear on GitHub
4. README
5. Releases