Thanks Mieszko, but I figured I’d come back here as email may not be the best way to reach you.
Right now I’m trying to identify where the streamed nav mesh data is loaded, and then more importantly, where it is discarded.
To lay out my testing case:
GlobalPersistentLevel is our level that loads into the menu and then loads sub-levels for gameplay. All sublevels brought in this way have Static(statically generated) NavMesh data, and none are set to Dynamic/Create on Load. They are, however, all occupying the same world locations as each other sublevel (and the GlobalPersistentLevel) and are not world-contiguous a la WorldComposition. After loading through our menu system, we see no NavMeshes and I can’t find the code that dumps them anywhere in the streaming load/serializing code in the engine.
If we load one of the sublevels in Editor and then do PIE, the NavMeshes remain intact, and the code path is similar but not quite the same as when loading a sublevel from our UI.
The theory is that these sublevels are having their nav data dumped because during the load process a bounds check is done and it’s determined that none of the sublevels have valid nav data in the locations that the engine cares about.
The proposed fix is to retain the nav mesh data by providing bounds to encompass the sublevels in our GlobalPersistentLevel, and to modify the engine code so that sublevel tile data for the nav mesh gets brought in piecemeal into the GlobalPersistentLevel’s nav mesh actor.
For PIE I see the ARecastNavMesh being serialized in as part of object duplication for PIE, it then makes itself a FPImplRecastNavMesh and they cross-associate to each other by sharing their pointers. In PImplRecastNavMesh’s Serialize() function, the underlying DetourNavMesh is created and then serialized in. The Serialization functions get hit repeatedly for reference counting and loading and saving, which makes for a difficult to trace code path when trying to determine who, after the valid DetourNavMesh has been loaded, it gets dumped again (or just not added to the world.)
So my more direct questions are these:
- Where does the code determine whether or not the serialized-in valid pre-generated static nav mesh data can be discarded?
- Is this done against bounds in the local level or in the persistent?
- Where is the data dumped?
- When ULevels are being brought into the world, and the Archive flag shows that it contains a map, is that enough information to identify nav mesh data coming from that archive’s serialize call chain?
With some of this information and the ability to step through and see it, I’ll be ready to ask you even more specific questions. I’m deeper in the bowels of the engine than I’ve been before, and the garbage collection and serialization system are making it hard for me to set clever breakpoints to catch the engine in the act. I’m having to do a lot of engine mods with logging and parse log files. Any better grounding you can supply me would be a big win.
Thanks for help with this,
Steve