runtime navmesh rebaking — how are you handling dynamic geometry changes without hitching?

working on a game with destructible environments and the navmesh situation is slowly breaking me. every time a wall collapses or a door gets blown open, agents need to know about it, but rebaking the whole navmesh causes a noticeable hitch even on relatively small maps. players absolutely notice.

been looking at a few approaches:

• tile-based incremental rebaking — Unity's NavMesh Surface component lets you rebake individual tiles, which helps, but figuring out which tiles are actually dirty based on the changed geometry is its own problem. I'm doing AABB overlap checks right now which feels fragile.
• NavMesh Obstacle components — fine for simple stuff (doors, pushable crates) but they just carve through the mesh, they don't reshape it. useless once you have irregular rubble geometry.
• Recast + Detour directly — been eyeing integrating the library directly for proper tile streaming control. the API seems like the right move but the documentation is genuinely sparse and most usage examples I can find are years old.

current hack: I'm queueing rebuild requests, throttling to one per second, and briefly suspending pathfinding queries during the bake. agents freeze for a frame or two. it's ugly.

also tried async rebaking off the main thread and Unity's navmesh baking touches main-thread state in completely undocumented ways. great afternoon, 0/10.

is anyone handling actual topology changes cleanly at runtime, not just obstacle avoidance? what's your setup?