> > 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® 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
