MTerrain gives Godot an octree terrain with 16 kilometre terrain sizes

A terrain system written in C++ as a GDExtension

M Terrain is described as an optimized terrain system and editor for Godot Engine, and the repository description calls it a GDExtension plugin which gives Godot the ability to produce highly optimized terrain for open world games.

The implementation is C++, and the shape of it is a native extension rather than a set of scripts. A GDExtension is Godot's mechanism for calling into compiled code, so the terrain generation, the octree bookkeeping and the mesh building happen outside the engine's interpreter.

The scope is open worlds, and the numbers in the feature list are the clearest statement of what that means. The terrain uses an octree based LOD system for terrain sizes as big as 16km by 16km. A separate octree system provides optimized control of LOD, allowing for a large number of objects in the world, which is a different problem from the terrain mesh itself, because a forest of trees and a field of grass have their own density problem.

Around that core the plugin adds a terrain shader with support for splatmapping, bitwise and index mapping, navigation integration with Godot's navigation system, a grass system with collision for things like trees, grass and rocks, and a path system based on bezier curves with mesh deformation for roads and rivers.

The licence is MIT, the last push was on 2026-09-06, and the release tags are all alphas, with v0.18.2-alpha from 2025-11-25 the most recent.

Why octrees, and what the editor expects from you

The Getting Started section has a sentence that tells you more about this project than the feature list does.

To use this plugin you will need to learn some concepts, and this terrain plugin will not work out of the box. Please read the wiki, or watch the video, which will be helpful.

Three videos are linked, and they are the tutorial: one showing how to use the plugin, one showing how to use height brushes to sculpt the terrain, and one showing texture painting.

That is the honest characterisation of the project. It is not a terrain you drop in and get a landscape, it is a system with a model that you have to understand before it does anything useful, and the documentation is the wiki plus three videos rather than a manual.

For a terrain system, that is defensible. A quadtree or octree LOD system has concepts, and the concepts are what make the tool make sense. A tool that hid them would just be a set of buttons whose behaviour you could not predict.

It also tells you what to budget for adoption. Before you write a line of GDScript you are going to spend time in the wiki and the videos, and the plugin assumes you know how a heightmap, a splatmap and a level of detail scheme fit together.

Splatmapping, bitwise operations and index mapping

The terrain shader is where the visual result comes from, and the feature list names three specific things it supports: splatmapping, bitwise, and index mapping.

Splatmapping is the technique of blending several ground textures according to a weight map, and it is how a terrain gets grass in one place, rock on a slope and sand near water without a separate texture per combination. The weight map is the splatmap, and the plugin's editor tools can import and export them.

Bitwise and index mapping are the parts that are specific to this implementation, and they are the reason a large terrain can carry more than four or eight ground materials. With a conventional splatmap, the number of layers is limited by the number of channels available, and blending many materials means many separate weight maps. With an index mapping approach, each texel encodes an index into a palette of materials, and the bitwise operations are what let the shader read that encoding and resolve it. The result is a single map covering many more materials, which matters when the terrain is 16 kilometres across.

That is the design of the shader, and it is why the terrain is described as optimized rather than merely large. The number of ground materials in an open world is usually much higher than the four a channel-based splatmap handles, and the encoding is what makes the single-map approach viable.

Grass with collision and bezier paths that deform the mesh

Two of the features are about populating the terrain rather than shaping it.

The grass system provides collision for things like trees, grass and rocks. In a world with an octree LOD, vegetation is usually instanced per cell, and the question of whether the player can walk through it is a separate problem from the rendering. A grass system with collision means the collision follows the same distribution as the visual, so the two do not drift apart.

The path system is based on bezier curves with mesh deformation for roads and rivers. Deforming the terrain along a curve is the operation that makes a road sit in the ground rather than on it, and doing it with a curve rather than by hand painting the heightmap is what makes a long road through a 16 kilometre terrain practical to author. A river is the same operation with a different material.

Both features point at the same underlying problem this plugin is solving. An open world is not a mesh, it is a mesh plus a set of things on it, and a tool that only handles the mesh leaves you writing a second system for everything else.

The navigation integration closes the loop. Godot's navigation system needs to know where the ground is and where the obstacles are, and integrating it means the agent paths and the player movement agree with the terrain you actually shipped rather than with a collision proxy.

The editor tools are half the product

The last feature in the list is a long one and it deserves its own reading: editor tools for terrain sculpting, grass painting, navigation painting, path editing, and importing and exporting heightmaps and splatmaps.

Sculpting is the height brushes, which the second video demonstrates. Grass painting and navigation painting are the same idea applied to the two other layers, and the existence of a paint tool for each tells you that the terrain is understood as three stacked maps rather than one. Path editing is the curve authoring for the roads and rivers, and the import and export of heightmaps and splatmaps is the bridge to the tools you already use, so a heightmap produced elsewhere is not locked out.

This is a meaningful design choice for a plugin. A terrain plugin that only renders a heightmap you imported leaves the authoring entirely in a third party program. One with sculpting, painting and path editing in the engine means the whole iteration loop stays in one window, which for a large world is the difference between an artist and a programmer doing the work.

It also means the plugin is a substantial piece of editor code, not just a renderer, and that is where the C++ and the editor tooling in the repository tree are going.

The screenshots in the readme show the plugin in the Godot editor, which is the honest way to evaluate it, since the editor surface is the product.

Building it yourself with godot-cpp and scons

The Build by yourself section is short and it covers the case where you cannot or should not use a prebuilt binary.

First you clone the repository on your local machine, and you need godot-cpp to exist in the GDExtension folder so that you can build it. godot-cpp is added as a submodule in the project, so the only thing you need to do after cloning is to run this code.

git submodule update --init --recursive

That pulls godot-cpp into the GDExtension folder automatically. After that you go inside the GDExtension folder and use scons to build the project.

The arrangement is the standard one for a GDExtension. godot-cpp is the C++ binding layer that lets an extension call into the engine, and shipping it as a submodule means the binding version is pinned to the one the extension was written against, rather than floating against whatever is on the machine. The recursive flag is there because the binding itself has submodules.

SCons is the build tool, and that is a fact about the GDExtension ecosystem rather than a choice this project made on its own.

The practical value of building it yourself is version matching. A prebuilt binary for a GDExtension is compiled against a particular engine version, and if your project uses a different one it will refuse to load. Building from source fixes that, at the cost of needing a C++ toolchain.

The repository is a native extension wrapped in a Godot plugin

The top level listing shows both halves of the project side by side, and it explains how a GDExtension plugin is put together.

There is plugin.cfg, which is what makes the directory a Godot plugin at all, and m_terrain.gd and mterrain_settings.gd with their .uid files, which are the GDScript side, the resource definitions that the editor binds to and the settings that the plugin exposes.

The gdextension/ directory holds the compiled extension and the build files, and the C++ source sits alongside the subdirectories named for the parts of the system: asset_manager/ for the asset loading, brush_masks/ for the brush definitions, gizmos/ for the editor gizmos, gui/ for the panels, and inspector/ for the property editors.

The shader side is substantial, with a shaders/ directory, a shader_include/ directory for shared shader code, and the top level files that define the start of the material. There is show_region.gdshader for displaying a region, start.gdshader and start_opengl.gdshader for the renderer entry points, and the start_material.res and start_material_opengl.res resources that go with them. The presence of a separate OpenGL variant of the same shader is a compatibility measure, so the plugin can run on a renderer that does not support the newer path.

The .gitmodules file and the .github/ directory complete the picture, and the icons/ directory holds the plugin's own icon.

The release tags are worth reading for what they say about the state of the project. All three recent ones are alpha, v0.18.2-alpha, v0.18.1-alpha and v0.18.0-alpha2, so the plugin is at a featureful but explicitly unfinished state, and the author runs a Patreon to support the work.

Editorial conclusion

Adopt M Terrain when you are building an open world in Godot and the built in terrain cannot hold the scale you need, and you are prepared to learn a system the author says will not work out of the box. Do not adopt it for a small scene, since the whole design is an octree LOD system for very large terrain. Verify first which Godot version the GDExtension binary in the release matches, that you can build the extension yourself with godot-cpp and scons if the prebuilt binary does not load, and that the wiki and the video tutorials cover the workflow your project needs, since the readme points there rather than documenting the setup itself.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. mohsenph69/Godot-MTerrain-plugin on GitHub
4. README
5. Releases