# T-Rex Run 3D rebuilds the Chrome dinosaur as a voxel WebGL experiment

> dino3d is a Three.js experiment that redraws the Chrome offline dinosaur game in 3D with hand crafted Magica Voxel assets, a rewritten nature and enemy manager, and a README that is unusually open about how unfinished the code is.

**Priler/dino3d** — 🦖 Google Chrome T-Rex Run! in 3D (WebGL experiment)

- Repository: https://github.com/Priler/dino3d
- Website: http://priler.github.io/dino3d
- Stars: 540 · Forks: 201
- Language: JavaScript
- License: GPL-3.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/priler-dino3d

## A browser game experiment, published as two pages

T-Rex Run 3D is described as a ThreeJS WebGL game made as an experiment, and the repository is structured the way a personal experiment is: a homepage pointing at a playable build, a second low page, and the source in the repository.

The two URLs matter for anyone evaluating it. The low page is the one to open if you want the game to run on ordinary hardware, and the main page is described as the alternative version with the best quality settings for high-end PCs. That is a sensible split for a WebGL project whose cost is mostly fill rate, and it tells you the author expected a range of machines rather than a single target.

The framing as an experiment is repeated in the README, which also says the graphics were all hand crafted with Magica Voxel software so that the overall feel and look of the game stays the same as the original 2D game. The goal was fidelity to the original game, not a new game design, and the assets follow from that decision.

## Voxel assets built in Magica Voxel and parsed in the browser

The asset pipeline is the most transferable part of the project. Every model was authored by hand in Magica Voxel, and at runtime the .vox files are parsed and turned into Three.js meshes by vox.js, a MagicaVoxel .vox file parser and Three.js mesh builder.

That combination is what produces the look. Voxel art is blocky by nature, and the Chrome dinosaur game is pixel art, so hand building the 3D models in a voxel editor is a way of keeping the same feel rather than approximating it. The alternative, modelling in a conventional 3D package, would have produced something smoother and less like the original.

The repository layout backs this up. There are objects, textures, media, sound, css and js directories, and a libs directory, with the game itself in index.html and a second low.html entry point, and a gulpfile.js for the asset and script tasks. Two separate HTML entry points is also how the two quality profiles are served.

The audio and effects side of the same experiment uses howler.js for audio, the three-nebula particle system engine for WebGL based particles, and a Page Visibility API shim, which is the piece that keeps the game from stuttering when the tab is in the background.

## The control scheme changed twice

The change history documents two substantial updates, and the control scheme is where the churn is visible.

In the first update, the interface was new, the jump button was Space, Arrow Up or W, and the bend down button was Arrow Down, S or Ctrl. Infinity jumping while holding the jump button was added, along with a restart on game end, and several fixes: a bug where a player could switch active tab and in-game collisions stopped working, a bug with textures not fully loaded before the game start, a bug where high scores kept counting after the game ended, a hitbox fix, and the ability to jump from the bend down position, plus disappearing ground textures.

In the second update, the W and S keys were removed. The jump and bend down keys are the ones the README lists today, and the removal of the letter keys is a design change, not a bug fix, which is unusual to see in a game whose whole point was to match the original.

The other changes in the second update are the ones that tell you about the architecture. A voxel terrain was added, palm trees were removed in favour of scorpions and skulls, the user interface became fully pixel art styled, a load screen was added, and there is a new dino reaction on collisions. Most importantly, the nature manager and the enemy manager were fully rewritten for better performance and new features.

## Rewritten managers, and one bug that explains the rewrite

The manager rewrite is the most interesting engineering note in the README, and it comes with a lesson attached. The changelog records that the nature manager and the enemy manager were fully rewritten for better performance and new features, and, in the same list, a fix for moving objects stuttering with the parenthetical comment never use .splice() again.

That is a specific and practical piece of advice. Removing and re-inserting elements in an array while a render loop walks it will reorder or drop elements mid-frame, and the symptom is exactly the stutter the changelog describes. Rewriting the managers so that the update path does not mutate the collection being iterated is the structural fix, and the new features came out of the same rewrite.

The other fixes in that update are of the same character. The black screens bug was fixed, the high jumps bug was fixed, and the scores display was fixed. A game like this fails in the seams between the renderer, the collision data and the timing, and the fix list is a map of where those seams are.

## The README admits the code is unpolished

The most honest paragraph in the README is the one italicised near the top. The code has not been polished and is provided as is, there is a lot of redundant code, and there are tons of improvements that can be made.

That admission sets the terms for reading the source, and it is the right thing to take at face value. The project is a demonstration of an idea, built to show that a browser game with voxel art and a particle system could be assembled in Three.js, and the code was written to reach that point rather than to be maintained as a foundation.

Two other details reinforce the picture. The task list lives on a Trello board rather than in the repository, so the intended direction of the work is public but is not versioned with the code. And the dependency manifest is an old style package.json with a lockfile version 1 and a flat list of pinned transitive packages, which is what a project that was built once and not rebuilt for a long time looks like.

None of that makes the code bad. It makes the code an example, and examples are read differently from foundations.

## Where the project is the wrong choice

The first limit is the one the author states. This is not a codebase to extend into a serious game, because the redundant code and the missing polish are the point of the disclaimer, and a project that adopts it inherits both.

The second is the asset pipeline. The models are Magica Voxel .vox files, so anyone producing new content needs Magica Voxel or an equivalent exporter, and the runtime depends on a third party parser and mesh builder to turn them into Three.js geometry. A team with its own art pipeline in a conventional format would be converting assets rather than authoring them.

The third is the web platform dependency. A Three.js WebGL game needs a browser with WebGL, and the two quality profiles exist precisely because the high settings need more than a modest machine has. The Page Visibility API shim in the credits is another reminder of how much of this is a browser environment project.

The fourth is packaging. There is no published release, the homepage is a GitHub Pages site, and the change history stops at the second update, with the last push to the repository on 2026-07-09. If you want a maintained engine to build on, this is a reference implementation rather than a dependency.

## Licence, authorship and the stack behind the game

The project is licensed under GPL-3.0, with the LICENSE file at the root of the repository, and the author is credited as Abraham Tugalov with a 2020 copyright line. The README also credits Aidar Ayupov and Vildan Safin for inspiration about the 3D models, Rifat Fazlutdinov for a Telegram bug report bot, and Arnur Bekbolov for skin ideas.

The third party stack is listed explicitly, which makes the project a reasonable reference for anyone assembling a similar WebGL game. Three.js provides the 3D library, ephtracy's project is credited as a free lightweight 8-bit voxel art editor, vox.js handles the MagicaVoxel parsing and mesh building, howler.js handles audio, three-nebula is the WebGL based particle system engine for Three.js, and visibly.js is a Page Visibility API shim.

The repository also has a .github directory, a .gitignore, a gulpfile.js, a package.json with a lockfile, and the media, sound, textures, objects, css and js directories, so the whole thing is a static site with a build script rather than a package published to a registry.

## Conclusion

dino3d fits a developer who wants to read a complete small WebGL game, especially one that shows how a voxel art pipeline plugs into Three.js, and the change history is a useful record of what breaks in a browser game. It is the wrong base for a production game, since the README states the code has not been polished, that redundant code remains and that many improvements are possible. Before you build on it, check three things: that the browser supports WebGL, that you can live with the asset pipeline requiring Magica Voxel files parsed by vox.js rather than a standard model format, and that you accept the dependency stack, which is pinned to an old npm lockfile format with no published releases. The licence is GPL-3.0, there are no GitHub releases, and the last push was on 2026-07-09.

## FAQ

### How do I play T-Rex Run 3D?

The game is published as web pages: a low page for ordinary hardware at http://priler.github.io/dino3d/low.html and a version with the best quality settings for high-end PCs at http://priler.github.io/dino3d/. It needs a browser with WebGL support.

### Which keys control the dino in T-Rex Run 3D?

The jump keys are Space, Arrow Up and W, and the bend down keys are Arrow Down, S and Ctrl. The change history notes that W and S were removed in the second update, and that holding the jump button gives an infinity jump.

### What tools were used to make the 3D models?

All the graphics were hand crafted with Magica Voxel so the look matches the original 2D game, and at runtime the .vox files are parsed and turned into Three.js meshes with vox.js, a MagicaVoxel .vox file parser and Three.js mesh builder.

### Is the dino3d code suitable for a production game?

The README says the code has not been polished, is provided as is, contains a lot of redundant code and has many improvements that can be made. It is best read as a reference implementation of a WebGL game rather than a maintained engine.

### Which libraries does T-Rex Run 3D use?

Three.js for 3D, howler.js for audio, three-nebula as a WebGL particle system engine for Three.js, vox.js for parsing MagicaVoxel files, and visibly.js as a Page Visibility API shim.

## Sources

- [Issues](https://github.com/Priler/dino3d/issues)
- [License: GPL-3.0](https://github.com/Priler/dino3d/blob/master/LICENSE)
- [Priler/dino3d on GitHub](https://github.com/Priler/dino3d)
- [Project website](http://priler.github.io/dino3d)
- [README](https://github.com/Priler/dino3d/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/priler-dino3d