Why is there a difference between packaged build and in editor for ProjectPointToNavigation?

Development Programming & Scripting AI
, , , , , ,
1

I am having trouble with this piece of logic, specifically for the function ProjectPointToNavigation:

FNavLocation navLoc;
FVector queryingExtent = FVector(0.0f, 0.0f, 50.0f);
FNavAgentProperties navAgentProps;
bNavMeshProjection = GetWorld()->GetNavigationSystem()->ProjectPointToNavigation(result.Location, navLoc, queryingExtent);

I use this to detect if there is nav mesh on the ground where my cursor is hovering over. It works perfectly when I play the game in the editor, but once I make a packaged build it works MOST of the time. Sometimes, however, the packaged build will return false for places with nav mesh that should return true. More specifically, the places that will return false in the packaged build but true in the editor are areas of nav mesh that are bordering objects/buildings in the world.

For example, if I project a trace to this location marked by the red X, playing in editor will return a true, which means there is nav mesh present, but the packaged build will return a false.

51386-navmesh.png
51386-navmesh.png972×580 522 KB

2

Have you tried enabling Rebuild At Runtime for your project?

Project Settings -> Navigation Mesh -> Runtime Generation = Dynamic

and

Force Rebuild On Load

I’m not claiming it is a perfect solution, I am curious if it improves your results / reduces variance between editor/packaged build

:slight_smile:

Rama

3

I’ve tested that already actually, and no, it doesn’t make any difference. I’m currently playing around with different querying extents as well, but so far that hasn’t made any obvious changes either.

Thanks for the suggestions though!

4

I have had numerous issues with the ProjectPointToNavigation function in general – I was attempting to make exactly the same kind of query as you, and found that the approach you’re taking (specifically querying with (0,0,N) extents) didn’t work all that well even in PIE.

I think the main issue is that the extents themselves, by the time they get pushed down into recast, get quantized (according to whatever quantization scale recast actually uses in building its own internal representation). As a result, when I made extent queries, I was finding the result were sometimes off by 50-100 units in either direction. This would explain why sometimes your getting incorrect results – though I stress I have no idea why cooked vs. non-cooked would be different.

I’m wondering in your case whether you might not want to do several queries within a short distance of your target point, and find some intelligent way to combine the results. That is essentially the approach we have taken in our game.

5

The weirdest thing about this is that I actually had the exact same problem as you (couldn’t get it working in PIE, even with querying extent (0, 0, n)). Then one day it worked and I just assumed there was some sort of fix/update for it, or maybe I hadn’t tested it well enough before.

And now that I have a packaged build it’s not working again, haha. I will try that idea (using several querying extents), thank you for your suggestions!

6

Oh Rama, actually, it works! I think it was because I was also testing out a different querying extent (100, 100, 100), which obviously gives me the offset if it were working properly. I’ve set the rebuilding nav mesh option to Dynamic, and my querying extent is back to (0, 0, 50), and now it works. Thank you!

7

Oh, nevermind, my querying extent was at (500,500,500) at the time of that build. I guess I’m really getting all my test cases messed up. I will try with (0, 0, 50) again…