Summer of Code - General Info
General information for GSoC and Crystal Space can be found at this page.
Summer of Code - Partner projects
- Digital Assets Managed neatly or DAMN is a Project and Content Management platform targeted at game creation. Take a look below to see a list of their ideas.
Summer of Code - Project ideas
As Crystal Space is a 3D engine, there should be plenty of opportunities for interesting projects. If the intended end result is nice and shiny, it's probably a project candidate ;). So feel free to submit your own ideas, or discuss them some of the administrators/mentors if you want some more guidance. At this point no specific project has been assigned to any specific mentor, so if you cannot find "the" mentor for your questions, try to talk to Jorrit, Frank (res2k) or Christian (kickvb) and they will help you out.
Below you will find our proposals for things to do within the Crystal Space project.
Game/Demo showing CS Features
We would like a set of small, single-serving games dedicated to showing off the features available in Crystal Space. As a project for this summer, you can propose a small game that demonstrates as many of the features of CS as possible.
The main target applications are the csbias, csisland and Crystal Core demos that should be enhanced with ideas such as the ones listed here. You can also propose a new application but this is not encouraged, and then you should take care of not having the need to spend too much working time on concept designing or asset management, and you should try to emphasize as much as possible the current abilities of CS.
Your proposal should include the following:
- The list of features you plan to add to the current demos, or, if it is a new application, the conceptual idea of the game, with a initial set of rules and gameplay characteristics. (You don't have to include any concept art, but if you want to, feel free!)
- General structure of how the program will be designed (general plan for breaking the game into a set of tasks, and a schedule of these tasks).
- Discussion on what assets will be required and where those assets will come from.
- Discussion on which features you would like to highlight from CS, and how you intend to go about doing that.
Because this is a much more general project than some of the other, more specific and refined tasks, it will likely require a more rigorous schedule. For this reason, we //highly// encourage you to propose the idea on the mailing list or in IRC before submitting a project idea, so that the community can discuss the idea and help you to refine it before submission.
Note on Assets
One of the most challenging parts of developing a game (for programmers) is finding a source for graphical assets. Unfortunately, by Google Summer of Code rules, we're not able to support a student to design assets for the summer. As such, it's unlikely that a student who is working on the GSoC in this project area will have the time to devote to building their own assets for the game. We thus are looking that you find a source for your game assets. You can safely use assets from the following locations:
- To be privileged: any assets currently in the Crystal Space source tree.
- Yo Frankie (Open Game Project between Crystal Space and Blender)
- Crystal Core
Assets that are acquired from any other source will require a release from the author, or some form of proof that the content is available under an suitable Open Source or Creative Commons license – i.e. you can't simply take something from deviantart or blenderforums and incorporate it into your project.
http://opengameart.org/ is a website dedicated to free & open game art and is probably a good starting point to find assets. Still, it's hosted content is licensed under various conditions, so some license checking still has to be done.
You must also pay attention to the size of those assets data and try to limit it as much as possible.
Car racing games improvement
This project would have the global goal of adding and improving the functionalities for a car racing game. This can include the following ideas:
- Improve the behaviors and functionalities of the vehicle class within the physics2 plugin.
- Improve the support of terrains in the physics2 plugin in order to be able to define different physical properties depending on the materials of the terrain.
- Add particles and skid marks at the rear of the tires and when hitting objects.
- Destruction model of the car.
- Sounds modulated by the speed of the engine.
- Lights and horns.
- Turbo engine.
- Other ground vehicles such as bikes and tanks.
- Motion blur when moving fast.
Improvements to VFS (Virtual File System)
CS has used a VFS overlay to handle files in a platform independent way since a long while. But while many basic functionalities of file access are there another good amount of them is missing: Copying files, moving files, changing attributes for both archives and real file systems are just an example of such things. Improving this layer by adding more functionalities might be useful to increase the easiness of use of crystal space and avoid obliging projects using CS to implement their own file system functionalities to overcome these limits.
In that goal, a new VFSv2 implementation has been started during the GSOC 2012 (see here, based on the ideas listed here. The goal now would be continuing the work which was started, after syncronizing with current Crystal Space head revision.
Material and shader weaver editor
This project would have the goal to implement an editor for materials and weaver shaders.
Weaver shaders in Crystal Space can be defined by a set of shader snippets that are combined for more advanced effects. The combination of snippets forms a graph structure with links connecting together the various snippets. One main goal of the editor would be to provide the functionalities needed for the edition of such graphs.
The work would be split in two main tasks: implementing a graph node editor and using the graphs for editing the materials and shaders.
Graph node editor
This would be a general graph node editor, allowing to define nodes and links between those nodes, and abstracting the actual node types that are manipulated. It is designed to be used in several places such as a shader weaver editor, an animation node editor, and a behavior tree editor.
Such tool has already been started in some previous work (available here). The main issue would be to update the API to fit with the new iModifiable interface.
Material and shader weaver editor
A specific editor would be written, to be included within the cseditor framework (see the 'CSEditing' branch). This can include:
- Display of textures and materials.
- Material definition: shader and shader variables.
- A shader weaver editor based on the graph node editor.
- The current API for shaders might not allow all the manipulations needed for an editor, and adding some accessors methods might be needed.
Crystal Space can handle large scaled terrains with paging, multi-splatting, decals, deformations, and can use a mesh generator to dress them up with objects such as flora and rocks. It is however lacking an editor in order to define all these properties.
A GSOC project on that topic would work on this editor, trying to achieve as much as possible of the functionalities listed below:
- To be made as a set of tools in the cseditor framework (this also means that it will also benefit of the tools already in cseditor).
- Definition of the basic terrain properties (count of cells, size, etc).
- Use decals to display the mouse cursor and the current modification primitive.
- Heightmap modifiers using different primitives and weight (see the application csterrainedtest).
- Painting of the splatting textures.
- Painting of the decals.
- Painting of the mesh generator materials and properties.
- Optional: different display modes: eg wireframed or textured.
- Optional: import from other (very raw) formats.
Crystal Space new(er) lightmap calculation 'lighter2' has over the last years been improved to a state where it can replace the older lightmapping system and generate nice-looking static lighting. However to fully compete in quality with commercial alternatives it does need a set of improvements.
At this moment, the most interesting parts in 'lighter2' to look at are:
- Light probes: sample information in incoming light at different points in space. A full implementation would include a lighter2 part (generation of light probes) as well as an engine part (loading light probes, and setting information on meshes from the light probes). In fact, a framework for light probes would be a more interesting result than a fancy light probe style. (Light probes here means information about incoming lighting at some points in space. Think of it as kind of a lightmap in 3D. "HDR light probes" are _not_ meant here.)
- Improve directional lightmaps: lighter2 already has support for that, but the implementation isn't great - it could use a cleanup. And, of course, some improvements: e.g. right now, directional LMs are enabled globally, per-object control would be desirable. They should also be "future-proofed" so e.g. photon mapping can be dropped in easily. -- This is more of a "janitorial" task, but it would be great for people that don't like to juggle much with maths, but love to solve real-life implementation problems ;)
- More memory efficient data representations. At the moment the data needed for computing the lighting takes massive amount of memory (multi-GB on big levels) and the techniques needed to handle it (explicit swapping, compression etc) slows the process down. A student with strong interest in data structures should be able to find a more memory efficient data representation.
- Improve the configurability of lighter2. Currently lighter2 takes a lot of runtime configuration parameters, especially for photon mapping, it would be great to have more configurability in the sense that the end user should be able to mention some basic stuff based on which most of the parameters should be set, or read from a config file, and also providing an option to mention them explicitly if required.
- Implementation of area lights. Full implementation and support would be desirable for quality of lighting. Might relate to photon mapping.
- Automatic resolution reduction - so a lightmap only uses the resolution it needs, like described in http://www.bungie.net/images/Inside/publications/presentations/Lightmap_Compression_2008_02_22.pptx - would be nice, although that will probably require some knowledge in the area of digital image processing.
- Look into lightmap packing: the current algo might leave a lot of unused space, implementing e.g. a tetris packer would help here. [A “tetris packer” alone is somewhat janitorial and could be connected with something else (as an "optional" goal). However, together with an automatic lightmap resolution reduction the package would certainly qualify as a project in it's own right.]
- Multi-threading / multi-computer improvements. To speed up the execution of lightmapping, which is an inherently parallel process, 'lighter2' should be able to utilize more than one processor; both via multithreading (taking advantage of multicore) and across multiple processors. Some work on this has been done in previous SoCs, code is accessible here.
- Using OpenCL (ideally) or CUDA, implement support for GPGPU computation in lighter2.
'Lighter2' subproject is not realtime per se and can offer other interesting areas to look at for a student that is more interested in offline rendering than realtime rendering.
Shadow mapping improvements
Last year we got a deferred shadow mapper which works reasonably well. More work in this area can be done like improving support for large shadows, improving performance and so on. One option for improving performance might be to implement caching for the shadow maps.
In addition we need support for dynamic shadows in the forward renderer as well. This will require adaption of the generic light setup for shadows (basic support is already present). Note: Very good template knowledge is recommended for the work on rendermanagers.
Projects related to shadowmapping but involving other techniques are also welcome.
Advanced rendering techniques
CS has now good support for advanced rendering techniques such as rendering to texture and post-processing effects, but is lacking of examples on the way to use them. This project would involve implementing one or more cutting edge rendering techniques, to act as a starting point for those of our users that wish to utilize them.
Examples might be Screen Space Ambient Occlusion (SSAO), Relaxed Cone Step Mapping, Skin, Trees, inspiration for algorithms and/or effects can be found from Nvidia, ATI, SIGGRAPH presentations, GDC presentations and papers: paper1. Improvements can also be made to the previous GSoC project on clouds.
The new deferred render manager has been added during the GSoC 2010. Many existing shaders of CS may need an adaptation for this render manager, and some new effects can be made by exploiting the G-buffers of the deferred process.
CS has support for simulating bodies of water (river, lake, ocean) already, however there is much to be improved. For example;
- Ocean support is only half complete (the size of the mesh is limited, the fragment shader needs work, better foam can be added).
- There is little in the way of simulating waves hitting a shoreline (needs more than just movement, some graphical effect for the head of the wave would be desirable).
- There is no standard (and convenient) method of supporting 'fogging' when the camera goes underwater (or more difficult; half above, half below the water). Other underwater effects are welcome.
Level of detail and resource management
This project would have the global goal to provide the functionalities needed for seamless virtual worlds, i.e. the ability for the user to navigate in virtually infinite worlds without the visible loading of the objects of the scene.
This work would leverage on the many different solutions that are already present in CS for LOD and resource management. For LOD, there are static and progressive LODs, imposters, and several meshes such as the terrain, the animesh and the fur mesh have builtin features for LOD management. For resource management, there is the threaded loader, and an overhaul of the resource loader has been started in the CS/branches/feature/loading SVN branch.
Here are the tasks to be done:
- All the LOD functionalities should be merged under a common interface, abstracting the way the LOD is actually managed by the underlying mesh.
- A new mechanism should be added, allowing some kind of templating functionalities in order to be able to define the LODs of a mesh as a variation to be applied on that mesh (e.g. changing the material, disabling a submesh).
- A global resource manager can be added, responsible of the management of the meshes that are to be loaded and unloaded, and of the selection of the LOD that has to be applied to each mesh visible in the scene. To that end, the resource manager would use some heuristic taking account of parameters such as the amount and the size on screen of the objects, the total count and size of render buffers, the current framerate, the history of the changes of LODs in the meshes (to avoid flickering between two LOD states), etc.
- The work for the overhaul of the resource loader should be continued.
Optimizing runtime data usage/memory requirements
This task is about the optimization of runtime data use. Due to the increasing size of data needed to deliver 3d games and visualization it might be useful to provide additional tools to alleviate the weight on systems which aren't as good as the last gaming gear on the market. For example expanding the support for texture downscaling in order to, optionally, not only operate as a divisor but also provide a lower bound limit, and finding ways to squeeze the ram and vram usage of crystal space on heavier maps. This will likely also be extremely needed in order to use crystal space on portable devices. Another use case are servers using Crystal Space, like AI servers using CEL functionality and such. In these cases many graphical features, like textures/materials, tend to slow down the load process and result in an higher inert memory usage. It would be useful to be able to avoid loading useless features from maps, without having to use a different set of maps. Some runtime data optimizations would probably be facilitated by an improved general resource management, but it's not necessarily a prerequisite for tackling them.
Scene and mesh preprocessing tools
Creating optimized levels can greatly increase the workload of level creators. As a result, many levels created for CS run far slower than they could do. The idea behind this project is to create one or more tools to help automate the job of level optimization.
Along with the new cseditor framework, a new system for the management of preprocessing tools is currently being designed. A first step in the project would therefore be to fix and implement the API defined here, then to implement some user interfaces for the management of the preprocesses, both through a command-line application, and an integration in the cseditor framework. In that goal, the report system already present in CS may need some extension (report hierarchies such as in lighter2 is one idea).
The second step of the work would be to implement one or more preprocessing tools. Here are some suggested functionality:
- Move the preprocessing tools that are already existing to the new API (e.g. lighter2, basemapgen, etc).
- Merge multiple textures into a big texture and update the UVs of the corresponding meshes.
- Adapt the resolution of the textures depending on the size on screen of those textures.
- Merge multiple objects into a single object. Objects should be merged based on spatial locality.
- Optimize the index buffer of meshes to get better cache performance.
- Improve the progressive LOD generator. It would need at least a better heuristic to accelerate the process, as well as more parameters to control the generation of the LOD levels. Animeshes would also need a special treatment using the bone influences in order to keep details at the articulations.
- Integrate CS with some open source mesh processing library such as GTS or VCGLib and provide access to some of their functionalities such as LOD generation and mesh repairing.
An important format to be supported is COLLADA, along with its extensions COLLADA FX and COLLADA Physics.
There are currently two main ways to manage COLLADA files within CS:
The collada2cs plugin is still quite limited and supports only static meshes. On the other hand, the Assimp plugin has been thoroughly tested and supports static and skeletal animated meshes.
What is not supported by both solutions are morph targets/blend shapes, advanced material properties (that is, COLLADA FX), particles, and physical properties (COLLADA Physics).
In order to achieve a real added value for CS, a GSOC project would mainly concentrate on one or several of thoses missing features. Those would been added within the collada2cs plugin.
Note on materials: ideally, the materials developed through the Blender's composite nodes system could be exported into COLLADA FX then imported into CS. An interesting idea would be to have two twin GSoC projects about that: one from the Blender project about the export into COLLADA FX, and one from the CS project about importing from COLLADA FX.
DAMN (Digital Assets Managed Neatly) is a Project and Content Management platform targeted at movie and game creation. It can automatically generate thumbnails, show 3D WebGL previews right in the browser, manage dependencies between files, ... And soon much much more for which we need you help!
Under the CrystalSpace Umbrella, DAMN will partake in GSoC 2014. So take a look at our Ideas page, maybe there is something that interests you. If so, you can contact us on IRC on freenode #peragro or submit a proposal to GSoC after 10th of March. If you have questions you can find us on IRC on freenode #peragro
Improvements of the collision and physics simulation systems
CS now uses Bullet as the default physics simulation engine. This plugin has quite a lot of features, with support for rigid bodies, joints, soft bodies, kinematic objects, terrain2 meshes, and collision and hit tests.
During the GSoC 2011 and 2012, a new API and implementation of this plugin has been setup, unifying the two different collision and physical plugins that were used in Crystal Space. This project also added support for the splitting of a scene in several sectors linked by portals.
A new project on that topic would add new functionalities to the work done so far:
- Sanitation of the work done in the previous GSOC's.
- Improve the support of cars and other vehicles.
- Add support for explosions.
- Add support for fracturable objects.
- Add support for 2D and/or 3D fluids.
- Dynamic creation of portals like in the game Portal.
Advanced animation techniques
The new iAnimatedMesh has already many advanced features such as forward dynamics (ragdolls) and inverse kinematics. More advanced animation techniques can now be added to leverage on the infrastructure already present.
Parametric Motion Graphs
Motion graphs are some kind of extension of a Finite State Machine, where the graph is built automatically by analyzing a set of pre-recorded animations, e.g. acquired through a motion capture process. Parametric Motion Graphs go even further by letting the user specify in terms of parametric constraints the goal to be reached by the animations. The reference paper is here.
Managing the motion of the feet of animated characters is a complex topic, because it has to deal with the highly variable constraints of the environments while being reactive to the changes of orders given by the player or the AI. A project on that topic would be to implement the solution developed in the Unity engine.
The goal of this project would be to add the ability for the animated characters to react dynamically to actions such as being hit, preventing from falling, or falling with the ragdoll animation then getting back on his feet. Reference papers on that topic are here, here and here.
OpenGL ES support
An additional renderer plugin supporting OpenGL ES (OpenGL for Embedded Systems) would be a first step towards supporting mobile systems such as Android and iOS, consoles such as the PlayStation 3, and the Google Chrome Web Store using Google Native Client.
This new renderer has been started during the GSOC 2013 (see the code here and it has been merged in trunk since then. The project this year would continue on the work done so far.
One useful tool for testing OpenGL ES conformity may be ANGLE, an OpenGL ES implementation for Microsoft Windows which translates calls into the DirectX 9 API (because no other OpenGL ES implementation reportedly exists for Windows).
Other platforms support
As side topic of OpenGL ES support, it might be useful to introduce native atomic operations support for several platforms, which are likely to be used with OpenGL ES, like ARM (v6/v7+) or MIPS. Additionally verifying and solving the deadlocks/crash which happen while using the generic atomic ops provided by gcc or the ARMV5 native atomic ops will allow a broader access to crystal space from the most common platforms to the most exotic ones.
Clipboard/Web browser launch
Add support for all the 3 major platform (windows/linux/macosx) clipboard. So applications can access them through an unified cs api, in order to get the data in it or put new data. Additionally support for launching special links, like browsers url could be useful in the same multiplatform way.
* Look into general profiling & subsequent optimizations, e.g. with SIMD instructions, improved data structures or just cleanups. * A faster xml parser than tinyxml (eg like rapidxml) could be added as an additional parser in order to reduce load times.
Projects specific to the Crystal Entity Layer (CEL)
Path finding and steering behaviors
CEL has support for hierarchical path finding using the ' Recast & Detour' library.
The implementation of the plugin should be enhanced:
- Several issues need to be checked regarding this library, like portal handling, parallel loading, and errors in the path management.
- The ' Recast & Detour' library should be updated to the last version.
- The recently added functionalities of Recast & Detour for dynamic objects and steering behaviors should be used.
There is a network layer that has been implemented in CEL. An API has been designed for the network management of CEL entities and property classes, and a first TCP plugin was written, but it is still missing some features before being usable.
This work would involve:
- Define and implement a system so that the whole networking behavior is defined through property classes, e.g. so that a CEL game can become a networked game simply by adding some specific entities and property classes.
- Extend or change the current newtorking API in order to insure a generic and optimal persistence of the property classes.
- Implement the persistence for the existing property classes of CEL. This may sometime need to rewrote part of the behavior of the property classes in order to insure a framerate independence.
Fill In Your Own Idea Here
There's some graphics effect CS doesn't do? You know of some paper and want to implement it in a real environment? You've noticed that some CS feature is not that elegant to use? Feel free to submit your own ideas!
You can also check the “Developer's Whiteboard” - it contains note and scraps of ideas for changes to CS. It's more aimed towards existing CS developers, so it's occasionally sparse on explanation and describes things rather roughly, but it can serve as a source of inspiration if none of the ideas above appeal to you and you feel adventurous.
Things we can't have
- Documentation updates would be nice, but are not allowed per the Google SoC rules: http://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/faqs#documentation