# threejs-sandbox: render experiments you will have to finish yourself

> The threejs-sandbox repository is a set of experiments and extensions to THREE.js, one directory per effect, from a GTAO pass to temporal reprojection and translucent materials. Its own README warns that the pages are a sandbox of examples, not necessarily ready to include in projects, and the licence is MIT with credit appreciated rather than required.

**gkjohnson/threejs-sandbox** — Set of experiments and extensions to THREE.js.

- Repository: https://github.com/gkjohnson/threejs-sandbox
- Stars: 869 · Forks: 107
- Language: Roff
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/gkjohnson-threejs-sandbox

## A disclaimer first, and it is the most important line

The README opens with a claim and a warning in the same sentence. It is a set of experiments and extensions to THREE.js, and then this: these pages are a sandbox of examples and not necessarily ready to include in projects and may require some work to properly and performantly integrate.

That sentence decides how to read the whole repository. Nothing here is a maintained library with a compatibility promise, and the word sandbox is doing the work: the code is a working demonstration, and the distance between a demonstration and a production component is exactly the work the author is warning about.

The licensing position is unusually relaxed. If any classes are used in a project or application credit is appreciated, though not required, and the author asks to be told about it. The licence itself is MIT. So the code can be taken, and the only expectation is a mention and a note, which is the arrangement that makes these pages usable as reference code in a way that a more restrictive licence would not.

The project metadata is thin in the way you would expect from a laboratory notebook rather than a product. There is no homepage, no GitHub releases, the default branch is master, and the last push was on 2026-10-18. The topics are 3d, effects, experiments, geometry, memory, optimize, shaders, three-js and webgl, which describes the interests of the collection rather than the shape of an API.

## No build step, one linter, and a static server

The package.json is four lines of script and three dev dependencies, and the absence is the architecture.

```json
{
  "scripts": {
    "start": "static-server",
    "lint": "eslint \"./**/*.js\""
  },
  "devDependencies": {
    "eslint": "^7.32.0",
    "eslint-config-mdcs": "^4.2.3",
    "static-server": "^2.2.1"
  }
}
```

There is no build script, no bundler, no transpiler, no test script and no three.js dependency. The start script runs a static file server, and the lint script runs ESLint over every JavaScript file in the tree. Everything else is absent because it is not needed: the demos are static pages that load three.js themselves and run in the browser, with no compilation step in between.

That has two consequences. For a reader, opening a directory and looking at the files is the entire workflow, with the same page you would see running. For anyone who wants to use a class in their own build, the code has to be lifted out by hand, and the integration work the README mentions is exactly this: the code was written to be self-contained on a page, and a project has different module boundaries, different bundler assumptions and different performance budgets.

The lint configuration is equally minimal, an .eslintrc.json at the root using the mdcs config, and the .editorconfig handles formatting. The ESLint version pinned at ^7.32.0 is a good deal behind current releases, which is consistent with a repository that is not trying to be a maintained package.

## Thirty-odd directories, one technique each

The top-level listing is the catalogue, and the naming convention is consistent enough to read as a table of contents.

The screen-space work includes gtaoPass/, motionBlurPass/, screenSpaceReflectionsPass/, pixel-reprojection/ and pixel-outline-pass/. The filtering and image work includes sharpen-filter/, bicubic-filtering/, sobel-outline/, lens-effects/ and colorblindness-utils/. Transparency gets its own cluster: translucent-material/, screendoor-transparency/, volume-lights/ and shadow-volumes/, and the README's project list adds stochastic transparency and a triangle draw order reorganizer for transparency and overdraw as ideas.

The remaining directories cover the parts of a renderer that are less often written from scratch. There is pcss/, mergeVertices/, basis-transform/, custom-mipmap-generation/, a 3d-lut/ directory, colorspace-exploration/, transform-utils/, tracked-scene/, binned-cube-points/, blue-noise-generation/, conditional-lines/, topography-shader/, world-unit-points/, fat-line-opacity/ and perspective-fat-lines/.

Two directories stand out as more than an effect. shader-debugger/ is a shader debugging tool, and the project list names a related idea of using a GLSL syntax parser for a debugger. shader-replacement/ is a mechanism for swapping shaders, which is the kind of thing that becomes a development tool rather than a render feature.

Taken together the collection covers most of what separates a three.js scene from a good-looking one: light transport approximations, transparency ordering, filtering, colour management and the small utility code that every project ends up rewriting. That is the real value of the repository, and it is a value that is easy to underestimate until you start looking for the third-party library that does one of these things well.

## The potential projects list is a research agenda, not a roadmap

Roughly a third of the README is a list of things that do not exist yet, and it is worth separating that list from the directories above because the two are easy to confuse.

At the top of the list are Deferred Renderer, and TRAA, non float buffer on volume-lights, with two references attached: a playdead implementation and an article by Alex Tardif on temporal anti-aliasing. Those links are the tell. A temporal reprojection implementation is the kind of thing that takes a long time to get right, and the fact that the author is pointing at a well-known presentation and a specific write-up rather than at his own code suggests the idea is still being worked out.

The list continues with a GLSL syntax parser for a debugger, VXGI, subsurface scattering, SSDO, stochastic transparency, a glossy refraction post effect based on overlap and depth, a glint shader, an immediate-mode style global or imported tool for drawing debug widgets, bent normals, screen space shadows, a helper for depth peeling renders, a gem shader, a texture atlaser for mesh optimization, screen space global illumination, a triangle draw order reorganizer for transparency and overdraw, and temporal volume lights with per-fragment jitter.

The Next section is shorter and more fundamental: a half edge data structure, GPU particles, and curl noise, the last with links to a Bridson paper and an introduction to curl noise. Those are not render effects. A half edge structure is a mesh representation, and GPU particles is a simulation technique, so the direction of travel is away from post-processing and towards the data structures underneath a real-time renderer.

So the honest reading is that the directories are things the author has tried, and the lists are things he intends to. If you are looking for a temporal reprojection implementation, the repository may not have one, and the references are more useful than the code.

## What the repository does not give you

Three gaps are worth naming before anyone builds on this.

The first is packaging. The package.json has no name and no version field, there are no GitHub releases, and the only scripts are start and lint. There is nothing to install, nothing to pin and no changelog. When you take code from here, you are copying files, and the record of what version of three.js they were written against is in the demo page, not in any manifest.

The second is tests. There is no test script, no test directory and no test framework in the dev dependencies. The demos are the verification: if the page renders, the effect runs. That is a reasonable way to validate a render technique and a poor way to validate a component you depend on, because nothing tells you that a change in the three.js version has broken the effect.

The third is the compatibility question. The three.js API moves, and a page written against an older release can break in ways that show up as a blank canvas or a silently wrong render. With no version pinned in the project, the only way to know what a given demo expects is to read the demo.

None of this makes the repository bad value. It makes it a body of reference code with a permissive licence, which is a different thing from a dependency, and the difference is worth keeping clear before the first folder is copied into a real project.

## How to use it, and how to credit it

Given all of that, the sensible uses are specific.

The first is reading. If you are implementing temporal reprojection, screen space reflections, translucent surfaces or a GTAO pass yourself, having a working page to read is worth a lot, and the technique is the part that transfers, not the code. The transparency cluster in particular, with translucent-material/, screendoor-transparency/, volume-lights/ and shadow-volumes/ sitting side by side, is a set of four problems that are usually solved separately and are easier to get right when you can see them next to each other.

The second is lifting. The MIT licence permits it, the author explicitly wants to know when his classes are used in a project, and the credit request is a request rather than a condition, so the cost of doing the right thing is a line in a NOTICE file and an email.

The third is the tools. shader-debugger/, shader-replacement/ and the colourblindness utilities are closer to development aids than to render effects, and the immediate-mode debug widget idea on the list is a natural fit for anyone who has wanted to draw a diagnostic overlay in a three.js scene.

What the repository is not is a library you depend on, and the author says so twice in three lines of README. Adopting it as a dependency is not an option that exists. Reading it, borrowing from it, and then doing the integration work yourself is the path it was built for.

## Conclusion

Use threejs-sandbox as a reference library when you need to read a working implementation of a specific render technique, because each effect sits in its own directory with a page you can open, the code is MIT licensed, and the author asks only for credit. Do not plan to install it as a dependency, because there is no published package, no version in package.json and no build step, and do not drop a page into a production project without the work the README warns about, since the examples may need real work to integrate properly and performantly. Before you build on one of these, read the demo's own page for its assumptions about the three.js version it was written against, check the corresponding directory in your own project for the same assumptions, and decide whether the effect you want is one the author has actually built or one that is still only an idea on the potential projects list.

## FAQ

### Is threejs-sandbox ready to use in a project?

The README says the pages are a sandbox of examples and not necessarily ready to include in projects, and that they may require some work to properly and performantly integrate. There is no published package, no version in package.json and no build step, so the code has to be lifted into a project by hand.

### How do I run the threejs-sandbox demos?

The package.json defines a start script that runs static-server and a lint script that runs eslint over the JavaScript files. There is no bundler and no three.js dependency in the manifest, so the demos are static pages served from the repository.

### What licence does threejs-sandbox use?

MIT, with a LICENSE file in the repository. The README asks for credit if any classes are used in a project or application, though not required, and asks to be told about it.

### Which render effects are actually implemented in threejs-sandbox?

The top-level directories include gtaoPass, motionBlurPass, screenSpaceReflectionsPass, pixel-reprojection, translucent-material, screendoor-transparency, volume-lights, shadow-volumes, pcss, mergeVertices, basis-transform, custom-mipmap-generation, 3d-lut, colorblindness-utils, sobel-outline, sharpen-filter, bicubic-filtering and shader-debugger. The README's potential projects list, by contrast, is a set of ideas that do not exist yet.

## Sources

- [gkjohnson/threejs-sandbox on GitHub](https://github.com/gkjohnson/threejs-sandbox)
- [Issues](https://github.com/gkjohnson/threejs-sandbox/issues)
- [License: MIT](https://github.com/gkjohnson/threejs-sandbox/blob/master/LICENSE)
- [README](https://github.com/gkjohnson/threejs-sandbox/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/gkjohnson-threejs-sandbox