Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not direct path in some situations #239

Closed
1vanK opened this issue Nov 5, 2016 · 4 comments
Closed

Not direct path in some situations #239

1vanK opened this issue Nov 5, 2016 · 4 comments

Comments

@1vanK
Copy link

1vanK commented Nov 5, 2016

2

@hymerman
Copy link
Member

hymerman commented Nov 7, 2016

This is a side-effect of the choice of node locations for the A* search. It's a bit unfortunate and does happen a fair bit, especially where there are large polys next to small ones. Mikko wrote a little bit about it a long time ago here: http://digestingduck.blogspot.co.uk/2010/08/navmesh-node-locations.html

What I suggest is decreasing the max edge length, which splits up long edges and results in polys being similar sizes. It does mean your navmesh will have more polys, so will be slightly less efficient in many ways.

Something I personally found to work slightly better too is tweaking the pathfind to put node positions in poly centres instead of edge midpoints, but this is a bit more of an involved changed and still suffers the same problem often. Change this bit of code in DetourNavMeshQuery.cpp to create the node position at the poly centre:

        // If the node is visited the first time, calculate node position.
        if (neighbourNode->flags == 0)
        {
            getEdgeMidPoint(bestRef, bestPoly, bestTile,
                            neighbourRef, neighbourPoly, neighbourTile,
                            neighbourNode->pos);
        }

Lastly, what I ended up doing on another project, was to run a pass over the path to raycast along the navmesh between pairs of points, replacing parts of the path with more direct results if found. It's expensive but does produce nice paths (but again, isn't perfect!).

@jackpoz
Copy link
Contributor

jackpoz commented Nov 9, 2016

another trade-off could be to raycast only between start and end position and fallback to usual pathfinding with nodes if end position is not in line of sight.

@jakobbotsch
Copy link
Member

Also look at DetourPathCorridor.cpp. It contains some interesting optimizations, and I believe some of them deal with this problem.

A typical way to deal with your problem here is to continuously optimize the path by trying to raycast a few polys ahead, i.e. 3-4 polys ahead, and then skipping the polys in between if there is a straight path.

I believe Mikko has written about this in a blog post some time ago, but unfortunately I cannot find it. You can try to look for blog posts that may be relevant at his blog.

@hymerman
Copy link
Member

hymerman commented May 9, 2017

Hey @1vanK , did you get anywhere with this? Have we helped enough? I'll close this issue for now; if you need more help please ask on the google group (link is in the readme).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants