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.
First, to quickly wrap up last week's discussion of the problems with a few apps hanging, I have raised a ticket covering this problem (Ticket 103) and will look to help with a solution later into the summer once I am sure to have met the planned deadlines.
This week work moved on to focus on beginning to implement event driven behaviour trees (BTs). I spent some time studying openly available implementations and have made some initial decisions that I would like to discuss briefly.
The current CrystalSpace BTs parse the entire tree every frame starting from the root node. This will obviously not scale well to large trees or games with many trees. Event driven BTs instead remember where in the tree they have reached and parse only active nodes on each callback.
Therefore, my intention is to add a stack of pointers to BT nodes to the behaviour tree and pass a pointer to this to a node when it is executed. This way parent nodes can push their child nodes to the stack instead of calling their children themselves. Then when the behaviour tree receives it's callback it only needs to execute the top node on the stack.
This will reduce the number of nodes executed per callback to a constant number. It should also help with debugging, as by watching the stack a developer can understand which nodes in the tree are being executed and which path has been taken to reach there.
Furthermore, this should allow me to easily add the function of being able to control the rate of updating a BT as the top node can be executed multiple times per callback (with the callback set to either every frame or by time.) On each execution of the top node the subsequent top node may change and so repeat execution of the top node is effectively parsing through the tree.
Whilst exploring existing implementations and designing our solution I noticed that the easiest milestone to add first was Christian's suggestion of extending the termination statuses. Previously a node would indicate only success or failure on termination, but now (as of revision 4899) a failing node can indicate whether it failed cleanly or whether it has exited unexpectedly. (For more detail on why this is useful please see this article.)
This revision will be used more in the upcoming work on event driven BT's as a parent node will want to check the final status of a child node once the child has terminated and the parent has returned to the top of the stack. To do so I intend to add the current status of a node as a public variable of the iBTNode interface.
Please feel free to comment on this blog, email me on the mailing list or catch me in the IRC channel if you have any comments or suggestions.
As mentioned in my proposal I am now leaving for a conference, and so will not be updating the blog next week nor likely to commit any code. However, I do have my linux laptop with me and the source code checked out, so I may get time to think more about the design and look further into prop classes and existing XML code in CEL (as needed for the later BT milestones.) I will update the blog again Friday 15th June.
See you all in 2 weeks time, Sam.
As the first week of GSoC is coming to an end, I thought it best to update the blog with my progress so far. I intend to (as I did previously during GSoC 2009) post weekly on Fridays with quick updates for anyone interested in following the project.
This week has been mostly occupied by getting bttest to work again. It seems there may be a bug in trunk that is causing bttest (and graphtut, steering and walktut) to hang. I have not solved the problem but I have commited a workaround to my branch in revision 4893. If anyone else is having the problem or has suggestions to fix this please join in the conversation on the mailing list (Archived here.)
Revision 4893 also contains a workaround fix to get plgtcpnetwork to compile as DebugWithDLLs in Windows. Which may also be a general problem at this time in trunk.
The final changes in revision 4893 are what I needed to overcome compilation and linking errors in appelcmtst, plg_guiinventory and plg_guiinventory2 due to CEGUI. I think from the discussion on the mailing list these changes were needed only by me.
Since overcoming these difficulties, I have fixed a minor but significant bug in the bttest app that stopped the tree from being evaluated (see revision 4897.)
I now have a working bttest app, a better understanding of my code from 2009 and am ready to start implementing event driven behaviour trees next week.
A quick update and thank you to all who have helped me out the past couple of weeks. Thanks to the mailing list and in particular Christian's efforts I now have a fully compiled and up to date CS and CEL. I have refamiliarised myself with svn-merge.py (I typically use TortoiseSVN but wanted to stick to the tools other CS developers are using for this project), and with my code from the previous GSoC project on behaviour trees. I now feel ready and keen to start coding next week in time for the official start of GSoC.
I include below my proposed timeline and goals, with priorities labelled 1-3 with 1 being the highest:
-Update to event driven BTs (May 21st – July 1st)
(1) -- Focus on debug tools
(2) -- Allow all termination statuses
(2) -- Add load from XML option
(2) -- Create dedicated propclass (set root node, set update rate)
(1) -- Documentation
-Update to latest version R&D (July 1st – July 29th)
(1) -- Allow iPcSteer to use its methods
(2) -- Partial navmesh loading (with missing sector callback)
(2) -- Make navmesh creation parallel
(3) -- Improve function with portals
(3) -- Optimise debug mesh
(3) -- Optimise Terrain
(1) -- Documentation
-Improve life sim demo (July 29th - August 13th)
(1)-- Make behaviours work (perhaps requiring other new propclasses or
fixes to existing ones)
(1)-- Use new BTs and R&D
During this time, I will have one significant break (as mentioned in my proposal) from June 2nd-12th when I will be attending a conference in Valencia. Other than that I am excited to be back and keen to get started :)
Hello CrystalSpace and thank you for again choosing me for GSoC.
Coding begins again May 21st, before then I will be updating this blog with plans for the new project and getting up to scratch with the recast and detour code.
If anyone has any suggestions for behaviour trees, recast and detour or the life-sim demo please contact me :)
Excited to get started again.
'Guano covered demons from hell!' Exclaimed the preacher, 'I'll be a gypsy whore wobbling O-legged through the doors of this church after a long night out in town If I'd ever let you enter this holy place dressed like that!' I wasn't trying to make a fashion statement, this banana coloured thong was the only piece of clothing still in my possession after Thick Tony raided my place...I figured I'd try my luck anyways 'Sanctuary?' I requested humbly. This just seemed to enrage the man of the cloth even more.... Why was Tony at my place? I haven't pissed him off for at least 3 years, not since I won against him in a match of poker and he carved the now clearly visible 'IOY' in my chest. What changed? Taylor was at my place last month...sweet Taylor involved with Tony's affairs, the thought sends a chill up my spine. Maybe if I had been nicer to her, I could have kept her out of trouble. I dodge a collection plate, the preacher hasn't given hope on kicking me out of his church. I need a lead or at least some clothes, it's already dark outside maybe I'll take my chances on the street. I need a contact, someone that wouldn't run away horrified seeing me like this, Crazy John comes to mind, John has seen it all, the outskirts of Vegas, donkey shows in Mexico, midget wrestling in Texas, midgets wrestling donkeys and every fan art forum on the internet. If there was a person on this globe that could see me like this and consider it the most normal event in his life, it would be John, but would he have reinstalled his passenger seat already? I could use a ride. Empty drive way, shit he's not home! My eye catches a shimmer of the porch light in a piece of glass near the fence, I walk towards it and pick it up, a remnant of a glass jar covered in blood. What happened here? There's something in the weeds as well, a face plate of a Cisco router... Olathe, a crime hub? I chuckle and toss the face plate and bloody piece of glass on the ground. Maybe he's at the warehouse with Brant? I start jogging in its general direction. Have you ever seen a grown man jog in a yellow thong, if you haven't, don't try to mentally picture it, it's not a pretty sight! But I digress, why was Tony after me? Or what and why was it at my place? It doesn't even matter anymore, I'm tired and cold, I just want someone to hold and fall asleep with. Preferably not in this outfit.
|<< <||> >>|
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.