Realistic Terrain Generation

Realistic Terrain Generation

3M Downloads

Surface block bleeding

topisani opened this issue ยท 28 comments

commented

I havent looked at how decorations are bled between biomes, and i am not sure if this would be possible with the current biome setup. But surface blocks bleeding through into other biomes, would make way better biome transitions.
2016-03-09_11 58 14

commented

RTG 0.4.0 and below used to do this quite well in some biomes, but it also used to go very VERY wrong in other biomes as well, which is why we removed it in favour of decoration bleeding.

To be honest, the more I see the decoration bleeding in-game, the more I'm falling out of love with it. However, if we could somehow combine both surface and decoration bleeding, that might look pretty sweet?

commented

definately, and if we can customise which decorations bleed for each biome, that would maybe help too. All of that would be easier with a new biome system.

commented

The problem with surface bleeding is that sometimes it works and sometimes it doesn't. So, basically, between every PAIR of biomes, you need a flag saying whether it's OK. That would be over 10,000 flags right now, and expanding with every biome you add. Not fun! It would be OK if you could do it programmatically, but that would mean you'd need a program that understands the aesthetics, which is - tough - ...

To be technical, we didn't remove surface bleeding in favor of decoration bleeding; < 0.5 was doing both. The decoration bleeding range was actually cut back by 50% IIRC (maybe 75%).

I like the decoration bleeding a lot myself. What is it you don't like? Some of it could be fixed by doing placement checks (making decorations pickier about what kinds of blocks they're placed on).

Kdot is working on a biome placement system.

commented

That's a big Twinkie lot of biome pairs! :O

My main/only issue with the decoration bleeding is the 'sick leaves' effect, where the leaves of trees turn into an 'off' colour when placed in a different climate, most noticeable when palm trees generate outside of the beaches, but happens in other areas. Most of the time I like the decoration bleeding, so maybe we just need to figure out a way to solve the sick leaves effect?

Either way, it's not a priority at the moment so happy to keep things as they are until we finish the terrain/biome/river/lake project.

commented

to be clear, by surface bleeding i only mean a couple of blocks. 5-7 max. Just thought this would be something to consider for a potential big biome refactor

commented

If biome placement/layout is out of scope for RTG, maybe split it off as a library/add-on instead? Realistic Biome Generation?

commented

You get a problem related to sick leaves when a tree crosses a biome boundary and yes, that's a problem. I notice it most with almost anything in a desert. Hypothetically, although it might be a lot of work, you could have tree generators check the biome colors for the blocks they're going to spawn in and refuse to spawn if they're going to generate "off" colors. You might have to rely on temp-rainfall if the color vars are suppressed server-side.

commented

Another way to "fix" sick leaves would be a registry system for decorations. This would make it easier for one biome to not accept bleeding of a specific decoration, for example making sure bleeding palms wont generate in mesas. It all leads back to #561

commented

So I know this is very old but I came across it and had an idea. What if, and i'm speaking specifically for RTG1, you had a system where biomes that dont blend well with grass biomes could only be bordered by either an ocean or a river? That way you could have massive grass continents separated from desert continents, separated from ice/snow continents. With none of them ever touching. Maybe a config option? Maybe a step further and remove all the different grass colors and all the sudden you have a minecraft world seemingly with no biome transitions with regards to the surface blocks.

commented

That's probably out of scope for RTG, but... that would certainly make for a cool mod!

commented

Oh my bad, this comment didn't post for me yesterday.. but I guess it did lol. ignore the message I sent you :) and hmm.. I would attempt to build the mod myself, but it would be almost useless without RTG terrain so that's that i guess.

commented

If you really wanted to make the mod, you could always make it an RTG addon. That's what I'm doing with Appalachia, which is a biome-adding mod made especially for RTG (doesn't even load unless RTG is installed).

I could give you a few pointers for getting your development environment setup if you want - just PM me on the forums or Discord.

commented

ima try this, maybe it will look good maybe it will look like crap

commented

just a proof of concept, i was lucky to find a place where it actually worked. What do you think?
2016-03-28_00.19.09.png
2016-03-28_00.19.32.png

commented

This looks promissing.

commented

I've always been a fan of surface bleeding, and this indeed looks promising as a proof of concept, but... as Zeno mentioned above:

The problem with surface bleeding is that sometimes it works and sometimes it doesn't. So, basically, between every PAIR of biomes, you need a flag saying whether it's OK. That would be over 10,000 flags right now, and expanding with every biome you add. Not fun! It would be OK if you could do it programmatically, but that would mean you'd need a program that understands the aesthetics, which is - tough

What's the plan to avoid all of the transitions that don't work?

commented

For the transitions that don't work, is it an issue where Random Biome A just doesn't bleed well with Random Biome B, but does with C, D, E, F, doesn't with G, H, does with I, J, , and Random Biome B does/doesn't with a completely different set of biomes?

Or, is it an issue where Random Biome A just doesn't bleed well at all with ANY biomes?

If it's the latter case, perhaps we can add a boolean property to the biome class 'canBleed' that is set to FALSE for problem biomes, and bleeding will only occur between 2 biomes that are both set to TRUE?

commented

One could assign each biome a set of "transition groups". A biome could have multiple transition groups, and in order for two biomes to transition like this, they have to share at least one of the same groups.

The trouble with this might be that, while it's more general than a simple true/false, it still might not be general enough. In addition, adding new transition groups will require going back and adding them to relevant existing biomes.

More general could be: Allow all biomes to bleed by-default, and add a list of no-bleed pairs as problems arise. This would allow more fine-tuned control, but shifts the responsibility a bit more away from biomes themselves to declare properties in a self-contained manner, to explicit external intervention. It could also still get out of hand if you have one biome that looks absolutely horrible bleeding into basically any other biome.

EDIT: To add onto the above, a third option could be:

  • Each biome defines one "transitional terrain type"
  • An external mapper holds the key to which types are allowed to bleed into other types.

Also as a side note, I would like to mention that I think it would look a bit better if we used fractal noise rather than white-noise dithering for this kind of transition. It would still leave fragmented pieces of biomes in their neighboring biomes, but it wouldn't look as grainy.


Also yes I am working on a new biome system, which will (hopefully) automatically produce fractal-noise-like biome transitions.

commented

I actually don't like this effect, but I'm not going to die on this hill. If you want to test the aesthetics, you should look at mesa or ocean borders because those were generally the problematic ones.

Technically, the current boundary is a fractal, it's just relatively low dimension (barely above 1). I'd agree that a fractal border (with a higher dimension, say maybe 1.3 instead of the current one which is probably more like 1.1.) would be better than white noise.

For the nonmathematically inclined, a higher fractal dimension means a wigglier border.

commented

For the nonmathematically inclined, a higher fractal dimension means a wigglier border.

More of these translations please! ๐Ÿ˜›

commented

It would also be good to have this as a config option. Nothing complicated, just a simple enable/disable.

commented

Another thing, with snowy biome borders you don't neccessarily need to have any kind of bleeding transition with the surface blocks, you can just bleed over some sparse snow layers... If something looks ugly, you don't always need to fix it.. you just need to cover it up. ๐Ÿ˜ Out of sight, out of mind.

commented

Beach biomes should probably never bleed, as they are pretty much supposed to be hard on edges. Oceans and rivers the same. That might take out most of the issues. For the rest, maybe we could compare surface blocks that don't blend well instead of biomes?

I may be taking math at the highest level possible in the Danish version of highschool but fractals... Still voodoo to me. I'll read up on it :D

commented

you don't always need to fix it.. you just need to cover it up. Out of sight, out of mind.

Sounds like my philosophy for home DIY ๐Ÿ˜„

commented

id like to look into it with the new surface system and possibly terrain features in v2, but probably not in 1.7

commented

I wouldn't mind closing this, but happy to keep it open if it's still something we want to do for 1.7.10

commented

Yeah, seems like too big of a change for 1.7 at this point.
+1 to close this.

commented

Cool, sounds like a plan ๐Ÿ‘