[GSoC 2018] Idea Discussion

[paroj]

OGRE did not participate in 2017 and was not selected in 2014-2016 which makes GSoC 2013 the last one where we got contributions. So.. lets try again

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

1. You must be already familiar with C++. The timeframe is too short for learning the language and finishing the project.
2. 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.
3. Documentation, tests and tutorial are as important as the code.
4. GSoC 2018 Timeline https://developers.google.com/open-source/gsoc/timeline

[PhilipLB]

Hi there,
(despite being rather inactive the last years) I'm still very interested in Ogre and it's ecosystem.
I would like to be a mentor here if possible and usefull.

One topic proposal which is currently holding me back to go back to Ogre: What is the state of the MacOS toolchain? Fix anything that's broken until all samples run on MacOS.

[spookyboo]

My suggestion is to write proper documentation for 2.1 to make Ogre more accessible to new users.

[paroj]

One topic proposal which is currently holding me back to go back to Ogre: What is the state of the MacOS toolchain? Fix anything that's broken until all samples run on MacOS.

OSX is part of our CI that compiles the code and runs the unit tests (e.g. https://travis-ci.org/OGRECave/ogre/jobs/307820937).

Furthermore Eugene is specifially working on the platform support, so it should be in a quite good shape.

[xrgo]

I would like a really nice showcase sample, very eyecandy using all the nice features of 2.1 =D... but this is more art than code actually =/

[Tobse]

I would like to see ogre to be part of GSoC 2018, whatever topic it would be. So IMHO it is more important that a topic would be accepted, than it would be the "super duper gimmick" for ogre.

[Zonder]

I would like a really nice showcase sample, very eyecandy using all the nice features of 2.1 =D... but this is more art than code actually =/

Thats been brought up before but it's not allowed as it's not adding to the engine or something

[xrgo]

Thats been brought up before but it's not allowed as it's not adding to the engine or something

My bad, I haven't really checked the gsoc conditions, something like this would only add more users lol

[paroj]

I would like to be a mentor here if possible and usefull.

I guess it would be in the area of Volume Rendering. Could you formulate a concrete topic here?

[PhilipLB]

I guess it would be in the area of Volume Rendering. Could you formulate a concrete topic here?

Hi,
what immediately comes into my mind:
- A new source for 3d textures. The editor Acropora seems dead by now.
- A better file format for the volumes. 3d textures need more space than needed. It would be nice if only the volume near the surface could be stored. Maybe in an Octree? Ogre could provide functionality to store this format to the filesystem. Combined with the existing CSG, the groundwork for an editor would be done.
- Of course: Examing the state of the volume component against Ogre 2.1 and porting it over.

[farrer]

My suggestion: rework and fix the SDK generation process and automagically generate releases for both Ogre 1.10.x and Ogre 2.1.

Although it's straightforward to compile Ogre, for newcomers it seems like a significant initial barrier, as suggested by the high frequency new people appear at this forum with compiling-like questions. Also, pre-generated SDK releases appearing at the Downloads page would give the "alive-feeling" that sometimes is lacking for those which aren't on this forum or didn't look at the Mercurial commit log to check.

[paroj]

My suggestion: rework and fix the SDK generation process and automagically generate releases for both Ogre 1.10.x and Ogre 2.1.

Although it's straightforward to compile Ogre, for newcomers it seems like a significant initial barrier, as suggested by the high frequency new people appear at this forum with compiling-like questions. Also, pre-generated SDK releases appearing at the Downloads page would give the "alive-feeling" that sometimes is lacking for those which aren't on this forum or didn't look at the Mercurial commit log to check.

I think this is not enough for a GSoC. Basically it boils down to extend the existing CI scripts to upload its artifacts to e.g. https://bintray.com/

This should be a matter of weeks and not months.

Actually anybody can start tackling this - the scripts are in git: https://github.com/OGRECave/ogre/blob/m ... travis.yml and as soon as you open a PR the builders will pick up whater you write in there..

[dark_sylinc]

My suggestion: rework and fix the SDK generation process and automagically generate releases for both Ogre 1.10.x and Ogre 2.1.

Although it's straightforward to compile Ogre, for newcomers it seems like a significant initial barrier, as suggested by the high frequency new people appear at this forum with compiling-like questions. Also, pre-generated SDK releases appearing at the Downloads page would give the "alive-feeling" that sometimes is lacking for those which aren't on this forum or didn't look at the Mercurial commit log to check.

I think this is not enough for a GSoC. Basically it boils down to extend the existing CI scripts to upload its artifacts to e.g. https://bintray.com/

This should be a matter of weeks and not months.

Actually anybody can start tackling this - the scripts are in git: https://github.com/OGRECave/ogre/blob/m ... travis.yml and as soon as you open a PR the builders will pick up whater you write in there..

I'm not sure I agree. As I wrote a short time ago, ALL of our CMake scripts could use of a clean-slate.
Something like that is a 3 month project (writing the new scripts, gradually replacing the old ones, tidying up, testing all platforms, testing all config combinations)

[paroj]

I'm not sure I agree. As I wrote a short time ago, ALL of our CMake scripts could use of a clean-slate.
Something like that is a 3 month project (writing the new scripts, gradually replacing the old ones, tidying up, testing all platforms, testing all config combinations)

for 1.x the INSTALL target already generates something usable on windows & linux. To me the missing part here is to get that from the CI to some persistent storage where people can download it from. (ideally also providing "nightly" builds)

Although it would be nice to get an INSTALL target for android as well..

[dark_sylinc]

It's not about having something usable, it's about having source and prebuilt SDKs matching 1:1 (i.e. if I switch to source version, I don't have "build" the SDK).

And then there's the inconsistencies between platforms. Ideally, the user should double click (or type a single command) and everything just works. Everwhere. We're extremely far from that. (e.g. 1.10's scripts run quite poor with QtCreator)

[al2950]

Been meaning to post for a while and its probably a bit late, but kept slipping my mind...

This might be more of a wish list.... but Ogre is a rendering engine and I feel that projects like this should focus on that point. So there are plenty of great suggestions here of things that would benefit Ogre, but in my mind not many are rendering orientated. So I feel the following would be more suited (I am coming from an Ogre 2.x point of view, but I dont see why these ideas could not correspond to Ogre 1.x as well)

• GPU Particles, or a decent particle system in general! this would has some challenges but would be a good size GSOC ( I started on this over Christmas, but annoying fell ill on my few days off each year!).
• Reflection system. A robust reflection system is crucial to any modern shading. Ogre 2.1+ has a number of reflection systems, SSR, Reflection probes, gloabal relfection map, planar reflections. But even they are not currently very joined up and require a fair amount of effort to get working as a single unit.
• Volumetric lighting system, again volumetric lighting is used quite heavily these days, and comes out of the box for most engines.
• VR rendering techniques. You can just about at the moment use Ogre to render to VR HMDs, but its not without its problems. It would be good if Ogre could support VR out of the box.

I have not mentioned global illumination as there is no single technique (yet), that solves all the problems and basically each scene requires its own technique. But we should probably provide functions the aid in implementing various techniques.

There are plenty more 'graphics' projects, just need to look at rendering featured for UE4, or Unity, or other smaller engines like Godot .

[paroj]

unfortunately we were not accepted this year.

However looking at the idea page of Godot, which was accepted, It seems that we were on the right track with the "ecosystem" theme:
https://github.com/godotengine/roadmap/ ... OC-2018.md

the ideas are mostly about interoperability with other frameworks. So I think we should focus on the "Ogre building blocks" idea to get a better stance next year. For this we must provide a stable Ogre core as a foundation for others to build upon.