I don’t think I’ve made a complete example of that.
Using the physics behavior with the path finding behavior kind of solves that. But it can be janky because the two behaviors fight with how the objects move. It’s slightly improved by setting the physics velocities to 0 every frame, but the behaviors are still at odds.
To remove the fight you’d ideally just use the physics behavior to move, and not use the pathfinder for movement, although you would use it for finding the path. Basically you’d set the velocity to velocity+(targetVelocity-velocity)/10. Where target velocity is the velocity you’d want to go toward the next waypoint on the path. The /10 is to make it smoother, but isn’t frame rate independent as is. Then you’d just need to check if a waypoint was hit or no so it would move on the the next waypoint.
The main issues here are not being able to reach a waypoint so it could cause things to get stuck.
There is also a technique called steering behaviors (not actual C3 behaviors) or boids that I think could be useful here. The math above is basically steering, it changes the velocity till it’s facing a certain direction and velocity. Basically you’d find the paths, or since it’s many objects to one spot you could use dijkstra's algorithm to get kind of a flow field. Then you’d steer the enemies to move along the path, away from each other and walls, and in the average direction the enemies around them are going. A last step would be the physics to keep things from overlapping as a last ditch effort. Lighter than the physics behavior is one technique called verlet physics which has the benefit of inferring velocity from the previous position which could be useful here.
To handle a high volume of objects using some kind of grid spacial partitioning would reduce the number of collision checks.
In theory the enemy’s would the flow around the terrain while not overlapping each other.
Anyways that’s just few rough ideas. Might attempt it later and see how much simpler an actual example would be.