Replies: 1 comment · 3 replies
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, seems the 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. |
Beta Was this translation helpful? Give feedback.
-
|
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! |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
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"?
Beta Was this translation helpful? Give feedback.
All reactions