-
-
Notifications
You must be signed in to change notification settings - Fork 20
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
Emit polygon path #30
Comments
Hmm, looks like I was mistaken and Polyanya only supports duplicate points and zero-area triangles, but not overlapping triangles. |
Polyanya with overlapping meshes! output.webmThis is on a local fork where I've converted everything to use indices to uniquely identify points instead of |
I didn't continue with my demo. The math I thought would work to generalize this to non-uniform-cost movement didn't pan out as I expected (which was actually what I was more interested in at the time), and after hitting a dead end there I moved on for the time being. I'm happy to push the non-planar demo to github tomorrow |
I have something that works for that now, see this test: Line 899 in c74391b
it's setting up a navmesh with 5 layers like so:
with layers 1 and 2 having a higher cost of traversal than layer 3, then for 20 points equally distributed in a line in layer 0, find the path to the corresponding points in layer 4. The path correctly goes either through slower layers or around them depending on the cost. @taktoa to support overlapping polygons I added the notion of "layer" that can be connected at some of their vertices. The path with the layer information can be retrieved when feature Lines 64 to 66 in c74391b
Does that work for you? |
For 2D pathfinding, the current
Path
type works fine, but if you want to do 3D pathfinding (with multiple overlapping floors etc.), the current interface is insufficient. In particular, I'm imagining that you project out the X and Y positions of each point in a mesh, which may result in duplicate points. Polyanya supports duplicate points and overlapping/zero-area triangles, at least from my experimentation, but since it only outputs a list of positions it's impossible to know which of many overlapping triangles a given element in a path is from (and therefore what its Z position is). If the indices of polygons traversed were included in thePath
then this wouldn't be an issue.The text was updated successfully, but these errors were encountered: