Manually navmeshing from the editor? Options

[Dnamro]

I remember reading a post where someone had mentioned that they generate navmeshes from the editor manually, but they did not explain how. Can someone explain how?

[clivewil]

i realise this isn't quite what you were asking D, but it might prove helpful info at some point anyway...

i generate mine manually from a cmd window; but first copy an existing ai folder to your map, and then the editor is used for is the command sequence - aiPathfinding > ExportGTSmeshes which will put a Meshes folder inside MapName/GTSdata - this meshes folder needs to be moved to \NavMesh\Work\MapName\GTSdata\ before you can launch the navmesh generator - (and while you're inside the editor still, make sure you have UsedByPathFinding checked for the combat area you want to use as the boundary for your navmesh)

after that's done and IF it was done correctly (if not, check the combat area hasn't become inverted or doubled-up) you can then launch CreateNavmesh.bat in the cmd window, first making sure that /navmesh/ is your current directory

(at this point, the navgen will attempt to open the editor, load the map, export the gts meshes, and copy them over to the work folder. it often CTD's at this point, which is why i learnt to do it manually. if it crashes, the navgen will continue because it has everything it needs already. - my scripts have the editor lines removed, for two advantages: i don't have to wait for the above CTD-prone process to finish, and i can also modify - import - examine, modify - import - examine etc. on changes to my navmesh without having to open and close the ed every time)

the navgen asks for the name of the mod, then the name of the map, and then runs, hopefully to completion. the Output folder is copied to the map's own GTSData folder at the end.

final step is aiPathFinding > LoadGTSData > SaveQuadTrees, and AI > createHeightMap

as far as i know, it's not possible to gen navmeshes 'manually' from the editor - the Generate Pathfinding function is pretty much automatic, when it does work

[Dnamro]

The occasional CTD problem when the editor launches is what was prompting my search. So I think your answer helpful. I think I was confused between the command window inside the editor (that doesn't appear to work) and the windows dos command window.

So, if the editor crashes while running the createnavmesh.bat, how do you know if you the editor did what it needed to do and its OK to continue?

What is the editor supposed to do when the createnavmesh.bat launches it?

How do you replace the editor process if you removed those lines from your script?


What about if the editor crashes during the fixnavmesh.bat process? How do you get around that?

[clivewil]

well the editor is initially only doing those steps i mentioned anyway - exporting gtsmeshes, and copying them to the navmesh work folder.

after the navmesh process is complete in the cmd window, then back to the editor again to load the gts data and save the quadtrees, also to create the heightmap

obviously bad navmesh data can still cause problems - usually during the LoadGTSData stage - but some maps are problematic even without a navmesh. Fushe Pass used to crash my editor because of the particle waterfall, for instance - so the manual navmesh method bypasses problems like that.

and also there's the aforementioned ability to make changes much much quicker than having to open the editor/load the map every time; you just keep the ed/map open in the background, edit your navmesh in max/maya, export it, run fixnavmesh, and then in the ed select LoadGTSData > hide the navmesh > show the navmesh > your new changes are shown in the editor. when you're happy with it, save out the quadtrees and heightmap as per usual

crashing on LoadGTSData or fixNavmesh is often due to either multiple islands, or two vertices occupying the same space (easily fixed by welding them or moving them apart, whichever is appropriate)

command window inside the editor (that doesn't appear to work)

you're using the small 3-paned command window with the green button to the right, yes?
you can't input commands via the large output window down the very bottom. thought i'd better mention that, just in case...

[Dnamro]

I think I see how you run a command from the editor now.

I went throught the scripts and came up with what seems to happen in each step and outlined the process in more detail:



Prepare map for navmesh generation
- Copy the AI folder from another map into the new map level
- Turn off any windows screen savers (it can crash the editor) and load up the editor.
- Check that the combat area is good with usedbypathfinding checked or that its the last line of the combat area code and only one combat area defined in the GPO.
- Make sure the map has at least two CPs and an overgrowth folder.
- switch to the single player plugin and click on place on all to create the Strategic areas.
(You don't keed to worry about neighbors at this point, and I do them by hand anyway).
- click on generate pathfinding to create the GTSDATA folder in the map level.
(If the editor generates an error message try redoing the combat area)
- Create a mapname folder in the navmesh\work directory and copy the GTSDATA folder from the map level



Create navmesh process


- Clean up Old data Aipathfinding and GTSdata\meshes from the map.
- Load up the map in the editor and run exportGTS
- copy the exported GTS files from the map into the navmesh work folder
- Generate a navmesh
- Create qtr files in the navmesh work folder
- Load up the editor and run saveQuadNoP4


The next step is to verify the infantry and vehicle navmesh files and run fixnavmesh
- Check the debug islands folder in the map level of the navmesh\work area. If more then one file is listed in the infantry and vehicle folders, then there are too many islands. The best way to fix that is to edit the infantry or vehicle obj files in the output folder. The only other option is to copy the largest files in the infantry and vehicle folders into the output folders and rename and infantry.obj and vehicle.obj.
- Fix navmesh makes a copy of the the infantry and vehicle obj files and runs the navmesh program on them.
- The last step is to load up the editor and run SaveQuadNoP4 again.

[Dnamro]

How do your run exportGTS from the editor?

[clivewil]

How do your run exportGTS from the editor?

in the 3-pane window, select: aiPathfinding > exportGTSMeshes > click green button and wait til it finishes

you must of course have the singlePlayer plugin loaded for any of those commands to be available in the window. i think it's in Tools > AddInManager. set it to autoload UNLESS you're planning to create envmaps often, in which case you're better off manually loading the plugin each time (the singleplayer plugin leaves lines of white numbers in any envmaps that are created while it's running)

[Dnamro]

Thanks. Found it. I did not understand how the drop downs work, or that a specific option in the first box had to be selected to get the exportGTSmeshes option to show up.

BTW, I was looking through the generateNavMesh python code and found that there is an option to convert the Qtr files from the editor without the NOP4. There is a comment that says P4 is Perforce. Any idea on what this means?

print "Converting to qtr-files"
conScript = "saveQuadNoP4"

if (useP4 == True):
conScript = "saveQuad"

runEditor(level, conScript)

print "Done..."
print ""

return True



p4 - If specified the editor will automatically submit the data to perforce

There is an optional argument that can be passed from the batch file to the python code script that would useP4, but currently its not being used.

[SatNav]

this would be a good thread to sticky,lots of info not commonly known.

[clivewil]

i saw those lines a while back but didn't pay them much mind as the navgen was still working properly - as far as i know, Perforce is just the version control system dice were using during development

unless you're getting some form of 'unable to locate master server' error messages, you probably won't gain much from disabling that part of the scripting - it seems to save fine locally as it is.

this would be a good thread to sticky

stickied.

[Dnamro]

Ok, the exportGTS updates all the files in the map name\GTSdata\meshes folder.

I don't understand, why we don't just exportGTS from within the editor right after you created them? Why get out of the editor just to have it load it up to do this one step? Or am I missing something?

Also, what is the point in running the createnavmesh.bat file just to type in the level and mod names and then launch the python code. It seems easier to me to just define the level and mod names in the python code and launch it directly. Especially since the mod name needs to be defined anyway.

I can't find the option to run saveQuadNoP4 from the editor. I see saveQuadtrees, but that doesn't seem to do anything at this point.


Now in the fixnavmesh.bat file, all that seems to do is to copy the files around and rename the infantry and vehicle obj files with _fix extensions. Then it runs the navmesh program on them. This step, sets up the Aipathfinding folder with some apparently dummy files.


I just remmed out the line to run the saveQuadLocal.bat and run the commands in the editor to LoadGTSdata and SaveQuadTrees. This step apparently creates the Aipathfinding files.

The last step is to run the ai.createheightmap 16 command from the editor. This add the aerialheightmap to the map's aipathfinding folder.

I was wondering if it made any difference if createheightmap used 32 or 64, but it did not seem to on the small combat area that I tested it. I will have to do some testing on some larger combat areas.

[clivewil]

why we don't just exportGTS from within the editor right after you created them? Why get out of the editor just to have it load it up to do this one step? Or am I missing something?

my method assumes you've altered your scripts so that they never open the editor. you manually export the gtsmeshes yourself, close the editor, then you never see it again until after navmesh generation when you're ready to save quadtrees/shift spawns around etc.

It seems easier to me to just define the level and mod names in the python code and launch it directly. Especially since the mod name needs to be defined anyway.

the mod name sure, because that never changes. map name, meh - i normally copy and paste that in anyway (right mouse button at the cmd cursor drops it in there) and after that i just use the key buffer during subsequent fixnavmesh operations - is just a case of pushing up, up, up, enter, down, enter... i can live with it

I can't find the option to run saveQuadNoP4 from the editor. I see saveQuadtrees, but that doesn't seem to do anything at this point.

if you're not saving quadtrees then you have a major problem. sure there's nothing in the levels\mapname\aipathfinding folder? if it doesn't write anything there, you usually get either an error message or more likely a ctd. did you remember to to go aiPathfinding > loadGTSData > green button first?

Now in the fixnavmesh.bat file, all that seems to do is to copy the files around and rename the infantry and vehicle obj files with _fix extensions. Then it runs the navmesh program on them. This step, sets up the Aipathfinding folder with some apparently dummy files.

it does a little more than create dummies; most importantly it calculates the clusters for the mesh you've just edited, replacing the old ones. it also strips out unnecessary crap; if a mesh object i have just exported from max is 6mb, often after the fixnavmesh process it is about 3 - 3.5mb - it is reduced down to purely vertex/face info and materials only.

I just remmed out the line to run the saveQuadLocal.bat and run the commands in the editor to LoadGTSdata and SaveQuadTrees. This step apparently creates the Aipathfinding files.

good move.

I was wondering if it made any difference if createheightmap used 32 or 64, but it did not seem to on the small combat area that I tested it. I will have to do some testing on some larger combat areas.

the higher the number, the more detailed the heightmap but also the longer to generate it. the most obvious indicator (for airhead me) was that the helicopters would fly lower and use the terrain's masking much more (but jets doing the same thing run the risk of colliding more than with a 16 .ahm)

from memory 64's are ok but 128 caused a beautifully detailed ahm to be written but with one major flaw - many of the statics were missing, i.e. the dalian carrier, some of daqing's chimneys, etc. which was a real shame as it was rather cool watching a UH-60 fly between daqing's oil cisterns without hitting any of them. when in doubt these days i just opt for a 32 to be safe. i would LOVE some way of editing an ahm directly but photoshop just destroys them. you can use it to view the ahm's contents however, with a bit of fiddling

[Dnamro]

Thanks for all the good info. I wasn't loading the GTS data in the editor before saving the quad trees during the createnavmesh process. But I was doing it correctly during the fixnavmesh process, where I could see something actually working.

Do the quad trees need to be saved before and after I edit the navmesh in maya/3dsmax? It looks like the scripts are set up to do it twice, but it appears that the quad tree saving only needs to be done after the navmesh is edited.

I can't tell you how much this helps working in 2142 or First Strike, because the editor crashes half the time during the normal navmesh process, but its working fine when I run the commands from the editor.

The way I have my scripts set up now is that createnavmesh.bat runs the generatenavmesh_local python script without any parameters and I just define the level and mod in the python script (I prefer it that way so that If it make a typo, I can easily fix and relaunch and I only have to set the mod and level in one place). All the script commands to launch the editor automatically are removed. I put a pause command at the the end of the bat file, so the command window will stay open after the process is completed until I hit the enter key so I can look through any messages.

Now, for First Strike BF2142 mod, I was thinking that it might be possible to create an aerial height map for the Hoth Space map that would include the Star Destroyer by moving it to a land map and creating a steep mountain under it. That way, the bots should fly over and around the Star Destroyer. The same trick might even work on an asteroid map, buy adding land and creating peaks that raise up to the asteroids. So, I might need to experiment with the different aerial height map sizes.

[clivewil]

it appears that the quad tree saving only needs to be done after the navmesh is edited.

yep, that's your very final step, along with creating the heightmap.

moving it to a land map and creating a steep mountain under it. That way, the bots should fly over and around the Star Destroyer.

if you wanted it to just hover in space, that's fine too. assuming the .ahm is created correctly, the bots will see it as being connected to the terrain by a column anyway, i.e. they won't try to fly underneath it

here's Fushe Pass's aerial heightmap:



the arrow shows a bridge that is very fly-underable, but because the heightmap is only 2d, to any bots in aircraft it represents a wall. the beauty of the navmesh system is that it allows multiple vertical levels of bot-walkable surfaces to exist in the same area i.e. satnav's skyscraper, unlike the old BF1942 pathmap system. as you've probably seen yourself, bots can and do travel both under and over that bridge (just in case anyone was wondering why BF2 uses such a complex pathing system)

unfortunately you can't navmesh an entire sky due to its volumetric nature, so for aircraft we have to make do with a 2d system

[Dnamro]

Hey even getting bots to fly over and around objects is a big improvement over BF42/BFV, so I am not complaining.

So any floating object would look like it was basically a shadow over the aerial height map.

How did you get that aerial height map to load up in PS? When I try, it just tells me that the file type is not supported.

Edit - I did some testing on creating aerial heightmaps from floating objects, and if the objects are too high above the ground, they won't generate any GTSdata files, so they won't be navmeshed and therefore can't be included in the Aerialheightmap. So mountains may be needed.