Add fetched data and heightmap margins to improve tile transition ☼

[pyrollo]

Changes

Add margins around heightmaps, models and voxelization area.

To make tile edges totally invisible, renderers need to know a bit about what's around current tile, in order to be able to draw things that overpass neighbor tile borders (placeable structures in particular).

Voxelization areas

Enlarging voxelization area is quite straightforward. The renderers know what they have to place and can enlarge voxelization area accordingly. They only needed that Placeables tells what space they could take. A bbox method has been added for that to Placeable interface.

Model fetch areas

To perform proper voxelization, model fetch area also needs to be enlarged according to renderer needs. For example, a rendrer placing trees needs to know about forest area near the edge of other tiles. It also needs to know about what altitude trees outside have to be placed.

This means that a renderer may add margins to several model types (in the above example : vegetation areas and altitude).

To manage that, a list of model type margins have been added to Generation, to store all the needs. Margins don't add but they overlap. A list of model type volumes have also been added to GenerationTile. It stores actual needed volume per model type (this will be really useful for further development, see below).

TileTaskParams has a new AddMarginsTo field where can be told which model types should be enlarged according to the task needs. placementMargins method has been added to TileTask interface to express that volume need as a 'margin' bounding box (margins the six +X/-X/+Y/-Y/+Z/-Z directions stored in a bounding box).

Heightmap areas

Heightmaps may also need to overpass tile limits. This is the responsibility of task writing data to the heightmap to do that.

WritableHeightmap interface have been modified so its now possible to increase its area, until some data is written.

Showcase

Before the PR:

Some tree parts are missing around tile edge (in the middle of the image). Tile transition can be guessed.

After the PR:

No missing tree parts. Tile edge is totally invisible.

Next step

This PR makes it possible to create tasks enlarging model type volumes according to other already fetched models (typically buildings).

This is not included in this PR as it implies some more development (extra needed volume depends on vector feature voxelization and this may be complex).

--> It would be better to wait for #113 to be merged before developing something new on voxelizers.

TODOs

• Check everything has been updated with new features (for example: water rendering code and yaml parameters)

Self-checks

• The code has unit tests associated
• The code has Javadoc Comments associated
• Complex / Unexpected code is explained / justified with a small comment
• Relevant documentation inside the /docs folder has been updated
• All examples in docs/usage/Examples.md work the same (or have been adapted if subject to changes in this PR)
• Git history is clean (each commit accomplish a single task and describe it accordingly)
• The texts have been proofread (documentation, error messages, logs, comments...)

[github-actions]

[Maven Build Status]

📑 Commit: 25c1ef8ac7b909ddef5df1198377ab84edda98e6
⌚️ Date: 2026-02-16T10:20:40 (CET)
🛠️ Status: ✅ Success

📦 Download artifact: Generator.jar

[naulan-chrzaszcz]

J'ai que des questions

[pyrollo]

Deux choses à vérifier suite à une présentation à Naulan :

• Les marges devraient être inversées par rapport aux structures (on part du voxel pour retrouver le point d'origine);
• Comment les marges parviennent-elles aux heightmaps ?

[naulan-chrzaszcz]

Est-ce qu'il faut preciser que cela ne fonctionnera pas avec les models de bâtiment ? et que ca fonctionne uniquement sur un model qui place des structures ?

[pyrollo]

Alors, ça marchera pour tous les modèles, il n'y a pas de distinction. En revanche cela ne marchera pas pour toutes les marges effectivement. Seulement celles qui peuvent être déterminées avant de lancer les tâches.

Dans le cas des statistiques sur les heightmaps, et selon ce que l'on veut faire, il va falloir procéder autrement puisqu'il faut peut être appliquer des marges en fonction des modèles téléchargés.

[naulan-chrzaszcz]

Je me demande si c'est pas plus simple comme ca et enlever l'attribut bbox

Suggested change

	@Override
	public WorldBBox3d placementMargins() {
	return bbox;
	}
	@Override
	public WorldBBox3d placeableBBox() {
	return WorldBBox3d.surrounding(inside, borders);
	}

[pyrollo]

Ça fait un peu de calcul en moins de la stocker mais effectivement on peut s'en passer (c'est appelé une fois par tache x tuile x relation si je ne me trompe pas).

En revanche renommer placementMargins en placeableBBox risque d'être très confusant. Dans l'interface, il s'agit de renvoyer les marges à appliquer et cela peut être totalement indépendant des placeables (ça pourrait être autre chose).

[pyrollo]

Je viens de voir, c'est utilisé à plusieurs endroits. Supprimer l'attribut va plutôt compliquer les choses (faire le calcul à deux endroits + le refaire plein de fois pour rien).