Pathfinding obstacles collision size

I’m getting confused with pathfinding obstacles. I have a similar set of wall/corridor/doorway obstacles in a few different places and the player can get through some of them and not others. And also alignment is important to me, I want the player to be at a similar y position in relation to the obstacles as it emerges from each doorway, but it’s not. I read that an obstacle and any grid it touches is a no go zone for the player.

This is from July 2021:

from here:

Which I think means that the obstacle area may be bigger than the object, it can extend as far as the grid that it’s in?

So I’m trying to understand what to do. I made a simple example and displayed a 20x20 grid same as the default pathfinding grid size. With any key press the blue block should go to the green block. The first picture shows that the black obstacle blocks are not touching the grid the blue square is in. And the blue block was ‘stuck’, it wouldn’t move.

So then I moved the left black block to the left with the arrow key one by one, testing, until the blue block would move. The second pic shows this layout when the blue block would move. But the black block is still ‘touching’ the grid that’s near the blue block.

I haven’t made any changes to the player pathfinding collision border size, it’s on zero.

So I don’t know how to interpret what the rules are. What do I do to make the gap between obstacles as small as possible with it acting in a consistent way across different sets of similar obstacles? Or, is the scene editor grid not in the same alignment as the pathfinding virtual grid and my assumptions about things not overlapping the grid are wrong? If so, how can I judge where to put things?

PS. I know that the pathfinding obstacle boundary is based on the object size and not its collision mask.

I always took it as being the virtual cell size of the pathfinding object, not the obstacle. And I always imagined it creating a path of cells for start to end.

This made it easier to see why small cell size makes it more likely for a path to be found - more wiggle room for the cells.

But that’s my take on it, I may well be wrong with my interpretation.

When you seek the path, is it form the blue block’s origin, or centre? I’ve found this makes quite a difference to how well it finds a path. To me it feels like the virtual cell centre is on the starting point. And if that’s at the origin on the top left of the blue block, then it would explain why you need to shift those walls so far before the blue block would fins a path.

I don’t know. But I had already made the origin of the blue block at the centre. But the black boxes had 0,0 origins.

Now I’ve reduced the pathfinding virtual cell to 10 x 10. And just for fun I made the black block origins in the centre too. In this picture, the blue block will move even though the left block is right up against it. But if I move the right block any closer to the blue block, the blue block won’t move. And for what it’s worth (probably nothing) I’ve changed the display grid to 10x10.

And if I leave the right block in the too close position and make the blue block’s border size set to -1 (negative 1), the blue block does move. But I really just wish I could see what was going on so that I could place my obstacle blocks in the right place in my actual game so that there is (almost) no wiggle room for the pathfnding player object.

Yes, because when one of my ‘doorways’ is apparently too narrow, and the objective is to travel a fairly long way to get to it, the pathfinding object doesn’t even try, it just sits there and doesn’t bother going to check it out, haha.

Firstly, I seem to have the wrong picture in my last post.

Here’s the latest tests
20x20 blue block, zero collision border, 10x10 virtual grid
Blue block moves and travels right up against the obstacle edges
Increase virtual grid size to 11,11, no movement

Virtual grid back to 10x10 and shift everything over a little bit, it doesn’t move. So now, things being in the same grid square are a factor. But it all seems like a lot of guess work with the grid size.