Terrains (as in Ground Mesh)

[AnneKitsune]

Should terrains be made in an external tool?
Should it be limited to a single plane per xz position?

How do we manage texture merging between different heights?

Planned features:
MAIN

• Mesh generation
• Get height(s) for xz position
• Mesh collider
• Texturing
• Texture merging with different heights (splatting) + modes / heightmap
• Noise generators support (external crates)

SECONDARY

• Foliage support
• Cave support
• Procedural infinite generation algorithm support
• Voxel vs Plane
• Chunk based for infinite generated
• 3D plane & voxel, 2D voxel
• Mesh optimisation
• LOD Support

This description will be modified after discussion.

[OvermindDL1]

Don't forget, not just hightmap terrains but also voxels of many forms, different splatting styles, chunk based or not, generative (infinite) or not, LODs (important to consider with generative LODs) or not, skirts or not, etc etc etc... Giant massive topic here..

[Xaeroxe]

I'd say voxels are out of scope for this RFC, but also definitely a goal of Amethyst outside this RFC. Procedurally generated terrain should be built on top of whatever we make here, but for now I'd also call it out of scope.

[torkleyy]

Should terrains be made in an external tool?

We should use a (if possible: common) file format. That's all. You can use an external tool, maybe we'll create our own tool one day, but if you got too much time there should be no restriction not to write it by hand. The point is it should be an open and easy to understand format, which tool you use doesn't matter. But before we can talk about file formats, we need to actually support the rendering of terrain ;)

[Xaeroxe]

But before we can talk about file formats, we need to actually support the
rendering of terrain ;)

I think we basically already do? It's just a mesh with a texture on it right?

[AnneKitsune]

For a simple one, its just a grid of triangles with a generated texture

[torkleyy]

There's a lot more to terrain rendering: * heightmaps * materials * water * grass * fog, clouds * instanced objects (trees, bushes, etc)

[Xaeroxe]

Yeah that's true. Before we can render anything we at least need some structs to stick the data in though

[AnneKitsune]

Water->Not actually related to terrain, most game implements this by adding water "boxes" around and through the terrain's ground.
Grass->Considered "foliage" (#654 )
Instanced objects-> Foliage (#654 )
Fog + Clouds->Separated from terrain.
Heightmaps->What I called Texture merging

Updating name to be less confusing as to what "terrain" is.

[OvermindDL1]

So should this be renamed to hightmaps then as it's not generic terrain? Don't forget that hightmaps have non terrain usefulness as well.

As for just hightmap rendering, I've generally always had a texture array for the splats, a 16-bit grayscale image (or 32bit but I've never needed that much space) for the height, an rgba image where each channel represents what splat mixture to use at that point, a normal image for fast pathfinding (not lighting, this normal image is for faster pathfinding and it may not match the actual angles of the map), and occasionally another rgba image for indexing into the splat array (so this one would define what splat texture to use at this location and the splat mixture image defines how mix the 4 selected images at this point this meaning you can have up to 256 images (atlas I used) on a single heightmap with up to 4 mixing at any specific point, trivial to do in shader). I thought I had another as well but can't recall off hand...

Then of course a Heightmap-based terrain can be built using the above primitive, but definitely keep the above primitive useful standalone as they have uses other than for generic heightmap terrains (especially once transformed/rotated).

[OvermindDL1]

There could of course be more modern rendering styles, the above is just how I made mine many many years ago all in textures with a single flat mesh passed in.

[AnneKitsune]

Well, since it can have multiple heights per xz position (a cave, for example), we can't really call it a heightmap?

[OvermindDL1]

How are those planned to work, multiple layers of heightmaps alternating flipped to allow for multiple internal layers so things like caves are done, or planning for sections to become invisible and replaced with custom meshes of any format entirely (I've done both in the past), or something else?

[AnneKitsune]

I actually didn't think much about how caves would be done. I know that not having them is a massive limitation of most engines. It requires devs to makes holes in the terrain, and then manually add custom meshes.

[OvermindDL1]

Custom meshes aren't bad though, they can look fantastic if done right. Layered heightmaps work fine but look downright funky at times because the map itself can't angle properly without starting to add tons and tons of layers (aren't you making a voxel thing at that point anyway?). If you want proper caves and you don't want custom meshes then really the only good option then are voxels (voxels can do an excellent job replacing heightmaps, can even just not render the bottom-most polys as well, honestly I'd not mess with heightmaps at all if I were to remake my engine today because you can still load a heightmap into a voxel system anyway so I'd focus on making the best voxel system properly, and with a simple RLE optimization they aren't really any more costly than heightmaps anyway in the case of heightmaps).