Classic Battlefield Modding Wikia

This is a deep dive into the Navmesh process.

First A quick overview of what happens behind the scenes.

The Navmesh process involves using the BF2 editor and the navmesh.exe.

DICE generously provided the Navmesh.exe code n C++. It is located in navesh\navmesh SDK. It uses the opensource GTS (GNU Triangulated surface library) which is a free graphic code library that is used to create the navmesh files. This library in the GTS 3d model format. The BF2 editor takes care of creating GTS versions of all the objects and heightmaps used on the map. This how and why the GTSdata is created. There are also routines used that convert the GTS data to obj format. As far as I can tell this is only for debugging purposes as it appears that everything is done in GTS data format and then converted to obj file format to be verified and edited.

Also, I can tell from looking at the code, that the navmesh generator was designed to work with MAYA. So any strangeness in the obj files generated is due to Maya format choices. One example is the navmesh islands that the navmesh generator creates use custom reference for ground material in the obj file instead of the standard reference of:

g ground usemtl ground

This is even though it uses the same material file all the time. 

Navmesh.exe command line options 

-dir [(target directory)]

-cmd [manifold (manifold step)]

-cmd [stitch (stitch step)

-cmd [opt (Optimize Step)]

-cmd [export (fix navmesh step)]

-cmd [tesselate] ???

-cmd [testObjects]  ???

-cmd [logIslands]  ???

-cmd [gts2Obj]  convert gts format to obj

-in [(input file, either the infantry or the vehicle obj file)]

-out [(output file)

-mode [vehicle, infantry]  used with optimize 

The create navmesh process (This is after the GTSdata is created in the editor) is actually three steps that can be run separately. So, if Windows restarts in the middle, it is possible to restart one of the steps, but the steps can not be skipped. I have done some testing and am able to restart the process from a previous step. The three steps are as follows:   

Step 1 - create Manifold; 

Step 2 - Stitch. This is where the preopt is created

Step 3 - Optimize. This generates the infantry and vehicle obj navmesh files. This is the most time consuming step and most likely where the navmesh would need to be restarted in case the process is interrupted.

After this is to check that the Navmesh obj file is only one mesh and do any manual navmesh editing, then run Fixnamesh and finally restart the editor and convert the Navmesh into the AIpathfinding files used by the game engine.

Now, both the create navmesh and the fix Navmesh routines all uses the same navmesh.exe program to do all the navmesh creating and editing, just with different options. Here is run down:

create navmesh command lines:

(manifold step)

navmesh.exe -dir \work\[level name]\GTSData -cmd manifold

(preopt/stitch step)

navmesh.exe -dir \work\[level name]\GTSData -cmd stitch

(Optimize Step)

navmesh.exe -dir \work\[level name]\GTSData -cmd opt -mode infantry

navmesh.exe -dir \work\[level name]\GTSData -cmd opt -mode vehicle

Fix navmesh command lines:

(This creates the Cluster [CTI] and Quadree [QTI] files that are used by the editor to create the AIpathfinding files.. There are .txt versions of the files that can be read by a text editor,since the others can't. Dice has provided no explanation of how to read them, so the .txt files were for DICE use.)

navmesh.exe -dir \work\[level name]\GTSData -cmd export -mode infantry -in infantry_fix.obj

navmesh.exe -dir \work\[level name]\GTSData -cmd export -mode vehicle -in vehicle_fix.obj

One thing I did notice is that the Fix Navmesh routine does not send the output to the log file, but uses the screen instead. I have not figured out why yet.

I also found some examples listed in the code of different navmesh options:

navmesh.exe -dir work\dalian\gtsdata -cmd testObjects

navmesh.exe -dir work\dalian\gtsdata -cmd gts2obj -in meshes\ladderBB00001.gts -out debug\ladders\ladderBB00001.obj

navmesh.exe -dir work\dalian\gtsdata -cmd tesselate -in debug\toBeTesselated.obj -out debug\tessewlated.obj

navmesh.exe -dir work\dalian\gtsdata -cmd logIslands -in output\infantry.obj -mode infantry

I think testobj option will test all the map's objects and list any issues with them. This appears to be what we see in the navmesh log file.

gtsobj option appears to convert gts files to obj.

tessalate - bridges, the walkable/destructible area of bridges is tessellated

logislands - also not sure of what this can be used for as well.

I found this tip from Joker:

Well, we created all .obj files and we're need a non-tesselated ground mesh. It's simple by using navmesh.exe Something like that:

navmesh.exe -dir work\operationroadrage\gtsdata -cmd gts2obj -in meshes\ground.gts -out output\ground.obj

Another thing is the in the \GTSdata\meshes folder the config.dat file has this info:

MaxSlopeInfantry: 0.698132

MaxSlopeVehicle: 0.488692
RadiusInfantry: 0.25
RadiusVehicle: 2.1
HeadClearanceInfantry: 1.9
HeadClearanceVehicle: 7
MaxWaterDepth: 0.7
WaterLevel: 12.8
Infantry_NumberOfKeyPoints: XX
... listing of coordinates
Vehicle_NumberOfKeyPoints: XX
... listing of coordinates
NumberOfMeshes: XX
...list of object00000X files with their corresponding object file name
NumberOfDestructableMeshes: X
.. list of destructable Meshes
NumberOfWaterMeshes: 0
... list of water meshes
NumberOfLadders: 20

... list of ladder objects

So it would appear that the destructable objects are tracked separately for navmesh purposes. It would also appear that these settings are taken from the map- mostly from the map's AI.con file. The slope settings are converted to another format other than degrees - possibly radians (0.698132 is equal to 40 degrees, which is the standard infantry slope setting) . The keypoints appear to correspond to the spawn points, but for infantry the height appears to be +1.25, which appears to be constant bump for only infantry. Vehicle key points match up to vehicle spawn points exactly.

As far as ladders go, it appears that the navmesh generator was originally designed to handle it, but later changed to ignore it. The obj files never have any faces actually defined in the ladder material section. 

I also noticed that keypoints effect the navmesh differently from adding extra statics.

Keypoints are from spawn points and help ensure that areas covered by the keypoints are included in the navmesh. Extra statics will prevent areas from getting over optimized and also help to ensure that areas are included in the navmesh. There are times when a building that has a working Aimesh would not get included in the navmesh until after I added some extra statics alone one of the connecting paths to the building.

Keypoints are associated with the infantry and vehicle spawners. The navmesh generator uses those points to help it decided if it should include an area in the navmesh. If there are no keypoints in small areas, those could be optimzed out of the navmesh. They don't prevent an area from becoming over optimzed, but they will help to make sure areas are included in the navmesh. This is an important navmeshing tip, because I have not seen it discussed much elsewhere. Someone thought it might related to the spawnpoint naming convention, but I have not seen that being an issue.

Based on that information, there are some valuable take-aways:

- It can help a navmesh to add vehicle and infantry spawnpoints to areas\pathways of the map that you want to make sure get navmeshed. - Make sure to include the vehicles in the editor setup files so that the editor is able to load them. In the past, I would only load the statics and not worry about the vehicles. - Replace the vehicles that have editor problems with stand-ins. I added a feature specifically for this purpose to my navmeshing tool. I thought it would make it easier to use the editor with problem mods, but now I realize that is is very helpful to also setup vehicle keypoints.

I figured out some key things that can cause the editor to crash:

1. Crashing while creating the Aipathfinding files (load GTsdata/Save quadtrees) -- bad vehicle spawns. This frequently happens with BF2142. Replacing with BF2 vehicles seems to fix the problem. 

2. CPs numbers skipping a number. They don't have to be numbered in sequence, but if there are 8 CPs they should be numbered 1 through 8, with no missing numbers in between. This will cause a crash in the editor when you go to turn in the pathmaps but have to turn on the AI first.

Also, along with this, the CPs number have to match up with the strategic area numbers. So, if you change one, you need to change the other. What will happen is that the editor will crash when loading. I run into this occasionally when changing to work on a different GPO level and forgetting to delete the old strategic area file.

Flagpoles are also necessary. The editor will also crash if you enable AI prior to displaying the infantry or vehicle navmesh

Other useful tips:


The navmesh pathing will only go a short distance without an exit. Long paths will optimize out of the navmesh if it doesn't connect to the main navmesh on the opposite end. For instance multistory buildings will usually navmesh to the second floor with a proper AImesh setup, but may not reach the roof if the roof does not connect to another building that is also pathed. A lot of times I was thinking that the AImesh was not working or that the pathing was too complicated, when the AImesh was fine it was just that long dead ends tend to not navmesh completely. But if a path was created by adding a gangplank or other platform to connect to buidlings with AImeshes that both have access to the roofline, then the navmesh should complete the connection. So, one trick would be add a ramp, plank or stairs to make a connection to that dead end path. Then you can include it in the map or leave it out of the original map and, after navmeshing, hand edit the navmesh to break the connection so the bots don't try follow it and commit suicide. This way the bots would still be able to be spawned on the roof and take the stairs down.


I have found out that although the BF2 editor checks for BF2 to be installed in order to the installer to work, and it uses some of the BF2 files, it does not check the registry in order to run. Therefore I was able to copy the BF2 game files and the editor files to another folder on another drive and use the editor on another system that did not have the BF2 game or the Editor actually installed. This is useful for when the I need to reinstall BF2 or the Operating System or even to use the editor on a old system that does not have a graphics card that can handle BF2.


I have found that I can generate several navmeshes at the same time, but only "Fix" one Navmesh at a time. I don't even see a significant slow down in navmesh time.


broken data - This is just a generic message that could mean several different things. Look at the down in the navmesh.log to see if there are more detailed error messages. By itself, it may not have to be fixed. 

Object is not a closed mesh - This is a critical error message that unless fixed, will navmesh with the boundbox of the object. This is should easy to find with an STL check on the object in 3ds Max or other modeling tool.

Object is not orientable - Also critical. I believe this means that the object has a reversed face (Normal). In 3ds Max try edit Normals, select all and then Unify. Then try exporting.

didn't intersect with ground - Another Critical. The object's AImesh does not intersect with the map's heightmap or another object. Load up the map in the editor, and look at the pathmap, then find where the object is not navmeshing. Turn on Aimesh view and see if you can adjust the object so it will intersect the ground. I have started adding small ramps to AImeshes to the entry way for objects where I see this a lot to help with this problem. For bridge segments, I will add a small lip the ends so that the Aimeshes will overlap and make a good connection.

not OK to expand - This does not always mean that there is a problem. If there is a problem with the navmesh, then I will try to simplify the AImesh, which usually fixes this issue. I don't actually understand what this error message means.

Self Intersecting - Critical as well. For this error you can look in the navmesh\work\[mapname]\gtsdata\debug\self_intersecting_objects\ folder for the obj versions of the objects with the problem. There will be two files. One will show the the intersecting faces and the other will show the full obj version. You can import these into most 3d modelling tools to see where the problem is in the object.

If your having problems with an AImesh and can't figure it out if can be useful to look at the obj version to make sure it looks like what you are expecting:



I have found that redoing the combat area, sometimes to expand it somewhat, and re-creating the Navmesh will resolve this most of the time. Sometimes there may be multiple combat areas listed in the GPO in the map's editor folder. Delete all and recreate is the best option. The combat area also can be too small. If you have already tried redoing the combat area, try expanding it. Of course don't forget that the combat area has to be created counter clockwise, closed, and use AIPathfinding must be checked. Save and then generate pathfinding again.