[GSoC 2012] Ideas from community

[spacegaier]

banner-gsoc2012.png

Looking for ideas!

As OGRE has been accepted as one of the 180 GSoC 2012 projects, we are now looking for students to participate this year. This also means that we need good ideas on which topics those potential candidates could work on during the summer.

This thread therefore offers the possibility to everyone in the community to simple drop in ideas that might be worth discussing in detail. Those detailed discussions should then take place in separate, dedicated threads in this GSoC forums section. So please use this thread as a pure idea stack...

Other sources of inspiration
Before posting in ideas here, please check whether they have already been listed in one of the sources of inspiration:

GSoC Project Ideas wiki page
Help Requested wiki page

[Shaun]

Idea #1 I was thinking of this project which I have had in mind for quite a while. I wanted to work on a single player RPG zombie apocalypse demo that we could put together with the rest of the demos in the OGRE SDK download. People could actually play a game to see what you can pull off with the engine and not only that. I'll post up about this demo and what files contain what data how it was all done, along with posting about it on lots of zombie forums that I know of, and since all the code is already right there in the SDK download, people just need C/C++ to tweak around with the demo and recompile to create their own mods, this could go really really big, because there are a lot of zombie enthusiasts in the world and none of them have actually come across the right game to give them the perfect fix, so they're always looking for the next zombie movie or video game title.

Imagine people posting on Youtube for their respective zombie apocalypse spin-offs from this game. The amount of folks that would play and watch videos with "OGRE" or "Made in OGRE" inscribed somewhere on the screen may get us a lot of people interested in learning about this engine called OGRE. And the creativity that could stem from all these people learning to use this engine and the source code of my game and use it for creating other things could really be a hell of a bomb for us all!

I know I'm being a tad more optimistic there... I generally am

Idea #2 The other thing that I have had in my mind for a long time is Ogitor. The whole idea of Ogitor is so awesome. I mean it could make creating any video production (be it a game, movie or simulation) out of OGRE a breeze when compared to all the things that we have to do at present yeah? A lot more so for the newbies. The present introduction for OGRE that we have, is still kinda esoteric and a lot of newbies who are impatient, move on to other projects when they get nothing done out of this in a short span of time, and this is a loss to us. I feel there are a lot of such people since there aren't any folks that I know of who are interested in game development that I have met face-to-face in life who know about OGRE. And that is very sad because this is a pretty awesome engine (The best imo). We could try to do something about it. Add more features like better and more robust integration with other libraries like Hydrax, ODE, Bullet, SpeedTree, some AI library, GUI libraries, audio library etc (some of these have already been done but almost none of them are in a state that I currently have in mind. The integration could really be wayyyy better despite all the hardwork already gone into the project) and feature for scripting with Python 3.1/3.2.

That's more or less it from my side! Whaddaya guys think? I also think if we could get both the projects done it would be wayyyy better since the two would complement wachother really well.

[Thoran]

I am not quite sure how good it qualifies for GSoC, but finsihing up the DirectX 11 renderer together with some samples is something that I think would greatly help the whole Ogre3D community. To be honest DirectX9 rendering times are not over, but they are declining. Therefore the move towards DirectX 11 should be done with more consequence, which the GSoC would be a good opportunity for. I don't have a clear overview of what the DirectX 11 renderer still needs, but definately some samples. So maybe people who are working more closely on it can judge that better and maybe give feedback if this something totally unnecessary

On a second thought combining this with a second GSoC project, the following book chapter from GPU Pro 1 could be implemented

7.3 Shadow Mapping for Omni-Directional Light Using Tetrahedron Mapping by Hung-Chien Liao

taking into account Geometry Shaders to limit the amount of render passes for the shadow maps. The source code for that is even available from the book related blog, so in fact it is an adaptation of the code to Ogre3D. However still the above technique could also be implemented for DX9 in a first step, to avoid interdependencies between GSoC projects.

So to summarize:
1. Finish DirectX 11 renderer and add samples (e.g. shader 4.0)
2. Implement Shadow Mapping for Omni-Directional Light Using Tetrahedron Mapping for correct point light shadow mapping

Thoran

[Brocan]

1 - Official Android support.
2 - Finish DX11 render system, generate samples with tesselation and the other dx11 features.
3 - Make a benchmark demo with a lot of awesome graphic techniques. . Something like unreal engine last tech demos

Cheers!

[saejox]

I love all the ideas. However they all seem to be on the "tech" side of things. What Ogre really needs is tools. It is very off-putting for artists to work with Ogre.

- A fully functional mesh viewer. movable lights, material information, included tools for resizing, updating, rotation etc...
- Material Editor , not just a glorified text editor. Likes of which you see in Unreal Engine or 3ds Max. Build your shaders by seeing them
- Particle Editor , users should not be forced to buy some product to create good looking particles, maybe a new particle system to allow mixing/timing/blending different particles

Ogre doesn't need new fancy effects. "intuitive tools" is where all effort should go.

[Xavyiy]

As Thoran and Brocan have suggested, I think finishing the DX11 render system should be the highest priority for this year GSOC. And by finishing the DX11 render system I also mean adding to the Ogre core the needed abstraction classes for dealing with the new DX11/OGL3+ features, which IMHO is a quite hard task if we want to keep the consistency which characterizes to Ogre.

On the other hand, I think Android support is going to be quite important in a near future, since it's a market which is quickly growing and also new mobile devices power(2-4 cores, decent graphic cards, etc) is far enough for Ogre.

Xavier

[dark_sylinc]

I'm with saejox, although he hurt my feelings when he said "fully functional mesh viewer". OgreMeshy only lacks material info. As for mesh editing tools, that's not a "viewer" function.
Edit: Oh, I see you're the one suggested movable lights using billboards. Sorry about that. Been dead busy. Too bad I'm busy now, so I can't participate in GSoC

I should also suggest a compositor editor, in which each chain is seen as a "layer" just like you can in GIMP or professional video editors; while being able to set visibility masks to control what gets drawn on each layer. In other words, how things get "composited".

DX11 support should also be high priority.

[mkultra333]

First thing I thought of when seeing the thread title was DX11. But I was beaten to it by five others, so I'm out of ideas.

[syedhs]

DX11!!

Refine Ogitor. Take note: I have lots of respects for efforts behind Ogitor as there lots of work have been done. However , IMHO it is still not very usable for production but all it takes is many but minor improvements. Specifically
1) Add physics support. You can use NxOgre for an example. Efforts should be connecting the dots between Ogitor and NxOgre.
2) It is still an editor meant for programmers - this is very minor actually but it bugs me when I see the heightmap import dialog box 'Scale' and 'Bias'. Just rename it to Minimum Height and Maximum Height, really that is all. Change the skin of the editor to somewhat blackish or dark grey like Unity. More drag and drop thingies so it is seamless experience for artist.
3) RAM usage is quite big. Heightmap import is buggy so I have to resort to f32.
4) Stability.
5) Probably some can dabble in generating better lightmap generator (terrain area probably).
6) Support for spline, helpers within Ogitor - world editor is not all about simply placing visible entities (grass, meshes).
7) And one FPS game sample made possible by Ogitor. The budget can go toward purchasing the arts needed.
There is a great need for a complete world editor for Ogre, and I think Ogitor is the closest effort. So lets perfect it, otherwise - we will keep seeing new editors done by others so instead of concentrated efforts on one single editor, we will see many but not usable editors.

Android.

[Thoran]

- Particle Editor , users should not be forced to buy some product to create good looking particles, maybe a new particle system to allow mixing/timing/blending different particles

I think this would be a waste of time, as there is already a really great PraticleEditor out there, even if it is not without cost, but I think the ParticleUniverse is really worth the 20€.

Thoran

[kulik]

I would love to see at least one slot dedicated to Ogitor. It's a great tool but as of now it's more of a platform, it hasn't gone past the "ready to be thrown at artists" point Making it production ready is the key. I agree with the points raised that it's targeted at developers whilst it should be usable by artists. Polishing isn't a task that is suitable for GSoC though, if anything it should be done as a side goal.

While material editing is already under development according to their bug tracker, RTShaderSystem support is not included. I would love if RTShaderSystem material editing was supported in Ogitor, especially if it's in a visual way (node-graph? research would have to be done).

- Particle Editor , users should not be forced to buy some product to create good looking particles, maybe a new particle system to allow mixing/timing/blending different particles

I think this would be a waste of time, as there is already a really great PraticleEditor out there, even if it is not without cost, but I think the ParticleUniverse is really worth the 20€.

Thoran

I disagree, ParticleUniverse may be great for proprietary games but the fact that it is commercial is a blocker for FOSS games. Projects like Summoning Wars can't possibly adopt it.

[Alexiss]

Maybe implement sparse virtual textures for Ogre::Terrain (http://silverspaceship.com/src/svt/).
There's a lib which supposedly implement this technic, I haven't checked what it's worth yet though : http://sourceforge.net/projects/libvt/

[CABAListic]

I don't know what Google's official policy on this is, but from my point of view Ogitor is an independent project, and I don't think it's allowed/appropriate to donate them one of our slots.
Either way, we usually prefer to see our GSoC projects focus on core Ogre development.

[spacegaier]

I don't know what Google's official policy on this is, but from my point of view Ogitor is an independent project, and I don't think it's allowed/appropriate to donate them one of our slots.
Either way, we usually prefer to see our GSoC projects focus on core Ogre development.

+1
And we are always accepting patches and proposals for Ogitor. Just create a ticket on our tracker and I will have a look at it and discuss further steps.

[syedhs]

Cabalistic,

I think if Ogitor can be declared as project done by Ogre users, and it is an official Ogre tool - then it not a problem. Google probably will just clarify it back with Ogre team members - just my hunch

[kornerr]

1. Full-fledged 9th Basic (!) tutorial which shows AND EXPLAINS how to setup texture shadows that look better than stencil ones.
2. Variance shadow maps: http://www.punkuser.net/vsm/

[spacegaier]

1. Full-fledged 9th Basic (!) tutorial which shows AND EXPLAINS how to setup texture shadows that look better than stencil ones.

Doesn't sound like a project that should take a dedicated student the whole summer, but rather like something a "normal" community member could do (given the needed knowledge).

[duststorm]

My first thought was also on OpenGL 3+ and Direct3D 11
But maybe this is not a task that is easy to outsource because it involves an important redesign of the ogre core, it's not an isolated project.

What about adding some advanced shaders to the RTSS system. Something from nvidia articles or other sources, to get some recent eyecandy in Ogre.
However, since a lot of those shaders are based on the latest shader features lately, I fear that this proposal and the previous go hand in hand.

[Thoran]

I don't know what Google's official policy on this is, but from my point of view Ogitor is an independent project, and I don't think it's allowed/appropriate to donate them one of our slots.
Either way, we usually prefer to see our GSoC projects focus on core Ogre development.

I 100% agree with Cabalistic. even though Ogitor is a really great project it is still an open source project of its own and as much as I would love seeing the features mentioned here in Ogitor, I think this is something that would have to be done in a GSoC where Ogitor is represented as an independent project. Therefore I would also propose to focus on core features which belong into the Ogre library.

Thoran

[errorist]

Hmm... I was dreaming to have a all-in-one mesh exporter for OGRE. Because all these plugins for 3DSMax, Maya, Blender and others are too rough... You need to find plugin, to install and configure it and finally, all of them have its own features, different for each plugin.

If a single tool could simply take, for example, *.3ds, *.blender, *.dae and *.whatever file (lets say, one for each editor; unique for that editor... dunno how to say it better - official editor (export) file format maybe?) on the input and provide a *.mesh, *.skeleton and others on the output - that would be really great!

[noorus]

Further terrain improvements.
I want to nominate "Very Large Terrain" paging, rendering and precision considerations for GSoC, as a logical extension of kuxv's Terrain LOD work from last year.

Completed DirectX 11 support.
I have to admit that I don't know the current real state of the DX11 rendersystem, but my understanding is that some of the core DX11 features are still missing, and that it still has quite a few rough corners. So I'm with the above posts here, it would be good to be able to move to DX11 as the default renderer sooner or later, and at least have it as a stable, proven alternative for the DX9 renderer.
And of course the samples should be up to date with it.

Modern shadowing methods/samples.
Poor shadows are an easy way for any project to look out of date. Shadowing is also one of the most complex topics in the field of realtime graphics.
So I think the more attention the subject gets, and the easier and cleaner modern shadowing implementation is made for the average user, the better.

[spacegaier]

Hmm... I was dreaming to have a all-in-one mesh exporter for OGRE. Because all these plugins for 3DSMax, Maya, Blender and others are too rough... You need to find plugin, to install and configure it and finally, all of them have its own features, different for each plugin.

If a single tool could simply take, for example, *.3ds, *.blender, *.dae and *.whatever file (lets say, one for each editor; unique for that editor... dunno how to say it better - official editor (export) file format maybe?) on the input and provide a *.mesh, *.skeleton and others on the output - that would be really great!

Search for OgreAssimpConverter.

http://www.ogre3d.org/tikiwiki/OgreAssi ... ture=Tools

[Wolfmanfx]

* Refactor OGRE's Scenegraph to support CHC++ and other advanced techniques (tuan's scenemanager could be used as a base)
- Also the SM should not call RS::_render directly it should just fillup the Renderqueues
* Research multithreading techniques using intel tbb (multithreaded culling,...)
* Retrofit RenderSystem interfaces to better support DX11 threading model
- I do not know if this fits into GSOC
* Create a heavy scene to showcase OGRE's performance (which we could use to optimize the culling - maybe a city of boxes)
* Extend shader support for CGFX (its already started inside CGProgramManager)
* Remove overlays and replace it with an component maybe steals some ideas of gorilla

[CABAListic]

* Research multithreading techniques using intel tbb (multithreaded culling,...)

Quick note: While multithreading projects are definitely welcome for GSoC, tbb is problematic. It was decided a while ago that tbb is not suitable for an Ogre core dependency due to its license. Although GPL with the runtime exception is technically a very liberal license, the name GPL alone will trigger alarm bells in any legal departments of companies that might be considering Ogre for a project.

[Wolfmanfx]

Yeah then tbb could be used for the research i think its easier to use the features which tbb provides to see if there is an potential to improve. I think this could be really a promising project - like a technical report.
Every time when i talk to gamedevs the say: "...yeah know OGRE its single threaded..." so this must change