Ideas G So C

Ideas list for participants of Google Summer of Code

This is a list of possible topics to work on during summer of code. If you want to take part in Google's Summer of Code, which includes gaining $5000 in 3 month, just look through the following topics. In case Irrlicht is chosen as a mentoring organization for GSoC, you can work on one of those topics together with a mentor from the Irrlicht dev team. You can also suggest your own topic, which needs to be worked out together with a possible mentor. Just contact us directly or meet us in the forums.

Ideas list

The ideas list is split into two parts. First comes a general feature list, which requires at most some insight into rendering techniques. In most cases good C++ knowledge should suffice. The second list includes ideas which require decent Shader knowledge.

General features

  • Mesh optimization as part of HW buffers
    With Irrlicht 1.5 we added hardware accelerated vertex buffers. Vertex buffers are used to copy the whole mesh data onto a dedicated memory area on the GPU (see e.g. OpenGL VBOs). This only happens when geometry changes, which gives a huge performance gain compared to the usual way where the whole geometry is copied onto the GPU in each frame.
    Besides this performance improvement, this addition also established a distinct point where all geometry is prepared before it is uploaded to the GPU. In this project, these means shall be extended to buffers which store optimized or otherwise altered versions of the actual geometry. This can increase render performance, e.g. by converting the meshes into tri-strips, or support currently unsupported geometry types such as quad faces under DirectX or in the software renderers.
    The geometry algorithms are pretty simple. In some cases, it will just require certain index duplications. It may also be possible to integrate NVidia's tristrip tool to optimize the meshes before rendering. The second part of this task is to enhance the current vertex buffer structures towards the additional algorithms and the necessary API accessors. Since the whole structure is pretty much self-contained, the amount of code to change is easily identified. The proposed schedule would be as follows:
  1. Get an idea of the current implementation and usage
  2. Add a software implementation of the buffers, for system not supporting the accelerated version
  3. Create an example for quad support
  4. Generalize the API for further algorithms

Difficulty of this project is low-average. Only C++ knowledge is necessary, 3D rendering knowledge might be useful for adaption of optimization algorithms.

  • Decal effects
    Decals are graphical elements, which are added on top of an existing surface. They can be used for, e.g., dirt or blood spills, bullet holes, ... A simple implementation is easily done, one just needs to check the triangle hit, and add the texture on an additional face on top of it. However, there are certain corner cases, which have to be handled. Especially the proper clipping at edges, and a correct shape on non-flat surfaces. The proposed schedule would be as follows:
  1. Check out the current implementations
  2. Analyze the pros and cons of each implementation
  3. Integrate one of the best fitting into Irrlicht
  4. Work on fixing the remaining problems

Difficulty of this project is average. C++ knowledge and some 3D rendering knowledge is required.

  • Cube and volume textures
    Even though we often had this on our TODO list, Irrlicht still does not support these types of textures natively. Cube textures and volumen textures are certain groups of multiple textures, which can be used very efficiently in special situations. Cube textures are, e.g., used for environment mapping with reflections, and volume textures can display things like medical images from MRTs.
    The implementation requires some additions to the txture handling scheme in Irrlicht. Though, some fragments for this already exist, and some implementations from the forum will also help. Still, also programming with the low-level gfx APIs OpenGL and Direct3D will be required. The proposed schedule would be as follows:
  1. Learn about the various uses of these texture types
  2. Get known with the current implementations
  3. Add an implementation for a driver of your choice
  4. Produce some examples to show their use
  5. Add the remaining driver implementations

Difficulty of this project is average. C++ knowledge and some 3D rendering knowledge is required.

  • Image manipulators
    Irrlicht needs some ways to create or alter images and textures. Typical applications are Perlin noise and color format changes, but also image manipulation algorithms such as edge detection and scaling. This project will define an object-oriented framework which allows for the mentioned methods on both images and textures. The easiest way to integrate these algorithms into Irrlicht is by using the functor concept of C++, mimicing the already existing VertexManipulator approach of Irrlicht.
    Most image manipulation algorithms can be taken from the literature. The framework is a pretty straight-forward C++ approach. If the necessary knowledge is available, it might be useful to include GPU-acceleration support for the manipulation API in order to speed up the algorithms. The proposed schedule would be as follows:
  1. Propose a layout for the new structures
  2. Add the basic framework for accessing and manipulating the images
  3. Implement an exemplary manipulator and according tutorial
  4. Work on adding more manipulators and/or the acceleration techniques

Difficulty of this project is average. Only C++ knowledge is necessary, 3D rendering knowledge might be useful for the integration of GPU-acceleration.

  • Occlusion culling techniques
    There are many algorithms for optimizing the rendering process by skipping over non-visible meshes or polygons. This project will integrate a certain class of those into Irrlicht. Possible techniques include portal culling or hardware occlusion culling. The former defines a structure of rooms and doors with visibility links between the rooms via the doors. If no line of visibility can be defined between the current room and another one, the non-visible is not rendered, even it would be in the view frustum. This technique can dramatically increase indoor rendering performance. Occlusion culling is a technique which renders the whole scene or parts of it, and tests the visibility of a certain (complex) mesh in the rendered output. This test is performed on the GPU and cn be very efficient. Hence, if a very complex mesh is e.g. hidden behind a wall directly in front of the camera, it would not be rendered even if the simple culling techniques do not help at all.
    Since Irrlicht has a distinct culling section, the integration of the suggested algorithms has a clear destination. Both techniques require some changes in the render process and maybe even certain additional low-level API calls. The proposed schedule would be as follows:
  1. Read about possible techniques and implementations, and choose one
  2. Sketch a design for the integration into Irrlicht's render pipeline
  3. Implement an early prototype into Irrlicht
  4. Work on fixing the remaining problems, better driver support, etc.

Difficulty of this project is average-high. Since this project works with non-trivial rendering techniques, it will help to know at least the basic 3d rendering foundations. Help for the gfx APIs OpenGL and Direct3D will be provided by the mentor. All coding will happen in C++.

  • File format advances or add-ons
    Irrlicht supports many mesh formats. However, most of them only support static meshes while the original format would support animation as well. This project targets at supporting animation for e.g. Collada or 3ds. Alternatively, or in addition, the student may add some more of the commonly used 3d mesh formats, e.g. fbx or u3d. The proposed schedule would be as follows:
  1. Choose the format and make familiar with the docs for it
  2. Add a first implementation, usually supporting geometry information only
  3. Extend the support for advanced features, such as animation, material effects, etc.
  4. More work can be put into writing an exporter for this format, choose another accompanying format, ...

Difficulty of this project is low-average. Only C++ knowledge is necessary. The formats are well documented and can be freely chosen. The most difficult job is the parsing of the formats, which requires only basic C knowledge.

  • Level of detail support
    Irrlicht doesn't currently support LOD methods for static and animated meshes. This project will focus on implementing LOD methods for such nodes. For example by switching to user-provided low detail meshes on certain conditions. This can, e.g., render less detailed meshes in a distance. Moreover, it would be welcome to add mesh manipulation methods in order to reduce meshes on-the-fly in the 3d engine. Several such algorithms can be found in the literature, which can also be provided by the mentors. Impostors are also a very useful optimization method which render an image of the mesh, and draw this image for a certain number of frames. The proposed schedule would be as follows:
  1. Learn about the different techniques, choose the one best fitting for Irrlicht
  2. Analyze the best approach of integrating the algorithm into Irrlicht
  3. Implement the code using Irrlicht's architecture
  4. Compare your work to the other approaches, or develop further towards a combination of those techniques

Difficulty of this project is average-high. C++ knowledge is necessary, also some knowledge about 3d rendering and 3d modelling, depending on the mechanisms to be implemented.

  • .NET update
    Irrlicht has many wrappers for integration into other programming languages than C++. One of the most commonly used wrappers is one for C# and the .NET framework. Until Irrlicht 1.3 this wrapper was developed as part of the core engine, until then the Irrlicht-CP.NET project maintained the wrapper. Unfortunately, this wrapper was not upgraded to the latest Irrlicht release, and lacks some major features of the engine. The proposed project would update the existing wrapper to the current Irrlicht release and establish increased maintainability of the wrapper. The proposed schedule would be as follows:
  1. Check out the current implementation
  2. Get in contact with the people currently working on updating this extension
  3. Develop a proper workflow for simplifying the work of updating the wrapper for the next versions
  4. Develop the wrapper for the current stable Irrlicht version

Difficulty of this project is low-average. C++ and C# knowledge is necessary, development platform should be Windows.

  • SColor/IImage updates
    The current Irrlicht implementation of image classes requires images to consist of 3 or 4 colors per pixel with integral color values (usually 0-255). In order to support HDR images, depth buffers, alpha channels, and other advanced features in the image class, a major refactoring has to take place. This project would factor out the currently used image methods, add a more general image handling with all the required features, and adapt the texture handling to the new formats. The proposed schedule would be as follows:
  1. Sketch the current design and the relations of the various elements used for image/texture handling
  2. Design an extension of the current state towards certain dedicated color formats (the most urgent ones)
  3. Integrate this solution into Irrlicht
  4. Analyze the amount of work and necessary architectural changes for a fully generalized implementation

Difficulty of this project is high. Good C++ knowledge is necessary, decent knowledge of rendering techniques and render APIs is required. This project should be chosen only with some knowledge about the architecture of Irrlicht. Many different locations of Irrlicht have to be touched.

  • Flexible Vertex format
    The typical gfx APIs offer certain additional information to be passed to the GPU together with the geometry. Irrlicht uses the most often required things such as vertex color, normals, texture coords, and tangents. However, many more information is required for advanced rendering techniques. Due to the current implementation, an extension of Irrlicht towards these things is hard. This project aims at adding a more flexible way to define the information being passed to the GPU, and add these structures throughout Irrlicht. Much care has to be taken for performance issues in this processing. The proposed schedule would be as follows:
  1. Check out the current implementations in the low-level APIs, from forum siggestions, and other engines
  2. Analyze the pros and cons of each implementation
  3. Integrate one of the best fitting into Irrlicht
  4. Work on fixing the open problems

Difficulty of this project is high. Good C++ knowledge is necessary, decent knowledge of rendering techniques and render APIs is required. This project should be chosen only with some knowledge about the architecture of Irrlicht. Many different locations of Irrlicht have to be touched.

Shader based add-ons

  • Postprocessing framework
    Postprocessing is a common practice in 3d rendering. Some proposals for a post-processing framework have been made in the Irrlicht forums. Post-processing adds certain effects, such as motion blur or field of view, after the whole scene was rendered without the effect.
    This project will integrate one of the existing frameworks into the engine, and extend it to support the fixed function pipeline. Since most post-processing frameworks are shader based, the effects would not be visible on small or old machines. Adding support for the fixed-function pipeline would fix this, and requires often only multiple rendering calls into a special render target texture. Additionally, some post-processing effects could be added in this project, which can be found in the literature. The proposed schedule would be as follows:
  1. Check out the current implementations
  2. Analyze the pros and cons of each implementation
  3. Integrate one of the best fitting into Irrlicht
  4. Work on fixing the remaining problems

Difficulty of this project is average. C++ and Shader knowledge is necessary. Some initial code exists.

  • DirectX 10/11 driver
    Irrlicht currently supports DirectX 8 and 9 (for the DirectX based drivers). This project will add a new driver which uses one of the more recent DirectX-APIs. Since the fixed function pipeline has been dropped in those drivers, the implementation will require a shader-based rewrite of the Irrlicht material system. While the driver internals are not too complex and mostly straight-forward implementations of the current driver versions, the material system will require quite a lot of work. Therefore, even a limited feature set with only a few material effects would suffice to finish this work. The proposed schedule would be as follows:
  1. Draft a design for the new material system
  2. Implement a minimal driver into Irrlicht
  3. Work on fixing the whole material system
  4. Analyze the applicability of the new materials for the existing drivers

Difficulty of this project is high. C++ and HLSL knowledge is necessary. Development platform must be Windows Vista or Windows 7.

  • Advanced shadowing techniques
    Irrlicht currently supports shadow volumes, a limited and often very slow technique. Shadow maps are implemented in extensions from the forum. This project will integrate the existing shader based shadow techniques, namely shadow maps, and possibly add some other advanced shadowing techniques, e.g. as described in the GPU Gems books. Moreover, certain accelerations of the shadow volume methods can also be implemented with shaders, even geometry shaders could be used. The proposed schedule would be as follows:
  1. Check out the current implementations
  2. Analyze the pros and cons of each implementation
  3. Integrate one of the best fitting into Irrlicht
  4. Work on fixing the remaining problems

Difficulty of this project is average-high. C++, 3d rendering, and shader knowledge is necessary. Implementations have to be for both HLSL and GLSL in order to run on all supported platforms. Initial code from one of the Irrlicht dev team members will be provided.

  • Support for NVidia's Cg
    This project will add support for Cg shaders (currently only ASM, GLSL, and HLSL are supported). An extension for Cg is available on the forum. This code needs to be adapted to the current shader API and fully integrated into Irrlicht. Additional work has to be put into simplifying the choice and fallback for shader languages. The proposed schedule would be as follows:
  1. Get familiar with the current implementation
  2. Adapt it to the current Irrlicht shader approach
  3. Integrate the extension into Irrlicht
  4. Add examples for Cg shader usage
  5. Analyze useful extensions of Irrlicht's shader API for simplified shader usage

Difficulty of this project is average. C++ and Shader knowledge is necessary

  • Support for OpenCL or some other GPU computation language
    In this proposal, an integration with one of the new GPU programming languages shall be established. These languages, such as OpenGL, CUDA, or ATI's Stream, allow to program the GPU processing units with a C-like language. This allows for very fast computations in stream based applications, such as image manipulations or integer arithmetics. These calculations can be mixed with rendering parts in order to calculate certain parts of the scenery on the GPU, and then render it. A set of examples of such calculation shall be implemented and integrated into the Irrlicht API. The proposed schedule would be as follows:
  1. Make familiar with the language of choice
  2. Develop some examples showing the mixture of Irrlicht rendering and GPU compuations
  3. Sketch the new API for this integration
  4. Implement a prototype for this extension into Irrlicht
  5. Work on completing the API towards a simple, yet powerful programming interface

Difficulty of this project is average. C++ and GPU programming language knowledge is necessary