General

This page lists some GSoC project ideas for 2015 that the Ogre team considers especially relevant for this year and that the team deemed manageable within the limited time frame of GSoC.

If you are interested in one of the ideas or have further questions, please feel free to create a thread in the GSoC Ogre forum section. The same applies if you have additional ideas that you either want to propose to potential GSoC students or might even consider tackling yourself.

Note: Please do not add entries to this list without having proposed and discussed them in the GSoC Ogre forum section!

There is also a legacy project ideas page that contains some other potential projects. However, the ones listed on this page are considered much more relevant and are therefore have a much higher chance to be accepted by the team.

Ideas

D3D11 RS

It needs to be upgraded to support AZDO too (not all of it can be supported, but still). This is a hard task, but I (dark_sylinc) will be helping too.

Knowledge Prerequisite: C++, very familiar with D3D11 API, some HLSL.
Difficulty: Hard. But you will be working side by side and coordinating with other programmers.

Improve Ogre 2.0 mesh format

The Ogre 2.0 mesh format is in infancy. It can only be loaded by Items (v2 object). Ideally, Entities (a v1 object) should be able to load the 2.0 mesh format too (with certain limitations and or extensions to write v1 information into the v2 mesh format that aren't yet supported, i.e. edge lists and facial/pose animation).
This way users wouldn't have to keep two mesh files for each format (ugh!!!) or use v1 mesh files and import them on the fly (less ugh!)

Knowledge Prerequisite: C++, be familiar with the Mesh serialization format in Ogre.
Difficulty: Easy.

Level of Detail (LOD)

A previous GSoC did all the LOD'ing stuff. The algorithm is great, but it only supports v1 objects. V2 objects no longer allow "manual lod" the usual way; however it supports using custom models as LOD and exchanging with automatic LODs seamlessly; which is superior. We need tools for artists to make the LOD generation (both manual and auto) work quick, easy, and friendly.
e.g. Suppose you have Sinbad.mesh, SinbadLOD1.mesh and SinbadLOD2.mesh; we need a tool that allows its user to create a single mesh "SinbadFinal.mesh" in which internally contains:

Lod0: Sinbad.mesh
Lod1: Auto Lod from Sinbad.mesh
Lod2: Read from SinbadLOD1.mesh
Lod3: Auto Lod from SinbadLOD1.mesh
Lod4: Auto Lod from Sinbad.mesh
Lod5: Read from SinbadLOD2.mesh

This is now possible in v2 objects (Items), but not possible IIRC on v1 objects (Entity)

Ideally there should be a library interface, and a command line tool for batch processing and and a simple GUI to set the settings interactively (load external meshes, generate automatic LoDs from which LoD, etc).

Knowledge Prerequisite: C++; Ogre; MeshLodGenerator Component; Toolkit knowledge (Qt/wxWidgets)
Difficulty: Medium. There's a big demand for this!

Particle FX

The old system is good enough; but there's a lot of room for improvement with a rewrite from scratch while reusing as much code as possible. Both in terms of features (more like ParticleUniverse) and performance.
A v2 pfx would use data oriented practices, multithreading (c'mon! particles are very multi-threading friendly!!); write only position information and/or orientation information (and generate the 4 vertices in the vertex shader using a custom Hlms implementation) and use the superior v2 buffer interfaces.
Vertex Shader Tricks by Bill Bilodeau is an excellent reference on modern particle fx rendering. Particularly slides 15-18.

Additionally, particle FXs should be capable of sharing renderer batches so that independent instances of particle FXs using the same sprite can be rendered in one or few API calls (instead of having one API call per particle FX instance).

I would do this myself (dark_sylinc) and I know 3 months would be enough for me, but I don't have the time and want to spend my efforts somewhere else.

Knowledge Prerequisite: C++; Ogre Particle FX Component; HLSL and GLSL shader knowledge; Data Oriented Design.
Difficulty: Medium to hard.

Port Pose animations to v2 (aka. facial animations)

Items (v2 objects) don't support pose animations; one still has to use Entity (v1 object) which operates in legacy mode.
Write a more lightweight system that can store position and normal offsets for each animation and each affected vertex into plain old array.
System should also be capable of importing the pose animations from v1 Entity into Item.
Implementations could support:

• SW: Accumulate pose offsets all from all animations in CPU (using multithreading!) and upload them every frame to a texture buffer. The Hlms' vertex shader will lookup the texture buffer for the final offset to apply.
• HW: Use use a single compute shader run to accumulate all the pose offsets into a single list, which will be later used by the vertex shader in the same way as the SW one.

Knowledge Prerequisite: C++; A bit of Hlms; Pose animations; GLSL and HLSL; Compute Shaders
Difficulty: Medium to hard.

Port DualQuaternion Skinning to v2

Dual Quaternion Skinning support was added via a previous GSoC.
Items (v2 objects) don't support DualQuaternion animations; one still has to use Entity (v1 object) which operates in legacy mode.
Hlms implementations should automatically modify the vertex shader so that it uses the proper math to support DualQuaternion blending. The math code should be in its own Hlms piece files for clarity and modularity.
Due to performance concerns inside the Hlms implementation (evaluating whether the mesh uses skeletal animation with regular blending or dual quaternion blending for every skeletally animated object); this feature should be toggleable from CMake; so that it doesn't penalize those who don't want this feature.

This idea may be too simple for a 3-month schedule as it doesn't require that long considering a previous GSoC did all the heavy lifting. Students should look into other easy ideas in the list to complement.

Knowledge Prerequisite: C++; Hlms; GLSL and HLSL; Dual Quaternion and 4x4 matrices.
Difficulty: Easy

OpenGEX Importer

We want to officially support OGEX as the main format for importing meshes into Ogre; as it is really good. I'm not convinced this would take 3 months to develop. Probably half of the time or even less. Could be paired with point lodding tools idea since they're related to the import process and the timeframe may match or students can propose further improving the pipeline import process (i.e. provide nice UI tools to convert to mesh formats); which may not be limited to just OGEX.

Knowledge Prerequisite: C++; JSON background would be great(*), read the OpenGEX and OpenDDL spec and be familiar with its sample code.
Difficulty: Easy.

(*) OGEX is not JSON, but it is very similar.

Depth Textures

Add support for Depth Textures (DX11, GL3) using DepthBuffer & Texture classes.
Special care must be taken so that it is easy to use DepthBuffers without killing performance.
For example once the DepthBuffer is used as sampled as a Texture, the GPU will be forced to decompress it; and will remain so until cleared. Trying to use the Depth buffer again for writing after decompressing it can seriously affect performance. It is often better to make a copy of the depth buffer so that one is used for reading (and is decompressed) while the other is for writing. Compositor interface for achieving this should be simple; and Ogre should warn if it detects the user is trying to write to a depth buffer that is already marked as decompressed.
Furthermore sampling MSAA depth buffers was added in D3D 10.1; D3D10 hardware can't do it and needs to resolve the depth buffer first, therefore Ogre should warn if trying to sample an MSAA depth buffer (that it will not work on D3D 10.0 hardware) and provide the capability to automatically resolve it.

Improve texture shadow demo, so that it only uses depth shadow maps. Provide multiple techniques (see example)

Knowledge Prerequisite: C++; Ogre Compositors (2.0); D3D11 API; GL API
Difficulty: Medium

Flexible Vertex Layouts

Implement flexible vertex layout in XMLConverter just as described in Ogre 2.0 slides (page 119). This includes adding support for normal conversion to QTangents and angle-based normals. Refactor VertexElement so that the offset is calculated automatically rather than stating explicitly.

Knowledge Prerequisite: C++; Vertex format layouts (API agnostic)
Difficulty: Medium

Automated server

Work on nightly builds / build server / test server / automated tests. A previous GSoC did a lot of work on this area; but is currently unattended. Most of the projects are currently failing on the build servers and simple changes to the project layout easily break the build.
Build servers should at least email key developers.

Knowledge Prerequisite: Minor C++; CMake; Bamboo.
Difficulty: N/A

Improve Hlms parser

The Hlms parser could do some work on how it reports the parsing errors. Also maintaining the HlmsCmd.exe project which is supposed to be a fast way of fixing compiler errors. Currently it tells you the wrong line. I often end up firing up the debugger to see where it's wrong. A quick workaround could be to print the near area that went wrong though instead of spitting out the line number; which could render this as a GSoC pointless.

Knowledge Prerequisite: C++, efficient C string parsing, experience with writing text parsers or compilers.
Difficulty: N/A

Important Notes

Projects with "Medium" to "Easy" or lower difficulty levels mean that they are perfectly / 100% doable in 3 months or less. If you don't meet the defined target requirements we will probably fail you.

For example the OpenGEX importer idea is rather an easy one. If after 3 months one cannot successfully import an ogex file into an Ogre mesh using a variety of samples (simple meshes, textured and vertex coloured meshes, lots of vertices, skeletally animated, with pose animations, etc), you will fail. We can of course expect and tolerate a few mesh samples not importing correctly by the end of the GSoC, however the overall project idea (successfully import of the majority of OpenGEX files into Ogre) should work as expected.

Projects with higher difficulty levels may fit tightly into a 3-month schedule depending on the students capabilities and/or unplanned/unexpected events that may lead to exceeding the planned schedule, and we will take this into consideration (always within the conditions and spirit of a Google Summer of Code). Other projects in that difficulty level may fit into the 3-month schedule, but they cannot realistically aim to finish the whole long term plan / bigger overall topic. One example would be the D3D11 project (classified as "Hard"): We cannot expect it to produce a fully stable and working render system on par to GL3+ in 3 months, but rather a good base on which other contributors can build after the GSoC.

With these ideas of higher difficulty, you will have to be specific in your proposal plan about which tasks will be tackled and improvements to be made, so that your performance can be properly evaluated by your mentors in case of any mishap or setback.

Alias: GSoC_Project_Ideas
Alias: GSoC Project Ideas