General information

There's an "Advice for Students" page on the Summer of Code wiki. Reading is highly recommending.

The CrystalSpace project has a few prerequisites for Summer of Code applicants:

  1. You are expected to be experienced with object oriented programming with C++.
    CrystalSpace is written in C++ and makes use of templates, virtual inheritance and other C++ features. Please browse the source code online to determine whether this is a project you will feel comfortable working on.
  2. You will need to provide your own development environment on a supported platform.
    CrystalSpace currently supports Windows, OS/X, Linux and various other Unix platforms. See the building and installing section of the online manual for specifics related to each platform.
  3. You are expected to participate in a short interview/discussion prior to being accepted. To make sure the student is fit for the project and also to help the student get into the development we will have a short interview/discussion with the top candidates prior to being accepted as students into the SoC program for CrystalSpace.

In addition, over the duration of the project the CrystalSpace project will expect you to:

  • Do your best to complete the project.
  • Learn how to use a version management system (SVN) and if needed use it to cooperate with your fellow CrystalSpace developers.
  • Follow the CrystalSpace development guidelines as outlined in the manual.

There are some guidelines that every SoC student will have to follow to work with us. Here is a list:

  • There is a Google Summer of Code forum. This forum can be used for all discussions and questions related to the seven SoC projects.
  • It's expected that the students subscribe to the crystal-develop mailing list. That's also a place where a lot of development related discussion occurs and design discussion should be held here before implementing the project to give room for feedback.
  • It would also be great if you could visit IRC (#crystalspace channel on irc.freenode.net) regularly. IRC is a great place to get help soon and there are always people there available for help.
  • We will require every student to open a blog on the CS site. This blog should be used to post progress about the project itself. We want at least a weekly entry there. More is ok. Note! I mean one blog per student.
  • Every student will work in a seperate branch in SVN. The student will have to merge back changes from main development branch into the SoC branch at regular intervals (to avoid the two branches growing apart too much).
  • As a participant in the Summer of Code project, Google expects you to follow their guidelines and regulations. Please be certain you have fully read the Summer of Code Student FAQ and Summer of Code Terms of Service as well as any other rules provided to you by Google.

Mentors / Administrators

If you want to discuss your idea or application, feel free to contact us using either mail (crystal-main mailinglist, see http://sourceforge.net/mail/?group_id=649) or on #crystalspace on irc.freenode.net

Administrators:

  • Jorrit Tyberghein (jorrit)
  • Marten Svanfeldt (thebolt)

Possible mentors:

  • Jorrit Tyberghein (jorrit)
  • Marten Svanfeldt (thebolt)
  • Frank Richter (res2k / res|laptop)
  • Vincent Knecht (vknecht)
  • Scott Johnson (jwir3)

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.

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

Lighter2 improvements

CrystalSpace new lightmap calculator lighter2 begins to work decently but there is still a number of central things that can be improved. Ideas for improvements:

  • More memory efficient data representations.
  • Support for global illumination in lightmaps, for example by photon tracing/mapping.
  • Multi-threading / Multi-computer split of calculations.
  • Implementation of spot, directional & area lights
  • Complete support for lighting terrain.

The project would be to improve lighter2 by implementing one or more of the above for immediate inclusion into CS trunk version. We as soon as possible want to retire the old lighting system.

Foilage mesh

Improve (we already have something half done) or make a plugin for nice fast foliage. It might also be worth considering some shader/mesh combination.

Cloud mesh

There's an interesting paper about real-time clouds at http://www-evasion.imag.fr/Publications/2008/BNMBC08/.

Ocean mesh

Implement an Ocean-like mesh. An interesting paper: http://www.presagis.com/files/whitepapers/2007-WP-VP-Wave-Modeling.pdf

Other Environmental Effects

There are other various environmental effects that could be implemented: realistic water (maybe have one for rivers, one for large bodies of water), cloth, dust.

Cross thread communication

Cross-thread communication system; a way to pass messages between any objects inheriting from some class (and subscribed to the messenger thing) and the rest of the Engine. So you could do something like Engine->WellNamedFunction<iLoader>(LOADTEXTURE, arg1, arg2, arg3); to load a texture in a csloader object running in its own thread. Also handles the request queuing, with the option to extend it in the object.

Loading

Possibly working/extending alongside the idea above, extend csloader to be threaded and scale (maybe detected at runtime how much to scale based on cpus/cores available).

The goal is somewhat similar to last year's "Streaming Loader":
CrystalSpace content loading is currently a synchronous process where the user initiates, and waits for data to be loaded and parsed. There is already a start for an API to load vertex data (positions, color, triangles, etc) from a binary format, this needs to be expanded and fully implemented. The main definition of maps and meshes would stay in the current XML format but the big blocks of data should be loaded from binary file. This project was a GSoC 2006 project but never finished.

  1. Fully implement the loading of vertex data from binary files for at least the main mesh object types.
  2. Extend the process to do the loading in a background thread and stop; fallback meshes should be used until the vertex data is fully loaded.

...however, the implementation approach differs. Notably, the "cross thread communication" facility would serve as a foundation.

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.