Height Limit

[Immortius]

When we reach the terrain generation stage we are dealing with chunks that now are something like 16x16x16 or 32x32x32 or so. I figure there's some benefit to them being cubic, and 32^3 = 32,768 so an array of shorts would take 65,536 bytes, useful?

I don't think there's any particular magic number to the number of blocks held in a chunk. The considerations are the minimum required for sane light propagation (16 for any given dimension), and a memory saved vs mesh generation time - the larger the chunk the memory is saved through the use of congruent primitives in a simple array, at the cost of how long it takes to generate the chunk.

To save space on height we could make the value stored in the heightmap be a byte (256 values) but be multiplied by a static value to get the actual in-world average height of the surface in that chunk column. I'm not sure how useful that is, but using an exact height from 0-256 isn't enough. Maybe multiply by 16 or 32 to get the real height in the world?

Keep in mind that the only requirement is to be able obtain a general height value for a given block/chunk. It need not be overly accurate, nor necessarily stored if it can be derived from the same seed condition reasonably quickly. If you are doing erosion and tectonic plate simulations that is unlikely, but you can still have a relatively sparse heightmap and interpolate.

Around the average surface height we care about sunlight calculations in a set vertical band, like 256 blocks. Anything below that is considered devoid of sunlight (and that value could be used for something else) and anything above is always the max possible light value as per time of day (so again we can use the value for something else)

I don't agree regarding the handling of sunlight high up. It would mess up any sort of enclosed space, such as cave systems in large floating islands or even just houses. What we need is for shadows cast high up to decay at some distance from the shadow caster,

The difficulty comes in a few ways:

1. Player modifies the terrain drastically so the average height value changes - the world map storage for height values must be able to change after initial generation
2. Player outright does something obnoxious, like fill one side of a chunk column with blocks and clear the other side Where does the sunlight go, as simply averaging a chunk column could leave the average value hundreds below the top solid block?

I would just leave the world map heights alone. If the player drills a huge hole, they are drilling it into the darkness. Similar to the underground in Terraria, although sadly lacking the visual indicator (although we could add one).

For sunlight affected areas, what I would suggest is having 16x128x16 chunks (or even larger vertical), and setting up sunlight propagation so that it goes from total shadow back to full sunlight over a distance of ~128 blocks, given no further shadow casting blocks. That is, we have shadow attenuation rather than light attenuation. This ensures that you only ever need one chunk above (and one chunk below) in order to do lighting recalculations. Obviously large enclosed spaces would be lit wrong (like huge caverns in floating islands), but it should suit the majority of cases.

 

[Nym Traveel]

Keep in mind that the only requirement is to be able obtain a general height value for a given block/chunk. It need not be overly accurate, nor necessarily stored if it can be derived from the same seed condition reasonably quickly. If you are doing erosion and tectonic plate simulations that is unlikely, but you can still have a relatively sparse heightmap and interpolate.

Referring to my current plans a average heigth map would be actually saved. I'll post an update probably tomorrow - brainstorming at my whiteboard right now.

Regarding light propagation:
I had a sneak peek at the light propagation code and light propagation works at the moment as follows:
Each vertical column is went through and the lights reaching straight down are calculated. then the light trys to spread out of that 16 blocks horizontally. (kinda verified this in a quick ingame test bore)

Reading this and the part about the meshing I would also recommend some higher values for the height of the chunks like 128. We then can try to have 2-3 chunk layers loaded all the time. The range will probably change during tests.
So, what about just not to change a running system? Chunk light computation is still done top to bottom. We would just need to access once a column the above chunk. If not loaded or generated we just take the default skylight.

Anyway, I think we should look into lighting somewhen in the future to get some more realistic shadows and whatnot.

 

[Immortius]

My concern would be that it would be somewhat inconsistent, since the lighting you would get would largely depend on what chunks have been generated or loaded. An area of the world may be fully lit with sunlight... until you move upwards a little, triggered generation and loading of a chunk with a sky-island and a column of shadow would stretch down to the surface.

Having a lighting system that is resilient against new chunks and what chunks are loaded is desirable.

 

[Nym Traveel]

Thats right. Hmm, difficult situation.
I think the shadow fall off is kinda odd - imagine a cathedral or other large building without windows. Lets assume that the nave is 20 blocks high and the steeple is hollow and approx 50 blocks.
Well, even though there would be no natural light in this area the area under the steeple would be nearly half way lit up and spread a bit into the nave which will be fairly deep.
I think we are between a rock and a hard place here - I will sleep over that, too late to think seriously... (is the idiom also translated right with to take counsil with one's pillow?)

 

[Cervator]

Taking council with one's pillow kinda rings a bell to me, but not sure how accurately it translates

Yeah, max sunlight up top wouldn't count for caves in sky islands, but wasn't sure how to describe that better. Sounds fine with high chunks tied to max height for light (or shadow), although I'd be hesitant to permanently base the expected light bands on original seed values - if a player blasts an entire mountain into dust it would leave a huge dark spot? Although I recognize that there are benefits to it, and maybe some way of cheating by having it make sense in-game

My thought on the height map would be that it defines the "normal" surface of the world. Sky islands would be something special, like maybe that "Sky World" bit I mentioned (high enough up to worry less about casting shadows), or something minimal like artificial structures generated at the regional stage. In that case you wouldn't have to worry about what hasn't generated above you while you're running around on the surface (expecting no such thing as mega-overhangs)

An added weakness there is if the player manages to build a large artificial floating structure near to the surface. Then "Sky World" won't really help. How about partial chunk loading reading only summary values of chunks akin to the sparse loading of empty or near empty chunks discussed before? Wouldn't that also help the long-range rendering of chunks reduced to pixels / pixels clouds or whatever that was all about?

Is there a trade-off with tall chunks that benefit lighting vs short chunks you can keep fewer loaded of? Any feel for whether we're struggling more with memory or cpu? Although I figure keeping fewer chunks loaded also benefits cpu.

I am hardly an expert, but like spurring debate!

Edit: Something seems afoot with keeping "abbreviated" chunk data around. Is there good potential there for multiple systems? Also, something like a "Sky World" with floating islands could actually be produced by a separate generator with its own height map, in its own layer of the overall world. Might be a good thought example for how to mod terrain gen - think also different "Underworld" layers

 

[Immortius]

If we change chunks to keep track of their composition (i.e block type -> occurrence map) then that might provide metrics to help inform the determination of surface or other such things, in addition to switching between internal storage mechanisms.

 

[Cervator]

Got or want to come up with some more ideas/details on that, especially what you'd think an occurrence map would be? It sounds like we're at the right time for that to be of interest

Mainly I was thinking a variable to indicate how much of a chunk is solid, which could help identify empty chunks (0% solid) and maybe chunks with too little stuff in them to cast shadows or block long-distance sight. Although as usual there are problems with that in case a chunk has a single wall in it that should be visible, but the solid counter only sees 5% solid.

Could maybe add a variable for what is the most common block (category) for long-distance rendering (treating a chunk more like a single block), but then again you could wrap a stone chunk in pink wool and still have it count as majority stone and miss out on long-distance pink awesomeness.

Probably also some potential there for majority / entirely liquid chunks.

 

[Immortius]

The block type -> occurrence map would just be a count of how many times each block appears in the chunk.

 

[Cervator]

The block type -> occurrence map would just be a count of how many times each block appears in the chunk.

Think there's a benefit to that beyond a few basic notes on emptiness, maybe most common block, presence of liquids, etc? Or better to query said occurrence map for that sort of stuff?

 

[Immortius]

You can't determine what the most common block is without tracking the occurrence of all of them. Also I'm still tossing around the idea of liquids not being blocks at all.

Density by itself would be useful, sure.

Besides that I think it generally has utility for determining how best to store block information for a chunk. If a chunk is all or largely composed of a single block type (including air as a block type), then storage can be switched to something much more streamlined.

 

[Darkhog]

I think we should avoid arbitrary height limit by using 3D chunks, like Minetest and Blockscape does it.

 

[Cervator]

I think we should avoid arbitrary height limit by using 3D chunks, like Minetest and Blockscape does it.

Yeah I think this would be our goal to support - however, with some world types it might make sense, in particular for performance reasons if you need the engine to consider chunks above for stuff like lighting or other effects

 

[Immortius]

I think we should avoid arbitrary height limit by using 3D chunks, like Minetest and Blockscape does it.

I'm pretty sure that's what we've been discussing for the past 2 pages + other threads.

 

[Josh]

I'm pretty sure that's what we've been discussing for the past 2 pages + other threads.

I think he was just too lazy to read all of it.

 

[Immortius]

Well, obviously I agree with the idea - although we need to understand there are disadvantages and work with them. In many way limits are strengths - we pay a price for breaking them, so it is a matter of whether we feel the payoff is worth while and is desirable for game play.

 

[Josh]

Well, obviously I agree with the idea - although we need to understand there are disadvantages and work with them. In many way limits are strengths - we pay a price for breaking them, so it is a matter of whether we feel the payoff is worth while and is desirable for game play.

In my opinion I think it's worth it for my feature, but you guys may think different. Also how mountains go, it would look better having deep holes and giant mountains for you to climb, I think that would be fun to play around with.

 

[Cervator]

Bump! While tinkering with music today I ended up with an unexpected connection to this topic, specifically the idea of per-chunk summary data: context-sensitive music hooks

Been wondering how we could do that for a while, with the most obvious factors being time of day (implemented), nearby entities (if robot near play danger-will-robinson-danger.ogg), and biome. But the last one doesn't really help environmental "mood changes" for what the player can see - my usual examples being entering/exiting a cave or cresting a hill to observe for the first time a huge valley or canyon.

If we have easy summary data on surrounding chunks and especially chunks being processed that are outright visible to the player (enter that rendering reduction tweak for distant chunks) that could be a powerful provider of context to mood based on what the player is looking at (smoothed out a bit, of course, we don't want to give the player audio whiplash)

If you're in a cave most visible chunks will be solid, very few will be empty/mostly empty. Toward the exit out the empty/ish chunk count goes up, then whoosh it spikes as the player beholds the outside and the sun/moon again (another context factor) = play "Resurface"

Same could be used if you suddenly encounter a gigantic underground chasm (lots of empty/ish chunks), if you suddenly can see a large amount of ocean (lots of chunks mostly filled with water - although biome might be good there too), if there's a ton of lava in front of you, etc. It would also be somewhat fragile, but it seems like it would have good potential for a framework to create and see what can come from it. All from a feature we can use in general for rendering anyway.

It might also further push toward smaller cubic'er chunks since those will tend to be more homogeneous - 16^3, 32^3, etc.

Thoughts? Also makes me wonder a bit what we'll do with biomes as we go underground, especially with smaller cubic chunks, as it should probably start mattering less and less (cave/subterranean biomes? Or no biome at all? Tectonics could perhaps use biome for geological layer type ...)

 

[Esereja]

how about first one tall block like 500blocks and after it another similar or just small cubes.
as those are so high, that we don't need to worry about shadows and such.

and one thing for contex based music could be depth, other if you are surounded by (or in) water or lava.

 

[Cervator]

Super tall blocks can include a lot of waste - such as ground deep below you or empty air above

And yep, depth + liquids would be good too!

 

[Immortius]

If the chunk summary data includes metrics on the types and counts of blocks included, that should provide a fair amount of information for music, especially when multiple chunks are sampled.