History: GSoC 2015 Project Ideas

Source of version: 63 (current)

{IMG(fileId="2232",rel="box[g]",imalign="center")}{IMG}

{maketoc}

!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 [http://www.ogre3d.org/forums/viewforum.php?f=13|GSoC Ogre forum section] (please take the ((GSoC ApplicationTemplate|application template)) into  account). 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!

{DIV(class="Bloody_box1")}
__Additional inspiration:__
There is also a ((GSoC Legacy Project Ideas|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.

Additionally, there is a [http://www.ogre3d.org/forums/viewtopic.php?f=13&t=82719|dedicated forum thread] discussing more potential ideas from the community.
{DIV}

!Ideas

!!Improve Ogre 2.0 mesh format
The Ogre 2.0 mesh format is still in its infancy. It can only be loaded by Items (Ogre::v2 object). Ideally, Ogre::Entities (a Ogre::v1 object) should be able to load the 2.0 mesh format as well (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 or use v1 mesh files and import them on the fly.

__Knowledge Prerequisite:__ C++, be familiar with the Mesh serialization format in Ogre.
__Difficulty:__ Easy.


!!Level of Detail (LOD)
A ((SoC2013 Progressive Mesh Improvements|previous GSoC project)) did all the LOD'ing stuff. The algorithm is great, but it only supports v1 objects. Ogre::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.
For example, 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" which internally contains:

LOD 0: Sinbad.mesh
LOD 1: Auto LOD from Sinbad.mesh
LOD 2: Read from SinbadLOD1.mesh
LOD 3: Auto LOD from SinbadLOD1.mesh
LOD 4: Auto LOD from Sinbad.mesh
LOD 5: Read from SinbadLOD2.mesh

This is now possible with v2 objects (Items), but not possible with v1 objects (Ogre::Entity).

Ideally there should be a library interface, and a command line tool for batch processing 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 / C# / Python / etc.)
__Difficulty:__ Medium. There's a big demand for this!


!!Particle FX (PFX)
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, multi-threading (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|HLMS] implementation) and use the superior v2 buffer interfaces.
[http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/Vertex-Shader-Tricks-Bill-Bilodeau.ppsx|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).

__Knowledge Prerequisite:__ C++; Ogre Particle FX Component; HLSL and GLSL shader knowledge[http://www.dataorienteddesign.com/dodmain/|Data Oriented Design].
__Difficulty:__ Medium / Hard.


!!Port Pose animations to Ogre::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.
The task is to write a more lightweight system that can store position and normal offsets for each animation and each affected vertex into plain old array.
The system should also be capable of importing the pose animations from v1 Entity into Item.
Implementation could support:
*SW: Accumulate pose offsets all from all animations in CPU (using multi-threading!) 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 Ogre Hlms understading; Pose animations; GLSL and HLSL; Compute Shaders
__Difficulty:__ Medium / Hard.


!!Port DualQuaternion Skinning to v2
Dual Quaternion Skinning support was added by a ((SoC2011 Dual Quaternion Skinning|previous GSoC project)).
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++; Ogre Hlms; GLSL and HLSL; DualQuaternion 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 looking good and gaining traction throughout the industry. After a more thorough evaluation we believe this is a perfect 3-month project for students.

__Links:__
Reference implementation: http://opengex.org/OpenGex-Import.zip
3rd party parser: https://github.com/kimkulling/openddl-parser/

__Knowledge Prerequisite:__ C++; Debugging skills for breaking down / reverse engineering the reference implementation; 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 the user is 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 [http://mynameismjp.wordpress.com/2013/09/10/shadow-maps/|example])

__Knowledge Prerequisite:__ C++; Ogre Compositors (2.0+); D3D11 API; OpenGL API
__Difficulty:__ Medium


!!Flexible Vertex Layouts
Implement flexible vertex layout in XMLConverter just as described in [http://www.mediafire.com/view/?7k0q4guxgm74y2g|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 ((SoC2011 Visual Unit Testing Framework|previous GSoC project)) 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 upon build failures, package regular SDK builds and execute the Ogre unit tests (ideally also the visual tests).

__Knowledge Prerequisite:__ Minor C++; CMake; Bamboo/Jenkins/etc.
__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 (i.e. "Medium" or higher) 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: (alias(GSoC_Project_Ideas))
Alias: (alias(GSoC Project Ideas))
History: GSoC 2015 Project Ideas

Source of version: 63 (current)

Search by Tags

Latest Changes

Search

Online Users
