Polygonjs: node based WebGL scenes, now in maintenance mode

v1 is in maintenance mode and v2 has taken over

The most important paragraph in this README is the notice at the top, and any evaluation that ignores it will waste your time.

Polygonjs v1 is no longer actively developed. It has been superseded by Polygon v2, which is available on the same website. The consequences are spelled out: no new features are planned for this repository, only critical fixes are considered and even those are not guaranteed, and new projects should start with Polygon v2 instead.

What does not change is the installed code. Existing v1 projects keep working, the npm packages stay published, and the documentation below stays available for reference. There is also a commercial detail. If you purchased a licence for Polygonjs v1, the account page has a link to purchase Polygon v2 for the same price you paid for v1, which tells you the project is run commercially rather than as a hobby.

The repository is therefore a reference implementation and a maintenance branch rather than a growth area. The last push was on 2026-08-08 and there are no GitHub releases, so the npm version line in package.json, currently 1.5.98, is the practical reference point for what exists.

Scenes are built by connecting nodes

Polygonjs is a node based 3D WebGL design tool that helps create 3D interactive experiences for the web without having to code. A scene is assembled by creating nodes and connecting them, and the README describes the result as a non-destructive workflow where you can try different ideas quickly without fearing of breaking anything.

That non-destructive property comes from the structure. Nodes are grouped in contexts, each for a specific type of task. ANIM nodes create animations, AUDIO nodes generate and modify audio, COP nodes import and update textures, EVENT nodes trigger or react to scene events, GL nodes create GLSL shaders, JS nodes add state and events to scene objects, MAT nodes create surface finishes, OBJ nodes add objects to the scene, POST nodes set up post processing, ROP nodes set up the renderers, and SOP nodes handle procedural modelling.

The categorisation is the useful part for someone evaluating the tool, because it tells you the range: this is not only a modelling system, it covers shaders, audio and post processing in the same graph.

The second design commitment is extensibility. Polygonjs is designed to be extended, and the README says that if it does not have a feature you need you can add it, either through its API or by reading how the existing nodes are implemented in this repository and using that as a starting point.

Why the local editor is recommended for production

The editor can be used from the web or locally, and the README is clear that the web version is convenient to discover the editor while the local version is recommended for production. The reasons are listed and they are about workflow rather than features.

Quick access to models and textures on your computer matters when a scene uses real assets rather than placeholders. Tree shaken exports mean the build includes only the nodes you use, which is a direct consequence of the graph model and a real saving on a large scene. Git integration follows from the next point: every file is saved as text, either json or javascript, so a scene is diffable, mergeable and reviewable like code. Version tracking follows from that too, since the project is an npm module with its version in package.json like any other dependency. And integration into any web project is listed, with threejs, vuejs, react and vanilla named as examples.

The repository reflects that design. The tree holds src/, config/, examples/ with engine and presets folders plus start pages, tests/, public/, a vite.config.mjs, an .eslintrc.js, a .prettierrc.json, a tsconfig.json and a yarn.lock, with a .yarnrc.yml for the Yarn setup. The build scripts in package.json run webpack and esbuild in sequence, set a large old space size for the build, and copy the threejs examples plus the OCCT and xatlas WebAssembly assets into the distribution.

Starting a project or adding the editor to one

There are two entry paths, and the README keeps them simple.

For a new project the recommended route is the create command:

npm create polygonjs@latest

The Yarn equivalent is yarn create polygonjs. After that you choose one of the templates, and the list is the honest integration surface of the tool: vanilla js, threejs, vuejs, react or react-three-fiber.

If you already have an npm project, you add the editor package instead:

npm add polygonjs-editor

and then start the editor with npm run polygonjs-editor, or yarn polygonjs-editor in a Yarn project. The package name differs from the engine package, which is published as @polygonjs/polygonjs, so a project can depend on the editor tooling without pulling the runtime into its dependency list until it is needed.

The runtime package requires Node 16.13.1 or later and Yarn 1.22.15 or later, and its main entry is dist/src/engine/index_all.js with sideEffects set to false, which is the package level counterpart of the tree shaking the README describes.

Getting at three.js objects from a node

Polygonjs is based on three.js, and the README is candid that while it offers many nodes for many different types of 3D scenes, there are times when you may want to dig deeper and update the scenes in specific ways.

There are two documented ways in. The first is from the scene itself:

const scene = new PolyScene(); // this is the polygonjs scene
const threejsScene = scene.threejsScene(); // and it contains the threejs scene

The second works from any node in the graph. You create the node, compute it, and unwrap the result:

const scene = new PolyScene();
const rootNode = scene.root();
const geo = rootNode.createNode('geo');
const plane = geo.createNode('plane');

The README then shows the compute step, where the container is an envelope that contains a coreGroup, the coreGroup has a threejsObjects method, and the result is an array of THREE.Object3D. In other words, a node produces a scene graph element wrapped in Polygonjs containers, and you can step through those wrappers to the underlying three.js objects whenever the node vocabulary is not enough.

That escape hatch is what makes the tool practical for professionals. The graph handles the authoring, and the escape hatch means you are never trapped inside it.

Four official plugins and the community around them

There are four official plugins, and each one shows a different kind of extension.

The Mapbox plugin adds 3D objects to Mapbox maps, which is the case of putting Polygonjs geometry into a mapping context that is not its own scene. The Occlusion plugin calculates occlusion on a geometry and gets more pleasant lighting, which is a rendering quality plugin rather than an authoring one. The Mediapipe Facemesh plugin tracks a face from a webcam feed, which is a live input source feeding the graph. The Physics plugin creates and simulates rigid bodies, which is a simulation plugin.

Together they cover the four things people usually reach for a separate library for, and they do it in the same graph as everything else. Each plugin lives in its own repository under the polygonjs organisation, with example repositories alongside them.

The communication channels are worth knowing too, because the tool has a community around it: a Discord server, a Discourse forum at forum.polygonjs.com, and a Twitter account. The homepage, documentation and demo all sit at polygonjs.com, and the demo is linked from the README as the quickest way to see the editor without installing anything.

Where Polygonjs v1 is the wrong tool

For new work the answer is the README's own: use Polygon v2. A v1 project started today would inherit a dependency that receives no features, occasional fixes at best, and no GitHub release history to track.

The second wrong case is a team that wants the scene to live in a binary editor file rather than in text. The text based json and javascript files are a feature for git, diffing and review, but they are also a constraint, and a pipeline that expects a single opaque document does not fit.

Third, there is the licence question, and it needs care. The repository listing classifies the project as MIT, while the npm package metadata in package.json declares the licence as PolyForm Shield. Those are different instruments, and for a commercial product that matters. The LICENSE file in the repository root is the text to read, and anyone shipping a Polygonjs based product should settle the question for their own situation rather than assume the badge.

The fourth case is a team that does not want a graph at all. Polygonjs is built around connecting nodes, which is a good fit for procedural and interactive work and a poor fit for a scene that is mostly hand-modelled static geometry.

One detail is easy to trip over. The engine package is @polygonjs/polygonjs while the editor tool is polygonjs-editor, and the create command is npm create polygonjs@latest rather than an install of either name, so the first hour with the tool can be spent on npm naming rather than on 3D.

Editorial conclusion

Adopt Polygonjs v1 only to maintain or extend an existing v1 project, since the npm packages stay published, the documentation remains available and existing projects keep working. Do not start anything new on v1: the repository states that no new features are planned, that even critical fixes are not guaranteed, and that new projects should start with Polygon v2 from the same site. Verify three things first: the licence terms for your situation, because the repository listing shows MIT while the npm package metadata declares PolyForm Shield, and the LICENSE file is the one to read; which template you need, since the create command offers vanilla js, threejs, vuejs, react and react-three-fiber; and that your project can live with text based scene files committed to git rather than a binary editor document. The last push was on 2026-08-08 and the package version in the repository is 1.5.98.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. polygonjs/polygonjs on GitHub
4. Project website
5. README