Hi, i have a question. In the image, why does the white AILerp object travel to the corner of the map and then head towards the target instead of taking the shortest path? The path I drew with an arrow is the shortest route. This issue only occurs in certain positions. For example, this problem occurs when going from the point in the image to the target point. This problem may not occur when going from another location to the same target.
Graph Type: Recast Graph
Voxel Size: 1
Use Tiles: Don’t Use Tiles
Agent: AILerp
Recalculate paths auto: Never
Funnel Modifier Quality: High
Asset Ver: 5.2.5
Unity Ver: 2021.3.45f1
Those are always helpful yes You may just also want to post your settings for your recast graph (preferably just a full screenshot of them) and we can see if there’s anything that may be causing this. Same for your AILerp settings.
Hello again. I was able to reply late due to some work, but I prepared a very simple demo that simulates the error. You can download it from the link.
Used unity version: 2022.3.55
A* version: 5.3.1
Summary: When you start the game, after 1 second, the agent should go to the target in the shortest way, but after going to the corner of the map, it goes back.
So I was able to get this working by setting Use Tiles to… “yes”, and then setting Max Step Height above 0. Looking at the documentation, I’m not setting much reason to have Use Tiles off- if you have a specific reason for keeping that off let us know, otherwise I’d recommend turning that back on It’s currently set in your graph cache to not use tiles.
As for why this isn’t working in general I’ll have to defer that one to @aron_granberg.
I am using it in a project where I manage approximately 2500 NPCs and 500 players in total. If I remember correctly, the documentation mentioned that using “Use Tiles” could reduce performance. For this reason, I preferred not to use this option. Am I wrong?
If true, divide the graph into tiles, otherwise use a single tile covering the whole graph.
Using tiles is useful for a number of things. But it also has some drawbacks.
Using tiles allows you to update only a part of the graph at a time. When doing graph updates on a recast graph, it will always recalculate whole tiles (or the whole graph if there are no tiles). NavmeshCut components also work on a tile-by-tile basis.
Using tiles can break up very large triangles, which can improve path quality in some cases, and make the navmesh more closely follow the y-coordinates of the ground.
Using tiles can make it much faster to generate the navmesh, because each tile can be calculated in parallel. But if the tiles are made too small, then the overhead of having many tiles can make it slower than having fewer tiles.
Using small tiles can make the path quality worse in some cases, but setting the FunnelModifiers quality setting to high (or using RichAI.funnelSimplification) will mostly mitigate this.
A large tile size can be faster to initially scan (but beware of out of memory issues if you try with a too large tile size in a large world) smaller tile sizes are (much) faster to update.
Different tile sizes can affect the quality of paths. It is often good to split up huge open areas into several tiles for better quality paths, but too small tiles can also lead to effects looking like invisible obstacles. For more information about this take a look at Notes about navmesh graphs. Usually it is best to experiment and see what works best for your game.
When scanning a recast graphs individual tiles can be calculated in parallel which can make it much faster to scan large worlds. When you want to recalculate a part of a recast graph, this can only be done on a tile-by-tile basis which means that if you often try to update a region of the recast graph much smaller than the tile size, then you will be doing a lot of unnecessary calculations. However if you on the other hand update regions of the recast graph that are much larger than the tile size then it may be slower than necessary as there is some overhead in having lots of tiles instead of a few larger ones (not that much though).