Closed GoogleCodeExporter closed 8 years ago
Please use the latest version from SVN. It is always the safest bet.
Unfortunately I'm a bit lazy when it comes to
making releases, instead I do my best to keep the latest svn version tidy. For
major features or fixes, I usually
detail them in my blog.
Recast uses voxelization process as intermediate step to calculate the navmesh.
Huge worlds like your mesh
will need to be split up into smaller chunks so that the process does not run
out of memory.
In Recast this means tiles. Each tile is a square piece of navmesh and the
tiles can be loaded and unloaded at
runtime, Detour will stitch the mesh tiles together when a tile is added to
create continuous mesh.
You can load your navmesh.obj to the (latest) Recast demo and choose "Tile
Mesh" sample.
In your case I suggest using tile size around 128. You may need to use cell
size around 0.15-0.20 to capture
the finer details around the house. I tried with cell size 0.15 and agent
radius 0.4, and it seemed to create ok
results there.
The terrain is a bit tricky for Recast, but there are a couple of things that
can be used to fix that.
Recast generates detail mesh for every navigation mesh polygon. This helps pick
correct polygon when there
are multiple layers of navmesh and it also can be used to approximate the NPC
height location too.
The detail mesh generation is sort of geared toward smaller polygons (uses slow
algorithm). From 2.5D
walkability point of view your terrain is almost just a bumpy flat plane. The
problem is that Recast tries to build
a detail mesh for a large area with a lot of height differences and that is
slow.
One way to remedy this is to adjust the detail mesh generation to create less
accurate mesh. For example
increasing Detail Mesh Sample Distance to 10 and max sample error to 2 speeds
things up quite a bit (I got
around twice the speed) without too much loss in accuracy. Another one is to
keep the maximum area
relatively small, in this case it means keeping the tile size moderate.
I'm big fan of Overgrowth, I have kept keen eye on your progress :) I hope
Recast/Detour could be useful for
you.
Original comment by memono...@gmail.com
on 22 May 2010 at 1:41
Thanks for the advice! I am using the tile mesh from the latest SVN version,
and it no
longer gives me this memory error. I am not so worried about mesh calculation
time
because I think the navigation meshes for each level will be cached in advance,
though
it's still good to keep it responsive for level creators. Maybe we should have
a fast
low detail pass for testing, and then allow for individual tiles to be refined
as
necessary (such as complicated buildings).
Original comment by david20...@gmail.com
on 27 May 2010 at 4:25
If you can keep track of the tiles that change during one edit session, you
could
just update the ones that just changed. In your cases it should be just matters
of
few seconds to do that. In my tests one 128x128 tile took ~150ms to calculate.
In
case you change the whole terrain, or certain instanced asset changes
drastically,
then you will need to rebuild all. That should keep the iteration times tight.
Complicated buildings may actually be processed faster than open terrain :) The
generation algorithm works better and faster when you have smaller walkable
areas.
Original comment by memono...@gmail.com
on 27 May 2010 at 6:20
I'm closing this bug for now. If you have further question, maybe better place
is to discuss them in the discussion groups at
http://groups.google.com/group/recastnavigation
Original comment by memono...@gmail.com
on 8 Jun 2010 at 5:21
Original issue reported on code.google.com by
david20...@gmail.com
on 22 May 2010 at 12:50