Recast+Detour navmesh from cmangos - where's my cactus! (missing objects in nav mesh)

[Bogie]

Hi all,

I'm looking to generate a Recast+Detour Navmesh for WoW 1.12.1. In principle, I'm using cmangos' fantastic movemap generator to do so - albeit slightly modded to include known GameObjects as well.

This works fairly well, but I've noticed a few objects appear to be missing from the generated mesh. In particular, plants in Orgrimmar don't appear to be included.

Example - the cactus (cacti?) at the tower leading up to the flight master:

ogrimmar.JPG

ogrimmar_navmesh.JPG

Or, the big palm tree near the bank:

ogrimmar2.JPG

ogrimmar_navmesh2.JPG

Now, I'm at a bit as to why they're missing. From what I can see, those plants are not dynamic gameobjects, so are presumably part of the static map geometry.
But then again, looking at the cmangos code, I haven't found any particular piece that looks like it would intentionally skip/ignore loading any particular objects.

Would anyone know how those objects are placed on the map in the first place? Are they part of Ogrimmar.wmo (which the cmangos generators should actually already parse), or are they spawned through any other means?

If anyone has more specific tips on how to include those in navmesh generation, that'd be much appreciated too! Otherwise, I can hopefully figure that out once I find out "where they come from" in the first place.

Thanks!

[Bogie]

Right, I've found the answer.

It looks like cmangos-classic quite simply doesn't handle/parse doodad spawns on WMOs (wmo.cpp, section "MODR" isn't handled).
Light's Hope has a modified version of the vmap-extractor which does handle these.

[badusername1234]

Thanks for pointing that out, I was just getting around to sorting my navmesh stuff and I'd never have thought to check there - it might have just saved me a bunch of time.

Have you noticed any other issues with these meshes?

[Bogie]

Thanks for pointing that out, I was just getting around to sorting my navmesh stuff and I'd never have thought to check there - it might have just saved me a bunch of time.

Have you noticed any other issues with these meshes?

Great to hear!

unlies cmangos-classic, Light's Hope has a manual fix for the VMAP of Transport_Zeppelin.wmo as well, in case you want to include that.

Other than that, the mesh looks mostly good to me so far.
I've found one part in Orgrimmar where a bunch of vases appear to be missing. I don't know why yet - unless I see more problematic spots, I probably won't have a closer look at those though, that particular spot isn't too problematic.

(the navmesh on the second photo is mirrored, but hopefully still recognizable)

og.JPG

og_nav.JPG


In terms of "not a bug, still a gotcha", a few points I wish I had known or thought of earlier, in case it helps:

1. If you need to handle large parts (say, Booty Bay to EPL), make sure to initialize the nav mesh query with a large enough number of nodes. I'm using 1 << 20 at the moment. If you're doing that, you'll also need to adapt the data type of dtNodeIndex in DetourNode.h (eg unsigned int)

2. dtStatusSucceed() doesn't always mean that a Detour call truly succeeded. Eg dtNavMeshQuery->findPath may return DT_SUCCESS | DT_OUT_OF_NODES, or DT_SUCCESS | DT_PARTIAL_RESULT, which in some cases can mean you actually just got a bogus path back

3. "Dynamic" game objects (firepits, signs, etc.) are obv. not part of the normal mesh data, and a bit of a pain to integrate. I've tried two things:
A) I rewrote the navmesh generator to generate a dtTileCache instead so I'd be able to add cylindrical obstacles on the fly. That was a fair bit of work, needed a lot of tweaking, and increased loading times of the meshes significantly - in retrospect.. that wasn't worth it at all. Not using this anymore.
B) I just slightly modified the nav mesh generator to query the cmangos DB during generation for locations of relevant dynamic game objects, and added those to the mesh. That works very well - but of course very much relies on cmangos data to be bang on (alternatively you'd have to collect locations yourself on live servers)

4. Blocking large areas (eg enemy cities, so you don't accidentally walk through Grom'Gol or such) works well by setting the poly area to something unwalkable / something that is excluded by your query filter. For small obstacles, this is too imprecise.

5. There are a few doors on the map to which you may or may not have a key. Similar to #4 , I'm setting poly flags accordingly if they're inaccessible to the player.

6. Handling transports (zeppelins, boats, elevators etc.) is a little tricky. Worth keeping in mind - when you enter them, both location of the unit as well as camera become relative to the transport, not to the owning map. So either transform them to world coords, or work with relative coords.
I've started with the former, but am now moving over to the latter - I've generated seperate nav meshes for boats and zeppelins, and navigating based on those while on those transports.
For transports that pick up & drop off on the same map (e.g. elevators, or that boat in Feralas), it can be useful to add offmesh links during path generation, if you want those to be considered by normal pathfinding.