Hi,
I want to eliminate this lookup as it seems unnecessary for my use-case. In other posts you’ve said to add RecastMeshObj to my objects with dynamic set to false. I have done this and also have all of the search settings turned off so I’m not sure what is triggering this lookup.
The profiling output:
I’d much rather provide this known list of objects to AStarProject rather than it do a search every update.
Thanks,
Hi
That profiel scope both searches for all RecastMeshObj components (traversing a lookup tree, should be fast) as well as converting them to meshes that can be rasterized (might take a bit longer).
PS: I’d recommend using a larger tile size than 20. That’s pretty small.
We actually need to go to a finer granularity, bit of a tangent but i don’t know how recast is supposed to be good for big and small areas. We’re have bridges that are fairly narrow as well as big expanses which requires frequent updating.
I can’t believe this has never been done before hehe
What do you mean by you needing finer granularity?
With a cell size of 20 we have some reasonably sized paths and bridges that wont get nav over them
Oh tiles, bigger tiles are worse for rebuilding right?
Cell size is independent of tile size.
A smaller tile size will break up the navmesh into smaller parts. It allows for more parallelism when scanning, but each tile also has some overhead. I’ve found the sweet spot for tile sizes to be between 64 and 256.
Ok thanks I’ll give that a go
Hi,
Changing the tile size to 64 didn’t appear to make much difference. To give more context the nav rebuilding is coming from the need to prevent golfers walking in the water and since the water is now a fluid simulation and moves around quite a lot i need to rebuild as it does:
I’m currently batching up the areas where the water meets the land into graph updates that happen once per second. If i do them every frame then i get a 6ms to 9ms slow down per frame and that’s not acceptable.
If there is no way to get this faster, nothing obvious i’m missing, then i’m going to have to do the nav updates less often but that obviously reduces accuracy.
I suppose i could also reduce the triangle count in the terrain and water mesh that blocks the terrain navigation so that it’s much faster to crunch through in recast.
One other thing to note is that it appears to only spike the frame time in the editor, it’s barely noticable in a release build so maybe it’s debug overhead.
I might be doing a few extra checks in the editor. But I wouldn’t think the difference would be that large. But if it doesn’t seem to be an issue in a release build, then everything sounds good?
Btw. Unless you are already using it, you can try out the beta version. Scanning and updating recast graphs is a lot faster in the beta. See A* Pathfinding Project
Yeah i think we’re ok on this issue. I’m using 4.3.61.
Thanks for the help.
