Build a system to compose terrain transitions on the fly

[CelticMinstrel]

Currently, if you want a transition from grass or hills or mountains to a new terrain, it takes up 12 terrain slots per pair of terrains that require a transition. If we could split the existing transitions in half in such a way that one half can be overlaid upon a new base terrain, that would make it a lot easier add new transitions.

It would eliminate a lot of terrains from the base set in Blades of Exile Base – for example, only the encircled ones in the following image would remain as terrains. The graphics for the transitions would still be present, of course, but they'd take up a lot less space than they do now – there are duplicates of these transitions on other sheets for mountain-to-snow and other combinations. It would also make it easier to build three-way terrain transitions.

[NQNStudios]

@CelticMinstrel To clarify: Is the idea that the transition graphics would incorporate transparency (either with a solid color key or by being a png with proper alpha) and then these tiles could automatically be overlaid on the base terrain graphic of the adjacent tile?

[NQNStudios]

I'm not clear on how this would make 3-way transitions easier.

EDIT: Maybe I am. It just wrinkles my brain.

So if we had

01
22

0 and 1 would overlay with each other on the 2 tiles, and the 2 transition would draw on top of that?

How many permutations and edge cases are there of a 3-way transition? What about 4-way?

I notice that the scenario editor terrain window is dramatically buggier than the in-game one, which means they're not using entirely the same graphical code. So the two systems would also have to be made more unified to both use the new system.

[NQNStudios]

I think the first step in this system would be to loop through the map detecting edges and having them in a data structure like this:

struct terrain_edge_t {
    location tile;
    terrain_t this_tile;
    map<eDirection, terrain_t> differing_neighbors;
};

[NQNStudios]

The shoreline example shows that not all transitions are so simple that they could be done with a single set for overlays. Some manual artistry went into blending the grass to the water here.

[NQNStudios]

In GIMP, if you add a layer underneath those tiles like this:

You can set the top layer to "Difference Mode" and see that black pixels are duplicates from transition to base terrain.

It's not really cut-and-dry that we could separate out the transition graphics in a reusable way.

[NQNStudios]

We would have to define scenarios created before this change as Legacy (or Pre-Transition-Feature or something) and have them swap the trim terrains for the base terrains when loading.

[CelticMinstrel]

The idea was to use translucency to reduce the number of graphics, yes. I uploaded here my own attempts at separation. I think one or two of the XCF files here demonstrates it as well.

I know this would be quite difficult. That's probably part of why I haven't even gotten started. You'd essentially be defining that certain terrains extend into adjacent tiles, kinda like how the trim works for lava, pit, and dark lava, but a whole lot more complicated. It might even require #554 as well, if we want to be able to put a tree on the transition, for example.

We would have to define scenarios created before this change as Legacy (or Pre-Transition-Feature or something) and have them swap the trim terrains for the base terrains when loading.

Actually, this part probably doesn't need any extra work if we do #554. We just don't set any transition settings on terrains imported from legacy scenarios, and set their transitions to built up from the transition pieces that exist in the new graphics sheets. In essence, they'll just be using manually-placed transitions instead of automated transitions.

---

But speaking of #554, it could also be an alternative to this idea. The transitions would be composed from layers like the suggestion here, but not automatically – you'd have to set up each transition that you need.