New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Terrains (as in Ground Mesh) #16

Open
jojolepro opened this Issue Apr 18, 2018 · 31 comments

Comments

Projects
None yet
8 participants
@jojolepro
Copy link
Member

jojolepro commented Apr 18, 2018

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

This comment has been minimized.

Copy link

OvermindDL1 commented Apr 18, 2018

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

This comment has been minimized.

Copy link

Xaeroxe commented Apr 18, 2018

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

This comment has been minimized.

Copy link
Member

torkleyy commented Apr 18, 2018

@Xaeroxe

This comment has been minimized.

Copy link

Xaeroxe commented Apr 18, 2018

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?

@jojolepro

This comment has been minimized.

Copy link
Member Author

jojolepro commented Apr 18, 2018

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

@torkleyy

This comment has been minimized.

Copy link
Member

torkleyy commented Apr 18, 2018

@Xaeroxe

This comment has been minimized.

Copy link

Xaeroxe commented Apr 18, 2018

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

@jojolepro

This comment has been minimized.

Copy link
Member Author

jojolepro commented Apr 18, 2018

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.

@jojolepro jojolepro changed the title [RFC] Terrains [RFC] Terrains (as in Ground Mesh) Apr 18, 2018

@OvermindDL1

This comment has been minimized.

Copy link

OvermindDL1 commented Apr 18, 2018

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

This comment has been minimized.

Copy link

OvermindDL1 commented Apr 18, 2018

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.

@jojolepro

This comment has been minimized.

Copy link
Member Author

jojolepro commented Apr 18, 2018

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

@OvermindDL1

This comment has been minimized.

Copy link

OvermindDL1 commented Apr 18, 2018

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?

@jojolepro

This comment has been minimized.

Copy link
Member Author

jojolepro commented Apr 18, 2018

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

This comment has been minimized.

Copy link

OvermindDL1 commented Apr 18, 2018

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

This comment has been minimized.

Copy link
Member

torkleyy commented Apr 18, 2018

I agree with @OvermindDL1.

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

@jojolepro

This comment has been minimized.

Copy link
Member Author

jojolepro commented Apr 18, 2018

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

This comment has been minimized.

Copy link

OvermindDL1 commented Apr 18, 2018

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

This comment has been minimized.

Copy link

OvermindDL1 commented Apr 18, 2018

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

@jojolepro

This comment has been minimized.

Copy link
Member Author

jojolepro commented Apr 18, 2018

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

This comment has been minimized.

Copy link

Xaeroxe commented Apr 18, 2018

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.

@jojolepro

This comment has been minimized.

Copy link
Member Author

jojolepro commented Apr 18, 2018

@jojolepro

This comment has been minimized.

Copy link
Member Author

jojolepro commented Apr 18, 2018

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

This comment has been minimized.

Copy link

Xaeroxe commented Apr 18, 2018

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

This comment has been minimized.

Copy link

OvermindDL1 commented Apr 18, 2018

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

@jojolepro

This comment has been minimized.

Copy link
Member Author

jojolepro commented Apr 19, 2018

@MrMinimal

This comment has been minimized.

Copy link

MrMinimal commented May 5, 2018

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

@jojolepro

This comment has been minimized.

Copy link
Member Author

jojolepro commented May 5, 2018

That's actually insane.

@erlend-sh

This comment has been minimized.

Copy link

erlend-sh commented May 15, 2018

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 fhaynes changed the title [RFC] Terrains (as in Ground Mesh) Terrains (as in Ground Mesh) Dec 24, 2018

@fhaynes

This comment has been minimized.

Copy link
Member

fhaynes commented Jan 8, 2019

Moving to RFC repo

@fhaynes fhaynes transferred this issue from amethyst/amethyst Jan 8, 2019

@norman784

This comment has been minimized.

Copy link

norman784 commented Jan 12, 2019

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

This comment has been minimized.

Copy link

erlend-sh commented Jan 13, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment