shader-park-core: Writing GLSL Sculptures in JavaScript

A shader written as a JavaScript object

Shader Park describes itself as a library for creating real-time 2D and 3D shaders, with the summary line being JavaScript to shader. The idea is that you do not write GLSL by hand. You write a JavaScript object describing the geometry, the operations and the parameters, and the library compiles that into shader code. The README puts the pitch in plain terms: with a few lines of code you create shaders that are animated, interactive, and either 2D or 3D. The topics attached to the repository tell you the domain: GLSL, raymarching, signed distance fields, WebGL, live coding, and references to shadertoy and p5js, which places it in the creative coding tradition rather than the game engine one. The live editor on the project site is the fastest way to see what a sculpt looks like, and a separate repository of working projects is linked from the readme for building on.

What lives in the repository directories

The top level of the repository maps onto the pipeline. There is a `glsl/` directory holding the GLSL-side pieces, and the package manifest marks specific files there as having side effects, namely `glsl/bindings.js`, `glsl/glsl-lib.js` and `glsl/sdfs.js`. A `generators/` directory contains the parser and the sculpt handling, with `generators/glslParser.js` and `generators/sculpt.js` also listed as side-effectful. Then there is `targets/`, which is where the conversions live, a `converters/` directory with the command line wrappers, an `examples/` folder, a `test/` directory, and an `out/` directory. There is also a `shader-park-syntax.txt` file at the root, which reads like the grammar reference for the sculpt language, and `index.js` as the public surface. The distribution manifest is explicit about what ships: only `dist` is published, so the source layout matters for reading the code but not for consumers.

Installing the package and the CLI converters

Installation is a single npm command.

npm install shader-park-core

The package exposes several build outputs for different consumers, and the manifest names them all. The ES module entry is `dist/shader-park-core.esm.js`, the CommonJS build is `dist/shader-park-core.cjs.js`, and the browser build is `dist/shader-park-core.umd.js`. There are also dedicated bundles for p5, for TouchDesigner, and for a minimal GLSL renderer in both ESM and CommonJS form. Beyond the library, four command line converters are wired into npm scripts.

npm run toThreeJS my-sculpture.js

npm run toOffline my-sculpture.js

npm run toRawSDF4Meshing my-sculpture.js

Each script maps to a file under `converters/`, and the manifest also registers `toThreeJS` and `toMinimal` as binary commands, so they are callable directly after install. The converters are described as simple examples of how the API can be used, which is a useful framing: they are working code you can read rather than a separate layer.

Export targets and how to add another

The design is target oriented, which is why the same sculpt can end up as a Three.js scene, a standalone offline renderer, or raw signed distance field data for meshing. The README lists the environments it integrates with: webpages, Three.js, TouchDesigner, and Unity, where the note says under development. Adding a new target is a three step procedure. First, implement a class in `targets/` that converts the sculpt into the format the new target needs. Second, expose the functions externally in `index.js`. Third, implement a command line converter, which for now means copying an existing converter and swapping out the single converter function. The README is candid that the boilerplate should be factored out and the converters generated automatically, so this is a known rough edge rather than a settled process.

Running the site against a local copy of the library

For development against the Shader Park website, the project describes a linking workflow rather than a published dev dependency. In the shader-park-core repository you run `npm link`, or `yarn link`, and then in the shader-park-website repository you run `npm link shader-park-core`, or the yarn equivalent. The point of this arrangement is that a change to the library shows up in the site without publishing anything, which is the standard answer to the slow loop between a core library and an application built on it. The test setup follows the same pragmatic pattern: the `pretest` script runs the build first, the test script itself is mocha with the spec reporter, and `prepublishOnly` builds and then tests, so a release cannot ship without passing the suite. The build uses rollup with treeshaking disabled.

What the maintenance picture looks like

There is an odd gap in the version history that anyone evaluating this should notice. The repository is not archived and the last push was on 2026-10-05, so work is still landing. But the published GitHub releases stop at v0.1.26 dated 2022-05-29, with v0.1.25 and v0.1.24 released the same day, hours apart. The package manifest meanwhile carries version 0.2.8, which is well past the last tagged release and was never published as one. In other words, the npm package and the GitHub tags have drifted apart, and the tag list is not a usable signal of what is current. Pinning should be done against the npm version you tested rather than against the newest tag. The licence situation is similarly untidy, with the repository metadata recording MIT while the package manifest says Apache-2.0. Check which one applies to the code you are about to depend on before you ship anything.

Where this fits against writing GLSL directly

The alternative approach is writing GLSL yourself, or using a shadertoy style setup where you paste a fragment shader into a page. That route is shorter for a single effect and gives you full control, since there is no translation layer between you and the GPU. What Shader Park adds is a structured description of the geometry and operations, which pays off when you want the same sculpt in several destinations: a Three.js scene for the web, an offline renderer for stills, and SDF data for meshing. The trade-off is that you now depend on a translation step, and the translation is where surprises live, since a construct that behaves one way in GLSL may compile differently through the generator. The examples directory, with files named basic.js, disco.js, rotateBoxes.js and twirl.js, is the intended way to calibrate expectations before you write a large sculpt.

Editorial conclusion

shader-park-core fits creative coders who want to write shaders as JavaScript objects and export them to Three.js or an offline renderer without maintaining GLSL by hand. It is the wrong choice if you need a maintained release train or Unity support, since the published releases stop at v0.1.26 from 2022-05-29 even though the last push was on 2026-10-05, and Unity integration is listed as still under development. Before committing, run npm run toThreeJS on one of the example files and check that the generated GLSL does what you expected, then note that the package metadata lists Apache-2.0 while the repository licence field says MIT.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. shader-park/shader-park-core on GitHub