History: SummerOfCode Project Ideas

Source of version: 13 (current)

{IMG(src="tiki-download_file.php?fileId=2300&amp;display")}{IMG}

{maketoc}

!General
This page lists some GSoC project ideas that the Ogre team considers especially relevant 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)) from past years as well as a dedicated ((GSoC 2015 Project Ideas|list from 2015)) that contain 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=84884|dedicated forum thread] discussing more potential ideas from the community.__''
{DIV}

!Ideas

!!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!


!!Distance Field Fonts
Signed distance field rendering is a technique used in Team Fortress 2. It allows you to render bitmap fonts without jagged edges even at high magnifications. Furthermore the student should create an fast method to render many fonts (batching).

__URL:__ http://www.valvesoftware.com/publications/2007/SIGGRAPH2007_AlphaTestedMagnification.pdf
__Knowledge Prerequisite:__ C++, Ogre, Shaders (DX/OGL)
__Difficulty:__ Easy / Medium


!!2D drawing interfaces
Right now we have Ogre::Rectangle2D (which is not suitable for rendering large amounts of sprites) and Ogre::Overlay (which has a lot of design issues with Ogre 2.1 and is quite hard to use / over-engineered).
2D rendering should support sprite animation (at best can import direct from texture packer tool), ninepatches, lines, paths.
Everything should be done with performance in mind.

__Knowledge Prerequisite:__ C++, Ogre, Shaders (DX/OGL)
__Difficulty:__ Medium / Hard


!!Port the GLSLES 3.0 renderer 
Atm the GLSLES renderer is not working with OGRE 2.1. The student needs to review the current functionality
which is used inside OGL3+ and decide how we can replicate or emulate it with GLSL3.0.

__Knowledge Prerequisite:__ C++, Ogre, GLSL, GLSLES, OGL
__Difficulty:__ 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(*), nice to have: familiarity with the OpenGEX and OpenDDL specs and their code samples
__Difficulty:__ Easy

(*) OGEX is not JSON, but it is very similar.
History: SummerOfCode Project Ideas

Source of version: 13 (current)

Search by Tags

Latest Changes

Search

Online Users
