Tilemap tile full rect collision shapes are considered independent, causing Raycast to hit individual tiles inside tilemap

[hsandt]

Context

I'm using a raycast to detect ground in front of the character.

The raycast starts quite above the character's head in order to also detect ground potentially higher.

The ground, walls and ceilings are made of a tilemap using the same physics layer. The platforms are made of a tilemap using a different physics layer.

When the character is near the ceiling, the raycast starts inside the ceiling.

Issue

My issue is that the raycast considers the tilemap collider as a succession of independent tile colliders (even though they cover full rect and are therefore contiguous, creating a giant continuous collider). As a result, if the raycast starts at least one 1 tile of distance inside the ceiling, it will detect the ceiling tile just below and will return this collision position instead of a lower ground position actually under the ceiling.

In the actual game screenshot below, note the red arrow raycast, how it starts 1.5 tile above the ceiling surface and how it hits the lowest tile of the ceiling on its way, causing the ice attack FX to appear inside the ceiling, just above the lowest tile.

Since Hit From Inside flag is disabled on my Raycast, I expect it not to detect the ceiling surface when raycasting from inside to outside ceiling, and even less a point right in the middle of the ceiling.

This happens only because the tile colliders are considered independent inside of creating a big chunk.

Proposal

While this makes sense and is certainly easier to implement, it would be nice to have an option to enable a "contiguous mode" where the tilemap connects all collisions shapes that touches together, similarly to Unity's Composite Collider.

This would avoid hitting every individual tiles on the way before actually exiting the tilemap and finding the colliders that really matter (and since multi-hit raycast is not implemented, see #9059 and #2616 we cannot even just get a list of multiple colliders and iterate over it to skip the first ones based on some criterion).

In addition, since in my case the ground is also made of a tilemap on the same physics layer as the ceiling, we cannot just ignore the ceiling physics layer.

Currently, my only workaround is to place the ground, or more precisely the tiles exactly at the ground surface, on a different physics layer than the rest.

If I was using big rectangle colliders instead of the tilemap integrated physics system, I wouldn't have this issue as the ceiling would be one big chunk.

MWE for raycast inside tilemap

v4.2.1 - Raycast hits inside tilemap.zip

Run the game and check the output:

raycast starts inside tilemap, we may detect tiles from inside
hit!
TileMap:<TileMap#26004686019>
(11, 61)

[smix8]

The TileMap debug visuals are commonly misleading. The actual objects that the TileMap creates on the servers are all single tiles. Each tile with its own polygon. So all those tile polygons run into seam and quality problems.

This is not just a problem for physics, seam problem cause low quality with navigation meshes and pathfinding and light leaks for occlusion among other issues. It is a systematic problem that the TileMap has because it does not bake its individual tiles to reasonable units that make sense for the engine and server features the TileMap wants to use.

That all the solutions always involve removing the tile-factor from a TileMap is already telling. A modern TileMap is build with polygons and not just bit masks with squared blocks like some 40 year old "tile-based" game. The common perception that TileMaps are good for performance only exists because of the association with those old games that had a very different technical backbone.

A modern polygon-based TileMap is by default a performance eating moloch and quality offender by design. All those tiles have an absurd high cost to be maintained when they are actual polygons. It requires considerable dev hours to turn all those individual tiles back into something more reasonable with every engine system having different requirements. So far not a lot of community effort has been made in that direction.

The problem with "composite collider" is that what they really are is a polygon merge operation behind the scene. A "CSGCombiner" for 2D. Basically again removing the tile-factor from a TileMap which adds additional cost and problems, especially for runtime changes. Think of the performance cost of navigation mesh baking but worse because collision has so many collision variations that all need to be supported. Not many TileMaps are just build with simple square blocks.

Many TileMap projects that I know actually already do this for their own project. They only use the TileMap as a editor build tool and data provider. They merge the tile polygons in scripts to one or more optimized polygons with e.g, the Geometry2D class that is used with e.g. a StaticBody2D node. Same reasoning why the recommended way for navigation is to bake with a NavigationRegion2D node and not use the TileMap build-in navigation.

I think everyone agrees that it would be better if the TileMap could provide this by default. It is discussed quite frequently among devs but simply boils down to a time and resource problem.

[hsandt]

Thanks for the detailed post, that sums up the issues and limitations well. I realised this could also explain other tilemap issues I posted earlier such as godotengine/godot#88067

In my previous Unity games (one full 2D and one 2.5D i.e. 2D colliders with 3D graphics), I was indeed working with polygons or even surface edges I was drawing over the existing terrain visuals (at the time I had ridiculous bugs in Unity like a downward raycast hitting the corner/side of a ground collider causing the normal not to be up and the character to start running diagonally upward and leave ground at every ground transition - or the raycast would fall right in the spot between the two colliders and the character would fall in some invisible gap between two colliders for a few frames). Not sure how the Unity tilemap is doing, I only tried it for top-view games. Anyway, Godot doesn't seem to have these quirky edge cases so it didn't seem like a problem to use adjacent colliders, but I didn't think of the orthogonal issue of having tiles stacked along the vertical direction.

On another project made in PICO-8, everything was custom since there is a visual tilemap editor, but no physics system. From a given point inside ground, I go up until I find a non-occupied tile or pixel, completely agnostic of tile separation, so it also just worked.

Back to Godot, the final solution of baking the final tilemap before playing would probably be the easiest for me, although it can get quite complex with tile collision shapes other than full rectangles. Ironically my current scene is now just made of big rectangles, and I could just redraw the collision shapes myself over the tiles, which would just be there for aesthetics.

I don't need to do this now that I'm using the GroundSurface layer workaround I mentioned, but it really works for this specific case...