Closed reeseschultz closed 4 years ago
25be855e6463654284361ab051fd0c8c3e2730e6 has paved the way for me to start on this fix, in addition to improving performance by only running the non-Burst NavSurfaceTrackingJob
in NavSurfaceSystem
when the NavNeedsSurface
component is present, taking considerable load off the built-in EndFrameParentSystem
.
So anyway I'll look into this bug today. The gist of the issue is that the NavInterpolationSystem
's NavJumpJob
needs to be changed into a more general artificial-gravity-handling job, meaning it should apply to falling agents just as much as it does jumping ones.
Finally started the fix for this.
This is a known issue people will undoubtedly encounter. It's easily recreated by simply clicking too close to an edge of a surface in the
NavPointAndClickDemo
scene. It's avoided (99% of the time) in theNavMovingJumpDemo
scene by only generating destinations within acceptable bounds of jumpable surfaces by way of AABB scaling. Sometimes theNavFallSystem
will even detectNavAgent
s falling in theNavPerformanceDemo
due to a similar (or the same-ish?) issue when they try to go inside obstacles, but that is normally prevented with the built-in obstacle avoidance raycasting—meaning in that case they usually just embark on a partial path right outside a given obstacle.I won't classify this as
wontfix
yet, because I think this could be done better, but I need time to think about it. The workaround is just setting destinations that are not inside obstacles and and are nowhere near an edge of a jumpable surface.