Recast / Detour

[Neoptolemus]

Ok, it looks like the issue is to do with the bot's movement while on the ladder. I've put in some special case code for ladders so that the bot always moves directly towards/away from the ladder depending on whether they're climbing or descending, and the bot always tries to face more or less directly towards or away from the ladder.

Now it can climb and descend just fine Good stuff.

There are some tricky cases I need to look at where the navmesh gets confused as to where the top or bottom of a ladder is. For example, in cs_backalley there is a fire escape ladder, and the bottom of the ladder is placed perfectly, but the bot thinks the top of the ladder is INSIDE the room (i.e. on the wrong side of the wall), causing it to get stuck.

There may also be some issues with bots trying to climb the wrong side of a ladder (though I've not observed this yet)

[The Storm]

Any new progress? Btw check out RACC bot about navmesh and ladders, I think PMB have done it there.

[Neoptolemus]

Hi Storm,

I've had a little break as I've been focusing on some work-related stuff for a big show-and-tell at my company's next innovation gathering. I did do some digging around in the recast/detour libraries to see if I could get the bots to jump down from ledges, but all I did was end up creating horrible mutated versions of the navmesh

The recast/detour library is actually pretty limiting. Any kind of movement that has to ignore the navmesh, like jumping, teleporting, dropping off ledges, swimming and ladder climbing must be handled via "off-mesh connections", which are just two points in space that the bot knows it can move between. Thing is, if you've got a long ledge that you can drop off like in cs_assault, how do you handle something like that? Just stick dozens of off-mesh connections all along the ledge? Must be a better way.

This lead me to take a look at Quake 3's Area Awareness System. The Quake 3 bots from what I could remember were capable of doing some impressive stuff, including running off ledges, jumping gaps, swimming through tunnels, navigate moving platforms, and even rocket jumping onto hard-to-reach areas. I'm wondering if I can incorporate any of the techniques it uses to create better dynamic path generation.

I'm thinking something like the bot being able to intuit shortcuts (such as dropping off the ledge rather than going down the stairs) on-the-fly somehow. Many of the AAS principles (walkable areas especially) share a lot in common with a navmesh. Need to think about it some more when I have time.

[The Storm]

Well some bots when are "in combat" mode, use shortcuts to hide or get better view faster even if it takes some damage to them. This mode does not use waypoints or navmesh. They just trace lines around them to check the environment and make decisions on the fly. When the hot situation is gone they return to their usual navigation.

[Neoptolemus]

The navmesh is broken up into tiles which can be removed and inserted as necessary (for level streaming for example, or dynamic obstacles), so what I'm thinking is I could probably try and do a reachability test between tiles during navmesh generation, and if two meshes can be reached then create a connection between them.

Just need to figure out a reliable reachability test...

[The Storm]

Even if you make the best tests about reachability there will be always places that will need manual placement. Even the official CSbot have navmesh editor to place additional connections by the user when needed. There is even packs with .nav files around the net.

So don't be very disappointed if you cannot create the best pre-play automatic creation.

Note: You can do like the JKBotti does. Create connections dynamically based on the regular players that are currently playing the map. In this way when they go to hard to reach places you will save their movement points and after that the bots will be able to use them.

[Neoptolemus]

Yeah I'm not expecting to be able to create the perfect bot, but I want to get close

One of the biggest challenges is the fact that a navmesh "wall" is simply the edge of the navmesh. There is no way to tell if there is any actual level geometry in the way, or if it's just a ledge that the bot could feasibly walk off.

I think my first port of call will be to stop the recast library from eroding edges, so that bots can walk right on the very edge of walkable areas if necessary, and also to prevent it discarding walkable spots it deems as being too small. This should help a little, in so far that it no longer erects a barrier along the edges of a ledge.

[The Storm]

Yes, the navmesh cannot tell you if there is wall on the edge but the game engine can. Walking the bot must be combined algorithm with navmesh and game engine check routines.

[Immortal_BLG]

Hello Neoptolemus!
Look at THIS link, here Mikko make annotations builder for recast, combine it with some HL related changes and trace line checks will allow to create jump connections and maybe more...

BTW:
As for AAS, Quake3 uses a modified (more informative) BSP format, by which the creation of AAS became possible.
We do not even have the opportunity to realize the normal TraceHull function with custom hull size or even TraceLine, that will hit clip nodes...

Sorry for bad English...

[Neoptolemus]

Hi Immortal_BLG,

Thanks for the link, I'll take a look when I can. Had to have a bit of a break due to personal matters, but hopefully will pick this back up again soon!