Ideas from 2007
Inverse Kinematics animation support
At the moment animation is stored in files as simple keyframes for bones with no kind of hierarchical information stored. Therefore dynamically modifying animations at runtime is near impossible to do nicely. With IK support (and a couple of simple skeletal constraints), you can have a character stand on stairs, run around a slope, ragdolls become much easier (with the skeleton being defined by an animator not programmer) and limited 'effectors' like taking a bullet become a possibility.
It is also highly wanted to have a good integration with content creation tools, which in the case of CrystalSpace is preferably blender.
Here are some examples you can look at for some ideas.
http://www.emotionfx.com/site/index.php
http://www.mysticgd.com/protomgd2004/img/media/EMFX2_InverseKinematics_DivX.avi
http://www.mysticgd.com/protomgd2004/img/media/emfx_bodylookat_dx9.avi
Procedural animation (for things like lookat, realistic reactions) coupled with motion synthesis using pre-animated data (to generate new motions on the fly).
Material/texture combiner
CrystalSpace already has a rather advanced material and shading system which allows you to do most effects you would like to do. However the shaders and material needs input in the form of texture maps. Currently texture maps can be loaded from file or created by code (procedural textures). The student that accepts this project would extend this one step further. Often a surface description will require a number of texture maps: a diffuse map, specular intensity map, height map, normal map etc. For performance reasons you might want to combine the maps so that you e.g. pack height map into alpha channel of normal map, or in some cases even generate one map from another (such as generate normal map from heightmap).
- Design and implement a system where the user can specify how a given shader wants the textures maps combined, and then generate (if required) and combine the textures.
- Ideally, there would be both an "online" version and an "offline" version of the system. With the "online" version the map packing would happen at the level load time to allow maximum flexibility and shorten the effort required to get a working map from the editor to the engine. With the "offline" version, the packing would happen by an external tool in order to maximize the load time performance.
It would suffice to only implement one of those two "versions", however, the idea of reusing that system for the other version should be kept in mind during design and implementation.
Framework for platform specific optimizations
The current code-base in CrystalSpace have critical code paths optimized mainly by choice of algorithm and in some cases the implementation which however is in pure C++. In most places this is okay or even as good as it will get, but there are a number of places where we could benefit from correct usage of platform specific optimizations such as SSE on Intel and AltiVec on PPC. As the code in general is platform independent and support a wide range of hardware this pose a number of challenges when it comes to abstraction and using the right implementation.
This project would develop a framework within platform specific routines can be developed for critical code and right set of routines be selected both compile and runtime. It would also as a sort of "proof-of-concept" optimize one or a few choosen places to use this framework.
Unified API and binding for dynamics and collision detection
There currently is a number of interfaces and implementation plugins in CrystalSpace related to dynamics and collision detection. There is an abstraction for a dynamics system but not all aspects are properly abstracted so the implementation provide their own (private) interfaces with extra functionality. This disallows direct replacement of one implementation with another.
There is also a separate set of interfaces for doing simpler collision detection (CD without dynamics) which are disconnected from the dynamic interfaces and niether benefit from the other.
This project would look at a few aspects of this:
- Revise the current dynamics interfaces so that they properly cover all aspects wanted from the dynamics system.
- Update and complete the current bindings for ODE and Bullet dynamics systems for this interface.
- Look into the possibility to have bindings for PhysX (commercial dynamics system)
- Revise the collision detection interfaces and see what improvements could be made as well as what unification could be done between collision detection and the dynamics parts.
Environment rendering
CrystalSpace started out as a "quake-like" engine with main focus on indoor rendering of closed areas but have over the years evolved towards also handling large outdoor areas. Latest example is the new terrain engine by which we will be able to handle (almost) arbitrary large outdoor scenes in a seamless way. In relation to this it would be interesting to have more support for rendering of environmental effects such as sky, clouds, rain, water, snow etc.
The exact scope is up to the student to specify but the result should be a reusable component (code and shader probably) that work on a wide range of hardware platforms with at least decent result on the lower-end ones and outstanding result on high-end.
Level Editor
There is a need for a standard editor for CS world levels. So far the support for editing art has been at the modelling program level through exporters, but there are several arguments to have a dedicated standalone solution. First off, not every new feature in CS can immidiately be integrated into each of the exporters. Up to now this often requires developers to manually edit XML files by hand. Secondly there are a lot of simple tasks that don't require the complex functionality of modelling programs, like moving around finished objects or editing properties. Finally there are some functions that are pretty hard to integrate into the editors, but are easier to implement in a CS specific program. An example for this is creating terrain from heightmaps and applying terrain textures.
The previous community-based attempts at writing an editor showed that a very flexible design is needed to accomplish maintainability as well as the possiblity to add future plugins.
Further the editor should be compilable on every system that CS can be build on and not depend on any optional projects (with the possible exception of a gui framework). It should however still be able to support plugins for these optional packages if they are installed. As such the editor must be implemented in C++.
Since the amount of work needed for a feature-complete editor is too big for the given timeframe, the task during SoC would be to create a well-designed framework that can be heavily extended to support a wider range of features through the use of a plugin mechanism. Basic editor functionality like displaying and moving objects and at least one example of a more complex plugin should be delivered.
Note: this is partially done. It is possible to pick up the existing work and continue on it.
