Yugen's terrain toolkit turns Godot chunks into editable 3D cells

What the terrain plugin actually does

This is the public version of a Marching Squares Terrain plugin for Godot, written in GDScript and released under the MIT licence. The stated goal is a simple to use and powerful terrain authoring tool inside Godot, aimed at level based small to medium sized stylized 3D games, though the plugin is said to work for a wide variety of games and experimentation is encouraged. The feature list is concrete rather than aspirational. You can raise and lower terrain based on cells in a chunk grid, level terrain to a user set height, and smooth terrain depending on the average height of neighbouring cells. There is a bridge tool that creates a connection between two points by drawing a line between them, and a debug view that reports information for selected cells. The point of the tool is that all of this happens in the Godot editor, so terrain iteration stays inside the same tool as the level layout.

Texturing with sixteen slots and a separate grass mask

The painting model is what distinguishes this from a heightmap generator. You can paint up to fifteen plus one custom textures onto the terrain, and a mask map determines which selected cells should draw MultiMeshInstance3D grass instances. Separating the ground texture from the grass placement is a deliberate structure, because the mask controls instanced geometry rather than pixels, so a designer can grow grass on a slope without repainting the ground under it. There is also a global settings layer for things like the default wall texture, the texture blend mode, the grass animation frame rate and more. A further control sits deeper in the algorithm itself: the internal marching squares vertex merge threshold can be changed, which changes whether the resulting terrain reads as smoother or blockier, so the visual character of the surface is adjustable rather than fixed by the implementation.

Installing means copying an addons folder by hand

There is no package manager step. The install guide is to download or clone the latest stable version of the project and copy the plugin from the project's addon folder into your own, then enable it in Godot under the plugins section of the project settings by checking the box next to the plugin's name. Cloning the repository gives you the addon folder to copy:

git clone https://github.com/ToumaKamijou/Yugens-Terrain-Authoring-Toolkit.git

The repository layout supports that workflow, with an addons/ directory alongside scripts/, scenes/, a project.godot file and the icon files. The addon also carries its own documentation folder, which the README points to for more in depth documentation, and a playlist of YouTube videos is offered as the visual getting started path. For a community project with a Discord server for community demos, feature requests and bug reports, that video and Discord pairing is the de facto documentation, which is worth knowing before you commit a production map to the tool.

Forward+ only, and the renderer gap that comes with it

The supported pipelines section is short and it matters. The plugin only supports Forward+ and limited Compatibility rendering, with both Mobile and Web rendering not supported. The guidance is to pick based on your project and your GPU, since some GPUs work better with Forward+ than with Compatibility. In practice that means a Mobile or Web target rules the toolkit out entirely, which is a hard constraint rather than a warning. The known issues section reinforces the point with two rendering specific problems: d3d12 does not load the terrain surface properly when in game on some devices, and the advice is to set the renderer to vulkan if possible on your device, and some maps turn black or white in game. Both are open defects in a plugin whose purpose is visual output, so a team that needs a stable look should test the pipeline on the target hardware early.

The smooth blending edge case and the other open defect

Three known issues are listed. The first is that smooth texture blending breaks at certain raised or lowered cell edge cases, which is a specific and diagnosable complaint rather than a vague instability: the blending logic does not handle every combination of a raised or lowered cell at the boundary. The second is the d3d12 surface loading problem already mentioned, and the third is maps that turn black or white in game. Together they say the terrain output is reliable in most situations and unreliable at the edges of edited cells, which is exactly where a player will spend time. A level designer working with this tool should treat the cell boundary as a place to look when a texture seam appears, and should keep a fallback path for re-exporting a map through another tool if a project cannot tolerate a black frame.

Pull requests go to a branch that is not in this repository

The contribution workflow is unusual and worth understanding before you open a pull request. The instruction is to target and base your pull requests on public-testing instead of main, because otherwise they cannot be reviewed or approved, and to write a description of what the change fixes or adds so reviewers do not have to read every file. The default branch of this repository is main, so a contributor following the usual GitHub habit would submit against the wrong target. Development is credited to Yugen and originally forked from Jackachulian, with collaborators credited from version 1.0 onwards, including DanTrz, who also created the TileMapLayer3D plugin, powertomato and santarl, who co-authored large parts of the plugin since the 1.0 release. Recent tags include v1.2.2, v1.2.3 and v1.2.4 in March 2026, and the last push was on 2026-10-04.

Against a heightmap pipeline in an external tool

The alternative is to author terrain in an external tool, generating a heightmap, splat map and grass mask in a dedicated 3D package and importing the results into Godot as a finished mesh. The difference in approach is where the iteration loop happens. An external pipeline gives you far more control over terrain generation, erosion simulation and resolution, which matters for large open worlds and for anything photoreal. A toolkit inside the editor gives you a much faster loop for the specific task this plugin targets, small to medium stylized levels, because a designer raises a cell, sees the result immediately and paints a texture without leaving the editor or rebuilding an import. The cost of that speed is portability, since the terrain data is generated by GDScript inside the project rather than being a standard asset, and the plugin's rendering limits apply to everything it produces.

Editorial conclusion

The toolkit fits a Godot developer making level based small to medium 3D games in a stylized look who wants terrain editing inside the editor rather than a separate DCC pipeline, and who is comfortable with GDScript and a plugin that still lists known rendering issues. It does not fit a Mobile or Web project, since those renderers are not supported, and it does not fit anyone who needs a stable public API, because pull requests are reviewed against a private testing branch and several defects are still open. Verify first that your project uses Forward+, that you can accept the known d3d12 surface loading problem and the black or white map issue, and that the terrain granularity suits the scale of your level before you rebuild a map around it.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. ToumaKamijou/Yugens-Terrain-Authoring-Toolkit on GitHub