Summer of Code - General Info

The general information for GSoC and CS is now found at SoC

Summer of Code - Project ideas

As CrystalSpace 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 Marten (thebolt) and they will help you out.

Below you will find our proposals for things to do within the Crystal Space project.

Lighter2 improvements

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 is:

• 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.
• Multi-threading / multi-computer usage for calculations. To speed up the execution of lightmapping, which is an inherently parallel process, we would like 'lighter2' to be able to utilize more than one processor; both via multithreading (taking advantage of multicore) and across multiple processors. A SoC project here could include either or both parts.
• Implementation of spot-, directional- and area lights. Crystal Space traditionally only supported point lights and that is what 'lighter2' supports as well. Full implementation and support for other forms of light sources would be desirable for both quality and computation-time reduction.

'Lighter2' subproject is not realtime per see and can offer other interesting areas to look at for a student that is more interested in offline rendering than realtime rendering.

Visibility culling improvements

Visibility culling is the act of deciding which objects to actually render and which to ignore because they are either outside the view or they are occluded. Crystal Space at the moment implements two visibility cullers:

• Frustivs - Only does visibility culling to the view frustum (removes things outside the view).
• Dynavis - A partial implementation of original dPVS (earlier by Hybrid, now known as Umbra) which also does software occlusion culling.

Both these cullers gets the job done, but they are not the most efficient pieces of code around. Also since the introduction of dPVS in 2000 the way graphics cards work have changed and so has the requirements of the cullers. Also new cards have hardware features to allow for quick implementations of occlusion culling that Crystal Space at the moment does not take advantage of.

A SoC project in the area of visibility culling would be to develop a new, more "modern", culler ground up. Efficiency is a major concern as visibility culling is something that has to be done every frame. Thus we expect the student to look into the latest research in the area and then implement a new dynamic or dynamic/static culler utilizing frustum culling, occlusion culling either in software or hardware with software fallbacks and possibly precomputed visibility for static geometry.

There have been a lot published on culling, esp occlusion culling, in the last few years. Some examples  GPU Gems 1,  GPU Gems 2 and  loads of papers.

Impostors

Even with the most efficient rendering pipelines and algorithms there are times when the scene contains too many or too complex objects to render them all. Two common ways of handling this are LOD (Level of Detail) and impostors. Impostors are done by rendering the high complexity object (or set of objects) into one or more textures and then putting these on a simpler object, in its extreme just a flat polygon. Crystal Space today has the infrastructure to render one or more objects to textures and then use those for impostors but it lacks any automatic management of them. The target should be that the engine itself should be able to determine what to impostor either implicitly (settings for distance, complexity threshold etc) or from explicit tagging of objects, generate the impostors and if needed also update them when the object/view/environment change.

Some starting point for further research on algorithms etc can be  paper1 and  post1.

Environmental effects

One important part in rendering realistic environments is the rendering of environmental effects such as clouds, dust, rain, other atmospheric effects etc. Crystal Space today has a very advanced shader system, and with the new render manager almost finished good support for rendering to texture and post-processing effects which allows you to render these kinds of effects however at the moment it's all up to the user to implement this.

We would like to see at least an example implementation within Crystal Space itself to act as a starting point for those of our users that wish to utilize environmental effects. Inspiration for algorithms and/or effects can be found from  Nvidia,  ATI,  GDC presentations and papers:  paper1.

Programmatic control of skeletal meshes

During last year Crystal Space has got a new mesh object and infrastructure for meshes animated by skeletal animation. The new system allows for both better overall control of the animation as well as possibility to control animations on a finer level. It is however lacking in one area and that is having skeletons interact with other parts of the system automatically.

The first interesting area here is the combination of skeletal animation and physics/collision detection. When a skeleton is animated there is currently no way to automatically get a physics object representation to update and thus an user must manually update the set of physics objects every frame. By providing a method to automatically update the transforms of physics objects as bones moves this would be simplified.

As interesting as animation->physics connection is, as interesting is the reverse physically controlled animation. Often referred to as "ragdoll physics" it allows characters to animate under influence of and as a result of the physics simulation. This allows for realistic interaction with the physical environment as a animated object/character can fall around, be moved as result of heavy objects etc.

Another type of programmatic interaction that could be involved is 'inverse kinematics'. Currently the skeleton system only provides 'forward kinematics' (you set the angle of each joint and it computes where the arm ends up) that can be controlled by pre-baked animations; however sometimes it is desirable to be able to set the end-point (hand) location and have the skeleton automatically update the rotations accordingly.

A SoC project in skeletal animation/meshes would in our view focus on one of these areas but also be general enough that it provides some infrastructure to implement the other parts.

Unified collision and dynamics

Currently, Crystal Space has a system for "collision" between objects (based on opcode and our own code) and a different system for "dynamics" of objects (by either bullet or ODE). This differentiation exists both on implementation and API level and leads both to confusion among users and is sub-optimal as you have to early on decide if you want simpler collisions or full out dynamics.

Modern physics libraries often provide functionality to do only collision detection without the dynamics and there might be other synergies between the two so it makes sense to unify them into one set of API and implementations. This SoC project would include defining a unified API that is suitable both for simpler collision detection between shapes as well as full dynamics based on the current APIs and then an implementation of it (using say [code.google.com/p/bullet/ bullet]

More advanced lighting and shading

Crystal Space today mainly utilize direct and precomputed indirect lighting via the Blinn-Phong shading model. While being fairly efficient it does not always give the desired surface "feeling".

In this SoC project we would propose looking at alternative shading models such as  Cook Torrance or  Oren-Nayar and how to efficiently implement them for Crystal Space, both in the runtime part (shaders) and precomputation (lighter2). It would also be interesting to look at implementation of lighting algorithms, especially lighting approximations such as  Screen Space Ambient Occlusion (SSAO).

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!

Old Ideas

Old SoC Proposals contains the proposals for earlier years SoC which have not been realized and thus are still up for grabs.

Further Ideas

PreliminarySoCIdeas has a list of task that are valid for SoC, but need more detailed descriptions.

Ideas for projects related to CS

While not part of "core" Crystal Space the software projects mentioned here are part of the Crystal Space community and SoC projects for them could be handled under the "Crystal Space umbrella".

CrystalArchitect

CrystalArchitect is a CrystalSpace IDE. We are advancing well, but more hands are needed if we want to have fancy features soon !

Ideas are kept on an external wiki:  http://wiki.kyanite-studios.org/doku.php?id=org:gsoc2009