How many agents are being used in "Busy street crossing"?

[rob-myers]

https://sketches.isaacmason.com/sketch/recast-navigation/busy-street-crossing
https://github.com/isaac-mason/sketches/blob/main/src/sketches/recast-navigation/busy-street-crossing/index.sketch.tsx

It wasn't obvious to me where you specify the number of agents.

Is it consistent with this circa 2015 post claiming "more than 5ms for 30 agents on a mobile"?

[isaac-mason]

Hey! There are 200 agents in that sketch: https://github.com/isaac-mason/sketches/blob/main/src/sketches/recast-navigation/busy-street-crossing/index.sketch.tsx#L84

I haven't done much thorough profiling, but from a quick check on chome devtools just now, crowd updates are taking ~0.5-1ms in that sketch.

I should note though that the crowd agent avoidance does break down with many nearby agents. Detour by default only considers up to 6 other agents for steering decisions: https://github.com/isaac-mason/recastnavigation/blob/599fd0f023181c0a484df2a18cf1d75a3553852e/DetourCrowd/Include/DetourCrowd.h#L32

[isaac-mason]

The simplicity of that environment might be contributing to the quick update time, but we'd need to do some more testing and profiling to know.

[rob-myers]

Thanks, seems the 200 should have been obvious 🤦‍♂️ .
Yeah it's a very simple setup, but it's an order of magnitude better than what various vague StackOverflow posts suggest.

In other news, I will soon begin work on the dynamic navmesh story. I need it as part of upcoming website, and got a bit distracted building some walk cycles in Blender.

[isaac-mason]

All good! The entity component system library in that sketch does add a barrier to following the logic, which makes it a bad library example and is why I haven't copied it over here.

It's a similar story for the dynamic navmesh sketch. So creating a minimal example here is super useful 🙂 if you are happy to do that it'd be much appreciated!