Description
HTerrainDetailLayer._generate_multimesh currently allocates MultiMesh instances purely based on the density parameter per chunk, without considering the actual content of the detail map texture.
As a result, even when only a few pixels (e.g. 3 painted spots) are present in the detail map, the system still allocates:
instances = density × chunk_cells
for every chunk in the terrain.
For example, with density = 0.03, a chunk may still preallocate ~270 instances even if only a few are visually enabled via the detail map. The unused instances are later discarded in the vertex shader using mask sampling / culling logic.
Expected behavior
It would be beneficial if the system could optionally:
- Sample the detail map during MultiMesh generation
- Only create instances where the detail map value exceeds a threshold
- Avoid preallocating instance buffers that are fully culled at runtime
This would improve:
- GPU memory usage
- MultiMesh buffer size
- Initialization cost for large terrains
Context / use case
In my case, I am using integrated GPU hardware for development and testing.
When using tree meshes (~2000+ triangles per instance), the initial MultiMesh generation leads to significant GPU load and high primitive counts even when only a small number of detail map pixels are painted.
After adjusting density and distance parameters, performance becomes normal again. However, painting only a few trees still results in a large number of preallocated instances that are not actually visible.
This suggests that runtime cost is dominated by preallocation rather than actual painted content.
Suggestion (optional)
A possible improvement could be introducing a "bake" step:
- Editing mode: detail map only
- Bake mode: generate actual instance list from detail map
- Runtime: use baked MultiMesh only
This would decouple editing convenience from runtime performance.
Environment
- OS: Windows 11
- GPU: AMD Radeon 880M (integrated)
- Godot: 4.x
- HTerrain version: 1.8
Description
HTerrainDetailLayer._generate_multimesh currently allocates MultiMesh instances purely based on the density parameter per chunk, without considering the actual content of the detail map texture.
As a result, even when only a few pixels (e.g. 3 painted spots) are present in the detail map, the system still allocates:
for every chunk in the terrain.
For example, with density = 0.03, a chunk may still preallocate ~270 instances even if only a few are visually enabled via the detail map. The unused instances are later discarded in the vertex shader using mask sampling / culling logic.
Expected behavior
It would be beneficial if the system could optionally:
This would improve:
Context / use case
In my case, I am using integrated GPU hardware for development and testing.
When using tree meshes (~2000+ triangles per instance), the initial MultiMesh generation leads to significant GPU load and high primitive counts even when only a small number of detail map pixels are painted.
After adjusting density and distance parameters, performance becomes normal again. However, painting only a few trees still results in a large number of preallocated instances that are not actually visible.
This suggests that runtime cost is dominated by preallocation rather than actual painted content.
Suggestion (optional)
A possible improvement could be introducing a "bake" step:
This would decouple editing convenience from runtime performance.
Environment