Where we are with World Generation

[Nym Traveel]

Current State:
The generator Laurimann wrote is functioning with Windows and Linux now. Also Esereja made some progress with noise functions. I implemented a basic heigthmap terraingeneration and some humidity, climatesimulation.

What are the goals we have to achieve:
- Currently with one pixel per chunk we end up with a map with 8 km edgesize, not really enough...

Maybe it's enough to just change the bilinear interpolation to a bicubic one, stretch it out to something like edgesize 128km (see this GDoc for initial calculations) and let the noise take care of the rest. I'm gonna look into this hopefully next week ​

- tied to the above: making the map wrap around the edges.

I think this sould be as easy as writing a modulo operation to the right positions on the Chunk provider. I wouldn't really care about player coordinates not getting reset - it's not very likely that a player cycles around our world some more times. And if we happen to have a fast travel system we can there reset the coords to the initial range.​

​

- integration of lauris hm generator into Terasology.

I think this can be declared low priority, we can read text files with the heigthmap data. Nevertheless it would be cool to have a nice ingame gui setting the parameters and watch the earth move ​

​

- vertical chunks
I would say this is one of the important tasks. To be honest, I didn't fully understand the LocalChunkProvider completely... With minor tweaks the generators should be able to handle vertical chunks already. As the world position of the blocks in the chunks is defining the evaluation of the noises this should already be functioning. Only problem is to determine where the actual surface is when working with 3d noise. There the rawdata from the heigthmap could be vital (+ maybe some 2d noises on top).

So the biggest obstacle to take is to tell the chunkprovider to load chunks underneath the player when he comes near them. Any ideas? ​

Going further:

- climate zones

And tied to this: choosing wich block we need. Totally awesome would be a central methode like getBlock(bool toplayer, float temperature, float humidity, float pressure, ....) which gets all the information the coordinate has and returns the fitting block. This would get rid of all the ifthenelse things all generators have atm and unify it.​

Probably awesome but imho not technically possible: procedrally generated blocks. For example I call the getBlock methode and it determines that this block is some sandy earth, maybe 40-60 sand, earth 40 percent humid. Then it mixes the texture out of the sand and earth texture. When mined we have some drop probabilities included. Unfortunately this would mash every sparsechunk architecture and need much more memory to save it once created.​

Taking it one step back it shouldn't be much of a problem (I hope, dunno exactly how) to kindo copy/extend the system minecraft has where the grass texture is changed with the biome type. So just make a visual distinction and not in its function.​

​

- also related to the above one: ore distribution

Nothing really to say here, we're not even starting out on this ​

But we have a whole freaking lot of ores already there - waiting to be distributed ​

​

- procedural city placement/looking for good spots

Like the above one, ecept Skaldarnar has some promising first results with the procedural architecture ​

​

​

ok, this were basically the ideas i'd like to have discussed with you. I'm eager to your responses.
see ya

 

[Brokenshakles]

Hey! Sorry I missed the world dev meeting, but I have been thinking about item generation and tech trees. So far I have been exploring several different ways of doing this, but I'm leaning towards a tiered tech approach at this point, here is a rough draft:

Apprentice Carpenter Shop (Produces)
Wooden Tool A (Can be upgraded to)
Wooden Tool A-b (This here is the tier 2 version)
Journeyman Carpenter Shop (Upgraded from above)
Wooden Tool A-c (The pattern should be apparent now)
Wooden Tool A-d (This would be tier 4)
Master Carpenter Shop (Again, upgraded from the above)
Wooden Tool A-e (This would be a "Masterwork" version of the tool, which marks the highest tier)

This is the internal pattern I see for differentiating different Quality items. Note that making each tier of item should consume a similar item of the previous tier.
5 Tiers should be enough quality differentiation between Items, I really don't see making things more complex than that.

After that there is working on what shops there should be, and how they interact

At this point I would recommend putting forth plans for a:
Lumberjacks Mill (feeds ->) Carpenters Shop
Smelters Shop, (feeds->) Blacksmith
Quarry-masters shop (feeds->)Masons Shop

This should cover basic Metal, Wood, and Stone crafting. These are pretty much universal in a society building game, and I think the best starting point is the most obvious one. As for powering a Smelters shop ala DF, I think that can wait until the basic tech tree is hashed out.

 

[Cervator]

On mineral distribution there's the potential from Laurimann to include more data on "plate age" from PlaTec which could in part help determine what's underground (depth of layers and likely content). Going further we could get more accurate about the layers, maybe keep several heightmaps matched to major geological layers, but we probably don't need that level of detail just yet

Paging Panserbjoern here for more fun with chunks and their vertical layering

 

[Laurimann]

On mineral distribution there's the potential from Laurimann to include more data on "plate age" from PlaTec which could in part help determine what's underground (depth of layers and likely content).

Indeed! Shouldn't be a big thing, just need to take a few weekends out for it. Currently i don't have capacity to lift a finger, but before it's too late i'm surely working on this!

And about this "several heightmaps matched to major geological layers" idea, i'd like to hear more: do you mean that we'd just generate N maps and stack them over each other and behold, layers emerge? Or something fancier, like running the simulation with N different initial setups but with one plate piercing through all layers? Or even something fancier, like strain-stress based deformation of solid objects? I ask, for i am confuzzled.

 

[Cervator]

Unsure on the details for multiple layers, I'm just picturing the outcome

It is probably too advanced and too much work for now (plate age alone will be good progress - looking forward to it!), but I figure it is possible (perhaps too much processing needed though) to run PlaTec with one layer of plates to start with, but then introduce a natural process that builds the distinct geological layers.

• A sedimentary layer forms on top of the primary plates where more organic material would be present (ocean plates, for instance)
• An igneouslayer focuses on areas where magma is more active (plates hitting each other or moving away letting mantle rise up). Optionally divided between the two major types like in DF:
  • Intrusive igneous rocks - mainly for mountains
  • Extrusive igneous rocks - molten hot MAG-MA
• A metamorphic layer that likely corresponds closely with plate age more than anything else (old plates have had more time to cook)

You're the expert there though, both scientifically and technically as to how PlaTec works. I figure for each single calculation step you might do a slight increment to a sedimentary value (based on plate location - ocean gets more, this layer goes on top), increment age to slowly let the primary plate become metamorphic rock (that's the existing heightmap we have), and where plates hit each other, pull away from each other, or major volcanoes erupt one or the other igneous value gets incremented / forms a layer.

Ideally the new layers created this way (sedimentary on top, igneous in between, metamorphic at the bottom) would then additionally be able to intersect, go over or below each other, and in a later process even be affected by erosion/climate/organic simulation. The "sedimentary heightmap" produced by PlaTec could then for instance be further deepened by later relevant generators (or maybe instead a soil layer is added on top in the right places in a reasonable depth).

So all that is probably simultaneously simplified and ridiculously overcomplicated considering that the end product would just be differing thickness of the layers, maybe a bias toward certain minerals in the right places, plus perhaps sharp contrasts in weird spots where the plates shoved a spear of old metamorphic rock straight through a thick sedimentary junglescape for some reason

 

[Laurimann]

I figure for each single calculation step you might do a slight increment to a sedimentary value (based on plate location - ocean gets more, this layer goes on top), increment age to slowly let the primary plate become metamorphic rock (that's the existing heightmap we have), and where plates hit each other, pull away from each other, or major volcanoes erupt one or the other igneous value gets incremented / forms a layer.

Well figured!

So at the moment the sediment on oceanic plates is inversely relative to the amount of water at that point. This means that very old and very young locations have most sediment. A better way to do it would be to give locations some kind of counter - the longer it's untouched, the more sediment it has. But if we're going for these layers, then counters are unnecessary and best way to do it could be to add sediment to locations next to dry land and then just "blur it outwards". Simple and gets the job done!

Now, the simulation lacks all kinds of volcanoes ATM - and meteors that would wipe off layers near the area of impact. Adding hot spots was in the scope of the thesis, but i ran out of time. I could do that right after adding "getAgeMap()" to the API.

Additionally, the plates do not bend in any way. When two (continental) plates collide, they're just stacked on top of each other in cold blood - so, no spears sticking from anywhere, sorry. One question abour this stacking is that should the layers be randomly merged or merged in the order they existed before collision? The former introduces potential merges of layers that are of the same type and would result in less fragmented crust overall.

Finally, i haven't thought at all how shifting away from 2D array to 3D array will affect the simulation overall. Memory increase is evident, probably something like 8x. To save memory is to sacrifice performance and simplicity... And it's been almost year since i made the simulation and i was in a hurry then so adding anything complicated will be... Very complicated. :s Probably not worth it.

Edit: JNI API now supports getting the age map of the lithosphere.

 

[Cervator]

Very complicated. :s Probably not worth it.

Yeah and that's fine

I realize it is better to use approximating methods of some sort, you world gen wizards have some neat tools for that. Wanted to do the write-up anyway just in case you do end up making PlaTec fancier and dig around in a related area anyway. Like the hot spots. Or even meteors

What you say about non-bending plates and 3D also make sense. I wasn't sure how to do it or even approximate it the fancy way, but it obviously would be a lot of work. Maybe spots where layers are visibly messed up / out of order can be a locally generated feature instead, probably easier

 

[Laurimann]

Update: Plate age map works now, at least to some extent. It's not perfectly exact, because the ages of plates are reseted every time the surface is segmented into new set of plates. I'll fix this as my next thing!

About the age map: darker is older crust, white is freshly solifield lava. Due to poor choice of colors the actual age details of the terrain is invisible. However, if you wish to continue testing yourself, the JNI API is at your disposal.

Edit: Fixed. Now the age map is precisely what the plate techtonical simulation produces. There's interesting features, like the age of crust extends from deep inland far into the sea with very little change, or the fact that edges of mountain ranges seem to be younger than their surroundings.