View Full Version : [Single-Player] 'Navmeshing' explained

2009-10-09, 16:48
By now you probably have seen this thread about navmeshing (https://www.realitymod.com/forum/f196-pr-highlights/64877-prsp-what-hell-navmeshing.html), at least while searching for some cooler highlight to revive out of the archives.

creepin does explain it crudely, but there's a lot left out. Since v0.9 will feature SP integration, I've decided to write up a highlight explaining the whole process with screenshots supplied from my latest navmesh project on Battle for Qinling, which I've already meshed for PR SP 0.87, but decided to redo it. For others who also do navmeshing, I wrote up how I do it, some may have their own ways of doing this.

Map preparation

As said, the map in question here will be Qinling.
I start out by extracting the map files, making the init.con 'read only' as Editor overwrites it and backing up staticobjects.con file, then open the map in BF2 Editor.

I create a new layer for Co-Operative mode and start by selecting an appropriate area and draw the combat zone around it, which will mark the borders of the navmesh.

Normally we at PR SP try to incorporate most of the main play areas and leave the other uninteresting parts for humans to wander around as there is a size and performance limit to navmeshes.
For Qinling I've decided to use only the area encompassing the farm, village, PLA FOB and the coal mine. Key thing to note is that air assets do not need navmeshes to work, so the runways and helipads can be left outside the mesh, which will be the case here, while the rest of the ground forces will start at the farm and FOB.

Another issue with navmeshing is that the navmesh uses static objects to 'snap' to and mostly ignores the terrain. BF2 tolerates a small height difference between the ground/objects and the navmesh, however if the difference is too big, bots will simply die off on that spot, which is not good.
This is a very big issue on large open maps such as Qinling. Overgrowth trees do aid this, as they dot the terrain connecting the navmesh, however this doesn't always help. In this case I pick any random static object with a collision and then dot it around key areas where bots will travel to make sure the navmesh sticks to it, this time I used the gas station containers. :P


I mentioned before that navmeshes come with a size limit. The limit is "measured" in the number of boundary or border edges (for easier understanding). The maximum limit seems to be around 100 000 edges, but we normally stick to 80 000, though that doesn't mean all maps have meshes that big ;).
Meshes bigger than that can be generated, but the game will crash if you try to run the map, so it needs to be trimmed down.
Navmesh will avoid pretty much every object that has a collision and a hole in the mesh will appear there instead. All navmesh edges that neighbor the hole count as border edges, so the higher the object count, the higher the edge number, which is the reason why we can't navmesh dense forest maps like Kozelsk or Fools Road in one piece, as there's too many trees that cause high border edge count.

Most of the PR's static objects were not made with SP in mind and are missing the col3, which determines where the object will be navmeshed, so we got around this issue by using [R-DEV]ballard's navmesh statics, which are basically crude clones of the existing objects, but with a col3.


Once I'm done, I load up the Single Player Editor plugin and select the Generate PathFinding button, which exports all the info needed to generate a navmesh.


A new folder appears with all that info inside the map's directory


Generating the navmesh

The GTSData folder you just saw is copied to Battlefield 2/Navmesh/work/[map name].
The navmesh is generated by a program called Navmesh (who would have thought) which comes with the BF2 Editor install.
The program opens in a CMD window and asks you to write down the mod name and map name, after which it force runs BFEditor and grabs some relevant info and then starts processing the data.


The whole process needs about 200 Mb of RAM, but eats up to half the CPU power and depending on mesh size and PC specs can take several days.
The main process is pretty fast, but after it comes a process where the boundary edges are expanded (don't ask wtf is that all about) which is the part that takes the longest.
The generation of this navmesh took about 22 hours.
During that the process is of course logged and has it's own little lolz displayed here and there. :D


Editing the navmesh - see creepin's thread

Normally when the generation is done, the navmesh should come out perfectly in one piece as the game only accepts one navmesh, however for most of us doing this stuff (not just PR, all other mods with SP support, too!) this is not the case, as the navmesh process creates lots and lots of little 'islands', which are isolated pieces of mesh.
This bug goes to such distances as a mesh islands being generated on tree tops and so forth, really hilarious sometimes :p

The navmesh is a 3D object and can be edited in Maya or 3ds Max, but I use Maya because it's easier to learn than the super-pro-complicated 3ds Max.

The edit mostly just includes deleting the mesh islands and fixing, removing or adding any other parts of the mesh, trimming down the mesh is also done here if needed, then reexporting the mesh back in one piece.

Map edit

After the navmesh is read to go, I go back and start adding control points, spawns vehicles and such, play test the map and then release beta versions for others to check out. One last major thing I have to do is adding strategic areas, these are zones added on top of control points and then connected to direct the bots where to attack.
Another optional thing is to add waypoints for bots, normally they find their way from CP to CP, but if you want them to be sneaky you can show them alternate routes using waypoints. :D

That is pretty much it, there are a lot of details not mentioned, because I didn't want this to turn into a tutorial, if you're interested in navmeshing, check out this awesome tutorial I and many others used to learn the whole thing (or if you're just curious) :D

I would also like to thank [R-DEV]ballard, [R-DEV]Hans Martin Slayer and [R-CON]creepin for their support and everyone who helped me out at bfeditor.org

Hans Martin Slayer
2009-10-09, 20:19
Good stuff mate. Just a coupla days ago i found editor pics i made back when i tried to navmesh Qinling. Nope, we didn't have those fancy nav statics back then. :-P



2009-10-09, 21:19
Oh man I could never have the patience to do that. :D Good stuff guys!

2009-10-09, 23:04
Ahh thats looks like a lot of fun. If you need any new people to nav mesh i would love to give this a crack. Nice explanation Outlawz :)

2009-10-10, 00:02
So much information....ungh

2009-10-10, 00:37
i think i will continue mapping and let navmeshing to the real experts :)

2009-10-10, 12:16
Navmeshing messing whit my head O_O