SamD

2012-07-27

Further R&D Updates, and Concern Regarding PcSteer

Hello CrystalSpace,
This week I have been focussed almost entirely on celPcSteer, celPcPathFinder, celHPath and celHNavStruct. I have spent more time than I care to admit trying to get my head around these, but before I get into my concerns regarding this I would like to briefly comment on the positive outcomes of this week. In particular:

- Revision 4933, which fixes the problems I mentioned in my update to last week's post when saving/loading navmeshes with the new R&D library. These are now resolved, with no changes to the CEL api and so all existing apps using R&D should be able to now use the latest available version of the library.

- Revision 4936 switches to creating NavMeshes in parallel. On my single-core machine this causes a significant slow down. To avoid this, users with a single-core machine can call the thread manager's SetAlwaysRunNow method with true passed as the sole argument. An example of this is included in the message attached to this revision. On multi-core machines this should be faster, any readers with a multi-core machine and willing to test this are greatly encouraged to join in this discussion on the mailing list.(Updated 30/07/2012)

Moving back to my work on integrating R&D into PcSteer, I have noticed significant redundancy between the classes celPcSteer, celPcPathFinder, celHPath and celHNavStruct. In particular celPcPathFinder and celHPath both seem to be designed to create high level paths between sectors. The exception being that celPcPathFinder also includes steering behaviours. I think these classes could do with a significant refactoring. I see no purpose to celPcPathFinder now that we have celHPath. Instead I think celPcSteer should be tidied up, made to use celHNavStruct and some of the functionality from celPcPathFinder included (i.e. cyclic and two way paths.)

Furthermore, some of PcSteer is simply not functional - as noted as far back as revision 3391 by caedesv (Pablo?) This does not seem to have been resolved since but is probably beyond the scope of my summer project.

I also think there may be room for some links between DetourCrowd and the separation and cohesion methods of PcSteer. I have not looked into DetourCrowd sufficiently at this time to comment further on this, but perhaps this would also be a way to improve these plugins in the future.

Overall, I am trying to use this blog post to collate my views but am very keen to hear any feedback at this time regarding these suggested changes. Some of you may have reasons to keep celPcPathFinder for instance or a suggestion for a better refraction? My concern is that as it stands the overlap of these modules is unnecessary and makes choosing which to implement challenging.