An open-source 3D printable interlocking modular terrain system written in Python using Build123D.
The system is designed for 32mm scale miniatures, placing them on a 50mm square grid (~2"). This allows us to fit ~8mm walls on each side of a square, without encroaching on the space reserved for the miniature. The 32mm scale was selected due to its adoption among digital miniature artists, and because it still allows for the use of 1" scale miniatures even if they appear out of scale.
The system makes use of several parts. The terrain designs are captured on tiles. These tiles are designed to magnetically snap onto supporting plates. These plates come in many sizes, from 1x1 to 5x5, and can be locked together using the included tabs. The separation of terrain onto tiles and the interlocking structure is allow mixing the use of resin and FDM printing, capturing detail in resin for the terrain tiles and providing a strong rigid structure to support them with FDM.
This was created as a competitive alternative to existing systems which contain either restrictive or unclear licensing terms. This project has opted for permissive licensing options, allowing you to use this work in your own projects to create both non-commercial and commercial works. For more information regarding licensing and using it in your own works.
Copyright © 2025 Natalie Baker
Licensed under either of the "Creative Commons Attribution 4.0
International (CC BY 4.0)" or the "Apache License Version 2.0",
or both, at your option.
Unless you explicitly state otherwise, any contribution intentionally
submitted for inclusion in Patchwork Terrain by you, as defined in the
Apache License Version 2.0, shall be dual licensed as above, without
any additional terms or conditions.
The full text for the Creative Commons Attribution 4.0 International (CC BY 4.0) license can be found here:
The full text for the Apache License Version 2.0 license can be found here:
This section simply means to explain intent behind the offered licenses, and is not meant to restrict your selection of license or constitute legal advice.
The Creative Commons option is intended for artists. A lot of existing creative works are provided under a Creative Commons license and are highly compatible with each other, often allowing you to combine multiple works. In comparison, the Apache license is difficult to integrate with creative commons works.
If you are developing an improvement or extension of the base system, then you are encouraged to dual license your work the same as this one. This will allow your changes to be integrated back into this project, and allow artists to make use of the CC-BY license in their works. However, if you are integrating other software or assets you need to be aware of the terms they are provided under.
Both of these licenses require some form of attribution or copyright. I would consider mentioning the project name "Patchwork Terrain" and providing a link to this repository - if convenient - to be sufficient.
Example:
Patchwork Terrain Compatible - https://github.com/notverymoe/rpg_patchwork_terrain
We've setup a build system using mamba, which is a C++ re-implementation of conda. This is mostly to create an easy setup for users unfamiliar with python, venv and the pip package manager. If you would like to manually setup a vent, check the mamba/environment.yml to see the pip dependencies.
For most, this means installing conda-forge, which gives you a setup with miniforge & mamba:
You can find alternate options here:
Once installed, open a terminal in the repo:
- On Linux, run
source mamba/mamba-env.rc- This will initialize the repo's mamba env and activate it
- Subsequent invocations will always attempt an update
- On other operating systems you will need to execute the following commands:
mamba create --prefix ./mamba/env/ -f ./mamba/environment.yml- If you have already created it, you can later check for dependency updates with:
mamba env update --prefix ./mamba/env/ -f /mamba/environment.yml --prune
mamba activate ./mamba/env/
You can build the project by using the files in the script directory:
./scripts/build_release.shwill build all non-debug pieces./scripts/build_base.shwill build the base pieces./scripts/build_extended.shwill build the extended pieces./scripts/run.sh {args}will execute python with the correctPYTHONPATHsetup
You can enable debug logging by passing DEBUG as an argument to any of those scripts.