Integrate Terrain3D 1.0.2 (vendored, unused for now) #7
Loading…
Reference in a new issue
No description provided.
Delete branch "muse-lantern/da-game:terrain3d-integration"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What
Vendors Terrain3D 1.0.2 (Tokisan Games, MIT) into
addons/terrain_3d/— officialv1.0.2-stablerelease, unmodified (the release'sdemo/folder was not vendored) — enables the editor plugin inproject.godot, and records it indocs/external-resources.md+addons/terrain_3d/VENDORED.md.No level uses a Terrain3D node yet. This is integration only, per Zach's direction 2026-10-22 ("integrate it even if it's unused for now").
Why
Godot core has no terrain system (through 4.7; 4.8 frozen without one). Terrain3D is the mature option: C++ GDExtension on stock builds, GPU clipmap with 10 LODs, 64m–65.5km regions, editor sculpting, dynamic collision, nav baking. The full compatibility report and candidate uses (Region exteriors, traversal testing, menu backdrop) are tracked on the engine tracker: game-planning #1.
Notes for reviewers
bin/). Engine upgrades are gated on upstream builds; the release targets Godot 4.3–4.6+, covering our 4.6.3 standard pin.gl_compatibility, our path) is fully supported per upstream docs. VR/stereo frame budget and fog interplay remain open spike questions (on #1) before any level is built on it.tests/terrain_check.gdfollows the project's headless check style: classes register, a terrain + data instantiate, and the empty-terrain height query returns Terrain3D's NaN no-data sentinel (measured, not assumed).Validation (Godot 4.6.3 standard, headless)
terrain_check: PASS ·smoke_menu: PASS ·arms_check: PASS ·addon_check: PASS— Lantern
The vendor drop itself looks clean: an upstream release, the demo excluded, provenance recorded. Three things to decide before merging, none of them blockers.
The extension loads even though nothing uses it. Shipping
addons/terrain_3d/terrain.gdextensionmeans the native library loads on every editor start and in exported builds, and the enabled plugin (project.godot:19on this branch) adds its editor script, all before any level uses aTerrain3Dnode. That is about 3 MB per platform in a release export (2.6 to 3.5 MB for the desktop and Android release libraries), plus init time.There's no
export_presets.cfgin the repo yet (it's gitignored), so when the first preset is set up, consider addingaddons/terrain_3d/*to its exclude filter until a level uses Terrain3D. Re-include it with the first terrain level.Repo weight.
bin/adds 41.2 MB of prebuilt libraries in plain git (the ~52 MB in the description is roughly the whole addon folder): Windows, Linux x86_64, macOS, Android arm32 and arm64, iOS and web, each in debug and release. The arm32 pair isn't even referenced byterrain.gdextension. Every future Terrain3D upgrade adds another full set to history. Two ways to keep that manageable:addons/terrain_3d/bin/**under Git LFS before the first commit lands on main (CI's checkout step would then needlfs: true); ordocs/input-system.mdtargets Quest controllers via SteamVR; Android arm64 would only be needed for a standalone Quest build.The branch base is old. It's based on
284ec1c, before #8 and #9, so it predates the CI workflow and no CI run has covered this PR. It still merges cleanly: nothing it touches outsideaddons/terrain_3d/has changed on main since that base. Main's workflow already liststerrain_checkand skips it where the file is missing (.forgejo/workflows/tests.yml:43-47), so a rebase onto current main gets it run next to the full current suite list.View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.Merge
Merge the changes and update on Forgejo.Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.