godotengine / godotengine/godot
Tilemap terrain in "match corners" mode can't draw a minimal path; should probably paint corners, not centers
- Dominant language
- C++
- Stars
- 117k
- Forks
- 26.8k
- PR merge metrics
- PR metrics pending
Description
### 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](https://github.com/godotengine/godot/files/14155800/match-corners.zip)
Contributor guide
Research direction
Start by opening match-corners.zip and following the reproduction steps with a match-corners tileset, then inspect the terrain painting behavior involved in TileMap editing. Done should mean that minimal-width paths and corner-based painting produce the expected terrain transitions without breaking existing center-based painting.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp, godot
- Domain
- game-dev, tooling
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100