buildPolyDetail issue

[GoogleCodeExporter]

What steps will reproduce the problem?
1. I might need to dump data so you can build it?

What is the expected output? What do you see instead?
A good detail mesh :)

What version of the product are you using? On what operating system?
Latest SVN

Please provide any additional information below.
All the data up to this point appears good, but the detail mesh that comes
back from buildPolyDetail appears to be fubar. I dug around a little to see
if i could figure out what's going on without much luck. The only thing
that looked a bit suspect to me is in buildPolyDetail in the first loop
when it does this
pos[1] = getHeight(pos[0], pos[2], cs, ics, hp)*chf.ch;

The value for this is very large already, then it gets multiplied by my
cell height(8) The first screen is rendering the poly mesh, the 2nd pic is
the Poly detail mesh.

If it helps

RecastCfg   {width=296 height=296 tileSize=0 ...}   rcConfig
width   296 int
height  296 int
tileSize    0   int
borderSize  0   int
cs  8.0000000   float
ch  8.0000000   float
bmin    0x1d14fc60  float [3]
[0] 0.00000000  float
[1] -65535.000  float
[2] -512.00000  float
bmax    0x1d14fc6c  float [3]
[0] 2368.0000   float
[1] 65535.000   float
[2] 1856.0000   float
walkableSlopeAngle  45.000000   float
walkableHeight  8   int
walkableClimb   2   int
walkableRadius  4   int
maxEdgeLen  32  int
maxSimplificationError  1.0000000   float
minRegionSize   0   int
mergeRegionSize 0   int
maxVertsPerPoly 6   int
detailSampleDist    6.0000000   float
detailSampleMaxError    1.0000000   float

Original issue reported on code.google.com by jswig...@gmail.com on 8 Feb 2010 at 7:04

Attachments:

• 2010-02-08-005320-dm_metro_te.jpg
• 2010-02-08-005330-dm_metro_te.jpg

[GoogleCodeExporter]

Also, I tried artificially tightening up the vertical bounds with no change. I 
also
wanted to add that buildPolyDetail takes a couple minutes when it is doing this
nastiness.

Original comment by jswig...@gmail.com on 8 Feb 2010 at 7:08

[GoogleCodeExporter]

This is know problem which usually happens when you dont erode the mesh 
boundaries
(that is cfg.walkableRadius=0). I can see that you have cfg.walkableRadius=4 in 
your
settings, but looking at the screenshots the mesh does not look like eroded. 

If you updated to the latest SVN code recently, you will need to add one 
function
call to do the erosion, add this just after build regions:

// Erode the walkable area by agent radius.
if (!rcErodeArea(RC_WALKABLE_AREA, m_cfg.walkableRadius, *m_chf))
{
       if (rcGetLog())
                rcGetLog()->log(RC_LOG_ERROR, "buildNavigation: Could not erode.");
       return false;
}

The real solution when using zero radius will follow later when I find good and 
fast
solution to it.

2 minutes sounds long. How long does the other parts of the process take? Poly 
detail
takes quite a bit of time when you have sharp features (stairs) in your map. 
One way
to reduce the processing time would be to increase the sample distance
(cfg.detailSampleDist).

Original comment by memono...@gmail.com on 8 Feb 2010 at 7:38

[GoogleCodeExporter]

The whole process used to be effectively instant(in an older recast). I've 
never had
to wait for it like this. This is a very small map too, this may be ridiculous 
on a
full size map.

Adding the erode call after the rcBuildRegions still produced a crap detail 
mesh. I
tried putting it after rcBuildCompactHeightfield as the samples appear to do 
and it
appears to be better.

The speed appears to be significantly faster when the results aren't jacked up.

You're right though that I forgot to add the erode function.

Original comment by jswig...@gmail.com on 8 Feb 2010 at 2:50

[GoogleCodeExporter]

There are some code which tries to deal with the bad heights. I bet the slowdown
comes from the fact that the detail mesh tries to compensate for those bad 
samples by
adding many extra vertices.

I will leave this issue medium priority. It is something I want to fix, but I 
wish to
get the area features finished before I come back to this.

Original comment by memono...@gmail.com on 8 Feb 2010 at 8:27

[GoogleCodeExporter]

Should be fixed in R128.

Original comment by memono...@gmail.com on 12 Feb 2010 at 2:42

• Changed state: Fixed