Tilemap terrain in "match corners" mode can't draw a minimal path; should probably paint corners, not centers

[eevee]

Tested versions

Only tried 4.2.1.stable.arch_linux.

System information

Godot v4.2.1.stable unknown - Arch Linux #1 SMP PREEMPT_DYNAMIC Sun, 21 Jan 2024 22:14:10 +0000 - X11 - GLES3 (Compatibility) - NVIDIA GeForce GTX 1660 (nvidia; 545.29.06) - AMD Ryzen 5 1600 Six-Core Processor (12 Threads)

Issue description

This is my first exposure to the new tilemap in Godot 4. Love it. Being able to paint collision shapes? Chef kiss. Fantastic.

I tend to go for 47-tile "blob" tilesets (Godot 4 calls this "match corners and sides"), but for once I'm doing a top-down game, where transitions matter. So I thought maybe a corner-based tileset would be a better idea — that's only 14 tiles for every pair of terrains that could touch.

I included the oddball "island" tiles because my artist partner had already drawn them anyway, and went to go set some terrain bits in Godot.

Lo! This does not work well. If I draw four tiles in a counter-clockwise motion, the results look like this, in order:

Okay. Let's ditch the island tiles, then. (But then what's the point of the center terrain bit?) Now a single click produces this:

In fact it seems impossible to create a 2-wide strip of "match corners" terrain. This strikes me as counterintuitive, since the first thought that entered my head when I decided to make a corner-based tileset was "and we can still make a minimum-width area by just using two tiles".

And the behavior here is still weird, such as if I try to make the strip wider by painting above it:

The path mode doesn't fare any better (perhaps #68222 only applied to normal mode?):

---

I think the problem is that the tilemap is trying to paint one tile at a time. That makes perfect sense for "blob" tilesets, and I even specifically appreciate that Godot lets me set the terrain of the center of a tile — Tiled doesn't do this, so it's impossible to paint a single tile using its terrain tool.

But for a corner tileset, I want to paint corners. The whole idea is that the transition is running down the middle of the tile, so the middle of the tile isn't any one terrain. Instead I expect to click a grid intersection and have the four neighboring tiles change:

This behavior does make sense for, say, procedural generation, where a developer may want to simply draw a bunch of terrain and then have the edges all be magically fixed to look nice. (Though I don't know how you'd create a two-tile-wide strip with that approach.) But for live drawing, starting the update from a tile's center makes some obvious patterns impossible. And it doesn't work well anyway — I tried to make use of the center bit for those tiny one-tile islands, and it interfered with drawing anything larger.

---

Corner/edge painting is also useful in full "match corners and sides" mode — sometimes. For example, the obvious way to render a block of terrain is as a single contiguous blob:

But Tiled allows me to erase individual corners and edges, adding in some holes that make the result more visually interesting:

---

I see a number of issues still open on terrain, but hardly any of them are about corners mode, so here's one. :) cc @groud I suppose?

Steps to reproduce

Make a match-corners tileset and try to draw with it.

Minimal reproduction project (MRP)

match-corners.zip

[groud]

In fact it seems impossible to create a 2-wide strip of "match corners" terrain. This strikes me as counterintuitive, since the first thought that entered my head when I decided to make a corner-based tileset was "and we can still make a minimum-width area by just using two tiles".

Well, yes. The terrain systems relies on painting the center bit of tiles, then "connecting" them however it can to the surrounding tiles. If you need to paint a specific border between two tiles with the same center bit (here, painting sand between two tiles with water center bits), then you have to use the specific tiles on the right of the paint tools. There's no way around it.

Peek.05-02-2024.11-33.mp4

Solving it would require implementing the painting of "neighboring bits" on the map, which is not supported right now.