Submitting to Main as a follow up to 7308751
#jira none
#rb Yoan.StAmant
#review-7308772 Yoan.StAmant
#okforgitub public
[CL 7309638 by Mieszko Zielinski in Main branch]
#rnx
[at]maxime.mercier
#rb guillaume.guay
#ROBOMERGE-SOURCE: CL 7289773 via CL 7306493
#ROBOMERGE-BOT: (v370-7290619)
[CL 7306546 by yoan stamant in Main branch]
As part of the process I've deprecated essentially unused ARecastNavMesh.AgentMaxHeight and removed the code accessing it.
[at]Yoan.StAmant
#rb Yoan.StAmant
#ROBOMERGE-SOURCE: CL 7249093 via CL 7262675
#ROBOMERGE-BOT: (v369-7254125)
[CL 7262737 by mieszko zielinski in Main branch]
Notable changes:
- Added FNavigationOctreeController that wraps up what used to be NavigationSystemV1's navoctree-related logic
- Added FNavigationDirtyAreasController that wraps up what used to be NavigationSystemV1's DirtyAreas-related logic
- Added FNavigationDataHandler that is a helper struct that wraps up what used to be NavigationSystemV1's logic related to operation involving both navoctree and dirty areas
- Deprecated both FNavDataConfig.NavigationDataClass and FNavDataConfig.NavigationDataClassName and replaced them with a single NavDataClass property
- FNavigationOctree is not responsible for hashing element objects and storing their ElementId
- NavOctree elements how know about the octree they belong to (via a member property).
[at]Yoan.StAmant, [at]Maxime.Mercier, [at]Guillaume.Guay
#rb Yoan.StAmant
#ROBOMERGE-OWNER: mieszko.zielinski
#ROBOMERGE-AUTHOR: mieszko.zielinski
#ROBOMERGE-SOURCE: CL 7249089 via CL 7262555
#ROBOMERGE-BOT: (v369-7254125)
[CL 7262559 by mieszko zielinski in Main branch]
[at]Yoan.StAmant
#rb Yoan.StAmant
#ROBOMERGE-SOURCE: CL 7090744 via CL 7104302
#ROBOMERGE-BOT: (v367-6836689)
[CL 7104406 by mieszko zielinski in Main branch]
It used to Reserve rather than Empty which in edge cases left the array at undesided state/size.
#jira UE-76279
Yoan.StAmant
#rb Yoan.StAmant
#ROBOMERGE-SOURCE: CL 7061952 in //UE4/Release-4.23/...
#ROBOMERGE-BOT: RELEASE (Release-4.23 -> Main) (v367-6836689)
[CL 7061953 by mieszko zielinski in Main branch]
[REVIEW] [at]maxime.mercier
#ROBOMERGE-SOURCE: CL 7041604 via CL 7041619 via CL 7041621 via CL 7042245 via CL 7047496
#ROBOMERGE-BOT: (v367-6836689)
[CL 7048353 by yoan stamant in Main branch]
[REVIEW] [at]Josh.May, [at]Maxime.Mercier, [at]Tim.Tillotson, [at]Yoan.StAmant
[FYI] [at]Mieszko.Zielinski
#ROBOMERGE-SOURCE: CL 6868479 via CL 6868482 via CL 6868488 via CL 6868976 via CL 6870366
#ROBOMERGE-BOT: (v366-6836689)
[CL 6870484 by christopher moritz in Main branch]
Also, made sure we release the faultu dtNavMesh instance if we're not going to use it.
#jira UE-71027
#review-6676106 @Yoan.StAmant
#rb Yoan.StAmant
[CL 6676722 by Mieszko Zielinski in Dev-Framework branch]
The bug resulted from us using a strange extent ({Radius,Radius,Radius}) when projecting the initial location to navmesh. I've used a lot more reasonable DefaultQueryExtent for this purpose with Z being set to BIG_NUMBER. When a big Radius value was used the underlying recast code was expected to query a lot of polygons, but there's a hard limit of 128 polygons to process in multiple places in Recast lib (for performance reasons). These two facts combined resulted in finding awkward query starting point when using large Radius. The new approach first projects the query origin 'down' taking advantage of the assumption that the querier location is (more or less) on navmesh, since the whole query is about reachable locations.
#jira UE-66058
#review-6665296 @Yoan.StAmant
#rb Yoan.StAmant
[CL 6674755 by Mieszko Zielinski in Dev-Framework branch]
