Odd Tile Portal Behavior after Recast Upgrade

[Stephen Pratt]

Hi All,

I've been using Recast to successfully build tiled meshes for several months.  Recently I upgraded my version of Recast and now have problems where portals between tiles are being erroneously marked as solid...sometimes.  While I don't yet know the exact trigger, I do know that it has to do with the Recast build process (not Detour) and that the problem goes away completely if I fall back to the earlier Recast version.

The version upgrade was from r312 (September 2011) to r335 (March 2012).

Here is an example of the problem using a plane with a box.

Plane size: 100x100 world units.
Cell Size: 0.1

Tile Size: 128
Border Size: 7  (Various border sizes tried.)
Walkable Radius: 4

In the images, the bounding boxes represent tile size + border size.

In this first image I've built a section of the plane without the box.  As you can see, everything is fine.

Simple Plane - No Problem

In this next image, I've moved the box into one of the tiles.  Suddenly one of the portals changes to a solid boundary. (Red) 

Simple Plane - Tile Portal Error

I can see in my debug visualizations that this happening in the PolyMesh object.  Anywhere from zero to four of the portals will become solid as I move the box around.  Adjusting the boundary size effects which portals become solid, but the problem never goes away.

The problem goes away when I export the geometry and build it in the Recast Demo.  So the trigger is somewhere in my build process. But no luck tracking it down so far.

Any ideas where I can look for the source of this type of problem?

-Steve

[Mikko Mononen]

Hi,

Looks like a bug caused by R332
http://code.google.com/p/recastnavigation/source/detail?r=332
I moved the portal calculations a bit higher up.

I think it might come from border vertex removal, it probably does not
preserve the portal flags.

--mikko

[Stephen Pratt]

Just an update:

I've confirmed that the problem appears when I switch from R331 to R332.  So it looks like you are right about the R332 change set causing the problem.

It may take a little while to locate the cause since I don't have the ability to visualize contour data yet.

-Steve

[Mikko Mononen]

I reverted the portal detection changes from R332, can you try the
latest and see it works for you too?

--mikko

[Stephen Pratt]

I updated to the latest revision and everything is working fine again.

What is really bothers me is that I haven't been able to duplicate the issue in the demo code.  Strange.

[Mikko Mononen]

Hey, it worked on my machine too :) The cause was quite obvious once I
went through the code with more thought, I just had hard time finding
a repro case to make sure I would have fixed it.

--mikko

[Julien]

Hi,

I experienced something similar recently, and I'm wondering if it could be related.

So here's the issue I have: sometimes, a edge will be detected as a "wall edge" by my code although it shouldn't be.

For some collision meshes, I get the results you can see in this screenshot (the red edges are walls edges):

Here is a screenshot of how the tiles are arranged on this surface:

The code I use to detect walls edges is as follow:

// --------------------------------------------------------------------------------------------

void NavMesh::GetWallsEdges(const dtMeshTile* tile, std::vector<Vec3f>& outWalls) const

{    

    if (!tile || !tile->header || !m_navMesh)

        return;

    const dtPolyRef base = m_navMesh->getPolyRefBase(tile);

    int polyCount = tile->header->polyCount;

    for (S32 polyIndex = 0; polyIndex < polyCount; ++polyIndex)

    {

        const dtPoly* currentPoly = &tile->polys[polyCount];

        const dtPolyRef currentPolyRef = base | (dtPolyRef)polyIndex;

        // maxSegments should intuitively be DT_VERTS_PER_POLYGON, but some edges cases require

        // more segments, see http://groups.google.com/group/recastnavigation/browse_thread/thread/53aa4ee198864369 

        // for an example

        const U32 maxSegments = 2 * DT_VERTS_PER_POLYGON;

        float segmentVerts[maxSegments * 6]; // * 6 for 2 3d float coordinates

        dtPolyRef refs[maxSegments];

        memset(refs, 0, sizeof(dtPolyRef) * maxSegments); 

        int nsegs = 0;

        dtStatus status = m_navQuery->getPolyWallSegments(currentPolyRef, m_dtQueryFilter, segmentVerts, refs, &nsegs, maxSegments);

        for (int j = 0; j < nsegs; ++j)

        {

            if (!refs[j])

            {

                // Wall

                const float* segmentPair = &segmentVerts[j*6];

                outWalls.push_back(Vec3f(segmentPair[0], segmentPair[1], segmentPair[2]));

                outWalls.push_back(Vec3f(segmentPair[3], segmentPair[4], segmentPair[5]));

            }

        }

    }

}

With my debugger, I can break in the NavmeshQuery::getPolyWallSegments method when these edges are detected, but I don't know exactly what to look for to investigate this issue, so I would appreciate if you could give me some pointers :) Also, the Recast code I'm using is around six months old. Do you think it is likely that updating to the most recent version could fix this issue?

Thank you very much,

Julien

[Mikko Mononen]

Hi,

There was bug in r332 which sometimes added those collodable edged. It is fixed now in latest svn version.

Your wall code looks fine.

--mikko

Sent from my iPhone

[Julien]

Alright, thank you very much for your comments. I will upgrade to the most recent version of Recast then :)

[Julien]

Hi again,

I just upgraded to the latest version (r338). I still get the same "wrong" walls edges detected at the same place. Is there any information that could help me diagnose the problem?

Thank you!