Recast/Detour - Mesh not generated inside of a tower - why?

[Tanaris4]

All-

Has anyone ran into an issue where the area INSIDE of a tower isn't generated? Or does anyone know why it wouldn't be in the final nav mesh? or even within the recast view?

From this screenshot it looks like I'm not even getting the indicies/vertices properly from wowmapper. Has anyone else ran into this problem?



Edit: Here are my parameters (Note: I do 16 tiles per ADT):

#define GRID_SIZE       (533.0f + (1.0f / 3.0f))
#define TileSize        (533.0f + (1.0f / 3.0f))
#define TileVoxelSize   1800
#define MinRegionSize   20
#define MergeRegionSize 40

#define CellSize        TileSize / (float)TileVoxelSize

#define CellHeight              0.4f
#define WalkableSlopeAngle      50.0f
#define MaxSimplificationError  1.3f
#define DetailSampleDist        3.0f
#define DetailSampleMaxError    1.25f

#define WorldUnitWalkableHeight     1.652778f
#define WorldUnitWalkableClimb      1.0f
#define WorldUnitWalkableRadius     0.2951389f

#define WalkableHeight      (int)ceilf(WorldUnitWalkableHeight / CellHeight)
#define WalkableClimb       (int)floorf(WorldUnitWalkableClimb  / CellHeight)
#define WalkableRadius      (int)ceilf(WorldUnitWalkableRadius / CellSize)

#define MaxEdgeLen          (int)(WalkableRadius * 8.0f)
#define BorderSize          (int)(WalkableRadius + 4.0f)
#define TileWidth           (TileVoxelSize / GridDiv) + (BorderSize * 2)

#define GridDiv 4
#define MaxPoly  1048576 / ( GridDiv*GridDiv)

#define m_vertsPerPoly          6.0f

#define m_keepInterResults      false
#define m_monotonePartitioning  false

    rcConfig m_cfg;	
	// Init build configuration from GUI
	memset(&m_cfg, 0, sizeof(m_cfg));
	m_cfg.cs = CellSize;
	m_cfg.ch = CellHeight;
	m_cfg.walkableSlopeAngle = WalkableSlopeAngle;
	m_cfg.walkableHeight = WalkableHeight;//(int)ceilf(WorldUnitWalkableHeight / m_cfg.ch);
	m_cfg.walkableClimb = WalkableClimb;//(int)floorf(WorldUnitWalkableClimb / m_cfg.ch);
	m_cfg.walkableRadius = WalkableRadius;//(int)ceilf(WorldUnitWalkableRadius / m_cfg.cs);
	m_cfg.maxEdgeLen = (int)MaxEdgeLen;//8;(int)MaxEdgeLen;
	m_cfg.maxSimplificationError = MaxSimplificationError;
	m_cfg.minRegionArea = (int)rcSqr(MinRegionSize);		// Note: area = size*size
	m_cfg.mergeRegionArea = (int)rcSqr(MergeRegionSize);	// Note: area = size*size
	m_cfg.maxVertsPerPoly = (int)m_vertsPerPoly;
	m_cfg.tileSize = (int)(GRID_SIZE / GridDiv);
	m_cfg.borderSize = BorderSize;
	m_cfg.detailSampleDist = DetailSampleDist;
	m_cfg.detailSampleMaxError = DetailSampleMaxError;
    m_cfg.width = TileWidth;
    m_cfg.height = TileWidth;
    
    // save the tile's max/min not the 3x3!
    rcVcopy(m_cfg.bmin, bmin);
	rcVcopy(m_cfg.bmax, bmax);
    
    m_cfg.bmin[0] -= m_cfg.borderSize*m_cfg.cs;
    m_cfg.bmin[2] -= m_cfg.borderSize*m_cfg.cs;
    m_cfg.bmax[0] += m_cfg.borderSize*m_cfg.cs;
    m_cfg.bmax[2] += m_cfg.borderSize*m_cfg.cs;

Edit 2: Looks like the door is closed, but there isn't a door there in game - anyone have any ideas why this happens? Below is the view from inside.



Thanks in advance!
~ Tanaris

[guizmows]

do you see the door in recast demo?

Are you sure it's not a problem with your agent radius and weigh?

[namreeb]

This looks to me like a parser error. Not all triangles are collideable or visible in-game. Some are there for other purposes (like detecting when you've crossed into a building, for example).

[Tanaris4]

Any reco on how I could go about debugging? Stuff to look for in wowmapper?

Or should I e looking elsewhere. I'm sure the issue is in wowmapper and how I'm pulling the info, just curious what I should ignore (certain door doodads? Or something else?)

Edit: So I found your post namreeb on what flags I should check, has this changed? I added this and I'm still seeing the same as my earlier post:

        // flags != 0x04 implies collision.  materialId = 0xFF (-1) implies a non-rendered collideable triangle.
        if ((*iter)->getMopyChunk().infos[i].flags & 0x04 && (*iter)->getMopyChunk().infos[i].id != 0xFF) {
        //if ( !((*iter)->getMopyChunk().infos[i].flags & filter) ) {

in void WmoModel::getIndices( Indices32_t *indices, uint32_t filter, uint32_t off ) const {

[Bananenbrot]

This looks to me like a parser error. Not all triangles are collideable or visible in-game. Some are there for other purposes (like detecting when you've crossed into a building, for example).

this. iirc there are at least 2 different flags for insivible and uncollideable triangles, like some stair polygons and stuff...

[Tanaris4]

Do you know what they are? What I added to my post doesn't seem to r working for this particular case

[MaiN]

Any reco on how I could go about debugging? Stuff to look for in wowmapper?

Or should I e looking elsewhere. I'm sure the issue is in wowmapper and how I'm pulling the info, just curious what I should ignore (certain door doodads? Or something else?)

Edit: So I found your post namreeb on what flags I should check, has this changed? I added this and I'm still seeing the same as my earlier post:

        // flags != 0x04 implies collision.  materialId = 0xFF (-1) implies a non-rendered collideable triangle.
        if ((*iter)->getMopyChunk().infos[i].flags & 0x04 && (*iter)->getMopyChunk().infos[i].id != 0xFF) {
        //if ( !((*iter)->getMopyChunk().infos[i].flags & filter) ) {

in void WmoModel::getIndices( Indices32_t *indices, uint32_t filter, uint32_t off ) const {

Doesn't look right. I personally don't have the 0xFF check at all. Try just skipping the triangle if (flags & 4) != 0.

[Tanaris4]

Is there a list of what the flags are? Wish madx.dk was still up - isn't that where most of that info was?

Edit: Re-built just doing the 0x4 check and the door is still there :/ so confused any other ideas?

[Bananenbrot]

Quick google for adt wow turned up WoWDev .
Only include triangles with material id 0xFF. That will be the collision mesh. WMO/v17 - WoWDev

[Tanaris4]

Same issue unfortunately. Anyone have any ideas as to why this door just doesn't want to go away! Or what I should be looking for? Any flags you know of that aren't listed on that page?

    // filter vertices by triangle material info
    size_t num_triangles = grp_indices.size() / 3;
    for ( int i = 0; i < num_triangles; i++ ) {
        
        //printf("[%d] 0x%X 0x%X\n", i, (*iter)->getMopyChunk().infos[i].flags, (*iter)->getMopyChunk().infos[i].id);
        
        // flags != 0x04 implies collision.  materialId = 0xFF (-1) implies a non-rendered collideable triangle.
        if ((*iter)->getMopyChunk().infos[i].flags & 0x04 && ((*iter)->getMopyChunk().infos[i].id & 0xFF) != 0xFF ) {
        //if ( !((*iter)->getMopyChunk().infos[i].flags & filter) ) {
            //printf(" saved...\n");
        increment[i*3+0] = -1;
        increment[i*3+1] = -1;
        increment[i*3+2] = -1;
      }
    }

[dook123]

I had this same problem when I started out with navmesh... I might look back at my notes after work to give you some ideas.

[Tanaris4]

I'd appreciate that, thanks. It's so strange b/c obviously the change I made is required (given that the ogrimmar gate is now gone). There must be some other type of door we don't know about yet? Or know to recognize? I just happened to find the one tower it affects? hah



Edit: Found out if I just ignore the doodad named "WORLD\GENERIC\HUMAN\ACTIVEDOODADS\DOORS\SHADOWFANGDOOR01.MDX" then the door goes away... I know this isn't really a solution. Still investigating...

Edit 2: I decided to print out the unique flags and ids for this model that are NOT filtered by this check:

if ((*iter)->getMopyChunk().infos[i].flags & 0x04 && ((*iter)->getMopyChunk().infos[i].id & 0xFF) != 0xFF ) {

I'm a bit confused as to how I ensure it would be ignored... Obviously SOME of the triangles are being ignored, but the door itself still stays. Is there a flag elsewhere that I should be checking as well?

Flag id
0x60 0x9
 0x60 0xA
 0x20 0xA
 0x60 0xC
 0x20 0xC
 0x20 0xF
 0x48 0xFF
 0x8 0xFF
 0x20 0x1
 0x60 0x1
 0x60 0x3
 0x60 0x4
 0x20 0x5
 0x60 0x6
 0x60 0x7
 0x20 0x7
 0x60 0x13
 0x60 0x0
 0x20 0xB
 0x60 0xB
 0x60 0xD
 0x20 0xD
 0x60 0xE
 0x60 0xF
 0x60 0x10
 0x20 0x11
 0x60 0x12
 0x20 0x12
 0x60 0x14
 0x61 0x9
 0x21 0xF
 0x61 0x12

[Bananenbrot]

iirc, those portals are m2 s with a portal flag or sth set. too bad recast demo isn't colored :P

Edit: It also says that you only accept triangles with a materialId of 0xff, not that you should discard them.
So this should be

if ((*iter)->getMopyChunk().infos[i].flags & 0x04 && (*iter)->getMopyChunk().infos[i].id == 0xFF)

[Tanaris4]

Ahh nice catch, do you know how I determine if a model has a portal flag or sth set?

[ament]

The door have a few animations so maybe it's closed by default?