Intersect_ray only triggering at (0, 0, 0)

Godot Version

v4.2.1.stable.official [b09f793f5]

Question

Hi There,

I’ll try to describe my problem first without posting too much code.

I’m quit the noob when it comes to Godot, but I do have some experience with Unity. At the moment I’m trying to port some code from Unity that creates a hexagon map. This went well until now.

I’ve managed to create a ‘tile’ scene and am adding instances of it to a ‘map’ scene using gdscript at runtime. The map code determines the position and texture of each tile and adds them without any problem.

When I run the scene the tiles appear. I’ve set the debug option ‘Visible Collision Shapes’ to true so I can visually confirm that the collision shape I created from the mesh is added correctly. The result looks something like this.

My tile scene looks like this

image

I’ve connected the ‘enter’ and ‘leave’ signals to the ‘base_tile’ script so the ‘TileSelectionIndicator’ (the red hexagon) is made visible when the mouse enters a tile and is hidden when it leaves it. This all works as expected and this, together with the visual confirmation of the collisions shapes at runtime, proves to me that the CollisionShape3D is at the right position to detect collisions for the tile mesh it is covering.

Now for the problem…

I want each tile to know its neighbouring tiles. In Unity I did this by casting rays through them and so I thought I’d try the same in Godot. Determining the coordinates of the neigbouring tiles is not that difficult. The screenshot below shows the tile at hand and the coordinates of the surrounding tiles visualized by simple cylinders.

These are the exact coords I’m using when creating the casting the ray using the following code:

Now for the weird part: This code only returns a collision object when the ray is cast at the origin (0, 0, 0). In all other cases the result is an empty dictionary and I really do not understand why this is.

The logging below shows this in more detail:

  • The line labeled ‘HC/GC/C’ shows the hex-coordinates, the global world coordinates and the calculated coordinates based on the hex-coordinates for the tile at hand.
  • The lines labeled ‘AC’ show the world coordinates of the adjacent tiles.
  • The lines labeled ‘RC’ show the ‘from’ and ‘to’ for the ray.
  • The lines labeled ‘Result’ show the result of the cast.

This shows that the cast is only succesful when it is executed at the origin.

I’m hoping this is just a noob error and some of you can point me in the right direction because I’ve been stuck on this for quite some time now.

Regards,
The Great Woldo (who doesn’t feel so great right now ;))

What kind of collision shape are you using? Since the ray is fired from the bottom up. It could be missing because a quad collision shape is only hittable in the front unless enabled to hit back face in the quarry.

Although this wouldn’t explain why the first one works…

This is the inspector for the CollisionShape3d that I’m using

I’ve turned on the ‘BackFace Collission’ flag myself, but that does not seem to make any difference at all.

I solved the problem using a different approach. While creating the tiles I now store them in a dictionary with their hex-coordinates as the key (determining the adjacent hex-coordinates of a tile is no more difficult than determining the adjacent world coordinates). Now I can query the dictonary using the adjacent hex-coordinates to find the corresponding tiles. This approach is performant, even for larger map sizes :slight_smile:.

The mystery remains however, and I imagine I will run into the same problem later on in development. So feedback is still really welcome.

Regards,
The Great Woldo

1 Like

I would say a concave polygon isn’t an ideal collision object. But I think you alternative approach does sound better.

:blush: Good luck!