This week has been decisively marked by Jorrit's discovery of a number of bugs and inefficiencies in the Recast&Detour plugin. I have dedicated my work to fixing these, and hope to have a solution before I need to head off for the weekend. Fingers crossed I can do it in time :) Either way I will commit what I have so far before heading off and finish any problems remaining early next week.
As I am still working on this, I will keep this week's post brief. The most significant commits I have made this week are revisions 4936, which switches to parallel construction of navmeshes, and 4942, which allows pcSteer's seek method to use R&D for pathfinding.
The parallel construction has been tested by a number of members of the community and appears to have sped up construction successfully. The integration of pcSteer and R&D shows how these two can work together. However, there is a lot more work that could be done, as I alluded to last week, to update pcSteer and pcPathFinder. Unfortunately, with the end of GSoC now in sight I will not have time to do so as part of this project. I will, however, make sure to write up all my thoughts on this fully during the write up week and may be able to spend some time on this later in the year.
Next week is the last official week of coding, it's going to be a busy week of coding to meet my last intended deliverables but I am confident that I should be able to complete all top priority deliverables.
But to do that I best get back to the code... :)
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.
I'm very glad to announce that my problems with Google's website have been resolved and I have passed the midterm assessment. I am very grateful for all your support in this project and am enjoying the experience greatly.
This week has been a frustrating, learning experience getting very familiar with the MSVC debugger. My progress so far is that all necessary changes to accommodate the API changes in Recast and Detour(R&D) have been made (See r4930) and all previous changes made by Leonardo and others that were lost in the update have been reimplemented (See r4931).
Finally, revision r4932 fixes a few minor issues that were causing unexpected results when building a navmesh. As far as I have tested both appnavmeshtest and apppathfindingtest are again fully functional as of this update.
Next week my focus will shift towards allowing iPcSteer to use the functionality of these libraries. I will also need to reconsider (with my mentor) my schedule for the remainder of the project. If anyone has any comments on what should be our priorities please feel free to let me know.
Update: There seems to be some issues with saving and loading navmeshes still, I will make fixing these my first priority next week before moving on to iPcSteer.
Well we've reached the midway point of the summer (although you wouldn't know from the weather here!) I've been having some trouble this week with the google website after completing my midterm assessment but hopefully this is not a significant problem and I will find out over the weekend if you are all sufficiently satisfied with my progress to continue.
I have begun this week to work on the Recast and Detour (R&D) part of my project. So far this has mainly consisted of getting familiar with the library and Leonardo's previous work implementing it into CEL. I have committed revision 4928 which updates the library files to r345 of R&D and have since tested them in msvc - they do not yet compile.
A number of changes need now to be made to
cellhpf.h/cpp to accommodate the API changes in R&D since the previous version (187) used in Leonardo's work. In particular I have limited the necessary changes down to the following R&D blog posts:
Once complete I may also need to (re)implement the following changes previous made to fit R&D into CEL:
I intend to work on these updates next week (provided the midterm has been passed successfully) with the aim to have the example apps
apppathfindingtest fully functional with the new plugin and latest R&D library by this time next week.
I have just committed the final deliverable for the behaviour tree (BT) portion of this GSoC project. As of revision 4927 BT's can now be loaded from XML. This functionality is also demonstrated in this revision of appbttest.
As mentioned last week this deliverable is slightly behind schedule, but at only 5 days late and given the significant improvements in the BT code, I hope you all agree that this part of the project has been a relative success - especially given that midterm evaluations are coming up next week! :)
I am taking a slightly long weekend, leaving shortly and returning Monday. Unfortunately I will be offline for all of this time. However please feel free to contact me if there are any suggestions regarding the code or the next stage of the project and I will get back to you asap Monday.
Next week I will begin work on the recast and detour code, but until then I hope you all have a good weekend.
Ocean looked nice with connected meshes but it lacked reflection and refraction. Although Ocean is actually a deep water system thus should have no refraction but I did it anyways. For this implementation i followed this Paper.
It involved 5 basic steps.
1. Create the reflection texture : provided by engine
2. Create the refraction texture : provided by engine
3. Distort the textures according to a dudv-map :- We don't need it as it's used to apply distortion. Normal map worked equally great.
4. Apply bump mapping : not needed since we are using vertex shaders to generate waves.
5. Combine with fresnel effects : no problem :)
and here's the result
-ocean exhibits No caustics. Caustics are already implemented in CS but aren't in ocean
-This shader is *not* shaderwaver. It is regular vertex and fragment program.
-LOD pops out as you move along.
-ocean doesn't entirely covers the island. a possible solution for it could be to increase the cell width and leght and corresponding parameters. so that it covers more area.
-also waves direction appears to be changing between different LOD when viewed from top. implementing inverse FFT could remove it, I think.
So Crystal Space had a Ocean system in which Ocean was made by combining little ocean cells(20x20). These ocean cells would have different Level of Details(LOD) Governed by distance from camera. This distribution of LOD wasn't quite working as distance computed between camera and the cell was actually a *squared* distance and comparison was made with actual distance. Also cells re-positions themselves as camera move parallel to ocean. This re-positioning was causing a jerk. Well, both these bugs are fixed now. :)
Now comes the major issue *aaahhhh*. LOD distribution was working fine but the problem was with adjoining ocean cells of different LOD. for example one cell has LOD 5 and adjoining cell had LOD 4. Now LOD5 has double the vertices at boundaries than LOD4. and since the vertices are moving in waves like patterns so the ocean cells looks unconnected and Thus looked Ugly.
Thanks to Nvidia's ocean demo(and of course my mentor res) I was successfully able to replicate their implementation to rectify this problem. Checkout the wireframe rendering of ocean.
Here's what's happening.
Now have a look at this
Yellow color represents an oceancell.
Blue color represents inner mesh.
Green color represents the division line of outer meshes for a single cell.
there are four outer meshes for each cell.
Red color represents how LOD levels are connected using low res boundaries in higher LOD cell.
The vertices for a cells are computed as usual. The real magic happens in computing the triangle(tris). tris for inner meshes are computed as usual. then 2^4=16 different cells are created for one LOD level and stored in an array.
2^4 where 2 is the resolution ie low/high and 4 are edges Top/right/bottom/left. That's how we got the number 16. Desired cell(out of 16) selection depends upon LOD level adjoining cell.
This week I have switched the previous celBehaviourTree to the dedicated propclass celPcBehaviourTree. There were numerous commits but most importantly, revision 4916 includes a fully functional BT prop class and example usage in appbttest.
These revisions also add the abilities to interrupt or reset a behaviour tree and to set how many nodes per frame are parsed.
With the 1st July rapidly approaching, it is apparent at this time that not all goals of the BT portion of this project will be completed as originally scheduled. My mentor and I have agreed that the best way to proceed will be to continue with BT development for now and complete the load from XML deliverable. I will then move on to the Recast and Detour work hopefully by the end of next week and, therefore, not significantly behind schedule.
Finally, I would like to publicly note my gratitude for all the assistance I have received this week. Thank you all - especially Anthony, Christian and Mat! :)
As intended this week I have focussed on making more use of the behaviour tree(BT) specific return status BT_UNEXPECTED_ERROR. In particular, revisions 4908 and 4910 add the reporting of nodes not having the relevant children, rewards, triggers or parameters specified first with severity notify at the node itself and then again with severity error if the unexpected error is not handled but propagated back to the root of the tree.
Revision 4908 also added the method
void SetName (csString nodeName) so that BT nodes cane be given a name, which is then reported if an unexpected error occurs. This should simplify debugging large trees.
Finally, in revision 4909, I added the method
void MakeLoopInfinite () to the loop decorator allowing the node to be set to run forever whilst the child returns BT_SUCCESS. If the child fails, then so does the loop. This will be useful as a root node for many behaviour trees as often non-player characters will be expected to continuously repeat some set of behaviours.
I have begun now to think about the dedicated BT propclass and loading from XML. I hope to make significant progress next week towards at least one of these desirable deliverables before beginning to work on the recast and detour side of this project which is scheduled to begin after next week (for the original timeline please see this post.)
Well I'm back, had a great conference and have dived into implementing the stack-based behaviour tree I discussed here before leaving.
One design change I found necessary was to add another status, BT_NOT_STARTED, to use in resetting and initialising nodes.
Revision 4907 switches from the previous 2009 method of parsing the entire tree every frame to passing a single node every frame. This will make the method far more scalable and should help with debugging as progress can now be tracked in the behaviour tree's stack. This is a significant revision that is key to this part of the project. If there are any comments in particular on this revision I am very keen to hear them.
In a smaller commit, revision 4906 merged all changes from whilst I was away and since I began coding. I intend to complete these merges at least once a fortnight to make the eventual process of merging my branch to trunk far simpler.
That's all for this week, next week I intend to add more to the debugging tools by making better use of the status BT_UNEXPECTED_ERROR and starting to look into loading from XML and making a dedicated propclass for the behaviour tree. Any suggestions either here, by email/mailing list/irc are always appreciated.
|<< <||> >>|
This is the long description for the blog named 'Blog All'.
This blog (blog #1) is actually a very special blog! It automatically aggregates all posts from all other blogs. This allows you to easily track everything that is posted on this system. You can hide this blog from the public by unchecking 'Include in public blog list' in the blogs admin.