# C2ME: a Fabric mod that makes Minecraft chunk generation parallel > C2ME is a Fabric mod that improves Minecraft chunk generation, I/O and loading by using multiple CPU cores in parallel, and it tries hard not to change vanilla behaviour while doing it. The repository is a stack of small modules for rewrites, optimisations and fixes, and the build needs a native toolchain as well as Gradle. **RelativityMC/C2ME-fabric** — A Fabric mod designed to improve the chunk performance of Minecraft. - Repository: https://github.com/RelativityMC/C2ME-fabric - Stars: 819 · Forks: 90 - Language: Java - License: NOASSERTION - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/relativitymc-c2me-fabric ## Chunk work moved off the main thread C2ME, short for C^2M-Engine, is a Fabric mod whose stated purpose is to improve the performance of chunk generation, I/O and loading. The mechanism is not a clever algorithm but parallelism: the work is done by taking advantage of multiple CPU cores, and the project expands the name as Concurrent chunk management engine, describing the goal as making the game better threaded and more scalable with regard to world generation and chunk I/O performance. That framing matters for the audience. This is not a client side optimisation for frame rate. It is for the case where a server is generating terrain, or a player is flying across new chunks, and the work is the bottleneck because it is being done one piece at a time. The project gives a clear recommendation for the best performance: use C2ME with Lithium and Starlight. Those are separate mods for other parts of the problem, and the documentation is explicit that they are companions rather than alternatives. The repository is Java, built with Gradle, and organised as a large set of small Gradle modules whose names describe what they touch. There are rewrite modules for the chunk system, the chunk I/O layer and the chunk serializer, option modules for allocations, chunk I/O, deferred feature calls, math, native math, scheduling and several world generation concerns including a biome cache, and fix modules for chunk I/O threading issues, general threading issues, world generation threading issues and vanilla world generation bugs. There are also utility modules, a server utils module, a lighting threading module, a notick module, an OpenCL acceleration options module, a client module and a FlowSched directory. Reading that module list tells you the shape of the work: this is not one performance trick but a set of interlocking changes to how the game schedules and stores chunks. ## Vanilla parity, and the caveat that comes with it The section on vanilla parity is the one to read before deploying this on a world you care about. The claim is that C2ME does not sacrifice vanilla functionality or behavior, or alter the vanilla world generation in the name of raw speed, by default. The word by default is doing work there, since it implies the behaviour can be changed with configuration. Then comes the caveat, and it is stated as a fact about Minecraft rather than about the mod. Due to the non-determinism of vanilla world generation, worlds will vary significantly run to run even with the same seed. The project says explicitly that this is not a bug on their side. That is a serious operational point and it is easy to skim past. Vanilla world generation already produces different terrain for the same seed, and C2ME does not change that, but the multithreaded version makes the divergence more visible because the order in which chunks are generated differs. In practice it means a seed is not a reproducible world, and any tooling that assumes it is will be wrong. The project is also candid that bugs are unavoidable after all, despite the care taken to avoid modifying vanilla behaviour, and it invites you to open an issue when you find a deviation. The usage notice is short and blunt: back up your worlds and practice good game modding skills. Given the scope of what the mod rewrites, that is the sensible instruction. ## Undefined behaviour sanitization aimed at other mods One module deserves its own section because it shows how the project thinks about its ecosystem. C2ME includes CheckedThreadLocalRandom for the world random, and that implementation is also included in the UWRAD mod on Modrinth, plus a few similar detections. The stated purpose of these detections is to prevent mods from screwing up Minecraft internals and causing undebuggable problems. The reasoning follows from the architecture. Once the game is running chunk work on many threads, a third party mod that reaches into internals and mutates shared state without knowing about the new threading model can corrupt state in a way that produces a crash three hours later with no useful stack trace. A check that fires at the point of the mistake converts an undebuggable failure into an attributable one. The project sets the expectation for these checks carefully. The detection should almost never produce false positives, and when it does fire it should be taken seriously and reported to the corresponding mod authors instead. In other words, a warning from C2ME is treated as a bug report against another mod, not as noise. That is a subtle piece of community design. The mod that benefits most from the threading rework is the one most likely to break other people's setups, so it takes on the work of turning other people's mistakes into actionable reports. ## Datapacks are safe, custom world generators are a risk The compatibility section splits the world generation ecosystem into two categories, and the distinction is practical. World generation datapacks that can run on vanilla Minecraft are fully supported. That is a clean rule, and it is the one most server operators will care about, since datapacks are the mainstream way to change terrain without writing Java. Custom world generators implemented in mods usually run well, but may cause compatibility issues, and the project attributes this to certain design assumptions used by mod authors being broken for further speedups of world generation. The assumption being broken is the one that the generator can assume it is called in a particular order, or that it owns the chunk being built. The project's response is to support the mod authors rather than to defend against them. It tells world generation mod authors that if they find their mod broken, they should look for help on the Discord server, and it says plainly that the maintainers are willing to help mod authors embrace scalable world generation. That is the right stance for a mod whose whole purpose is to change assumptions that other code relied on. The alternative would be to give up the parallelism that makes the mod worthwhile. So the practical guidance is layered. Datapack users are in the clear. Custom generator authors should test early against a C2ME branch, because the breakage will be in their generator's assumptions rather than in C2ME. ## Building needs Clang and CMake, not just Gradle The build section is short and it is where the native side of the project shows. JDK 25+, Clang 22+, CMake and GNU Make are required to build C2ME, and the commands are run in the root directory: ```shell git submodule update --init --recursive ./gradlew clean build ``` The submodule step is not optional boilerplate. The repository has a .gitmodules file, and the submodules directory and the libs directory at the root are where the native components live, so a shallow clone without them will not build. The Gradle wrapper, gradlew and gradlew.bat, is present, so you do not need a local Gradle installation. Why Clang, CMake and Make at all for a Java mod is the interesting part. The optional modules in the tree give the answer: there are options modules for native math and for natives in general, and one for accelerated OpenCL, plus a separate notick module and a lighting threading module. C2ME is not purely a Java mod, it has native components that are compiled outside Gradle and linked in, and the native toolchain is what builds them. The repository also carries a Jenkinsfile alongside the GitHub Actions workflows, a gradle.properties, a settings.gradle and a buildSrc directory, a tests directory, and a licenses directory holding per dependency licence information. The build badge points at a branch named ver/1.18 in the CI configuration and the icon path in the documentation references a 1.17 branch, which is a reminder that the module layout has been carried across many Minecraft versions. ## Only the newest release is fully supported The support policy is stated in three sentences and it is strict. Only the latest Minecraft release and the latest Minecraft snapshot are fully supported. Older Minecraft releases are in long-term support and will receive critical bug fixes. Older Minecraft snapshots are not supported. The distinction between a release and a snapshot matters here because Minecraft publishes a snapshot for every development build. If you follow the game closely and run on snapshots, you are on the fully supported path only on the newest one, and on an unsupported path on everything older. For a long-term-support version, the promise is critical bug fixes only, which is a different proposition from new features and from compatibility work. For a server operator, that generally means an old version keeps working but stops moving. The distribution channels are the two you would expect for a Fabric mod, Modrinth and CurseForge. The project's own issue tracker and Discord server are the support channels, and the Discord is described as the place where world generation mod authors are helped. The default branch name, dev/26.3.0, follows the same versioning idea as the branches referenced in the badges. That is a project organised around tracking Minecraft versions rather than around a single mainline, which tells you how much of the work is version porting. ## An unclassified licence, and what it means for reuse The licence is listed as a custom one that GitHub cannot classify, with the licence information in the licenses directory of the repository and a LICENSE.md at the root. For a mod that players install from Modrinth and CurseForge, that arrangement is common and largely unproblematic. The community norms around Minecraft mod distribution are their own, and the per dependency licence files in the licenses directory suggest the maintainers are tracking what they ship. For anybody who wants to reuse the code, for example in a server plugin, a fork, or a derivative mod, the custom licence is the thing to read carefully, and it is where your counsel comes in. The repository layout tells you why the question exists. The project contains modules that other mod authors are explicitly invited to depend on in spirit, and the undefined behaviour sanitization work in particular is described as a shared effort, since CheckedThreadLocalRandom is also included in the separate UWRAD mod. Work that is intended to be shared across mod authors is exactly the kind of work where the licence terms decide whether sharing is permitted. The release history gives the second half of the maintenance picture. Recent tags include 0.3.6+rc.1 in December 2025, 0.3.6.0 at the end of December 2025 and 0.4.1+beta.1 in June 2026, with the last push on 2026-10-17. The version numbers sit below 1.0 and carry beta and release candidate markers, which is a reasonable place for a mod that is deeply coupled to a game whose internals change every release. ## Conclusion C2ME suits a server operator or a player on a large world who has measured chunk generation and loading to be the bottleneck and has the CPU cores to spare. It is the wrong choice if your world is small, if you cannot accept worlds that differ between runs even with the same seed, and it is the wrong choice if you cannot read the logs when something breaks, because the project asks you to report deviations to the mod authors it detects. Verify three things before you deploy it: that the Minecraft version you run is the latest release or snapshot rather than an old snapshot, that the world gen datapacks you use are vanilla compatible as the documentation requires, and that you have a working backup, because the project states plainly that you should back up your worlds. ## FAQ ### What does C2ME do in Minecraft? It is a Fabric mod that improves the performance of chunk generation, I/O and loading by taking advantage of multiple CPU cores in parallel, with the goal of making the game better threaded and more scalable for world generation and chunk I/O. The project recommends using it with Lithium and Starlight for the best performance. ### Does C2ME change vanilla world generation? The project states that it does not sacrifice vanilla functionality or behavior, or alter vanilla world generation in the name of raw speed, by default. It also notes that because vanilla world generation is non-deterministic, worlds vary run to run even with the same seed, which the project says is not a bug on their side. ### Which Minecraft versions does C2ME support? Only the latest Minecraft release and the latest snapshot are fully supported. Older releases are in long-term support and receive critical bug fixes, and older snapshots are not supported. ### How do I install C2ME, and what should I watch out for? It is distributed through Modrinth and CurseForge. The usage notice asks you to back up your worlds and practise good game modding skills, which matters because the mod rewrites the chunk system and can surface incompatibilities in other mods. ### What does building C2ME from source require? JDK 25 or newer, Clang 22 or newer, CMake and GNU Make, plus the git submodules. In the root directory you run git submodule update --init --recursive and then ./gradlew clean build. ### What is CheckedThreadLocalRandom in C2ME? It is part of the mod's undefined behavior sanitization, used for the world random and also included in the separate UWRAD mod. These detections exist to prevent other mods from corrupting Minecraft internals and causing undebuggable problems, and the project says they should almost never produce false positives and should be reported to the mod authors concerned. ## Sources - [Issues](https://github.com/RelativityMC/C2ME-fabric/issues) - [README](https://github.com/RelativityMC/C2ME-fabric/blob/dev/26.3.0/README.md) - [RelativityMC/C2ME-fabric on GitHub](https://github.com/RelativityMC/C2ME-fabric) - [Releases](https://github.com/RelativityMC/C2ME-fabric/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/relativitymc-c2me-fabric