Announcement

Collapse
No announcement yet.

[REQUEST] Ability for paths not to build on Static Meshes

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

    [REQUEST] Ability for paths not to build on Static Meshes

    At the moment we've got one option on Static Meshes as to whether they block paths of not, 'Can Ever Affect Navigation'.

    However I would like another option that allows me be able to set meshes to block navigation, but not for the Nav Mesh to build paths on them, such as for high up ledges that the AI can never get to.

    This will really reduce the memory cost of the Nav Mesh, Nav Mesh rebuilt times and debug bugging times as it's clear to see where AI characters can and cannot go.

    #2
    If your mesh affects navigation and has collision, then the mesh won't be built there. There's a setting to limit the height and min size of mesh generation too. Finally, look at navmesh modifier components (UNavArea) where you can control whether they are navigable or if it's just really expensive to navigate there.

    Comment


      #3
      If your mesh affects navigation and has collision, then the mesh won't be built there.
      The problem is that the Nav Mesh will build ontop of these meshes.

      I have a project that embraces verticality so Nav Mesh Volumes encompass whole areas, including lots of points where the player can go but the enemies can't. Creating 10s of Nav Mesh volumes for a level seems like a waste of time, especially whilst environments are evolving, when it can be dealt with on a Mesh Instance basis. I can't remember if vanilla UE3 had this option for its Nav Meshes, but the projects I worked on did and it was alot quicker and stabler to mark meshes to not have Nav Meshes build on them whilst they still block the Nav Mesh.

      Also, coming from UE3 I'm used to the Nav Mesh system being associated with a Pylon actor, and paths coming out from there. However with UE4 it looks like the Nav Mesh will build on any valid surface within the Nav Mesh volume. Is there any way of associating setting Nav Meshes to behave like this, maybe via the Player Start actor (similar to UE4's original Path Node system)?

      Comment


        #4
        Originally posted by Jimmy_Jazz View Post
        At the moment we've got one option on Static Meshes as to whether they block paths of not, 'Can Ever Affect Navigation'.

        However I would like another option that allows me be able to set meshes to block navigation, but not for the Nav Mesh to build paths on them, such as for high up ledges that the AI can never get to.

        This will really reduce the memory cost of the Nav Mesh, Nav Mesh rebuilt times and debug bugging times as it's clear to see where AI characters can and cannot go.

        I've been searching everywhere and trying every setting I can to do exactly this but so far I have had no luck. I've seen other people ask for such an option as well but seems like it just isn't possible? It seems really strange that you can only set a static mesh to "has navigation data". I have several rocks on my terrain, and there is a lot of height variation in the terrain. I've setup a navigation volume that is a few hundred yards on the x and y axis, and has enough height on the z axis to encompass the play area. When I generate the paths, the rocks do block navigation as intended. But it also generates navigation/paths on top of the rocks, a miniature island of a path. In some cases we have had issues with AI mysteriously managing to get onto these areas, this also happens with foliage static meshes such as bushes or trees. It would be extremely time consuming to build navigation modifier volumes to manually block all the trees/rocks/bushes to prevent this. I've seen other engines allow for you to control whether or not navigation can be generated on the collision mesh of a static mesh, while also having the separate option to block navigation.

        Sorry for resurrecting such an old thread but I'm just hoping maybe you managed to figure this out in the past few years haha

        Comment


          #5
          It is still a problem. It's kinda pathethic that even such engine as Unity has a navmesh that allows for any collider to be set as "not walkable" making it completely cut out holes in navmesh with surprising precision and UE4 still can't get it right...

          Comment

          Working...
          X