Monday, July 20, 2009

Recast and Detour Roadmap

While preparing for 1.31 release, I just noticed that I have not updated my road map for a while.

The 1.3 release proved to me that the tile based method will be my choice of dynamic navigation meshes. It allows wide range if different ways to locally adjust the mesh, either by completely rebuilding it, or maybe even just partially cutting holes to it.

It looks like it is possible to speed up the per tile creation process so that the completely dynamic approach will be feasible. The future Recast and Detour process will be aligned towards that. I will probably experiment with the cookie cutter method at some point.


The next push with Recast will be to add more functionality which is required for a game. The first two items on my todo list are currently: jump links and area annotations.

As the name implies jump links allow off mesh navigation links, just as jumping down from a ledge or climbing ladders. My plan is port the tile navmesh link structure to the static mesh too and extend it to allow user specified extra links. At first the links will need to generated manually but I have a couple of ideas how they could be created automatically too. Any ideas regarding that are welcome! Especially how would you like to define the jump trajectory, how they should be places, etc.

Area annotations are first painted into the voxelized walkable surface and are carried over to the final navigation mesh. The annotations may come from some filters, such as dividing the walkable space in to areas based on the height of the agent. Another source of annotation could come from the level designers, they could mark certain areas as spawn areas, or hazard locations or places where the agent cannot stop, etc. That's very important stuff to get your gameplay done. And will be very challenging to get the API for the queries to work with all the new possibilities.

Continuing the gameplay track, I might provide some sample code how to embed extra data per polygon such as cover points.

I have also received a lot of feedback that the navigation mesh does not conform the underlying surface. I have toyed around with some ideas and it looks like the best solution is to create an optional filter which will tesselate the navigation mesh to conform the heightfield where there is a lot of height variance. This will come with the cost of extra polygons, but I think it certain situations it will be really useful.


That is the near future. In longer run I want to create path following code to Detour as an additional layer of code which uses the services from the navigation mesh code. It would show how to handle multiple agents and dynamic obstacles moving in the game.

I also want to expand the tile navigation mesh demo to contain more dynamic environment. That might spin off another layer of code which could be a good starting point for implementing destruction and physics based layer which controls the tiled navmesh.

In order to make the fully dynamic navigation possible I want to take a look at the whole Recast library and see if I can cut some corners when dealing with small tile sizes. It looks like there is a lot of room for optimization there. I have been brainstorming with even different kind of space partitioning and rasterization which should be both simpler and take less memory. I will work on this item along while pushing the gameplay features further.

1 comment:

  1. This roadmap sounds perfect! All my concerns are addressed. I'm particularly glad to see that the mesh conforming to the heightfield is on your radar.

    ReplyDelete