Closed GoogleCodeExporter closed 8 years ago
Is it possible to have that mesh (.obj) for testing, together with the values
which
result bad coordinates? If you don't wish to share the mesh here, you can a
link to
the file to my personal email address (you can find it in the readme.txt).
Original comment by memono...@gmail.com
on 27 May 2010 at 8:47
the obj is as attached, with the Max edge error set to 3.0, it always happens
in my
project, may be it is because we use very big size model, which lead to quite
big
val of cs...i don't know, i hope you can fix it ,thx.
Original comment by zhibin.l...@gmail.com
on 27 May 2010 at 9:58
Attachments:
I will take a look at it.
A simple solution on your side is to use better value for max edge error. Value
of
3.0 way off and will make a lot of shortcuts, which may lead to other problems.
Good
value for max edge error is somewhere between 1.1 and 1.5.
See this blog post for explanation of the different values:
http://digestingduck.blogspot.com/2009/08/recast-settings-uncovered.html
Original comment by memono...@gmail.com
on 27 May 2010 at 10:05
the same obj,with the config of cs = 3.0 , max_climb = 3.0, min region size =
0,
merge region size = 0....... crash!!!
it seems there are some bug in the function: simplifyContour, it require more
and
more memory here,and finally crash. Crash on the code below:
// If the max deviation is larger than accepted error,
// add new point, else continue to next segment.
if (maxi != -1)
{
// Add space for the new point.
simplified.resize(simplified.size()+4);
......
i wish you can fix the problem too. thx again
Original comment by zhibin.l...@gmail.com
on 27 May 2010 at 10:52
Can you post your other generation values too?
Original comment by memono...@gmail.com
on 27 May 2010 at 11:02
as attachment, all the config, except, cs = 3, max_climb = 3, min_region_size =
0,
merge_region_size = 0 ,other param is set to default
Original comment by zhibin.l...@gmail.com
on 27 May 2010 at 12:01
Attachments:
Please check the blog post how to select the values. If your cell size is 3.0
then it
is odd that your agent radius is 0.6, also max climb should be less than agent
height.
Original comment by memono...@gmail.com
on 27 May 2010 at 12:05
i am sorry, but can you provide your blog address? thx
Original comment by zhibin.l...@gmail.com
on 27 May 2010 at 12:42
See comment #3 above.
Original comment by memono...@gmail.com
on 27 May 2010 at 12:45
more example of bug:
1.it seems that there are sth wrong with the find path straight now, see the
attachment wrong_path. while the find path iter is ok, the straight path is not
right.
2. with certain config, as attachment wrong_detail, the detail mesh is not
right.
totally speaking, the config of building is always boring me, i have to try
different config again and again. i hope that the algorithm would be more
robust. thx
Original comment by zhibin.l...@gmail.com
on 28 May 2010 at 3:10
Attachments:
In the first picture (wrong_path.jpg) the generation settings are way off.
Maybe you are using old version. Please
try the latest one from perforce.
I fixed the case detail mesh case which you describe in the second picture in
change list R167.
Sorry to hear that you have had hard time trying to come up with good input
parameters. In practice the only
parameters you need to touch are the agent size and cell size. The others are
good defaults. It all starts from the
agent size, as the blog post describes.
Original comment by memono...@gmail.com
on 28 May 2010 at 6:36
it is so nice of you to fix the problem so quickly.
however, even when i use the latest version of demo.exe from the svn ,the
problem
still exists. see the attachment.
we are applying recast to a new project, maybe more bug would be met in future.
we hope that we can make the recast better and better together.
thank you again
Original comment by zhibin.l...@gmail.com
on 28 May 2010 at 8:23
Attachments:
Sorry, I did the fix on my Mac, I did not update the demo exe file.
Original comment by memono...@gmail.com
on 28 May 2010 at 8:39
another problem.
since my scn is so large, i wonder that if i can use the tile_mesh, but
applying
diffent config to different tile. for example , while the character in the
wild, i
would use the bigger cs. if the character is in the town, i would like to use
small
cs to handle the more complex enviroment.
would it cause any problem?
Original comment by zhibin.l...@gmail.com
on 28 May 2010 at 9:20
In theory it should be possible, Detour can handle slight inaccuracy at tile
borders. I have not tried it in practice.
Original comment by memono...@gmail.com
on 28 May 2010 at 9:41
Excuse me
i am confuse about the usage of m_saltBits.
especially in the code :
if (m_saltBits < 10)
return false;
why it should be wider than 10 bit?
can you also explain the meaning of m_tileBits and m_polyBits, thx
Original comment by zhibin.l...@gmail.com
on 29 May 2010 at 8:28
This blogpost explains how the handles work:
http://digestingduck.blogspot.com/2010/03/save-games-and-all-that.html
Original comment by memono...@gmail.com
on 29 May 2010 at 10:30
Closing this issue for now. If you have if you have further questions, please
use the discussion group at http://groups.google.com/group/recastnavigation
Original comment by memono...@gmail.com
on 8 Jun 2010 at 5:22
Original issue reported on code.google.com by
zhibin.l...@gmail.com
on 27 May 2010 at 8:38Attachments: