GSoC idea rough sketch: Distinct Terrain Features (Seeking Feedback)

kinshuk

kinshuk

New Member
Contributor
(EDIT:
First draft: Drive Link
Second Draft: Drive Link
Final uploaded version: Drive Link)

This is a rough sketch of what’s running in my mind about the terrain generation topic. Nothing is set in stone at this point, just me trying to articulate my thoughts, looking for feedback. This needs more elaborating, but this is the high level model I have in mind.

Current state of things:
From what I have gathered, currently terrain generation is done on a local per-block basis: a noise generator decides heightmap data for every (x, y) coordinate, and based on some threshold, block placement is decided. There is some complexity related to different noise generators for different biomes, but that in itself is decided on the basis of a Perlin noise generator, which decides temperature and humidity, which in turn decides the biome a particular block is in. All this makes the terrain look a bit wrong.

What I think would be better:
Terrain generation to be done in multiple passes. (As pointed out here: https://github.com/MovingBlocks/Terasology/issues/943)

First Pass:
A first high level pass which decides biome “nodes”: points representing a large span of area, like say a mountain range, or swamp area, or ocean. As new parts of the world are explored, the frontier of nodes expands, with biomes being designated according to a function(what kind?) of neighbouring biome nodes that are already generated.
(An implicit property would be that the world would be different for different order of exploration)

At this point we have a large scale view of the world:

All the different biomes have some parameters which are decided at “node” generation time:
General parameters like effective radius of biome, humidity; and specific parameters: Mountains might have max-height, flatness/pointy-ness, number of parallel ranges (read: strands of mountains)

(How to decide the location and shape of the boundary of biomes?)

Second pass: Based on the biome parameters we generated, generate a terrain heightmap (still not block-scale but maybe chunk-scale, or larger).

At this stage, we add secondary features like caves, overhangs, rivers, lakes.
(terrain deformation is the term that best describes this)
How to add caves and rivers? How do we make sure this propagates to the next phase?

Third pass: At this stage, the actual placement of blocks is done. We do some interpolation for intermediate positions between points we have heightmap values.
Surface features like flora placement can be done at this point.(need to elaborate on this)

I have collected some relevant forum threads, and also links from outside the forum while researching this (haven't digested the content of each properly):
Forum Threads:
Issues:
Other places:

  1. Is this what the admins had in mind when writing that idea? What modifications should I make?
  2. Is there more groundwork required before this can be done as proposed?
 
Last edited:
Adrijaned

Adrijaned

Administrator
Contributor
You don't want your world to be completely random, you want it to be deterministically random based on the world seed, at all times. Even if slight sacrifices in the world looks must be made (we are making a game, not a simulator after all. And players don't seek complete perfection).
How could it work (e.g. the simplest solution I threw together while I was knitting a bit):
  1. Separate the world into chunks of constant size, optionaly leaving some space in between them (red chunks and blue space in between, ignore white- not important for us)
  2. Assign indices to the red chunks (and blue too)
  3. Based on world seed and the index of the red chunk, pick one random point in the chunk
  4. Draw a line to the picked points in neighbouring red chunks
2529

Now you have deterministically polygonized the world (and you can do this on the go), and each polygon contains exactly one blue chunk - remember them still? These chunks have their own indices too - and you still know the world seed - so use that seed and the indices to generate info about that polygon/chunk. Now you have separated the world into biomes. But how do you ensure the biomes don't collide with each other? Use a noise function for generating from blue chunks - or several, rather. Use a correct noise function to generate a temperature of blue chunk, and you have basically guaranteed that it will be roughly the same as the temperature of all neighboring chunks. The same goes for humidity, magical potential, ..., ..., ...
 
Cervator

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
That all sounds pretty close and spot-on, yes. Deterministic worldgen is very important and there are a bunch of cool ways to warp polygons and so on, great articles available online.

The main important open question I have is: do our current facets support enough abstract / high level worldgen before you enter the rasterization phase to turn chunks into blocks? You can easily come up with a layer of noise that assigns biomes at a higher level for the world, and we've got facets to handle ... objects? Like trees and such. But we have a hard limit on larger objects that span chunks such as huge trees - you can get around that to a degree with Borders (that's how multi-chunk trees work right now) but those can be awkward. Is a chasm a world feature made of noise or a multi-chunk facet? A river?

The biome node image I like because it is relatively abstract. You can readily imagine building a whole world map out of polygons like that, which again has been done lots of times with good articles available online, with each node describing that region (coastal, jungle, in-land lake, a river runs through it, etc). Yet you can vary exactly how you then turn all that into actual terrain, unlike with noise which is more explicit.

PolyWorld the module even uses polygons within our present worldgen system to do its thing. I don't remember the details though. It may be wise to look at that module (and maybe CommonWorld) to see if these kinds of things we're thinking about have already been done in there to a point. The WorldViewer utility even visualizes these things into a 2D world map. Readme says it visualizes facets - so maybe they are good enough to also be used in an abstract enough fashion to show a biome node map like that? Admittedly the WorldViewer seems to show concrete world (chunks or even would-be-blocks) rather than abstract.

One possible step away from deterministic worldgen I'd like to consider: We have layers of noise that can result in all kinds of incredible terrain, biome assignments, and so on. What if you would want biomes to change over time, as a reaction to weather pattern or major player intervention? Would it be fair to add in support for some sort of non-deterministic layers that overlay on the deterministic layers? "In this cell external factors have raised temperatures by 5 degrees and humidity by 10%" -> plant growth, erosion patterns, etc reacts accordingly

That's one thing I'm skeptical about us having good support for currently. If a player on one side of a mountain chain builds a giant CO2-spewing monstrosity capable of greenhouse-effecting the entire world and raising the temperature by a dozen degrees or two that can currently only affect already-generated world. New chunks would generate solely based on original noise and thus come out pristine. You could have workaround systems that on generation would then apply some logic over simulated timesteps to weather new terrain, but that seems like a kludge. What I'd like to see is a new "pollution" layer that raises temperature even in ungenerated parts of the world, so when world generation does run there it can access any non-deterministic layers and add in their effects during generation itself.

That may still not be perfect. If the other side of the mountain was tundra before then it should perhaps not generate looking like it has been jungle for centuries just because a player spent a week filling the atmosphere with CO2. This example is somewhat contrived and real code might be more complex, but I hope it gets the idea across :)
 
kinshuk

kinshuk

New Member
Contributor
I made a draft of my proposal. Comments and feedback appreciated!
(Weekly timeline not added yet)
docs.google.com

(1st draft)GSoC Proposal: Distinct Terrain Features

GSoC Proposal:Distinct Terrain Features By Kinshuk Kashyap Introduction Terasology has many gameplay modules that rely on procedurally generated open terrain (JoshariasSurvival, for example). The current world generation methods are mostly of the following pattern: a noise function generates the...
docs.google.com docs.google.com

Also, I'm not yet sure how to go about implementing time-dependent and player-action-dependent terrain as @Cervator suggested, so for now it's not in the proposal. I'm still thinking about it though, and might do it if time permits!
 
Last edited:
Cervator

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
Bump :) I looked at that proposal a little while ago - @kinshuk are you still out there?
 
kinshuk

kinshuk

New Member
Contributor
It's kinda late, but here's a second draft:
docs.google.com

GSoC Proposal 2nd draft formatted

GSoC 2019 ProposalGeneration of Distinct Terrain Features Kinshuk Kashyap Email: kinshukkashyap.me@gmail.com Github: https://github.com/kinshukk Forum: https://forum.terasology.org/members/kinshuk.3110/ Discord: kinshuk Table of Contents Introduction 2 Basic Delivarables 2 Main Go...
docs.google.com docs.google.com
 
Adrijaned

Adrijaned

Administrator
Contributor
Seems fine to my untrained eye
 
Skaldarnar

Skaldarnar

Development Lead
Contributor
Art
World
SpecOps
Hi @kinshuk - thanks for the proposal update!

Overall, I think the focus should not be that much on implementing new facade generators for biomes types, but actually working on support for biomes, biome transitions, and featuers to be used inside biomes, such as trees. You have most of that in the proposal, probably just need to shift priorieties a bit around :)
 
You must log in or register to reply here.
Top