Pathfinding issue on portal crossover

[dmwever]

The following pathfinding is a failure, right on the portal line. The algorithm seems to prefer wrapping around black spaces when heading southwest across portal lines.

Here is a last comparison between a movement on the east side of the portal connection (ideal) and secondly the west side (longer).

[jere8184]

I'll take a look.

[jere8184]

@heinezen is there a reason we set the current cost of the start portals to zero instead of making it relative to the start position?

[heinezen]

The following pathfinding is a failure, right on the portal line. The algorithm seems to prefer wrapping around black spaces when heading southwest across portal lines.

For the first two results you got: This is because the A* portal search currently terminates immediately after finding a portal in the exit sector. I think the top portal is discovered first because it is closer to the target (orange). Therefore, the pathfinder terminates the portal search there immediately, instead of checking the other options. We could fix this by not terminating immediately and instead do a few more iterations to be sure that it's really the best result.

Here is a last comparison between a movement on the east side of the portal connection (ideal) and secondly the west side (longer).

The problem here is the calculation the heuristic cost for the portal nodes. The pathfinder uses the center position of the portal for its heuristic cost calculation. The ideal path in the second picture would use the portal on the right of the start node (green), but its center position is further down which makes it seem like the path is further from the target location than the portal going upwards.

[heinezen]

@heinezen is there a reason we set the current cost of the start portals to zero instead of making it relative to the start position?

It was previously done because that info was expensive to calculate, but we can actually get the info from start_integration_field in the get_path() function now if we want.

[heinezen]

Or using the heuristic cost as you did in your PR ^^

[jere8184]

Or using the heuristic cost as you did in your PR ^^

So my PR solves the first three results, but not the last one.

[jere8184]

Or using the heuristic cost as you did in your PR ^^

Would using start_integration_field be the better approach?

[heinezen]

@jere8184 Using the start integration field would only be marginably better I think. It's more accurate but also more complicated to check.

[heinezen]

So my PR solves the first three results, but not the last one.

The last one cannot be solved without changing the weighting of the distance cost. Currently, the distance is from portal center to portal center and this is not always accurate.