Hey Christian,
I read your e-mail, and here are a few points I came up with:
-Detour would take care of the pathfinding, and it needs data in a specific
format, so CEL's graph representation should be able to provide it. 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). I'm guessing the resulting data from Detour would have to be
converted to a iCelPath.
-As for giving polygons a different cost, I found a threat at the Recast
discussion group (
http://groups.google.com/group/recastnavigation/browse_thread/thread/13f9cdc2b3a45628/a719a2ea4df939bc),
where someone asked about influence maps, and Mikko made a good point
stating that navigation meshes don't make up for great influence maps,
because they tend to be composed of big polygons. He also 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.
-I think it would be best if the navigation mesh could be generated offline,
or at least having the option to choose between online and offline
generation. If we were to allow different costs for the polygons, the meshes
would probably need to be generated offline. Also, if the meshes were stored
in a file, it would open the possibility of later adding a tool to fine tune
them and graphically set the weights, if needed. 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.
-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.
-Dynamic changes to the graph are a problem I still have not really figured
out how to solve if the meshes are generated offline. If we were to remove
some polygons from the mesh, then we could probably mark them as not usable,
or remove them from the graph. To add some meshes, maybe we could calculated
dynamically the navigation mesh for the newly added areas, and then merge it
with the old mesh. Another way to change the mesh would be to actually load
another mesh, for example when some scripted action happens.
-A demo app to showcase the implemented options, and a way to render both
navigation mesh and resulting path.
Forgive me if I misunderstood something. Although I looked through CEL and
Recast's code, it was not enough so I could really know what is going on.
On Sat, Mar 27, 2010 at 1:29 PM, Christian Van Brussel <
christian.vanbrus...@uclouvain.be> wrote:
> Having Recast & Detour (R&D) integrated in CEL is probably the one great
> thing to have, and secondly a good demo/tutorial application. Steering
> behaviors can probably be a GSOC project in itself, and it is better to
> have a good support for path finding before working on it.
>
> Few notes/ideas:
> - the data structure of the navigation graphs of R&D is more complex than
> the one of the current iCelGraph (ie navigation polygons VS simple
> graphs). iCelGraph will probably need to be extended for this.
> - Recast seems to be able to generate the navigation graph on the fly. If
> it is not the case, then it may be needed to have an app to do it offline
> + storage of the graph in XML.
> - A great demo app may include a level with the camera at the top, the
> user can set/update any target to reach, and can add/remove doors and
> paths.
> - A separate tool/property class to display the navigation graph and the
> itinerary may be great.
> - The ability to handle dynamic changes of the graph is probably one great
> functionality to have. Or the ability to climb/jump?
> - The tiling functionalities of R&D are great but probably not needed at
> first.
>
> Unneeded rough ideas:
> - How do R&D behaves on a heightmap terrain? What to do in this case?
> - Some edges of the navigation graph may have different costs, eg it is
> slower to walk in a swamp than on a flat floor. The cost of an edge can
> also vary from various dynamic parameters such as the density of ennemies.
> - Have a mechanism for entities with different abilities, eg entities may
> have different sizes/speeds, or be able or not to climb/jump.
>
> > Hi
> >
> > My name is Leonardo Domingues, and I intent on applying for the GSoC
> > project
> > this year. After reviewing you list of ideas, I got interested in working
> > with the path-finding and navigation mesh creation parts of CEL. Here is
> a
> > draft of my application:
> >
> > "
> >
> > About Me
> >
> > I am a graduate student (graduated in Computer Engineering back in 2008)
> > currently working on my M.S. in Computer Science at Universidade Estadual
> > de
> > Campinas (UNICAMP), Brazil. For some time now, I have been interested in
> > Game Development, specially Game AI, Computer Graphics and Physics
> > Systems.
> > My M.S. project involves using machine learning techniques to train
> > autonomous drivers for racing games.
> >
> > Most of my college assignments were made in C++, so I have some
> experience
> > with the language. Also, for the coding parts in my M.S. project, I have
> > been using C++. As for Python, I also used it during a few assignments,
> > one
> > of which was utilizing the Python Maya package. In this project, Python
> > was
> > used as a scripting language for Autodesk Maya, and I created a small
> > physics demo with falling and colliding spheres.
> >
> > I have played around with some basic DirectX programming, animated some
> > sprites using Microsoft XNA, and I am learning the basics of the Unreal
> > Development Kit (currently building a level with it).
> >
> > For this summer, I will only have to work on my M.S. project, but that
> > shouldn’t take much time. However, I will still be having classes in
> June,
> > so time will be a little scarcer during that month. Having said that, if
> I
> > get accepted I’ll make sure I don’t get behind schedule.
> >
> >
> >
> > The Project
> >
> >
> >
> > - Integrate the Recast toolset into CEL, so navigation meshes can be
> > generated automatically from the maps. This would involve converting map
> > structure into one that Recast can work with, exposing the Recast API
> > through CEL and defining how to store the navigation meshes.
> >
> > - Integrate the Detour toolkit into CEL, in order to replace the
> > default
> > A* path-finding algorithm with a more robust version.
> >
> > - Create a demo application showing the creation of navigation meshes
> > from maps, as well as the use of those meshes in path-finding.
> >
> > - Continue the work on steering behaviors (if there is enough time).
> > "
> >
> > I am still going through the code of both CEL and Recast & Detour, so I
> > can't give any details about how I plan on implementing the proposed
> > features at this time. I plan on updating this application after I review
> > the codes.
> > Any ideas about features you would like to see and comments about the
> > application would be much appreciated.
> >
> > Leonardo
> >
> ------------------------------------------------------------------------------
> > 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
> >
>
>
>
>
> ------------------------------------------------------------------------------
> 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
>
------------------------------------------------------------------------------
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
