[GSoC 2015] Idea discussion thread

[spacegaier]

GSoC 2015 Main Thread: http://www.ogre3d.org/forums/viewtopic.php?f=13&t=82718

Project Ideas
We are hoping to once again find a group of capable and motivated students that help us move Ogre even further. In order to guide this effort, we created a list of potential GSoC projects that we deem most relevant for this year and consider manageable in the given GSoC time frame: GSoC 2015 Project Ideas.

If you have any comments or potential additional ideas, feel free to discuss them here. If you are a student who wants to tackle a project, you at some point should create your own forum thread dedicated to your proposal and application.

On a related note: The so far private Ogre Hlms/AZDO branch will most likely be made publicly available around the end of this week. This of course is needed for the related GSoC idea to be possible.

[scrawl]

I have two project ideas:

- Finish the 2013 GSOC "Redesign the resource system"

- Finish the windowing plugin system, which was started by holocronweaver. The missing parts being the DirectX and IOS/Android implementations.

The ideas on the wiki page are nice too. Most of them are for the Ogre Core, which is good. There is so much left to do, so staying focused is very important.

I won't be participating this year unfortunately (sorry, too busy ).

I hope Ogre gets some GSOC slots this year. I fear that the reason it wasn't accepted last year might be Ogre 2.0 being still too much in its infancy to be a viable learning platform for students. Either way, good luck!

[holocronweaver]

I managed to get DirectX working with the SDL2 window system yesterday, so that is done. I don't think the Android/iOS window system work is worth a whole GSoC, but could perhaps be part of much needed love of the 2.0 sample browser and unit testing.

[frostbyte]

I don't think the Android/iOS window system work is worth a whole GSoC

maybe it can be joined with other small assignments, or is joining different topics breaking gsoc rules?...
openGEX support with all the code and examples that was already written for it shouldn't take more than a month+, imho...
i prefer GSoC projects to focus on ogre core... all other stuff would naturaly come from the community once the need arises...

[Thyrion]

that's a big todo list. *thumb pressing *

[Transporter]

• - Finish the 2013 GSOC "Redesign the resource system

• OpenGEX Importer
• Automated server

I like that ideas. Bamboo is an expensive service, maybe it's better to work with travis ci.

[jacmoe]

It should only take 3 days, but how about a hardware-accelerated terrain renderer ?

[jacmoe]

Particle Universe to replace current particleFx plugin in Ogre ?
That would be really cool.

[frostbyte]

Particle Universe to replace current particleFx plugin in Ogre ?

should take a whole summer???
can be done in 3 days...
anyway i dont think particle-universe integrate well with hlms/azdo( yet... )
GSoC particle proposal by dark_sylinc sounds good as we need to start moving component to 2.1 way of doing stuff
i would only add to this proposal moving the whole particle system from cpu-threads to gpu-shaders( aka gpu based particles )

Edit: on the other hand, moving particle-univrese to ogre 2.1 azdo/hlms/multiThreaded can be a good alternative to writing from scrach...
guess thats what you really meant...

thing is that i think we should consider the chances of the project to be accepted more than its coolness...
writing from scrach provides a deep relegious enriching learning experiance for both the student and the mentor and therefor have a better chance...

[Transporter]

Particle universe - or something similar - should be a module of Ogitor to design particle effects. What about offering GSoC jobs for Ogitor parts?

[frostbyte]

What about offering GSoC jobs for Ogitor parts?

genious...yeah, why not?

[stealth977]

@Transporter:
old Ogitor is being shelved and new Ogitor is in early development, so, I dont think it is feasible.

Also, any new feature OGRE gains, Ogitor gains it too so GSoCs should be OGRE related...

[frostbyte]

Also, any new feature OGRE gains, Ogitor gains it too so GSoCs should be OGRE related...

other way around can work as well...Ogitor gains->Ogre gains...double chance....
oh well...maybe next year...but it is still a good idea that Transporter put on the table...

[al2950]

Particle Universe to replace current particleFx plugin in Ogre ?

should take a whole summer???
can be done in 3 days...
anyway i dont think particle-universe integrate well with hlms/azdo( yet... )
GSoC particle proposal by dark_sylinc sounds good as we need to start moving component to 2.1 way of doing stuff
i would only add to this proposal moving the whole particle system from cpu-threads to gpu-shaders( aka gpu based particles )

Edit: on the other hand, moving particle-univrese to ogre 2.1 azdo/hlms/multiThreaded can be a good alternative to writing from scrach...
guess thats what you really meant...

thing is that i think we should consider the chances of the project to be accepted more than its coolness...
writing from scrach provides a deep relegious enriching learning experiance for both the student and the mentor and therefor have a better chance...

I have already ported it to Ogre 2.0. This has caused me to go through the code in some detail. Getting particles to be updated in a multi threaded data orientated way should be pretty easy, as for making it AZDO compatible, it should also be pretty easy especially if Ogre::Billboard and similar entities are updated. Its not without its issues though, but I dont think they are show stoppers. Might have already done it by the time GSOC comes around!

[al2950]

Now Ogre 2.1 is here could we have GSOC that looked at some advanced rendering techniques;

• - Env probe system + screen space reflections
• - Physically based area lights (not a bunch of spot lights arranged in a square!!)
• - Deferred/forward 2.5+ render or what ever is the latest and most talked about technique!
• - True volumetric lighting
• - GI techniques
• - what else.....!??

Admittedly I have already started on a few of those, but I think it would make a good GSOC for a rendering engine. I know this was already done for V1.8? but it was limited by what Ogre could do then, but now we have Ogre 2.1

[jacmoe]

Do you have a public repository for the updated PU code ?

[jacmoe]

What about offering GSoC jobs for Ogitor parts?

That would be cruel
We don't even know what Ogitor does or doesn't do at the moment ourselves..

[TheOnlyJoey]

Debug information for render pipeline

- Be able to print current render pipeline, see what happens where and relations in automatic generated passes/schemes.
- A debug mode where you can highlight objects being rendered in their respective passes (ie, just render all renderqueue passes between 10 and 20).
- Out of the box support for rendering just 1 specific pass or compositor (currently only doable by hacking materials or compositors) (ie, Just show me the normal buffer etc).

This will enhance visual debugging, but also should be useful for verbose information (easier debugging for automatic generated components)

---

Our team has always had struggles with debugging, and specially since OpenGL debugging is one big mess, a couple of relatively simple in-engine debugging options would help out a lot!
Of course this can be done renderer agnostic for a big part, which helps out everyone.

[Transporter]

Do you have a public repository for the updated PU code ?

We should change it to Qt for Ogitor integration. The original files are written with wxWidgets.

I would like to see the redesigned resource system from last year

[al2950]

Do you have a public repository for the updated PU code ?

yup;
https://github.com/al2950/particleunive ... e/Ogre_2.0

Please note I will be pushing this back to scrawls repo, however I wanted to make sure it worked with Ogre 2.1 and I also wanted to sort out some of the renderers as some create objects using the Scene Manager and others do not! I will change it so they all create and own their renderables and the Scene Manager knows nothing about them, only the base ParticleSystem. Having said that the light renderer has to create the lights via the Scene Manager.

[jammm]

Hey guys, student here.
I've been watching this thread and so far I'm pretty excited to help you guys in the growth of Ogre3D!
In my free time I've been learning DirectX 11 and working on a rendering engine made from scratch using it. (Can post a video of current state of engine if needed)

In the past, I've used DX9 to develop my first game: http://www.gamedev.net/topic/656725-you ... try5159208

I've also worked on other games, including a type-racer game made using PyQT and a bot vs bot turn based game made using JS and WebGL.

Game engines has been my passion for a couple years now, and I'm learning more and more about it everyday, as I work on my rendering engine and add new features to it.
I saw the ideas page, and these are the ideas that seemed relevant to the rendering engine. I'm primarily interested in improving the D3D11 RS, as I believe my D3D11 knowledge will help here, and I've worked with other programmers in previous projects, so communication will not be a problem, at the same time it'll also benefit me by learning how a professional quality 3D engine works, which is why I am here.
Other than the D3D11 RS, I also find the OpenGEX importer, Ogre 2.0 mesh format improvements and flexible Vertex Layouts interesting. Basically anything that has to do with the rendering engine, I'm in

What do you guys think? Do let me know any other stuff that you need to know about me or my work.

jam

[Zonder]

Hey guys, student here.
I've been watching this thread and so far I'm pretty excited to help you guys in the growth of Ogre3D!
In my free time I've been learning DirectX 11 and working on a rendering engine made from scratch using it. (Can post a video of current state of engine if needed)

In the past, I've used DX9 to develop my first game: http://www.gamedev.net/topic/656725-you ... try5159208

I've also worked on other games, including a type-racer game made using PyQT and a bot vs bot turn based game made using JS and WebGL.

Game engines has been my passion for a couple years now, and I'm learning more and more about it everyday, as I work on my rendering engine and add new features to it.
I saw the ideas page, and these are the ideas that seemed relevant to the rendering engine. I'm primarily interested in improving the D3D11 RS, as I believe my D3D11 knowledge will help here, and I've worked with other programmers in previous projects, so communication will not be a problem, at the same time it'll also benefit me by learning how a professional quality 3D engine works, which is why I am here.
Other than the D3D11 RS, I also find the OpenGEX importer, Ogre 2.0 mesh format improvements and flexible Vertex Layouts. Basically anything that has to do with the rendering engine, I'm in

What do you guys think? Do let me know any other stuff that you need to know about me or my work.

jam

as a long standing comunity member.

Ogre isn't a game engine, its a rendering engine remember. But you seem keen I would recommend OpenGEX? it's harder than you think.-

[jammm]

Hey guys, student here.
I've been watching this thread and so far I'm pretty excited to help you guys in the growth of Ogre3D!
In my free time I've been learning DirectX 11 and working on a rendering engine made from scratch using it. (Can post a video of current state of engine if needed)

In the past, I've used DX9 to develop my first game: http://www.gamedev.net/topic/656725-you ... try5159208

I've also worked on other games, including a type-racer game made using PyQT and a bot vs bot turn based game made using JS and WebGL.

Game engines has been my passion for a couple years now, and I'm learning more and more about it everyday, as I work on my rendering engine and add new features to it.
I saw the ideas page, and these are the ideas that seemed relevant to the rendering engine. I'm primarily interested in improving the D3D11 RS, as I believe my D3D11 knowledge will help here, and I've worked with other programmers in previous projects, so communication will not be a problem, at the same time it'll also benefit me by learning how a professional quality 3D engine works, which is why I am here.
Other than the D3D11 RS, I also find the OpenGEX importer, Ogre 2.0 mesh format improvements and flexible Vertex Layouts. Basically anything that has to do with the rendering engine, I'm in

What do you guys think? Do let me know any other stuff that you need to know about me or my work.

jam

as a long standing comunity member.

Ogre isn't a game engine, its a rendering engine remember. But you seem keen I would recommend OpenGEX? it's harder than you think.-

True, it isn't a game engine, but as a rendering engine it still is relevant to me as I'm more interested in the rendering part of game engines - sorry not to clarify this earlier.
As for OpenGEX, I'm reading its specification (http://opengex.org/OpenGEX.1.1.2.pdf) and I'm positive it can be done within 3 months as long as I have one of the mentors to guide me towards the right direction while implementing the importer.

EDIT:
I've built the engine from source, and currently looking at the DX11 Rendering System.
Also, while playing with the samples, I found that once the camera is clamped completely down/up, as I move the mouse I notice the scene flipping itself, maybe increase the clamped phi value a bit?

[dark_sylinc]

My view on Particle Universe:

From a feature standpoint, PU is great. It offers a lot of scriptability, customization. Very powerful. Professional grade.

From a performance standpoint... meh.
Back in 2010, while PU was not open source, I provided customer feedback in PU's forums.

One of the key problems was that this level of scriptability & customization quickly leads to a lot of unnecessary batches per particle system.
Another one is that it wasn't threaded (Particle sytems are the easiest to thread!)
And I believe the recycling problem was fixed in more recent updates (correct me if I'm wrong).

Now facing 2.1; PU as well as the standard PFX plugin rely on Billboard. Billboard needs an alternative rather than a refactor for 2.1 (just like Entity had its Item).
Vertex Shader Tricks by Bill Bilodeau presents how modern particles (update in the CPU) should be rendered efficiently in modern architectures: Set a null vertex buffer, attach a dummy index buffer of the size of 4 * number_of_particles; and use the vertex shader's gl_VertexID to generate all four vertices programatically; while the VS reads the particle's position and orientation via a constant or texture buffer.
Not to mention that we have new buffer interfaces in 2.1 that should be preferred over the legacy ones for sending data from CPU to GPU.
That's light years away from how Billboard currently works.

I'd love to see PU become the main particle system in Ogre 2.1; just take in mind that the difficulty of such endeavour should be labelled as "hard"; and it's not just port the changes between 1.x and 2.x; but also address some longstanding issues.

[nickG]

- Physically based rendering
- Deferred/forward+ render
- True volumetric lighting
- LPV
- Image Based Lighting
- SSAO Alghoritms(SSAO,SSDO,HBAO,HBAO+)


I chose Ogre3d instead BGFX for new version of my project