> Is iCelGraph only used in the pathfinding algorithm? If so, it should be changed to Detour's structure (or at least be able to feed Detour this kind of data).
Yes, I think iCelGraph is used only in path finding. I'm not sure of the differences existing between iCelGraph and the data structure used by Recast, and how easy it would be to extend iCelGraph for that. iCelGraph is however a good candidate to store the navigation graph in XML, and to provide an API for manipulating dynamically the graph. I'm not sure neither of what to do with the current path finding property class: extend it, drop it, provide an alternate implementation? > -As for giving polygons a different cost, [...] talked about the alternative of tesselating the mesh, which would allow for a finer control over the costs, at the price of a decreased pathfinding performance. We could find a ideal size for the polygons for this use. Maybe an idea would be to simply provide an API so that the user can customize the tesselation of the graph depending on its needs. As you said, an editor to customize the weights of the graph may also be great. Or even a more generic solution, eg based on sth like the iMaterial of the floor, but this is probably another topic. > I also have not tested Recast with a big enough map to see if its able to generate the meshes dynamically, but I'm guessing it could be a problem. We may probably consider that a big sized level is split in different sectors connected through portals (see CS's iSector and iPortal). CEL has also advanced mechanisms for region management (see iCelMapFile, iCelRegion, iCelZone, iPcZoneManager). So navigation graphs can be generated dynamically by using Recast only on the sector, and connecting the graphs where there are portals (iff the portal is 'walkable'). This way, the path finding would also be able to handle space warping portals. This ability of handling portals and sectors is in fact probably one big great feature to have. iCelRegion and so on can also be extended to load/unload path finding data & files. > -The navigation mesh Recast generates is specific for a unit's width and height. So if two units were too diferent in size, 2 different meshes would have to be generated. This could be a good thing if we consider the possibility of adding different costs to the mesh, since different units could have different costs for each polygon. An ideal solution would provide a management of the intermediary results of Recast, so that it optimizes the use of CPU/memory when we want to compute the navigation graphs for different types/sizes of entities. There can also have one single common structure holding the graph for every type of entities, with different weights/nodes/edges depending on the type of the entities. 'Cat & mouse in a house' example: there is one big navigation graph for the whole house, some zones of the graph are common for both the cat & the mouse, some other zones/edges are only for either the cat or the mouse. Some edges have low cost for the mouse and high cost for the cat, and vice-versa. All of this is maintained in a single data structure, which is queried with the type of the entity we want to move. ------------------------------------------------------------------------------ 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
