History: SummerOfCode Project Ideas

• «
• »

            {IMG(src="tiki-download_file.php?fileId=2300&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

!!Finish the Metal renderer
To expand the

!!Remotery integration
Remotery is a realtime CPU/D3D/OpenGL/CUDA Profiler with a web browser viewer.
The student needs to integrate it into OGRE (DX, GL3+). This means extending both rendersystems
and our CMake build chain.

__URL:__ https://github.com/Celtoys/Remotery
__Knowledge Prerequisite:__ C++; Ogre; Javascript
__Difficulty:__ Medium.

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


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


!Ideas