XCoordinateInGrid and ZCoordinateInGrid performance

[ivan]

Hi!

I’m using DynamicGridObstacle script in my project and detected that it drops my game performance. So I decided to implement this module myself with custom code for detection regions that should be marked as unwalkable. First implementation showed me better performance but I would like to improve it more. With profiler I detected that most performance critical code is in properties XCoordinateInGrid and ZCoordinateInGrid in GridNodeBase (I’m using them heavily).
After looking in implementation of properties I have question.

Why you decided to calculate X and Z in runtime but not to cache in class members? Is it because of memory save or there is another reason?

Thanks!

[keypax]

Hi
I know this is not the answer for your question, but do you need “dynamic” grid obstacle? As far I remember DynamicGridObstacle is refreshing every X seconds (please correct me if I’m wrong)?
What do you want to achieve exactly?

In my project I have gates. Whenever I want to open them I set grid under the gate to “walkable”. If I want to close them I set this grid to “nonwalkable”. I can consider it as “dynamic”, because they changing pathfinding realtime.
Here, I have posted some code that I’m using to do that:

Possible to use with without colliders

Hi, have you seen this? https://arongranberg.com/astar/documentation/4_0_8_e597295/graph-updates.php Personally, in my game I try not to use colliders either. I have code like this: GraphUpdateObject graphUpdateObject = new GraphUpdateObject(bounds); graphUpdateObject.updatePhysics = true; graphUpdateObject.modifyWalkability = true; graphUpdateObject.setWalkability = false; AstarPath.active.UpdateGraphs(graphUpdateObject); and it works for me. The only problem is LayeredGridGr…

Maybe that will be enough

[ivan]

As far I remember DynamicGridObstacle is refreshing every X seconds

You are right. Except it also caches bounds from last check.

What do you want to achieve exactly?

I’m using (used) DynamicGridObstacle for blocking cells in grid, when units stopping moving.

[aron_granberg]

@ivan

Why you decided to calculate X and Z in runtime but not to cache in class members? Is it because of memory save or there is another reason?

Yes. Those fields are not really used for pathfinding at all, so storing 8 bytes more per node is quite significant.