Hierarchical pathfinding seem to be a good solution for handling big maps.

In the case of online calculation of the nav mesh, the whole map would have
to be processed prior to any pathfinding, right? Since we would need the
weights for the edges of the high level graph (which would be the cost of
the shortest path connecting the two portals represented by the vertices of
each edge) and the portal positions.

On Thu, Apr 1, 2010 at 11:24 AM, Christian Van Brussel <
christian.vanbrus...@uclouvain.be> wrote:

>
> >
> > How would this system work? Pathfinding for the unit would be done
> > inside the loaded sector using the graph normally, and when the unit
> > crossed the portal area (when chasing another unit, for example), it
> > would load the next sector?
> > And if we wanted to plot a path crossing a few different sectors, we
> > would just load them all?
>
> After a closer look to the Detour API, it seems to me that the tiled
> navigation graph is the way to go, because it can handle CS's portals,
> huge worlds, and dynamic worlds.
>
> Regarding your question about how it can work for portals and sectors, I
> found this thread:
>
> http://groups.google.com/group/recastnavigation/browse_thread/thread/ffeed098c1a15922
>
> Mikko Mononen suggests to use a hierachical path finding. Applied to CEL
> it would lead to sth such as:
> - as a reminder, a CEL world is made of various iCelZone (see
> iPcZoneManager), and a iCelZone is made of various iSector (see
> iCelRegion and iCelMapFile).
> - each iSector correspond to a Detour's tile. These tiles can be
> computed offline or online.
> - for the whole world, you build another, higher-level graph. In this
> graph, each portal (iff it is 'walkable' by the unit) is a node. Each
> portal/node is connected by an edge to every other portals belonging to
> the two sectors connected by this portal. The cost between each node is
> computed by using Detour on the tile.
> - when the path finder is asked to find a path to another, not yet
> loaded sector, the system queries the higher-level graph (with the
> current CEL's implementation of A*?) to find the tiles (not necessarily
> the sector) needing to be loaded. Then Detour is queried on the whole
> tiled graph to find the real path.
>
> Some notes:
> - offline computation of graphs is an optimization. IMO, optimizations
> are secondary and it is better to have a strong system rather than a
> more poor but optimized system. Offline computation may however be
> simple for you to implement, so choose what you prefer ;)
> - Recast & Detour is a young project, and the API changes often. Mikko
> Mononen has changed recently in trunk the API for loading/unloading
> tiles. Maybe it would be better to preventively use the trunk version of
> R&D, you may have more problems but your solution will be compatible
> with the probably incoming new release of R&D.
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Crystal-main mailing list
> Crystal-main@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/crystal-main
> Unsubscribe: mailto:crystal-main-requ...@lists.sourceforge.net
> ?subject=unsubscribe
>
------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Crystal-main mailing list
Crystal-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/crystal-main
Unsubscribe: 
mailto:crystal-main-requ...@lists.sourceforge.net?subject=unsubscribe

Reply via email to