Integrate Terrain3D 1.0.2 (vendored, unused for now) #7

Open
muse-lantern wants to merge 1 commit from muse-lantern/da-game:terrain3d-integration into main
Member

What

Vendors Terrain3D 1.0.2 (Tokisan Games, MIT) into addons/terrain_3d/ — official v1.0.2-stable release, unmodified (the release's demo/ folder was not vendored) — enables the editor plugin in project.godot, and records it in docs/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

  • First binary dependency in the project — prebuilt per-platform libraries (~52MB in bin/). Engine upgrades are gated on upstream builds; the release targets Godot 4.3–4.6+, covering our 4.6.3 standard pin.
  • Compatibility renderer (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.gd follows 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)

  • Import: clean (extension + plugin load; only the known exit-time dummy-texture noise)
  • terrain_check: PASS · smoke_menu: PASS · arms_check: PASS · addon_check: PASS

— Lantern

## What Vendors **Terrain3D 1.0.2** (Tokisan Games, MIT) into `addons/terrain_3d/` — official `v1.0.2-stable` release, unmodified (the release's `demo/` folder was not vendored) — enables the editor plugin in `project.godot`, and records it in `docs/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 - **First binary dependency** in the project — prebuilt per-platform libraries (~52MB in `bin/`). Engine upgrades are gated on upstream builds; the release targets Godot 4.3–4.6+, covering our 4.6.3 standard pin. - Compatibility renderer (`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.gd` follows 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) - Import: clean (extension + plugin load; only the known exit-time dummy-texture noise) - `terrain_check`: **PASS** · `smoke_menu`: **PASS** · `arms_check`: **PASS** · `addon_check`: **PASS** — Lantern
Per Zach's direction 2026-10-22: vendor the official v1.0.2-stable
release (addons/terrain_3d/, unmodified; demo/ not vendored),
enable the editor plugin, and record it in the attribution ledger.
No level uses a Terrain3D node yet — integration only.

Terrain3D is a C++ GDExtension (first binary dependency); builds
cover our Godot 4.6.3 standard pin and the Compatibility renderer
is fully supported upstream. Evaluation + spike questions are
tracked on game-planning #1.

Verified on the pinned standard build: headless import clean,
tests/terrain_check.gd PASS (classes register, terrain + data
instantiate, empty-terrain height query returns the NaN sentinel),
smoke/arms/addon suites still PASS.
First-time contributor

The vendor drop itself looks clean: an upstream release, the demo excluded, provenance recorded. Three things to decide before merging, none of them blockers.

  1. The extension loads even though nothing uses it. Shipping addons/terrain_3d/terrain.gdextension means the native library loads on every editor start and in exported builds, and the enabled plugin (project.godot:19 on this branch) adds its editor script, all before any level uses a Terrain3D node. 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.cfg in the repo yet (it's gitignored), so when the first preset is set up, consider adding addons/terrain_3d/* to its exclude filter until a level uses Terrain3D. Re-include it with the first terrain level.

  2. 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 by terrain.gdextension. Every future Terrain3D upgrade adds another full set to history. Two ways to keep that manageable:

    • put addons/terrain_3d/bin/** under Git LFS before the first commit lands on main (CI's checkout step would then need lfs: true); or
    • vendor only the platforms the game ships on, and fetch the rest on demand. Today that looks like desktop x86_64 only, since docs/input-system.md targets Quest controllers via SteamVR; Android arm64 would only be needed for a standalone Quest build.
  3. 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 outside addons/terrain_3d/ has changed on main since that base. Main's workflow already lists terrain_check and 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.

The vendor drop itself looks clean: an upstream release, the demo excluded, provenance recorded. Three things to decide before merging, none of them blockers. 1. **The extension loads even though nothing uses it.** Shipping `addons/terrain_3d/terrain.gdextension` means the native library loads on every editor start and in exported builds, and the enabled plugin (`project.godot:19` on this branch) adds its editor script, all before any level uses a `Terrain3D` node. 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.cfg` in the repo yet (it's gitignored), so when the first preset is set up, consider adding `addons/terrain_3d/*` to its exclude filter until a level uses Terrain3D. Re-include it with the first terrain level. 2. **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 by `terrain.gdextension`. Every future Terrain3D upgrade adds another full set to history. Two ways to keep that manageable: - put `addons/terrain_3d/bin/**` under Git LFS before the first commit lands on main (CI's checkout step would then need `lfs: true`); or - vendor only the platforms the game ships on, and fetch the rest on demand. Today that looks like desktop x86_64 only, since `docs/input-system.md` targets Quest controllers via SteamVR; Android arm64 would only be needed for a standalone Quest build. 3. **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 outside `addons/terrain_3d/` has changed on main since that base. Main's workflow already lists `terrain_check` and 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.
This pull request can be merged automatically.
This branch is out-of-date with the base branch
You are not authorized to merge this pull request.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u terrain3d-integration:muse-lantern-terrain3d-integration
git switch muse-lantern-terrain3d-integration

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.

git switch main
git merge --no-ff muse-lantern-terrain3d-integration
git switch muse-lantern-terrain3d-integration
git rebase main
git switch main
git merge --ff-only muse-lantern-terrain3d-integration
git switch muse-lantern-terrain3d-integration
git rebase main
git switch main
git merge --no-ff muse-lantern-terrain3d-integration
git switch main
git merge --squash muse-lantern-terrain3d-integration
git switch main
git merge --ff-only muse-lantern-terrain3d-integration
git switch main
git merge muse-lantern-terrain3d-integration
git push origin main
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
dead-air/engine!7
No description provided.