LayeredGridGraph bug with too many nodes being updated

1

Hi,

I ran into a problem with LayeredGridGraph.
I’m creating a build system and I’m in game adding items on top of each other.

  • I have a wall with 2 unwalkable nodes at the bottom and 2 walkable nodes on top
  • I add a wall on top with a GraphUpdateScene to manually set the 2 top nodes of the lower wall to unwalkable
  • This works, however the 2 nodes on the ground floor are reset to walkable, even though they are not included in my GUO bounds

Before: bottom 2 nodes are unwalkable

image
image476×513 89.8 KB

After:

  • top 2 nodes are unwalkable because of the GUS
  • bottom 2 nodes are walkable again :frowning:
  • you can see the bounds of the GUS that only includes the top 2 nodes
  • image
    image504×625 97.9 KB

My GUS settings:
image

My grid settings for ref:
image

Some debugging i done:

  • the bounds appear to work: 6 nodes get passed to them (ground, 1st floor + 2nd floor) but only the 1st floor nodes are in the bounds (which is correct)
  • the problem appears to be that the walkable values for the bottom nodes are not loaded correctly, they are true while they shouldn’t be, and even though I don’t modify these nodes, it looks like the wrong values get reapplied
  • if i put a break point in JobGraphUpdate and I then query grid (AstarPath.active) for the node based on the nodePosition, i get the correct “unwalkable” status
  • but if i look at the data.nodeWalkable[node], it’s set to true

I’m using version 5.1.6. I looked through release notes of more recent versions and didn’t immediately find anything related to this and upgrading atm is something I’d rather not do if it can be avoided.

Any workaround or input greatly appreciated.

2

Can you post the relevant code for when you scan the graph? Also you said the bounds for the GraphUpdateScene are properly encapsulating the four total nodes?

EDIT: Or in general how are you applying the GraphUpdateScene, since both apply on start and scan are disabled? I’m assuming that’ll be in the code I asked about

3

Yes I just call GraphUpdateScene.Apply() manually after the object on top is positioned. I also checked and only the single update gets applied and the transform position is correct as well.

4

Can you post the code for that Apply call?

5

There’s not much to post actually. In game you press a confirm action, which does a lot of things - mostly visual stuff - but one of them is sending a unity event in which i literally just call the Apply() method on the GraphUpdateScene. That’s the only graph related action taken.

6

Actually I’m lying, there is the separate GUS for the top nodes being applied as well. It also has bounds but it’s possible that those 2 updates run in a single batch:

  • they are 2 separate calls with 2 different bounds
  • Apply() is called for both in the same frame
  • The nodes they impact are above each other, but none of them should impact the ground nodes either way

I’m not at my project anymore but i’ll see tomorrow if i can split that out and see if they somehow influence each other. With earlier tests it appeared that they ran ok sequentially, but I haven’t checked if the node data goes “bad” somewhere in between.

Each GUS correctly encapsulates 2 nodes:

  • 1st floor (GUS is visible in the screenshot)
  • 2nd floor (GUS not selected, but it’s one higher)
    During the job execution: 6 nodes get processed, 2 nodes x 3 floors
7

I’ve been looking into the problem further and I figured out the cause.
The problem is indeed the the other GUS that creates 2 new nodes, and uses a GUS with “Physics” enabled.

This appears to rescan the x/z area and because of my grid height settings, it then did not detect collisions on the wall segments below.

So I managed to work around this but i’m a bit uncomfortable with it because I had to change global grid settings, and it’s hard to estimate the side effects. It’s also a bit a confusing situation and I was wondering if there is a way that I can avoid this?

I’m introducing a new object that creates new nodes. Is there a way to do so without a physics scan or can I limit the physics scan in some way? For example: do a physics scan for nodes, but then only persist the changes for the nodes that are inside the bounds area instead of all of them.

Main reason is that I have a lot of manual configuration changes of tags, penalties and connections, and I’d like to have good control about what’s being changed to avoid the grid to break.

8

Hi

I would strongly recommend using a declarative solution as much as possible.

For example, you can use the collider on the wall to make the nodes underneath the wall unwalkable.

And, you can add the “PerLayerModifications” rule to the grid graph to make the top of the wall unwalkable. See RulePerLayerModifications - A* Pathfinding Project

That way you can just issue a normal graph update (with update physics = true), and it will work robustly.

This is not possible, I’m afraid.

9

Thanks for the suggestion.

I also have obstacles put on the node edges that only impact how you can move between the 2 nodes.

Could I also use a (custom) graph rule to do physics checks to determine if I should strip connections?