wgpu-mc: a Rust rendering engine for Minecraft, mid rewrite

What wgpu-mc is actually building

wgpu-mc is a standalone WebGPU rendering engine written in Rust using the wgpu crate, and the stated goal is to create a new rendering engine for Minecraft to replace the existing OpenGL renderer. The project description calls it a Rust based replacement for the default Minecraft renderer.

The history matters for reading the current state. The project was started in late 2021 as a pet project, and it is now a substantial codebase with a Java and Rust split across the tree.

What WebGPU gives you in this context is a modern graphics API that maps onto Vulkan, Metal and DirectX, which the repository topics list alongside wgpu, wgpu-rs, 3d, engine, minecraft, renderer, rust, jni, java, fabricmc and blaze3d. The graphics backend becomes a choice rather than a fixed dependency on OpenGL, and a single Rust implementation can target several platforms.

The audience is fairly specific. This is not a resource pack or a shader pack, and it is not a client mod in the ordinary sense. It is infrastructure for people who want to work on Minecraft rendering itself, either as part of the project or by building on top of it.

There is a public Discord and a Matrix room, both linked from the documentation, which tells you where the conversation happens for a project without a website.

Electrum, Project Panama and the Blaze3D backend

The part of wgpu-mc that a Minecraft player would actually touch is Electrum, a Fabric mod that uses Project Panama bindings to integrate wgpu, or wgpu-mc, as a Blaze3D backend.

The mechanism is worth understanding, because it explains the project's shape. Minecraft's renderer is Java, and the new rendering architecture exposes a backend interface that a non-Java implementation can slot into. Project Panama is the mechanism for calling between Java and native code, so the Java side hands work to the Rust engine through those bindings rather than through a command pipe or a separate process. The result is that the Rust engine renders, and the Java game believes it is talking to a normal backend.

The stated goal of the rewrite is full compatibility with the Blaze3D backend API, which the documentation says is going quite well. After that, the plan is to start experimenting again with replacing parts of the Java renderer paths with wgpu-mc, such as terrain rendering and chunk meshing.

That last clause is the important boundary. Even in the project that started as a terrain renderer, terrain rendering and chunk meshing are listed as future work rather than shipped behaviour. The screenshots in the documentation showing wgpu-mc as the terrain renderer are explicitly labelled old.

The repository layout and the Rust and Java split

The top level of the tree shows two projects side by side and the tooling around them.

There is a rust/ directory holding the Rust engine, and a fabric/ directory holding the Fabric mod side. The Java build uses Gradle, with gradlew and gradlew.bat wrappers, a gradle/ directory, gradle.properties and settings.gradle. A lombok.config file sits at the root, which is the Lombok configuration for the Java code, a sign that the mod side uses Lombok annotations.

The helper scripts are revealing about how the project is developed. There are check_repo.sh and check_repo.bat, and cleanup_repo.sh and cleanup_repo.bat, so the same two chores exist on Unix and Windows with parallel implementations. An .envrc file points at direnv, and shell.nix provides a Nix shell for the environment, which together suggest a reproducible Linux development setup for the Rust and Java toolchain side by side.

There is also a media/ directory, holding the logo and the screenshots used in the documentation, and a .github/ directory for the workflows.

The presence of both a Nix shell and Gradle wrappers is the practical detail. Building this means a Rust toolchain and a Java toolchain, and the project tries to make the second one reproducible.

Where wgpu-mc is the wrong tool

The first limit is the one the documentation states outright. As of June 2026 the project is undergoing a large rewrite to work with Minecraft's new and improved rendering architecture. A renderer in the middle of a rewrite is a research project, and anyone expecting a drop-in replacement today will find the API moving underneath them.

The second limit is distribution. The repository publishes no GitHub releases, so there is no tagged artefact to download, no changelog to diff against, and no stable version to pin. The last push was on 2026-06-12, so the tree is a few months old and any build you make from it is a build of a particular moment rather than a release.

The third is that a Fabric mod is a hard dependency. Fabric and its loader have to be present, and the mod has to match the Minecraft version you run. There is no Forge or NeoForge path mentioned anywhere in the documentation.

The fourth is scope. Even after the backend API compatibility work lands, the documentation describes replacing parts of the Java renderer paths, with terrain rendering and chunk meshing named as the next experiments. So the realistic end state, as described, is a working backend with a subset of rendering paths moved, not a complete replacement of the OpenGL renderer.

Compare that with the shader pack route, where an existing renderer is kept and the way it draws is changed instead. The difference in approach is that a shader pack works within the pipeline the game already has, with no new backend, no Rust and no JNI, while wgpu-mc replaces the pipeline itself, which is why the first is a drop-in for players and the second is a project for developers.

Licence, the re-architecture and what an upgrade costs

wgpu-mc is released under the MPL-2.0 licence, with the text in the LICENSE file at the repository root. Mozilla Public License 2.0 is a file level copyleft licence, which is a reasonable fit for this kind of project: if you modify a file of the library and distribute it, that file's source has to be made available, while larger works that merely link against it do not inherit the obligation. That is a different shape from a project level copyleft, and it is worth understanding before you vendor anything from the rust/ directory into a closed product.

Read the LICENSE file yourself for the exact terms, and read it per file if you take code rather than depending on the whole project.

The upgrade cost here is not a version bump, it is a re-architecture. The June 2026 note says the project is doing a large rewrite to work with Minecraft's new and improved rendering architecture, and the Electrum section says the current goal is full compatibility with the Blaze3D backend API, with experiments on Java renderer paths to follow. If you have code against the old backend, that code is written against an API that is being replaced.

The other recurring cost is the toolchain. Rust and Java have to be in the same place, and the repository provides a Nix shell and a direnv file to help with that, but the Gradle side still builds a Fabric mod that has to match the Minecraft version you play, so a Minecraft update can break the mod side even when the Rust side is fine.

The documentation is thin, and that is the honest state

The project documentation is short, and it is worth being direct about what that means for an adopter.

There is no install guide, no build instructions and no configuration reference in what is published. The documentation covers what the project is, the Electrum mod, the rewrite note, and a set of screenshots. It points at a Discord server and a Matrix room for support, and it has a note on the renderer status, but there is no documented path from a fresh checkout to a running game.

What the repository tree tells you is that a build is possible. The gradlew wrapper, the rust/ directory, the check_repo.sh script and the shell.nix file imply a build workflow that exists even if it is not written down in prose. A developer who wants to try it will be reading the scripts and the Gradle files rather than a tutorial.

For a project that describes itself as a pet project started in late 2021 and is now mid rewrite, that is a coherent level of documentation. It is also the main reason to be careful: an adopter is not installing a product, they are reading a codebase.

So the practical approach is to read the code, join the Matrix room or Discord, and expect to talk to the maintainers rather than follow a guide. The one thing the documentation does give you clearly is the status of the rewrite, and that is the piece that should drive your decision about whether to start now.

Editorial conclusion

wgpu-mc fits a developer who wants to work on a modern graphics backend for Minecraft, or who runs a machine where the OpenGL renderer struggles, and who is comfortable building from source with a Rust and Gradle toolchain while accepting that the project is mid rewrite. It does not fit a player who wants a stable, downloadable renderer today, because the project publishes no releases and its own documentation says the rewrite is in progress. Before investing time in it, read the note about the rewrite, check whether the Electrum mod currently supports the Minecraft version you play, and confirm the backend API compatibility work has landed rather than assuming the terrain renderer screenshots in the documentation represent the current state.

Frequently asked questions

Official sources

1. Issues
2. License: MPL-2.0
3. README
4. wgpu-mc/wgpu-mc on GitHub