As the "advanced rendering techniques" theme from 2015 and "port stuff to 2.x" from 2016 did not cut it I would propose a more conservative theme for this year, namely:
"OGRE as a platform"
where we highlight what you can do with OGRE right now and improve and extend the experience. While this sounds quite fuzzy, hopefully it will become more clear with the following topics:
Topic1: interoperability between the addons
Improve the interoperability of the addons by combining them into a single project. Develop and show the best practices. Extend the Addons as needed to improve interoperability.
This also includes getting things into Ogre via blender2ogre. For this document how blender2ogre works, fix any issues you encounter and extend the export to bullet physics (.bullet) files. (Note that physics properties are already partly exported in the .scene file)
As time permits port the addons to programmable pipeline (GL3+) by using the RTSS.
This is an 1.x topic as it should focus on integration, not on fixing the API.
Topic2: bring Ogre to the web
We already have the emscripten platform to run Ogre in the browser. However this requires you to use C++. Create minimal API bindings for ogre allowing it to be compiled to an reusable js library "Ogre.js". Similar to what Mozilla did with ammo.js. Again this is 1.x as there is no WebGL for 2.x.
You should be familiar with Emscripten and HTML5.
Topic3: glslang shader plugin to generate SPIRV
Similar to Cg, add a Plugin for generating SPIRV shaders as well as support for loading SPIRV shaders in GL3Plus and/ or GLES2. The plugin should leverage glslang. This is a milestone for Vulkan support and is also very useful on mobile where shader compiler quality is mediocre.
You should be familiar with the Ogre Plugin System and OpenGL.
It should be possible to share the Plugin between 1.x and 2.x.
Topic4: Configurable Pipelines with RTSS
The RTSS has some advantages with managing the code complexity when compared to the HLMS. However it currently it is modeled very tightly after the Fixed Function shading model: e.g. computing lighting before texturing. But for Physically Based Shading we store data relevant for lighting in textures. So the RTSS needs to be made more flexible in this regard to allow scriptable render pipelines.
Also the code is currently overly verbose and poorly documented. The project therefore would also include documentation and cleanup tasks.
Therefore you should be already familiar with the RTSS or some other shader generation mechanism.
If you are interested in applying
- You must be already familiar with C++. The timeframe is too short for learning the language and finishing the project.
- Please only propose projects that you already know how to do. Mentors will assist you with the project, but will not be able to teach you a new area.
- Roughly follow our GSoC application template http://wiki.ogre3d.org/tiki-index.php?p ... onTemplate
- Describe in your Application in how far you used Ogre and the technology relevant for your project before.
- Documentation, tests and tutorial are as important as the code.
- GSoC 2018 Timeline https://developers.google.com/open-source/gsoc/timeline