recast/detour usage

[dgboone]

Hi,

I am looking into using recast/detour and as a result have a couple of
questions related to our usage.

1. Dynamic obstacles

We would like to be able to dynamically add/remove obstacles from the
navmesh as players perform certain tasks.

We could regenerate the navmesh to add/remove the obstacle but that
takes time.

We could pregenerate with and without the obstacles but we plan to
have many of these dynamic obstacles in a level and permutations of
all possible navmesh states would get pretty large fairly quickly.

Is there any way that I am not seeing to currently add/remove these
types of obstacles from a navmesh at runtime or any plans to add this
capability?

2. Pathfinding

First, a few details about our world. It is flat with stairs (which we
model as ramps) that lead from one level to another. There are no
height restrictions for where agents can walk, only restrictions about
obstacles placed on the walkable areas. I model the world as
horizontal triangles for the walkable area and vertical triangles for
the obstacles and then set the max climb low.

I have tried implementing pathfinding using both methods used in the
demo and have found the follwing results.

With Pathfind Straight distances on the same level work great but when
the ramps get involved it does not work so well. Then rather than
following the ramps it will sometimes take shortcuts. For example if I
create a bridge as a ramp up, flat top, ramp down and pathfind from a
point on one side of the bridge to a point on opposite side the path
does not follow the bridge but cuts straight across the gap. This is
probably how it is designed to work but not how I was expecting/
hoping :)

With Pathfind Iter the ramps get followed, but the number of path
points is very high even for walking in a straight line over flat
surface. These paths need to be distributed to clients over the
internet so having a high number of path points is not ideal. Also
even though my world is completely flat I am seeing points in the path
that have a vertical component. ie. the path lifts off of the surface.

Ideally I would like to get paths that contain only those path points
necessary to define the path. Is there a way to do this? Pathfind
Straight seems close, except as I said it bypasses the ramps.

[Mikko Mononen]

Can you tell a little bit more about the obstacles you want to
add/remove? If they are really simple it is possible maybe use
something else to avoid them. For example you could try to use the
areas and turn them, on and off when you need to enable, disable them.

You should never really calculate the full path to the target. You
calculate the path corridor (the list of polygons to follow), and then
each time you want to move, you calculate the next couple of vertices
and move along the path. Just like the path iterator! You should not
use it to calculate the full path, but to just find the next point to
steer towards.


--mikko

[dgboone]

The obstacles could be various things like doors that need to be
opened, other things that impede a players path that need to be dealt
with such as a log, a fire, or a missing span in a bridge. Could give
me a bit more info on how areas work (or point me to where to look)?

[Mikko Mononen]

Areas allows you to mark shapes into the navmesh. You can alter the
flags of the navmesh polygons at runtime to allow certain areas to be
blocked, etc.

http://digestingduck.blogspot.com/2010/02/area-progress-pt-5.html


--mikko

[dgboone]

Let's see if I am understanding this correctly.

I can create areas and mark them with a certain flag such as
BLOCKED_AREA and then set up the filters properly on the path find to
not allow access to areas that are marked BLOCKED_AREA.

If I then want to unblock an area so that it can now be accessed, I
change the areas flag to be UNBLOCKED_AREA, for which I allow
pathfinding to traverse.

Can I change the area flags on the fly or do I need to regenerate the
navmesh with the new flag settings? If I can change them on the fly
what is the API used to do this?

Thanks

On May 4, 10:14 am, Mikko Mononen <memono...@gmail.com> wrote:
> Areas allows you to mark shapes into the navmesh. You can alter the
> flags of the navmesh polygons at runtime to allow certain areas to be
> blocked, etc.
>
> http://digestingduck.blogspot.com/2010/02/area-progress-pt-5.html
>
> --mikko
>

[Mikko Mononen]

Almost :)

There are many ways to handle blocked polygons. Here's one.

The polygon flag filter works so that you can specify certain flags,
which must be on (included), and certain flags which must not be on
(excluded) for a polygon to be valid. In code the filter looks like
this:

inline bool passFilter(const dtQueryFilter* filter, unsigned short flags)
{
return (flags & filter->includeFlags) != 0 && (flags &
filter->excludeFlags) == 0;
}

You could for example have following default filter for "humans":

flt.includeFlags = SURFACE_GROUND | SURFACE_SHALLOW_WATER | SURFACE_DOOR;
flt.excludeFlags = SURFACE_DISABLED;

It means that it will accept polygons which are either ground, shallow
water or door, but not disabled.

Then it is matter of setting or clearing the SURFACE_DISABLED flag for
the polys which are disabled (i.e. locked door).

You can change the flags of a polygon using dtNavMesh.getPolyFlags()
and dtNavMesh.setPolyFlags().

Take care if multiple sources can change the same polygon flags.


Remember that a door area can be potentially composed of many
polygons. One way to handle this is to query the necessary polygons
using dtNavMesh. findPolysAround() at the door center location (and
approx radius) with following filter:

flt.includeFlags = SURFACE_DOOR;
flt.excludeFlags = 0; // will return both enabled and disabled polys

This will only expand to polygons which are have door "ability". Then
on your door logic you can change their flags based on the door state.


Area type is meant to specify how expensive the polygon is to travel,
but you can misuse it in certain cases to do secondary manual
filtering yourself.


--mikko