Hello,
Got some issues on Navmesh generation leading to a question:
We have a wall with a small Nav Modifier
[Image Removed]
On the following specific configuration , the navmesh cell below does not generate .
You can see on the image below than +2 units on Y translation enable this generation. (the wall is hidden by another graphical asset here)
[Image Removed]
Changing from default watershed to monotone or changing cell size from 20 to 10 fixed the issue.
So first question (the easy one) : is there an ‘official’ doc on pros/cons of each partitioning algorithms ? Not very clear of what to use in our case (PCG, rectangular rooms for most stuff, with assets that could affect navmesh on each room (pillars, etc))
But that’s not the real issue here : door frame do not generate navmesh, instead we use navlink to connect room ( mainly for door detection from a pathfind pov instead of physics, fixed path to handle crossing door animation, …)
But this navlink is set depending on door frame size :
[Image Removed]
So if navcell is not generated below end point, navlink is marked as failure and AI can not enter the room through it.
I wanted to fix that by creating a custom NavLinkProcessor as the default one adapt navlink for fall/jump.
But at this point, navmesh is still building, so i assume i cannot check/find a navigation point in a radius to fix my navlink.
I am missing something here ? Is there a better approach for this or should i assume that navmesh generation should not fail ?
[Attachment Removed]
We do not have any official docs on the partitioning for navmesh generation. The default in the engine is Watershed just due to it being the original one used and has been the default since at least the early UE4 days using Recast. Both monotone partitionings help eliminate the long skinny triangles that can cause issues in pathfinding. Internally, we use Chunky Monotone for FNBR and Lego FN, and we would advocate its use in nearly all projects. We have had recent discussions of changing it to be the default in the engine.
Summary of the partitioning methods:
- Watershed
- Best fit to complex geometry
- Handles curved and diagonal hallways better
- Can create long, thin triangles which can be problematic as well as small “islands” in some cases
- Monotone
- Fastest to compute (usually)
- Can result in some less natural fitting mesh on complex geometry especially compared to Watershed
- Chunky Monotone
- Similar to Monotone, but processed in chunks for better performance on large tiles or many layers
- Still quite fast for use in large nav bounds for generating navmesh
- Requires some tuning for number of splits
- Too many splits can increase overhead for each tile
- Too few lose the performance benefits of using chunks
The end of the navlink does need to be on the navmesh. Usually, there is a snap radius applied to the end point to find a poly to which it can attach. Are you using something akin to NavLinkProxy or a CustomNavLinkComponent on the door to set the end points? Are they done automatically either with the automatic navlink generation system or something similar?
-James
[Attachment Removed]
Thanks for the answer,
We will give a try with the Chunky Monotone.
For the navlink part, got our NavLinkCustomComponent, but mainly to be able to finely tune our NPC moving through doors (using navlink)
Started to add the code to find correct end point in case of corner case like the navmesh generation one (all doors / walls / rooms have the same setup, so i assumed a manual settings should be fine) and stumbled on the Nav preprocessor stuff.
So i wonder if i can simply perform a check at the BeginPlay of the component and if navlink is not correct, pick a close navigation point and perform a recompute ?
(note : i searched for the ‘navlink failed data’ and it seems it’s not a trivial matter despite debug show clearly this info)
[Attachment Removed]
For your custom NavLink component, what happens if you increase the SnapRadius value for the underlying NavLink that is created? Does the issue seem to be that the small modifier for your door is not being picked up when building navmesh with larger cell sizes? It looks quite thin in screenshots and may just line up in certain cases at the boundary between the voxels generated for the navmesh. Is the modifier applied to the door or the highlighted section of the wall in the screenshots?
As for the custom nav link processor hook in the NavigationHelper namespace, I am not sure we have anything running there internally. I know we have some custom navlink processors which run in FNBR to help validate links being generated at runtime, but it is custom to FN and FN’s derived navigation system.
[Attachment Removed]
for the small modifier on wall not being picked with larger cell sizes : does it means that boudaries between voxels are a range and not a line ? (on my screenshot we can only see the cell limit, did not display voxels)
Since only pushing away the modifier from some unit triggers a navcell generation that seems the case.
We did not switch to other method for now, monotone seems to give the best result, while Chunky Monotone delivers random gap with default settings (need to adjust size for better result but don’t have time to check for now)
As temporary fix, i asked for a better navmesh resolution for theses walls.
Did not check about snap radius for navlink since primary issue was bypassed
[Attachment Removed]
The voxels function in a line, but the imprecision may miss the small modifiers or collision near the edges. I am curious if making the modifier slightly larger allows for it to be picked up with the larger cell sizes. I am glad to hear that it seems to be addressed.
[Attachment Removed]