This topic is 2073 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

[color=#4A4A4A]Okay, so I have a working implementation of Navigation-Mesh path finding in my game - using A*[color=#4A4A4A]
It works great![color=#4A4A4A]
I've gotten to the stage where I want to start making some AI actually use the navigation mesh to find the player - always I good point to be at.
[color=#4A4A4A]
Now this is where the problem arises:[color=#4A4A4A]
I have to somehow determine which polygon in the mesh contains the player and each-and-every AI entity.[color=#4A4A4A]
( So I can find the path from the entity to the player )
[color=#4A4A4A]
Regarding my "Meshes"[color=#4A4A4A]
- All of the navigation-mesh's polygons are convex, containing up to 15 vertices[color=#4A4A4A]
- A "polygon" is nothing more that a collection of the vertices, and in turn triangles, that make it up, and "pointers" to its neighbors.
[color=#4A4A4A]
I don't know if I should do some sort of ray-cast, compare distances, or some other approach.
[color=#4A4A4A]
Ray-Cast:[color=#4A4A4A]
- Can be accurately done (my polygons follow a winding order)[color=#4A4A4A]
- Could be very expensive[color=#4A4A4A]
- Has to be done for each and every triangle and entity
[color=#4A4A4A]
Distance:[color=#4A4A4A]
- Cheaper[color=#4A4A4A]
- Not nearly as accurate[color=#4A4A4A]
- How would I even get this to return tangible results?
[color=#4A4A4A]
So, I'm stuck as to which approach to choose, a hybrid solution, or a completely different method...[color=#4A4A4A]
-or simply put, "How is this usually done, efficiently?"[color=#4A4A4A]
Any ideas or suggestions would be greatly appreciated
[color=#4A4A4A]
You can see more and get a better idea - PICTURES - of what I'm doing on my blog (the last few posts have been about navigation meshes)[color=#4A4A4A]
http://ruinedgame.blogspot.com/
[color=#4A4A4A]
-Thanks Again
[color=#4A4A4A]
P.S. I'm using XNA, so I have a [s]slight[/s] performance overhead...

Share on other sites
Hmm, not an expert on implementing this, but my first thoughts would be:
- Each agent keeps a record of polygon it is on.
OR
- Maintain a quadtree/hashtable/whatever of polygons by the x and z coordinates. This will give you a short list so you can check point-in-polygon (flattening to ignore y).

Share on other sites

Hmm, not an expert on implementing this, but my first thoughts would be:
- Each agent keeps a record of polygon it is on.
OR
- Maintain a quadtree/hashtable/whatever of polygons by the x and z coordinates. This will give you a short list so you can check point-in-polygon (flattening to ignore y).

Hmm... that first idea might work,
but I'd still have to check to make sure each entity hasn't been pushed aside / out of the polygon each frame.

So I'm seeing a process of steps like this for each entity:

 if (we are NOT still above the same (stored) polygon) { foreach of the stored polygons neighbors { if (we are above one of these polygons) { storedPolygon = neighbor-x return } } foreach of the Mesh-s Polygons { if (we are above one of these polygons) { storedPolygon = polygon-x return } } } else { Move along the path, towards its destination } 

Does this make sense, or am I still missing something?

Note: my meshes shouldn't have a TON of polygons, each "room" of a level has it's own Navigation Mesh

Share on other sites
Every time an agent is moved or bumped, it should do a vertical ray cast into the navmesh to find the intersection. This will keep your agent's vertical position correctly aligned to the navmesh. The agent can then store it's current polygon. I believe this is how Recast/Detour handles things.

Honestly, I would just start with this approach and profile your results before deciding to optimize further.

Share on other sites

Every time an agent is moved or bumped, it should do a vertical ray cast into the navmesh to find the intersection. This will keep your agent's vertical position correctly aligned to the navmesh. The agent can then store it's current polygon. I believe this is how Recast/Detour handles things.

Honestly, I would just start with this approach and profile your results before deciding to optimize further.

Yep, that's what I've done

So far it seems to work fine, to speed up the ray-tests I first check the neighbors of the last polygon the entity was on.
-This makes sense seeing how most monsters don't fly randomly across the map in the blink of an eye

Thanks for the suggestions!

... now all I have to do is figure out a way to prevent enemies from converging along the same path!