Yet another GSoC, only this time its shadows.
And that's how the CS water looks.
Shader weavers are intimidating at first mainly because it is difficult to debug them and connections are quite confusing.
The basic idea of weaver can be learned from here. However, the code written in it is outdated... better to go with code.
Following are some weaver debugging techniques that I learned.
1. Debugging by altering the output color. ex
if(something_happens) bug=1.0; op_col.r+=bug;
2. CS flag to Disable shader cache : -cfgset=Video.ShaderManager.EnableShaderCache=false
3. CS flag to Dump shader program at %temp%\shader : -cfgfile=/config/shader-debug.cfg
4. Dump textures at %temp%\textures
a. CS flag : -plugin=bugplug b. ctrl+d c. ctrl+shift+t
5. Switching between CG/GLSL
a. simplest way is to delete the shader plugin that isn't needed. b. Disable GLSL only : -cfgset=Video.OpenGL.UseExtension.GL_ARB_shader_objects=false c. remove/edit the GLSL/CG technique in main entry weaver.
6. CS flag to check syntax error: -verbose
Entire water's shader code has been ported to weaver which will enable to add post effects easily. Plus heightmaps to generate natural water waves and larger ocean size.
Now it looks like this...
So I had prepared couple of thing that had to be done before actually starting with interactivity.
1). Porting XmlShaders to ShaderWeaver.
2). Mismatching of texturemaps.
3). Large Size of Oceans
4). FFT in oceans
As for 1). I tried to port the code, but I'm kinda still struggling to get it right. Thanks to res, Rlydontknow and Sueastside I'm able to understand them quite well but still weird errors priest.
The Mismatching actually didn't existed in temporary weaver code. so I guess the complete weavers should fix this issue.
The values of CELL_WID, CELL_LEN and MAX_OCEAN_DISTANCE are increased to spread the ocean even wider. but they increased the pre-computation of LODs thus the "gran" (vertex per tile) had to altered accordingly. gran = pow(2.0,LOD_type)/64.0f;
FFT needed VS texture mapping, but weavers weren't complete at the moment. So I decided to give it a shot in old shaders. If you look at the FFT implementation then you'll find that FFT is essentially creats a complex "texture". FFT calculations are very heavy. Thus it would rather be easier to just take a heightmap and use for ocean waves. It actually gives pretty decent result.
Along the way I found that the ocean water move along the camera which shouldn't happen because in a game water usually stays at one particular position. It does that due to LOD calculations. So along with taking waves parameters from the world file, the plugin will also take position and radius to which the user wants it to extend.
This Summer is going to be really exciting. I'm gonna beat the heat by mutating the CS water system. Thanks to CS community for considering my proposal on water simulation. Watch out for Wet CS!
starting with shaders. ;)
Since my blog post on Friday, it has been brought to my attention that behaviours and the behaviour layer have been deprecated. Several of the apps I have worked on this summer, and in 2009, use these methods. In particular they are: bttest, pathfindingtest, questtest and steering. An example of how to remove this dependence from them can be found in Jorrit's revision 4958. There is not enough time left to make similar changes myself before the end of GSoC to all the apps I have worked on, but I have begun the removal of them from the life sim demo (Please see revision 4972.)
I have also, since the summarising post at the end of last week, kept myself busy trying to create a navmesh for the island level used in the life sim demo. Unfortunately, during construction an assertion fails in
celNavMeshBuilder::GetSectorData. More specifically the problem seems to be in the line
polyVerts = csVector3(xbase, cell->GetHeight(x,y), ybase); and occurs because at this time
csTerrainCell::heightmap is empty.
This will be my last update for the summer as the hard deadline set by google is today. However, I do hope this will not be my last involvement with CrystalSpace/CEL. I will continue to keep an eye on the mailing list and occasionally lurk in the irc channel. Thank you all again for having me for another summer and I hope the code continues to be of use to the community.
With the hard GsoC deadline rapidly approaching, I thought it suitable to wrap up what I have achieved this summer and my ideas for future development that could be done in the areas I have been working.
Event Driven Behaviour Trees.
Behaviour trees have been updated to an event driven design using a wider, more expressive set of termination statuses (See BTStatus in tools/behaviourtree.h.) Instead of evaluating the whole tree every frame, the new trees only expand a set number of nodes each frame. The number of these can be set using the property "Update Rate." These changes will improve the ability to handle large trees or applications with large numbers of characters.
Furthermore, I have implemented the behaviour tree as a propclass allowing a tree to be assigned to an entity. Because of this change trees are now executed by performing the action "BT Start" as opposed to the previous method of executing the root node. Examples of this can be found in appbttest and the Frankie's in lifesimdemo.
The manual coding of trees, however, has remained largely the same - with nodes constructed and children added using the same methods. Therefore, existing implementations only need to replace the previous execution of the root node with the initiation of the propclass celPcBehaviourTree and starting it by the action "BT Start."
Alternatively, behaviour trees can now be designed in and loaded from XML thanks to plgaddon_behaviourtreeload.
Other methods have also been added, most notably the ability to name a node by SetName allowing for clearer debug messages when a node raises an unexpected error and allowing loop decorators to loop infinitely.
Examples of how to load a behaviour tree from xml are available in appbttest and the life sim demo. Appbttest also has an example of constructing a behaviour tree in code and a related tutorial in the cel user manual.
Future work that may be helpful for the further development of these tools include a save to XML method (for outputting trees either coded or loaded and then manipulated at run time), the continued development of additional decorators (expanding the capabilities of the trees) and the incorporation of behaviour trees into csEditor and/or AresEd. I think the latter may be the key to wide spread adoption of this method in future applications and so am very keen to assist with this where I can post-GSoC.
Recast and Detour (R&D) Update.
The R&D plugin has been updated to revision 345 (the currently latest available) and the construction of NavMeshes is now performed in parallel.
I have also fixed a large number of issues left over from the pre-existing implementation of this plugin that required app developers to handle the deletion of variables initialised within the R&D plugin.
Appnavmeshtest and apppathfinding both demonstrate how to construct, display and use navmeshes.
Due to the unexpected discovery of the bugs mentioned above, I did not get time to get around to a number of deliverables that were considered lower priority but would be significant improvements to the R&D plugin. Namely they are the better handling of portals and the partial loading of NavMeshes. The first I think is a key improvement and should be addressed asap as the current method hardly/doesn't work and effectively limits users to only path finding within a sector, not across sectors.
Other issues noted with the creation of NavMeshes that could do with further attention have been noted in the outside sector of the bias level and the interior sector of the castle level.
Bias Level: Outside Sector.
When constructing a navmesh for this sector, the process seems to never stop. However, I predict it would given a very long time. The delay is in the double for loops on lines 2343-2345 of celNavMesh.cpp in the function celNavMeshBuilder::BuildNavMesh. Normally tw and th take values approximately in the range 1-20 but for outside they are both over 600. I think this is because the outside sector is huge, but also because it is a very uniform, flat surface. However, the latter should make it very simple to cover.
Castle: Interior Sector.
The navmesh constructed for the interior sector appears to be made up of multiple overlapping (and slightly different) navmeshes. There should be only one. I think this may be related to the handling of portals, because if you generate the navmesh for this sector alone or even with only one other sector it does not occur. As soon as navmeshes are generated for this sector and two others the overlapping occurs. I think that focussed efforts on a new method of handling portals will fix this incorrect behaviour. This problem is less severe than the above, however, as the path finding still works correctly in this sector despite the overlapping meshes.
Finally, I have also added methods to PcSteer for adding a HNavStruct if available and then using this when seeking to find a path rather than the bespoke path finding solution previously used. For an example of this use please see appsteering.
The work I have done on PcSteer could be improved by allowing pursue, flee and wander to also use the HnavStruct but I think a more significant change should be made to this plugin.
I propose that the plpfsteer is deprecated and the functionality of pcSteer merged into pcPathFinder. If the merged propclass is given a HNavStruct it can use that to move between sectors and pathfind within (with HNavStruct eventually being updated to have improved functionality between sectors) or alternatively it is given a celGraph to move between sectors and uses it's naeve move directly towards goal position pathfinding within them. It would also then allow methods such as FollowCyclicPath or FollowTwoWayPath to be used with R&D as well.
The new pcPathFinder would then include all methods for moving agents in an environment with the possibility of using either the celGraph or the recast plugin. Rather than the current convoluted architecture where pcPathFinder uses celGraph and pcSteer which may or may not use the R&D plugin.
In closing, I think this has been a very succesful summer. I feel this year I have learnt a lot more about the architecture of CEL as a whole and the experience of fixing memory management bugs in other people's code I'm sure will be priceless in the future (despite how frustrating it was at the time!)
Last GSoC I hoped to continue working on CS/CEL after the summer alongside my PhD, this never happened because I understimated how much of my life would become my PhD. After this GSoC I will be writing my thesis and trying to secure a job, so I will not make any promises for how much code I will be able to commit but I do hope to still be a part of the community and assist where I can with getting this code merged back into trunk and used more in future games and applications.
Finally I would like to thank everyone that has made this summer so productive and enjoyable. In particular: Anthony for being my mentor, Christian for his input and advice throughout, Matthieu Kraus for some key comments/suggestions regarding R&D and Jorrit, Vincent Knecht & Anders Reggestad for checking out my branch and testing/trying the apps I've worked on. Thank you all.
As expected it's been a tough week of coding, but I'm proud to say that as of my latest revision (r4963) appSteering, appPathFindingTest and appNavmeshTest are all working again, with the latest R&D library and without the deletion of variables initialised in either the recast or celgraph plugins. These deletions, left over from LeonardoRD's original work on integrating R&D, were not picked up on when compiling with DLLs but were when compiling with static libs.
Officially this is the last week of coding for GSoC, however, the suggested end of coding is next Monday and I intend to push that to the maximum to complete the last of the original deliverables on my list; adding a working Frankie to the lifesimdemo using the new BT and R&D code. It is not as much as I had hoped to achieve in the lifesimdemo but due to other issues like the bugs mentioned above this will be all there is time for now.
After this the focus is documentation, which I think can justifiably include updating the apps I have worked on to
CS::Utility::DemoApplication so that instructions on their use can be displayed by
iHudManager and the
PrintHelp() method. It will also include thoroughly documenting the changes I have made and the changes I still feel need to be made to pcSteer/pcPathFinder.
I hope you are all happy with the code I have added, and I look forward to helping (where I can) with integrating it back into the trunk.
So finally I finished with Shoreline implementation. I know my work should be over by now but I'm happy with new things i'm learning each day. :D. Basically I took a foam texture (programmers art like) and blended it on ocean mesh where ever ocean touches terrain.
This is done by first getting all the points( These points are in world space) where ocean touches terrain and then scale them down to store it in an array. Till now all steps are pre-computed on CPU. That array is now passed to shader program. Now in a vertex program, nearest distance between vexter position and array of foam points is computed and then that distance is passed to fragment program. In fragment program foam Colour is clamped depending on the distance.
I got pretty much everything working with ease except for first step i.e. Getting the foam point.
To get foam points first I got terrain from engine into the water plugin. Then iterated over each terrain cell's height map. Now the thing took me so long was that The coordnate system usually start from bottom left corner so are iteration over cells. But when you are performing texture(heightmap) lookups the coordnates start from top left corner. It took me 7 days to understand this.
This is how it looks like:-
*Array size is limited to 1000 a better way would be to create a texture and store all those points in it and perform a texture lookup in shaders
*This shoreline only works for Terrains. In order for them to work for any mesh, a plan collider can be used to get foam points. Rest of the steps would remain the same.
<<>> OLDER STUFF>>
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.
| Next >
|<< <||> >>|