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).

[torkleyy]

I agree with @OvermindDL1.

Btw, don't forget lighting, that's also special for terrains.

[AnneKitsune]

So we agree to remove the cave feature, and have holes instead?
Or is there a better way than to have holes directly into the mesh?

[OvermindDL1]

Holes could easily be done by a single bit per image or via an invisible splat layer. I've only ever used custom meshes on holes or layered heightmaps, I don't really know of any other way of hand. Still though, I'd vote for just going pure voxels anyway as they can represent heightmaps too, you can always add special detection to render slightly more efficiently in the case of rendered chunks being heightmap-like, that still allows other rendered chunks to fall back to proper full voxels for caves or whatever anyway. In addition this would allow for special rendering as well like a game could have normal angled terrain, or could use square blocks, or hexes, or whatever visualizer they want for the voxel rendering (I always did multiple overlapping voxel layers specialized for different shapes).

[OvermindDL1]

Otherwise I'd just say support holes, they support whatever is needed regardless anyway.

[AnneKitsune]

Okay, I did some research on voxel engines and that approach looks promising. My only concern with it is that they actually look a bit blocky, even at high resolutions. This one for example: https://www.youtube.com/watch?v=4oGl3F8xf6M or this https://www.youtube.com/watch?v=lXm5JWys55o

Also, voxel worlds appear to be a lot more worse performance wise, from what I saw.

If there's a way to make voxel worlds look realistic and decently performant, then I'm okay with going for a voxel only approach.

I think that it would be possible to use voxels for only the terrain (read ground), use instanced objects made in an external tool (trees) and also have foliage (3d grass or 2d billboard with a picture of grass). For fluids, I found something about "fluid dynamics" which allows voxels to act as fluid. If this consumes too much power, or doesn't look good, there's always the possibility of using other solutions like mesh deformations for waves.

All this would allow the user to either:

• Go full voxel
• Use voxel for the terrain, then use 3d objects for buildings, trees etc
• Use only 3d objects (but then we don't have a 3d ground editor)

So, is this a viable option?

[Xaeroxe]

Voxel is great for some games but it is far from a catch-all solution. I'd be strongly against supporting voxel only, however I do eventually want a voxel option.

[AnneKitsune]

https://www.youtube.com/watch?v=XkSS_veoSg0

[AnneKitsune]

Would multiple variable length voxel do the trick for a heightmap equivalent?
You'd have the voxel chunk with a fixed xz size, but the y size would be dynamic depending on the minimum and maximum heights of the terrain inside that one chunk.
If at all possible, it would be nice to have reusable solution for both voxel blocky worlds as well as super smooth terrains with caves. Also, being able to break any part of the world with explosion is pretty neat too :P

[Xaeroxe]

Alright my position has definitely changed after seeing that tech demo. I still think voxel isn't the most efficient way to do that but it certainly can be good enough for now.

[OvermindDL1]

Voxel is blocky depending on the renderer. It can render as blocks, marching cubes, smooth splines, all sorts of things. And they are not worse in performance, they are actually quite efficient... And yes, things like trees and such are generally not voxels, just terrain and so forth (though some games do have trees be voxels too, but eh).

[AnneKitsune]

Thoughts? @omni-viral @torkleyy @Rhuagh

[MrMinimal]

Being used to Quad trees for planet rendering, I am really impressed by how far commercial voxel engines have come.

[AnneKitsune]

That's actually insane.

[erlend-sh]

my 2c:

Should terrains be made in an external tool?

Yes. A general purpose terrain system is far from an essential utility in a game engine's repertoire. It's great for quick prototypes (lowers the time-to-interesting-interaction) and demonstrating the graphics ability of the engine. Even so, most games will end up building their own tooling for controlling the entire play-space as a whole. The way you construct the game space tends to be such an integral aspect of the creative process that most game designers strongly prefer to roll their own tooling for "game space creation".

There's also a lot of different ways to go about making a terrain system, and whichever you choose will always be pulling the rest of the engine a little bit in that direction. I think the best approach to terrain systems is to leave it completely to plugin territory, keeping the rendering stack as unopinionated as possible.

[fhaynes]

Moving to RFC repo

[norman784]

Hey everyone, I kinda taked this RFC and started building a terrain engine called Gaiku, still in very early development stage and still doesn't have a lot of features, but it is somehow generating the meshes from 2 sources at the moment (PNG and Goxel files), so far I've some draft implementations for heightmap, marching cubes (kinda buggy) and voxel.

All solutions are not yet optimized and/or use an octree for reading the chunks and generate the meshes. This is the next step I want to address.

But because is in early stages of development want feedback about the architecture and sugestions.

So far the library (cannot call this a terrain engine yet) export the generated meshes to .obj files, you can check the examples indide gaiku-3d.

Regads

[erlend-sh]

Great stuff! Since this is technically an RFC discussion (I.e. figuring out what place, if any, terrain features have in the core engine) I suggest you re-post this to #development on the forum where you can post progress updates as often as you want. I have quite a few questions I wanna ask about your immediate plans :)

Considering that my suggestion to work on terrain tools separately from the core engine hasn’t gotten any pushback, and with Gaiku we now have a 3rd party project to drive this effort forward, I will be closing this issue as resolved unless there are any objections in the following week.