LayerGridGraph null node/change walkability problem

I use a LayerGridGraph and have been looking into some issues I have.
I end up having “null” nodes being sent to TraversalProvider and when I check, i can see that the LayerGridGraph has a lot of null references in its nodes (there in the second part of the nodes array, so I more or less assume it’s the 1st floor nodes that are null?).

Is this expected behaviour?

I noticed that when I change walkability of nodes during runtime or with a gridgraphrule, things break.
As a test I added a custom rule that sets all scanned nodes to walkable in Phase.BeforeConnections, after which the normal path finding no longer works and claims the agent can’t move past the tile it’s already on and I get null nodes sent to seeker (which is check for).

If I drop the gridgraphrule, it works, but only until I change the walkability of a node (eg. using GraphUpdateScene). I ran into the issue because I need to modify the walkability at runtime.

Any help with this is greatly appreciated.

The layered grid graph can, as you say, contain null nodes. The internal data structure is a 3D grid, but there may be some regions of the world that has, say 2 floors/layers, and some that have 1 layer. This means that the data arrays will contain a lot of invalid nodes. Making those nodes walkable will cause trouble.

I’d recommend using the INodeModifier interface, which ensures that you don’t try to modify invalid nodes. There’s an example script here: Writing Custom Grid Graph Rules - A* Pathfinding Project

If you don’t want to do that, check for if (math.any(nodeNormals[i])) { before making changes to a node. Only modify it if the check is true.

That’s strange, though. Using a GraphUpdateScene component should definitely not cause nulls to be sent to the traversal provider. Can you reliably replicate this, or is it somewhat finicky?

I can reliably replicate it in the scene I’m working in, unfortunately there’s a lot of stuff in there so I’d have to try a completely separate project setup to reproduce.

I have a grid of 70x70 and nodes on 2 levels, and the total nr of nodes in the data array is 9800, which I assume is correct.

Based on your input and testing, I would guess that somehow some of those nodes get set to walkable with the GUO when they shouldn’t. I have an update shape which encompasses 3 tiles, but I get 6 node updates in JobGraphUpdate. Is there an easy way for me too see if they’re from a different level or if they are null?

Any debugging tips might come in handy. I’ll continue my search in a couple of hours.

Just make sure that you are only updating the graph using a GraphUpdatObject/GraphUpdateScene. Don’t do any manual changes to the graph, or use custom grid rules. Just to rule things out.

Okay, I did some more testing and as far as I can tell, empty grid nodes DO get passed to the JobGraphUpdate method.

The normals don’t get passed to JobGraphUpdate, but it looks like they get set in GridGraphUpdatePromise.Prepare() so I used the method you described to check and some normals are not set.

When I filter those nodes out for passing to the job update, everything seems to work and keep working as expected (and I get only the correct 3 nodes that are modified that visually are within the update shape).

In scene I have an update shape which is about 0.5m above the floor and approx 1 tile wide. But there is indeed no floor above it (so no second level tiles). So it looks to me a bit that the system assumes that the two levels are folded together at 0, and that’s why the 2nd level nodes get selected as if they are also inside the world space update shape?

Note: I’m not familiar with the jobs system, so my changes end up in error messages about mem leaks caused by accessing an array and not cleaning up, so it’s not a solution, but it appears to pinpoint the issue. I don’t know enough to see what the best/most performant way to fix this and if we can expect these null nodes to be passed or if they should be excluded from the shape to begin with.

Thanks!

It was indeed a bug. I have implemented a fix which will be included in the next update.