Some more Recast notes:
My characters use capsules with radius = 4.0 and total height = 15.0. After some tweakings I got the best results with those build parameters.
The cable holes on the ground are gone. But they did not disappear when changing the “walkable climb” value. They disappeared when changing the “cell height” from 0.2 to 0.7.
EDIT: the next paragraph is BS, see the comments.
On the other hand I still have troubles with cable holes in the small “command center”, somewhere else in that level. The nav mesh here would look very reasonable without that big hole in the middle. I didn’t manage to get rid of it. Admittedly the UI does not expose all parameters yet (like “max edge length”) and maybe playing with that one will do the trick.
I see troubles with the “walkable radius” otherwise. Even though I use the actual radius from my character’s capsule, the nav mesh misses some connections, areas that can definitely be crossed by the player. Reducing the “walkable radius” helps a bit but not much, since it’s quantized to an integer value internally. So I decrease the value a bit in the UI, nothing changes, repeat that a few times, until suddenly a big change happens because the internal code clamped the float to the next integer. Would be cool to be able to fine-tune this better.
Admittedly that mesh is not very friendly with all those narrow passages. But hey, real-world meshes tend to be painful to library developers - tell me about it!
To be continued, I will post more results after exposing the last build params to the UI.
EDIT: done! Tweaking the remaining params did not significantly change the results.
August 20th, 2009 at 7:16 am
Are you sure you are using cell height ‘ch’ when converting the climb value to voxels? That could explain why changing cell height makes the cables work.
The command center mesh looks ok. The mesh does not comply the input geometry height completely (I’m currently working on this to make it better), so the larger middle polygon just goes inside the underlying mesh.
The actual calculations done with the radius are done with the raster data, that’s the reason it feels like the value is clamped. Calculating the Minkowski sum that way is thousand times more robust and easier, but the downside is that it is not as accurate.
You could try to reduce the voxels size ‘cs’. This will allow greater accuracy with the expense of longer build time. But in general, having the AI to work robust in those tiny corridors is going to be huge pain in the ass (unless you allow them to walk through each other).
If my game would require such narrow passages (usually doorways have same problems), I would add special kind of navigation link and extra special code which can handle multiple people using that same passage at the same time, sort of like traffic lights. Special links are on my todo list too (http://digestingduck.blogspot.com/2009/07/recast-and-detour-roadmap.html)
August 20th, 2009 at 8:18 am
>Are you sure you are using cell height ‘ch’ when converting the
>climb value to voxels?
Yes.
>That could explain why changing cell height makes the cables work.
Indeed! Makes sense.
>The command center mesh looks ok. The mesh does not comply
>the input geometry height completely (I’m currently working on this
>to make it better), so the larger middle polygon just goes inside the
>underlying mesh.
You’re right, my mistake. I thought it was a hole like in the other case but it’s actually completely fine
>You could try to reduce the voxels size ‘cs’. This will allow greater
>accuracy with the expense of longer build time.
I just tried. This improves things in certain areas, but in others the problem does not go away (even after reducing ‘cs’ to 0.25, which produced very long build times and increased the amount of memory needed from ~20K to ~190K).
>But in general, having the AI to work robust in those tiny corridors
>is going to be huge pain in the ass (unless you allow them to walk
>through each other).
I agree that having multiple NPCs going through narrow corridors is tedious and usually requires extra code. But here even a single NPC would have troubles, since the nav mesh just doesn’t cover the corridor. So I’d say it’s a different problem.
I might just change the mesh a bit, or accept that the NPCs won’t follow the player there. It’s not really mandatory or anything in the game. That being said, as a library developer you might want to put that issue on your TODO list