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.
I ran out of roads to walk down and sailed the seven seas, more than men but less than a man, my ashes blowing in the wind and my words turning to whispers on the lips of the ones that once knew me.
Masks is what we wear, the truth is behind it, not out there. Made from cardboard, plastic or papier-mache, we think it hides all our cares away. Sometimes we switch masks, but we never take it off, afraid forever, to love.
As mentioned in the previous post, the main problem was that Cg allows to specify vertex/fragment shaders independently whilst GLSL does not. In fact as I explained last time, GLSL shaders require a linking process that binds the vertex and the fragment shader together. The linking process makes a GL object called a "program" which represent an entire pipeline itself. Shader parameters and other stuff are acting on this object. The shader plugin system of Crystal Space wasn't much designed this way, however layers on top of the plugin system are considering a shader as a pair of vertex and fragment shader, which simplified the work.
Basically, Crystal Space wraps vertex and fragment shaders (csShaderProgram, which implements iShaderProgram) into a single csXMLShaderTech class that is used for rendering. The shaders are specified in the corresponding XML shader file. The basic idea was "iShaderProgram should represent an entire pipeline (so a set of shaders) instead of a single shader". To ensure backward compatibility, this was achieved by adding a simple wrapper class, csXMLShaderWrapper, that holds a vertex and a fragment shader from the old Cg or ASM plugins.
The new GLSL plugin doesn't need to use this wrapper since the shader object provided already contains an entire pipeline, ready to use. A new XML syntax has been setup for shaders that don't need wrapping. You were currently specifing shaders like this:
<![CDATA[ /* code... */ ]]>
<![CDATA[ /* code... */ ]]>
As you can see, plugins are specified independently; a GLSL plugin could hardly fit this design. The following syntax has been defined for the new plugin:
<![CDATA[ /* code ... */ ]]>
<![CDATA[ /* code ... */ ]]>
The "unification" is made more explicit and the code is lighter.
Welcome to my GSoC 2011 blog! Here you'll be able to follow the progression of my project for Crystal Space.
This is my first time participating to the Google Summer of Code, and I'm glad I've been accepted into the project I was most interested in. My project will consist of, basically, add support for OpenGL GLSL shaders into Crystal Space, which currently provide support for OpenGL ARB and nVidia Cg shaders. Ideally I'd also like to add support for the famous geometry and tessellation shaders, which would allow Crystal Space to implement new generation and cool rendering techniques based on them. The project will be implemented as a Crystal Space plugin.
The main design difference between Cg (and ARB) and GLSL shaders is that Cg allows you to bind the vertex and fragment shaders independently while GLSL requires them to be linked (and thus non-separable) into a "program" before being used. Fortunately, Crystal Space's architecture doesn't use much of the "separable" functionnality provided by Cg, facilitating therefore the setup of a "unified" design, much like GLSL's. This will involve a new syntax in the XML shader files used by Crystal Space in order to make explicit the use of the "unified" model.
I hope that by the end of the summer I could provide a nice tessellation demo, but for now I have to focus on the core of the new GLSL plugin and its integration into the engine.
Have a nice summer! :)
This post will talk about the different ways to import assets into Crystal Space, and will present the recent improvements that have been made about that.
CS had until now several different solutions to import the models and scene objects from the many different 3D design tools and file formats.
Blender has always been until now the editor with the best support for CS. The blender2crystal project is a huge piece of software, with many advanced functionalities such as import and export of CS files, CS previsualization window directly embedded into Blender, animation tree edition, etc. Unfortunately, the blender2crystal project is no more active and has been overtaken by the Python 2.6 and Blender 2.5x series, it is blocked to the Blender 2.49b with Python 2.5 version and may hibernate there forever.
Currently, the solution to export data from Blender 2.5x into CS is to use the B2.5CS exporter from Peragro Tempus. It does not yet have support for animeshes, but it is planned to become the official exporter for CS and should therefore be improved in the future.
3D Studio Max had also some rather good support with either the exporter script from the PlaneShift team or the exporter plugin added recently by Mike. And for other 3D design tools and model file formats, CS had several solutions with either dedicated importers and/or exporters for COLLADA, Maya, Cal3D, md2, BSP.
So this was the situation until recently, but a big part of this has now been obsoleted by a new addition made recently to CS, namely the new plugin for the Open Asset Import Library (A.K.A. Assimp).
As suggested by its name, Assimp is an open source library providing a generic interface to load 3D models and scenes from a huge list of different file formats. It can import the meshes, the material properties, the skeletal animations, the lights, cameras and complete scenes. The support for vertex and morph animations is planned but not yet implemented. The support for meshes and material properties is rather excellent for all the listed file formats, while the quality of the import of the animations may vary depending of the format.
The Assimp plugin that has been implemented in CS uses the new guidelines for the preprocess and tool plugins. This basically means that the plugin is integrated completely transparently into the CS loader system: you simply drop any asset file of one of the format supported, and it is loaded magically in CS, without any further need to manipulate or export/import previously the file.
An example has been added in CS with the Seymour COLLADA animated test model. It is composed of one data file and one texture file that have been packed in a ZIP file in 'CS/data/seymour.zip', and the following image is the result of the command:
Technically speaking, this plugin simply implements the iBinaryLoaderPlugin and iModelLoader interfaces of CS, as any other CS-specific loader plugin. Therefore, when the iLoader is used to load a file, the Assimp plugin will be selected if it supports the file format. It will then analyze the file, and import the objects as genmeshes, animeshes or whole scenes depending on the loader interface used and the options that have been set.
Another interesting feature of the loading system of CS is that the definition of an object can be split in several files. It is therefore possible to have your model in its base format and being kept updated by your artist team, while still being able to already use this model in your application and extending its definition with CS concepts such as physics or more advanced management of the animations. These concepts will simply be defined in a separate CS XML file and will add their data ontop of the one loaded by the Assimp plugin.
A problem that has been mentioned about the Assimp library is that it does not yet support the import of vertex and morph animations. To overcome this, some tools have been added to CS in order to load and merge an animesh with its morph targets defined in several different files. Again, this functionality has been made using the new guidelines for the preprocess and tool plugins, meaning that you can activate this process transparently through the iLoader interface. An example of that has been added, using the default model from the FaceGen software. Here is the result of the command:
Lastly to be mentioned, there is the new exporter plugin for the PnP TerrainCreator editor, that has also been added recently by Mike. This last plugin should be presented more closely in an incoming post on the new 'csisland' demo.
|<< <||> >>|
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.