HeroEngine Forums
Welcome, Guest. Please login or Register for HeroCloud Account.

Author Topic: NavMesh & Pathing Issues  (Read 2567 times)

_Omzy_

  • General Accounts
  • *
  • Posts: 24
    • View Profile
NavMesh & Pathing Issues
« on: May 23, 15, 01:54:35 PM »

Hi guys,
Forgive me if some of these things have been posted before--I searched but didn't find anything related except some recent problems with paths ignoring models. I'm not sure if these are new since the recent update, are intended functionality with an explanation, or are actual bugs. Without further ado:

1) The navmesh doesn't seem 'complete'. When I turn on the visualizer, it looks riddled with holes like this one that seem non-intuitive. Surely this would have consequences in plotting a path down this actual path? I've given the PathMaker plenty of time to generate this area's paths as I've not modified the dat in days, allowed the world to sleep 2-3 times, and I see no dirty regions.

EDIT: Found this line under Path Planning panel:
WU_TestArea  (+): TaskNumber 11, BUILDING: status: BackLinking node 38702 of 49026. : /world/areas/9223372057044021587/area.dat

Would it really take this long to build the navmesh on such a small terrain? Its just a small testing area.



2) Using the default clean engine implementation of E_AIStateWander, E_PathingHelper, which utilizes its PathToPoint method, which calls '$PathSystem._PathSystemGetPath( me, me.E_phParameterSet, start, point )', these mobs are moving from random point to random point. You can see that they seem to float and sink into the ground as they path between points. Why are they not using the points from the navmesh to determine where the ground is?

EDIT: Upon turning on cached path visualization, all of the paths are straight lines instead of paths following the navmesh points




3) Using the default clean engine implementation of E_AIStatePursue, E_PathingHelper, which utilizes its PathToPoint method, which calls '$PathSystem._PathSystemGetPath( me, me.E_phParameterSet, start, point )', I ran into this mob's aggression radius, he followed me to my stopping point and accurately made it within combat range. However, his path was very erratic, and he turned multiple times before settling on a final point and heading towards my character. Is there a way to smooth this out?


Just now getting into this part of AI, so thank you for any responses!
« Last Edit: May 23, 15, 02:22:40 PM by _Omzy_ »
Logged
-OMZY-
Odyssey of Ydris

ToY-Krun

  • General Accounts
  • *
  • Posts: 677
  • Support Volunteer
    • View Profile
Re: NavMesh & Pathing Issues
« Reply #1 on: May 23, 15, 03:57:36 PM »

Hey,

The default wander AI is a basic implementation.   PathToPoint requests a route between two points.
The list of points sent back via the pathingSystem may or may not be a straight line depending on the terrain/pathNodes etc.    It returns random points via GetRandomPoint()

http://hewiki.heroengine.com/wiki/$PATHSYSTEM

At some point you'll probably want to make use of the Override script for the pathingSystem:
E_PathingHelper (might have to check to make sure thats the exact name.  either pathhelper or pathinghelper)

Quote
Not an implementation of AI, it does not make decisions for your "creatures"

if you look at the pics here: http://hewiki.heroengine.com/wiki/Path_Planning_panel
you'll notice "holes" as well, though it varies.



Quote
The INI file which controls how the navigation mesh is generated can be edited directly inside HeroBlade using the PathPlanning panel. You can preview changes to these settings by using the ‘TestBuild’ button. When you perform the ‘TestBuild’ operation, the new settings will be applied only to the currently visible region of the navigation mesh. This is extremely useful for experimentation and tuning of parameter changes.

If you wish to make a global change to all navigation meshes, then click the button ‘Publish as New Master Settings’. This will write out the file ‘DefaultNavMesh.ini’ to the root level of your repository. Remember that existing navigation meshes will not be rebuilt using these settings unless there is an editing change to that area or you remember to bump the ‘build_version’ number.

You can also make changes that apply only to the current area you are working in. You accomplish this by clicking the button marked ‘Publish Custom Settings’. This writes a file ‘area.ini’ in the same Repository folder as the corresponding ‘area.dat’ file.

To remove the custom settings for an area and have it revert back to the global navigation mesh settings, select ‘Delete Custom Settings’.]The INI file which controls how the navigation mesh is generated can be edited directly inside HeroBlade using the PathPlanning panel. You can preview changes to these settings by using the ‘TestBuild’ button. When you perform the ‘TestBuild’ operation, the new settings will be applied only to the currently visible region of the navigation mesh. This is extremely useful for experimentation and tuning of parameter changes.

If you wish to make a global change to all navigation meshes, then click the button ‘Publish as New Master Settings’. This will write out the file ‘DefaultNavMesh.ini’ to the root level of your repository. Remember that existing navigation meshes will not be rebuilt using these settings unless there is an editing change to that area or you remember to bump the ‘build_version’ number.

You can also make changes that apply only to the current area you are working in. You accomplish this by clicking the button marked ‘Publish Custom Settings’. This writes a file ‘area.ini’ in the same Repository folder as the corresponding ‘area.dat’ file.

To remove the custom settings for an area and have it revert back to the global navigation mesh settings, select ‘Delete Custom Settings’.

Its good enough to get you started, but in the end, when you reach the need for advanced pathing you "may" need to tweak the .ini file



Theres alot of information, too much to post really, but if you search for "navmesh ini" or "navigation ini" etc, you may find some useful info to help you out further.

Hopefully those links I gave ya will explain it better than I can here.



*EDIT*
Just another note, if the terrain between two points is above or below the straight line between those two points
the npc will walk above, or below, the terrain. 
It would get into another subject altogether, but on the client side you can also override some methods in the controller and nonPlayerCharacter scripts to make sure npcs "snap" to the ground while following a path. 
« Last Edit: May 23, 15, 04:04:34 PM by ToY-Krun »
Logged

ToY-Krun

  • General Accounts
  • *
  • Posts: 677
  • Support Volunteer
    • View Profile
Re: NavMesh & Pathing Issues
« Reply #2 on: May 23, 15, 04:07:57 PM »

Somewhere in the forums there is a good thread regarding npcs walking through the corners of buildings etc, due to the "resolution" of the navmesh (if i can call it resolution  :P).   

If i locate it I'll link it here, unless someone else knows where it is.

_Omzy_

  • General Accounts
  • *
  • Posts: 24
    • View Profile
Re: NavMesh & Pathing Issues
« Reply #3 on: May 23, 15, 06:22:20 PM »

Thanks for the info Krun,
I've looked into those resources and understand the asynchronous nature of path requests and such, but what isn't clear in the references is how to solve the basic issues of npcs snapping to the ground (you mention modifying clientside scripts, but where?) and npc path smoothing. When I use the path panel to capture a FROM and TO point, the paths generated look very nice and follow the curvature of my hills. However, the paths generated from PathToPoint, which uses a $PATHSYSTEM request for a path, appear to be straight lines. Even after reading the available information, I am still scratching my head.

Regarding ground snapping, I found this old thread of yours, but it doesn't mention what the eventual solution was: https://community.heroengine.com/forums/index.php?topic=4831.0

EDIT:
I realized im having the same issue WorldWideZ had in his first post of this thread, which he also did not post a final solution for. A call to $PathSystem._PathSystemGetPath( me, me.E_phParameterSet, start, point ) where me.E_phParameterSet is set to $PathSystem._pathSystem_GetWalkableParameterSetHandle() is made. I have verified that the start and point vectors are good inputs with distance between them between 0.5 and 10 game units on average. The resulting path from _PathSystem_PathComplete contains path._psrPointList that is empty 99% of the time, and 1% of the time has a real path. That 1% of the time is responsible for all character movement, but many of my npcs are just standing there because they are 'blocking'.
 https://community.heroengine.com/forums/index.php/topic,4912.msg27609.html#msg27609
« Last Edit: May 23, 15, 08:09:27 PM by _Omzy_ »
Logged
-OMZY-
Odyssey of Ydris

ToY-Krun

  • General Accounts
  • *
  • Posts: 677
  • Support Volunteer
    • View Profile
Re: NavMesh & Pathing Issues
« Reply #4 on: May 24, 15, 02:43:25 PM »

Our problems were twofold:

1) using diamond setting for heightmaps (often creates anomalies where the navmesh doesn't exact follow terrain)
WHEN
2)using heightmap resolutions other than standard(which we do in some cases)

The fixes mentioned in that post have been in for a while so I wouldn't think they would be an issue on your end.

I don't have much time at the keyboard atm as I'm dealing with some sickness in the family, but from memory...

There are a few things that "I" would check off the top of my head.

1.) As there seem to be "some" issue with the navmesh, as noted in the issues being investigated thread,
     I would wait a few days for the update before doing anything major, as , who knows, it could be related.
2.) If you've made changes to the E_nonPlayerCharacter(client side) see if those changes could be conflicting
     (compare it with earlier versions if need be to see what changes if any have been made)
3.)Check the E_ACCController script likewise for any changes(as this is where grounding/snapping etc take place)

4.)in E_ACCControllerClassMethods:(client side) find the following:
_HE_ACCC_Ground()

now look for the following code near the top:

Code: [Select]
if me.HeroEngineACCC_NavMode == NPC   
me.HeroEngineACCC_SnapToGround = true
else if me.HeroEngineACCC_NavMode == REMOTENAV
return
.

if the above block of code exists, it is supposed to be removed/commented out as per a Saphire update fix
but I would assume it is fixed in current version, but check anyway.  (I cant recall if there was any more to that fix, when I get a chance I'll see if i can find the post regarding it)


5.) In the same script/method, look for the following:

Code: [Select]
if ( groundy < (feet-0.005) )         
      groundy = feet - 0.005
    .

Its probably commented out unless you have it uncommented.  Uncomment it and see if it makes any difference.

Atm thats the only code I can recall working with in regards to that issue.  Currently We're running with that groundy code uncommented with good results, but I can't say it resolved anything.  Havent had to touch that code for a while.

If I think of anything else I'll try to post it.   This is all in regards to npcs walking above/below terrain and really has nothing to do with their choice of path points between two points.   

The default works fine other than, as you point out, you may get a "zig zag" path.   

If the npc has player in LOS, you could go straight to _DriverSetPoints and give it the points yourself like...
add back A to pointList
add back B to pointList
_DriverSetPoints(pointList) 

that may or may not be the exact method name, Im working from memory here.  The npc would then go directly tot he players position, if the player moves, the list is updated with new location FROM npc's location.  If player leaves LOS then it calls on pathToPoint to sort it out.  There are a few places we use this method, but for the most part the default has worked well enough up to this point.  You can edit the ini file in the Path Planning panel and either test/submit it for that area.   The Wiki has a write up on the does and donts of editing it.

ToY-Krun

  • General Accounts
  • *
  • Posts: 677
  • Support Volunteer
    • View Profile
Re: NavMesh & Pathing Issues
« Reply #5 on: May 24, 15, 07:11:14 PM »

The INI file:  If you have the path planning panel "docked" to the left or right, you may not see it.

Drag the path planning panel to the center if this is the case.  Or to another monitor if you use one.

Its at the bottom of the panel.  You'll also need to stretch the panel wider to see it all.

Here is a copy of one:

Code: [Select]
##########################################
# This INI file defines the properties #
# that control how the naviation mesh  #
# for an area is created.              #
##########################################
[DEFAULT]

build_version              = 1             # Bump this number to force the build of the Navigation Mesh for this area.
terrain                    = true          # True if path finding nodes allowed on terrain
non_terrain                = true          # True if path finding nodes allowed on non-terrain

water                      = true          # True if path finding nodes allowed on the surface of water
underwater                 = true          # True if path finding nodes allowed underwater
dive_down                  = true          # True if dive-down connections allowed
swim_up                    = true          # True if swim-up connections allowed

avoid1                     = true          # True if path finding nodes allowed on 'avoid1' type objects
avoid2                     = true          # True if path finding nodes allowed on 'avoid2' type objects
avoid3                     = true          # True if path finding nodes allowed on 'avoid3' type objects
avoid4                     = true          # True if path finding nodes allowed on 'avoid4' type objects

prefer1                    = true          # True if path finding nodes allowed on 'prefer1' type objects
prefer2                    = true          # True if path finding nodes allowed on 'prefer2' type objects
prefer3                    = true          # True if path finding nodes allowed on 'prefer3' type objects
prefer4                    = true          # True if path finding nodes allowed on 'prefer4' type objects

character_capsule          = true          # True if the character controller is a capsule
character_walk_slope       = 45            # The valid walk slope for the character
character_width            = 0.03          # The width of the charater (game units)
character_height           = 0.19          # The height of the character (game units)
character_step_height      = 0.04          # The step height of the character

node_granularity           = 0.03          # The granularity of a single unit for node generation (game units)
node_min                   =  3            # The minimum size for a node (number of granular units)
node_max                   = 45            # The maximum size for a node (number of granular units)

connection_search_distance = 8             # The distance allowed to search for connections (game units)
connection_search_count    = 20            # The maximum number of nodes to search connections for.
connection_max             = 8             # The maximum number of connections to keep for a single node.


Careful what you change and how much.
These settings control how many nodes are created in a given area of measurement and how many connections they will attempt to make with others around them.   The hole in the pic you posted above, is a result of the nodes around the hole being too far from each other to form a connection with each other, and/or having already the max number of connections each. 

I've not played with these very much as we're not ready to get that deep into pathing just yet.
You should be able to play around with them however to see how they affect the navmesh.
You can revert to the default as you wish.

I don't want to suggest you play with these settings without also pointing out the following:

From the Wiki :http://hewiki.heroengine.com/wiki/PathMaker#PathMaker
(some of this page may not deal with licensees or may be out of date)
Quote
DefaultNavMesh.ini

When the PathMaker server rebuilds a navigation mesh, it does so based on a set of rules which are defined in a master INI file called ‘DefaultNavMesh.ini’. This file is located in the root folder of your Repository. The first time a PathMaker server is ever spun up, if this file does not exist, then it will create a default one to use.

This file describes the rules which are applied when a navigation mesh is built. Great caution must be taken before making changes to this file, as it is easy to configure it in ways that would produce explosively large navigation mesh files. It has been pre-configured and tuned to work with the default character controller in HeroEngine.

With the 1.22 release of HeroEngine, there is only a single navigation mesh file available for any given area.

Currently you can edit the default settings, but it is strongly advised to do so with great caution and consultation before making the change.



The settings in the ‘DefaultNavMesh.ini’ file are as follows:

    build_version : This is the master version number of all pathing data. If you make a change to any of these rules which would invalidate your old navigation mesh data, then you should bump this version number up by one. This will force each navigation mesh to get rebuilt using the new set of rules.
    terrain : true/false. This indicates whether or not navigation mesh data should be generated on heightmaps. It is doubtful you would ever set this to be false unless, for some reason, no pathing on terrain would ever be necessary.
    non-terrain : true/false. Non terrain is anything in the area which is not terrain, water, or underwater. Generally speaking this corresponds to mesh objects in your world. In most cases you would want this to be true unless, in the context of your game design, you never want pathing to occur on anything other than heightmaps.
    water : true/false. This option indicates whether or not navigation mesh nodes should be generated on the surface of water. Additional work on the character controller would be necessary to take full advantage of this feature.
    underwater : true/false. Indicates whether or not navigation mesh nodes should be generated on surfaces which are below water. These nodes would be used for creatures which are capable of walking underwater, as opposed to swimming only on the surface. Additional work on the character controller would be necessary to take full advantage of this feature.
    dive_down : true/false. Indicates whether or not connections should be generated between water surface nodes and underwater nodes. This would allow path searches to consider diving down to the bottom of the underwater surface when producing solutions. Additional work on the character controller would be necessary to take full advantage of this feature.
    swim_up : true/false. Indicates whether or not connections should be generated from underwater nodes up to nodes on the surface of water. This would allow path searches to consider swimming up from the bottom as part of the solution. Additional work on the character controller would be necessary to take full advantage of this feature.
    avoid1-4 : true/false. Indicates whether not navigation mesh nodes should be generated on objects marked as ‘avoid1’ through ‘avoid4’. Generally speaking this option would never be set to false, as the ‘avoid1’ flag is used primarily to steer pathing requests.
    prefer1-4 : true/false. Indicates whether not navigation mesh nodes should be generated on objects marked as ‘prefer1’ through ‘prefer4’. Generally speaking this option would never be set to false, as the ‘prefer1’ flag is used primarily to steer pathing requests.
    character_capsule : true/false. Indicates whether or not the character controller is to be modeled as a capsule or a box. The default character controller settings in HeroEngine are modeled as a capsule.
    character_width : Indicates the width of the character controller. The default value of 0.03 matches that used by the default character controller in HeroEngine. If you have modified the character controller width in your game, you would want to match the size change here.
    character_height : Indicates the height of the character controller. The default value of 0.19 matches that used by the default character controller in HeroEngine. If you have modified the character controller height in your game, you would want to match the size change here.
    character_step_height : Indicates the step height of the character controller. The default value of 0.04 matches that used by the default character controller in HeroEngine. The character_step_height defines how high a character controller can ‘step onto’ a higher surface (example walking up stairs). If you have modified the character controller step height in your game, you would want to match the size change here.
    node_granularity : Describes the detail level of the navigation mesh nodes. Note that the default value of 0.03 matches the character width. This is a value which should be tuned extremely carefully! If you were to make it just a tiny bit smaller it could easily produce a navigation mesh that is far too detailed and could take forever to build and consume a massive amount of memory. However, it is generally safe to make it larger. In general you want the granularity to be as large as possible while still producing navigation mesh nodes in the tightest spaces a character could walk. Matching it to your character width is generally a safe bet.
    node_min : The minimum size of a valid navigation mesh node. The default value is 3 which indicates 3 times the node_granularity value. Making this number smaller would be dangerous as it would explode the number of navigation mesh nodes produced. It is always safe to make it larger. As you can see the node_granularity and the node_min value work together to define the smallest space that will be represented by the navigation mesh.
    node_max : This value defines the maximum size a single navigation mesh node should be. This number cannot be greater than 63. The actual maximum size is equal to node_max*node_granularity. In general you want this number to be large, as it reduces the density of the navigation mesh substantially and represents large open spaces more efficiently. However, very large nodes can limit the detail of the search space to some extent.
    connection_search_distance : This describes the distance to search for neighboring nodes when building connections. If you change your node granularity and node maximum sizes, you might want to adjust the search distance accordingly, though the default value should work fine in most cases.
    connection_search_count : This defines how many neighboring nodes will be considered for building connections. The default is 20 and probably more than sufficient in all cases. These parameters probably do not need to be tuned in most cases.
    connection_max : This is the maximum number of connections to keep between any one navigation mesh node and another.


We've been content to leave this work until we're a bit further along as , even with the random npc's feet under ground or above it, it suits our needs for the moment.   For specific pathing needs we have a game specific alternative that uses the $PathingSystem but we provide the point locations and /or we use the fixed path system with greater control over pathpoints(taxis etc)

_Omzy_

  • General Accounts
  • *
  • Posts: 24
    • View Profile
Re: NavMesh & Pathing Issues
« Reply #6 on: May 26, 15, 08:59:48 PM »

Thanks for the replies Krun! I'll have to put some thought into how to smooth things out and fix the grounding, so once I work it out, I'll try to post whatever fixes I come up with.

EDIT Here are my issues:
1) Some AI's do not activate properly after being awoken by $AiControl._GetOrMakeAiAgentRootNode()._WakeupAllAgents() in HE_PostOnAreaLoad of E_AreaClassMethods. I have found that postponing this awakening and doing it manually via script command (for testing) has allowed all AI in the area to awaken properly (Solved).
2) NPCs are not grounded properly
3) NPCs take very non-smooth paths during pursuit using E_AiStatePursue
« Last Edit: May 27, 15, 12:26:22 PM by _Omzy_ »
Logged
-OMZY-
Odyssey of Ydris