GSoC 2011 Ideas
This page lists our project ideas for GSoC 2011 participating students.
Should any of the ideas catch your interest, feel free to contact us via our dev mailing list. Please feel free to suggest any more project ideas or enhance any of the listed projects with your ideas. Remember, we see these projects in one way, but you may bring fresh thoughts and a clearer view on some of them. Bring them on! ;-)
Should you be interested in participating, we request you to send us the following information:
- Your name & nickname
- 3 or so sentences about yourself
- The project ID that you'd like to work on
- Some words about your experience on the chosen project
Please send the above information to our GSoC2011 admin: kg.kilo # gmail,com (guess you know which characters to change to make it work :D )
| ID | Title | Description | Skills needed |
| Graphics | |||
| G01 | Modern graphics engine demonstration | SD definitely needs a new graphics engine instead of the ageing PLib in use now. As SD is (aims to be) modular, the graphics modules should be swapped easily, just like Simu modules. This project means you start writing a new graphics engine based on a modern library, after running a comparison of the existing open source ones (OSG, Ogre 3D, SFML, etc). The target is not to get a fully functional graphics engine, but a working demonstration that the issues with our current one can be fixed (poor visual rendering, heavy CPU consumption, etc). We think this project needs someone with quite some 3D graphics / realistic rendering experience. | graphics programming, we need a real expert |
| G02 | Car damages | Develop an easily configurable visual damage system for the cars (mesh deformation). Must be easy to setup for a car designer through some parameters. | graphics programming |
| G03 | 3D interior view | Task D12/A39: Support for 3D cockpit model. Each car can have its own 3D interior design, or use a category default as fall-back. This project only needs to enable this feature, artists will fill it up with content (just like skinnable cars). | graphics programming |
| G04 | Animated objects | Enable the use of animated objects (buoys, flags, track side objects), with an interface that makes it easy to use for a track designer. | graphics programming |
| G05 | Enhance visuals | #131 More effects: Add a framework of particles systems for sparks, smoke, dirt, weather, etc. #130 More effects: Cars getting dirty, depending on environment and race length. The amount of dirt on cars should be adjustable, for later it can be connected to weather. However it should be already connected to driving on sand, mud or grass. #263 Robots should turn on lights at night -> define lights around a track (static light sources) and make cars' lights work (moving light sources). This project should enable SD to use such effects, but the actual representation in graphics would be the task of the graphics engine - either our old PLib based one or any other new graphics module. So the result of this project is "only" a system that makes it possible to have such effects turned on/off and calculated when needed, and the appropriate interfaces towards the graphics module. #201 Texture Blending modes for Multitexure supported by OpenGL | graphics programming |
| G06 | Camera enhancement | #149 Free view camera: we have a camera system, but it only supports points of view (POV) moving with a car. This project should add the possibility to define more types of cameras: - Fixed camera location, fixed POV (just like stationery track-side cameras often used in TV). - Hovering/chasing cameras, following a car, but user can change its position in relation to the car. | graphics programming |
| G07 | Better driving views | #161 Glance left/right for first person view. #210 Side mirrors. There is no glance out function yet in our game... But we do have mirrors, it only needs to be enhanced further. | graphics programming |
| G08 | Racing numbers, license plates | - Racing numbers on cars could be dynamically mapped as an additional layer, that can be disabled through the menu. Similarly, the game could display the (short) name of the player as a car license plate or at the rear at the car (using a mono-spaced font and limit the length of player names). | graphics programming |
| Input devices | |||
| G09 | Force feedback | Task D21: Decide if we use SDL or OIS or some other library by the means of a comparison test. Then develop the appropriate handler code for the chosen library. In the future it may also imply moving all input device code to the chosen library. Nota bene: the chosen library should be available as a real cross-platform one. | input device programming |
| GUI, alternative languages | |||
| G10 | Telemetry analysis | Task D40: External GUI for telemetry data. The simulator can produce logs of telemetry data and we need an interface to visualize that. | visualization, GUI programming |
| G11 | Track editor | The current track editor (written in Java) lacks a lot. A new one should support more flexible formatting of the tracks. Mart has already started work on a new editor, but you can have your own share of work: - Some calculations are better expressible in a functional language like GLPK than in C++. Changes in one track section might affect other (nearby) segments, but there are also many parameters of other segments which do not need to be recalculated. Test and demonstrate how a functional language can be used to solve and ease these problems and speed up the development of new track features. - Examine how we could make the track editor much better backwards compatible, to create a track based on an older version by loading a different base file only. This would also allow us to change many details of the track structure without releasing a new version of the track editor itself in the future. | GUI programming, functional languages |
| G12 | Menu enhancement | Demonstrate that we can replace our C/C++ GUI code based on a home made OpenGL graphics layer, written in Python + CEGUI code. It should also support #119 Fades between screens. This can be a really easy one for a person who already has developed such menu systems. | Python, GUI programming |
| Multimedia programming | |||
| G13 | Background music, GUI sounds | - Allow to select a music track folder through the menu system, then play the tracks in it (looped) during menu navigation or driving (configurable), with adjustable volume. - Allow the use of pre-defined sound effects (click on a button, menu fade) during GUI interaction events. | multimedia programming |
| Data structures | |||
| G14 | Reverse track directions | - Allow forward or reverse racing on tracks. While the tracks are not specialized for reverse racing, the game should enable this feature, multiplying our tracks easily. The most problematic area is the pit lane (especially for the robots) so this should imply close collaboration with robot developers. - Meanwhile the game should display a "Wrong Way" hint when the player is driving in the wrong direction on a track. | containers, lists, data structures |