[GSoC 2014] Ideas

Threads related to Google Summer of Code
Post Reply
Transporter
Minaton
Posts: 933
Joined: Mon Mar 05, 2012 11:37 am
Location: Germany

[GSoC 2014] Ideas

Post by Transporter » Wed Feb 05, 2014 6:52 pm

A new year - a new round of GSoC! Have a look at the timeline of this year.

Coming up next: Mentoring organizations can begin submitting applications to Google until 14th February.

Students: Feel free to start posting proposals for your project.

Edit: I'll collect ideas in this posting
Last edited by Transporter on Mon Feb 17, 2014 9:44 pm, edited 4 times in total.
0 x

User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 1
Contact:

Re: [GSoC 2014] Announcement

Post by Wolfmanfx » Wed Feb 05, 2014 10:06 pm

Hi,

I would like also to see some polish on the projects from last year with the focus on 2.0 / GL3+ but also a new platform via Emscripten.
0 x

hydexon
Gremlin
Posts: 163
Joined: Sun Apr 14, 2013 8:51 pm

Re: [GSoC 2014] Announcement

Post by hydexon » Wed Feb 05, 2014 11:45 pm

Creating a powerful dot-scene-loader-library
Yes!, i getting real tired to workaround of the bugs of the current dotScene libraries. i hope to do so.
0 x

User avatar
scrawl
OGRE Expert User
OGRE Expert User
Posts: 1119
Joined: Sat Jan 01, 2011 7:57 pm
Location: Germany
x 2

Re: [GSoC 2014] Announcement

Post by scrawl » Thu Feb 06, 2014 3:25 am

I posted my proposal :)
0 x

Transporter
Minaton
Posts: 933
Joined: Mon Mar 05, 2012 11:37 am
Location: Germany

Re: [GSoC 2014] Announcement

Post by Transporter » Thu Feb 06, 2014 6:58 pm

hydexon wrote:
Creating a powerful dot-scene-loader-library
Yes!, i getting real tired to workaround of the bugs of the current dotScene libraries. i hope to do so.
I agree! I've written a parser in pure C++ to parse the files with ogre and other applications but it's far away from a production state.
scrawl wrote:I posted my proposal :)
Thanks a lot! I like the idea, too. I'm not a big shader programmer so a material generator would be nice. I've added your proposal to the list to have a complete list of ideas in this thread.
0 x

User avatar
holocronweaver
Google Summer of Code Student
Google Summer of Code Student
Posts: 273
Joined: Mon Oct 29, 2012 8:52 pm
Location: Princeton, NJ

Re: [GSoC 2014] Announcement

Post by holocronweaver » Thu Feb 13, 2014 2:58 am

My #1 wishlist item is an easy to maintain multi-lingual interop as a primary OGRE feature. Perhaps using something like SWIG. I am particularly interested in using Python and Go with OGRE for rapid prototyping, though I am sure others want C# + Mono, Lua, and Java bindings. The goal should be simplicity and maintainability over speed. (BTW, SWIG 3 will be released sometime soon with C++11 support.)
0 x

TheSHEEEP
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 972
Joined: Mon Jun 02, 2008 6:52 pm
Location: Berlin

Re: [GSoC 2014] Announcement

Post by TheSHEEEP » Thu Feb 13, 2014 9:00 am

I like the idea, it would be nice for faster prototyping or maybe even full applications with not too much going on CPU wise.

But I see a problem with a fits-all solution like SWIG. They work, but for each single language there are much faster implementations.
So the solution with the best performance would be to choose a language (which would be Lua (we use OOLUA) or C# if performance is the main criterion).
But choosing a language will most certainly end up with some people not liking it.

Bottom line is that there is no perfect solution and I have no clue which one would be the choice that most users would welcome. If this should be chosen, I guess a poll would be in order.
0 x
My site! - Have a look :)
Also on Twitter - extra fluffy

User avatar
Zonder
Gargoyle
Posts: 1087
Joined: Mon Aug 04, 2008 7:51 pm
Location: Manchester - England
x 5

Re: [GSoC 2014] Announcement

Post by Zonder » Thu Feb 13, 2014 12:55 pm

Yes it's an awkward one, I think supporting something generic maybe best.

But maybe a poll is in order to get a feel for what people would want to use.
0 x
There are 10 types of people in the world: Those who understand binary, and those who don't...
My Blog - http://www.This post is suspected as SPAM! If you feel otherwise contact a moderator.

User avatar
c6burns
Beholder
Posts: 1511
Joined: Fri Feb 22, 2013 4:44 am
Location: Deep behind enemy lines

Re: [GSoC 2014] Announcement

Post by c6burns » Thu Feb 13, 2014 5:02 pm

When I think of scripting/prototyping I think about ease of use and quality of life above performance. swig has been great in the few projects I have encountered it.
0 x

User avatar
scrawl
OGRE Expert User
OGRE Expert User
Posts: 1119
Joined: Sat Jan 01, 2011 7:57 pm
Location: Germany
x 2

Re: [GSoC 2014] Announcement

Post by scrawl » Mon Feb 17, 2014 1:18 pm

Rewriting and completing the documentation
Unfortunately not allowed by google, see GSOC 2014 FAQ:
12. Are proposals for documentation work eligible for Google Summer of Code?

While we greatly appreciate the value of documentation, this program is an exercise in developing code; we can't accept proposals for documentation-only work at this time.
0 x

hydexon
Gremlin
Posts: 163
Joined: Sun Apr 14, 2013 8:51 pm

Re: [GSoC 2014] Announcement

Post by hydexon » Tue Feb 18, 2014 1:14 am

scrawl wrote:
Rewriting and completing the documentation
Unfortunately not allowed by google, see GSOC 2014 FAQ:
12. Are proposals for documentation work eligible for Google Summer of Code?

While we greatly appreciate the value of documentation, this program is an exercise in developing code; we can't accept proposals for documentation-only work at this time.
Suspectedly, we need an Google Summer of Documentation :lol:
0 x

User avatar
affentanz
Kobold
Posts: 30
Joined: Tue Sep 03, 2013 10:34 pm

Re: [GSoC 2014] Announcement

Post by affentanz » Thu Feb 20, 2014 5:24 pm

Hey, I'm new to ogre development, but I already made a few small applications with ogre and now I want to give something back. Maybe gsoc is a good starting point for that.
Transporter wrote: [*]Creating a powerful dot-scene-loader-library
This seems to be an interesting topic. Actually I'm thinking about a new level format for a while. Do you think the dot-scene-format is still good enough? I think, it should be more flexible. I always had trouble with dot-scene when I want to integrate other "non-graphical" components like physics, trigger etc in a level. Maybe this topic could be about developing something like "dot-scene 2.0".
0 x

hydexon
Gremlin
Posts: 163
Joined: Sun Apr 14, 2013 8:51 pm

Re: [GSoC 2014] Announcement

Post by hydexon » Thu Feb 20, 2014 6:07 pm

affentanz wrote:Hey, I'm new to ogre development, but I already made a few small applications with ogre and now I want to give something back. Maybe gsoc is a good starting point for that.
Transporter wrote: [*]Creating a powerful dot-scene-loader-library
This seems to be an interesting topic. Actually I'm thinking about a new level format for a while. Do you think the dot-scene-format is still good enough? I think, it should be more flexible. I always had trouble with dot-scene when I want to integrate other "non-graphical" components like physics, trigger etc in a level. Maybe this topic could be about developing something like "dot-scene 2.0".
Like COLLADA but for scenes?
0 x

User avatar
affentanz
Kobold
Posts: 30
Joined: Tue Sep 03, 2013 10:34 pm

Re: [GSoC 2014] Announcement

Post by affentanz » Thu Feb 20, 2014 7:33 pm

hydexon wrote:
Like COLLADA but for scenes?
I didn't know Collada, but it seems to be something like that.
0 x

Transporter
Minaton
Posts: 933
Joined: Mon Mar 05, 2012 11:37 am
Location: Germany

Re: [GSoC 2014] Announcement

Post by Transporter » Thu Feb 20, 2014 8:00 pm

Collada is a 3D format. Maybe it's a good idea to add this format to Resource System Redesign from the last year, but this project is not finished yet. Also it would be better to add the Open Asset Import Library as importer than reinventing the wheel by implementing various file formats aggain.
0 x

User avatar
affentanz
Kobold
Posts: 30
Joined: Tue Sep 03, 2013 10:34 pm

Re: [GSoC 2014] Announcement

Post by affentanz » Thu Feb 20, 2014 8:23 pm

Ok, then Collada has nothing to do with my idea. I thought of a flexible dot-scene format, that can easily be extended by users/game-developer to include also "non-graphical" things like trigger-zones, and of course a dot-scene-loader that can handle this.
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 3662
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 109
Contact:

Re: [GSoC 2014] Announcement

Post by dark_sylinc » Sat Feb 22, 2014 4:36 am

I'm gonna make a few comments:
Transporter wrote:[*]Creating a powerful dot-scene-loader-library
IMHO, that's the most useless idea so far. People are going to ignore it. That's my opinion though.
Transporter wrote:[*]Proposal: Material System Improvements (thx scrawl)[/list]
I'd like to postpone this idea to the next year. I have very important plans for the material system (*) but they're depending on the RenderQueue refactor. As long as the RenderQueue isn't refactored, premature Material System Improvements are going to be blocked or flawed.
Students are free to propose their RQ refactoring proposals though. I don't think it's enough for a 3-month GSoC, so if you plan to propose RQ refactoring, add something more (i.e. first steps of Material System is ok; as they're going to have to communicate)

(*) If you're interested to know, it involves auto-instancing (no more managers, everything done for you), as well as many other things being done for you (there will be an HLMS High Level Material System that handles much of the hassle for you and you can also extend; but you can still opt out and use your own shaders. I won't go into more detail here).


I can throw a few more ideas:
Depth Textures (difficulty medium to easy)
This is actually a very good GSoC project: People need it (so you are guaranteed people will end up using the code you wrote, it won't go to waste), it's very important, it's isolated from other tasks so it won't conflict, it can work with both 2.0 and 1.x; and fits perfect for a 3 month schedule.

The idea is that the student would put some interface so that Ogre::DepthBuffer can return a texture pointer. In D3D9 it would use the INTZ hack (which is widely supported), while D3D11 & GL would use the native support.
DepthBuffers are automatically generated and reused based on depth buffer pool ID and resolution. This isn't a problem because by assigning a different pool ID for each RTT, DepthBuffers can become unique.
DepthBuffers can also be created explicitly already and put into a pool, so this is also an option.

Additionally, the student could create a sample showing the depth texture in action (i.e. extending the shadow sample is ok).

Vertex Layout improvements (difficulty: medium to hard)
In my slides I talk about a custom vertex layout format (page 119) to be used with the cmd tools (like XMLConverter).
The student would implement the parsing of such text format, then make Ogre modify the existing mesh to adapt to this new vertex layout.
The student would also need to implement QTangents and (optionally, depending on schedule) Angle-based normals. This includes encoding in C++ and decoding in shaders.
If there's time, it would be nice having VertexElement refactored so that the offset is calculated automatically rather than stating explicitly for every element (which is useless because in practice no vertex elements overlap).

This is a very useful project probably most useful for advanced Ogre users. This project doesn't conflict with anyone else's work either, should work with both 1.x and 2.0 branches, and the code won't go to waste either. It IS useful.
0 x

User avatar
scrawl
OGRE Expert User
OGRE Expert User
Posts: 1119
Joined: Sat Jan 01, 2011 7:57 pm
Location: Germany
x 2

Re: [GSoC 2014] Announcement

Post by scrawl » Sat Feb 22, 2014 11:34 am

I'd like to postpone this idea to the next year. I have very important plans for the material system (*) but they're depending on the RenderQueue refactor. As long as the RenderQueue isn't refactored, premature Material System Improvements are going to be blocked or flawed.
I wouldn't be working much on the existing material system itself, really. If you read the proposal it's an additional higher level facility and changes to the low level material system should be very easily adaptable. That's why multilayer-architecture rocks! :)
Seriously, you're not talking to the underlying system a whole lot. In my "prototype" shiny, all the Ogre specific code is maybe 100 lines max.

Furthermore, it hasn't even been decided on which branch a high level material system project would go. I don't know what makes you assume it''d be 2.0. My vote would be to maintain at least a basic version of this system for 1.x, as it involves no breakage of existing interface and it's a very important feature that has been requested for quite some time. Another motivation to do it sooner.
Last edited by scrawl on Sat Feb 22, 2014 1:23 pm, edited 4 times in total.
0 x

User avatar
scrawl
OGRE Expert User
OGRE Expert User
Posts: 1119
Joined: Sat Jan 01, 2011 7:57 pm
Location: Germany
x 2

Re: [GSoC 2014] Announcement

Post by scrawl » Sat Feb 22, 2014 11:51 am

Depth Textures
Wasn't there someone already working on this? I think I vaguely recall some code for this from the dx11 gsoc. I might be wrong, though.
Not an essential feature. If you already use MRTs anyway, adding an additional depth channel would probably be faster. But if you only need depth, this is very nice as you'll be able to remove quite a bit of cruft from your code.
Vertex Layout improvements
Sounds like quite a bit of work for very little gain. You won't be able to enable this packing by default, since it must be unpacked manually in the shader by users. Experience shows that 95%+ of users wouldn't even bother with these options. It'll also be a new source of bugs and confusion, and I guarantee you we'll get new support requests with users picking the wrong exporter options and then wondering why their meshes render all skewed.
Optimization work is important, and I don't mind optimization GSOCs, but I think it would be a good idea to only pick projects that actually benefit *everyone*.
There is a reason we're only really seeing this feature in AAA engines at the moment. They have a very controlled pipeline and can integrate it seamlessly. Unfortunately that does not apply to Ogre (yet).
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 3662
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 109
Contact:

Re: [GSoC 2014] Announcement

Post by dark_sylinc » Sat Feb 22, 2014 3:10 pm

scrawl wrote:
Depth Textures
Wasn't there someone already working on this? I think I vaguely recall some code for this from the dx11 gsoc. I might be wrong, though.
I poster on their topic just in case. AFAIK it's a bit hacked into the RS and not done through a generic interface (i.e. it's just D3D11 specific). But just in case, I've added the question.
scrawl wrote:Not an essential feature. If you already use MRTs anyway, adding an additional depth channel would probably be faster. But if you only need depth, this is very nice as you'll be able to remove quite a bit of cruft from your code.
When it comes to shadow mapping, is a really cool feature. GPUs rasterize at 2x speed when it's depth buffer only, and you get free PCF filtering.

As for MRTs, evidence says otherwise. In terms of performance using the depth buffer means one less export unit (faster performance and less bandwidth usage).
In terms of shader coding, you forget about one output, and as for the compositor it's as easy/hard as with MRTs.
Vertex Layout improvements
Sounds like quite a bit of work for very little gain. You won't be able to enable this packing by default, since it must be unpacked manually in the shader by users.[/quote]
Actually the idea is that packing is always enabled by default; with different default presets and profiles for each platform. i.e.
  • Compatible (DX9/GL/GLES1) -> POSITION NORMAL TANGENT UV0
  • PC DX11/GL3 Full -> POSITION QTANGENT UV0
  • PC DX11/GL3 Regular -> POSITION QTANGENT UV0 (16-bit)
  • PC DX11/GL3 Small -> POSITION (16-bit) QTANGENT UV0 (16-bit)
  • Android / iPhone (no normal mapping) -> POSITION (16-bit) NORMAL (16-bit) UV0 (16-bit)
  • Android / iPhone (old generations) -> POSITION (16-bit) NORMAL (16-bit) TANGENT (16-bit) UV0 (16-bit)
  • Android / iPhone (new generations) -> POSITION (16-bit) QTANGENT UV0 (16-bit)
Of course if the mesh doesn't contain UVs or normals, the relevant attributes are removed.
We could even include more fine grained profiles depending on performance profiling of which one is the better layout (i.e. may be Android Adreno prefers floats while Android Tegra prefers shorts; or viceversa, etc).

PC DX9 compatible would produce a similar output to what we currently perform (Fixed Function compatibility). While on architectures where you require knowledge of shaders (i.e. DX11; you can do the unpacking yourself, it's not hard and we'll provide sample code) or usually high level systems are used (like RTSS, i.e. iPhone & Android) we can use more custom layouts.

Of course you would be able to write your own preset (particularly if you want to use many different UVs for different purposes) in case you're an advanced user.
I guarantee you we'll get new support requests with users picking the wrong exporter options and then wondering why their meshes render all skewed.
Which is why I prefer presets instead of fiddling with options. If you want fine grained control, you can write your own preset; but regular users won't play with these settings, just select from the list.

I do agree this project is harder than the average though; but it's not impossible.
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 3662
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 109
Contact:

Re: [GSoC 2014] Announcement

Post by dark_sylinc » Sat Feb 22, 2014 3:28 pm

scrawl wrote:I wouldn't be working much on the existing material system itself, really. If you read the proposal it's an additional higher level facility and changes to the low level material system should be very easily adaptable. That's why multilayer-architecture rocks! :)
Seriously, you're not talking to the underlying system a whole lot. In my "prototype" shiny, all the Ogre specific code is maybe 100 lines max.

Furthermore, it hasn't even been decided on which branch a high level material system project would go. I don't know what makes you assume it''d be 2.0. My vote would be to maintain at least a basic version of this system for 1.x, as it involves no breakage of existing interface and it's a very important feature that has been requested for quite some time. Another motivation to do it sooner.
Fair enough. I just don't want to have duplicated effort; and there are multiple advantages from having RQ support.
My system is aimed at becoming the default for regular users so that Ogre does everything for them automatically, kinda like it used to be with FF in the past (PBS, fog, shadow mapping, handle skeletal animations, facial animations, instancing).
Sounds similar to RTSS, but RTSS is constrained by trying to emulate FF pipeline, while I have no intention to do so. The RTSS isn't integrated with the Core either. The Core will talk to the material system so that it's easier to organize and generate shaders (right now RTSS looks at the material about to be rendered, uses it's complex system to spit a suitable shader or get it from a cache; this is the other way around: The core will tell the HLMS what is soon going to be needed, and they both acommodate to make life easier).
You can extend the HLMS and get the goodies (automatic handling of skeletal animations, shadow mapping, auto-instancing), or write your own shaders*

*The problem with writing your own shaders are that handling skeletal vs non-skeletal animated meshes need different vertex shader code paths; shadow mapping casters requires again a special vertex shader.
It becomes an O( 2^(N-1) ) task: Do you want to support non-skeletal, skeletal, shadow mapping and instancing? Then you'll have as this many VS:
  • Non skeletal animation
  • Non skeletal animation, instanced
  • Non skeletal animation, instanced, shadow mapping caster
  • Non skeletal animation, shadow mapping caster
  • Skeletal animation
  • Skeletal animation, instanced
  • Skeletal animation, instanced, shadow mapping caster
  • Skeletal animation, shadow mapping caster
3 toggable features, 8 VS. And that's just basic features. I'm not including any user-custom features (i.e. wind animation for grass, normal mapping vs non-normal mapping, multiple UVs), which skyrockets the possible variations.

Your system seems to do a good job in handling some of these togleable features (i.e. multiple uvs, normal mapping, skeletal animations) but it lacks enough information to handle it all in a scalable way.
The RQ can provide this information. A material system that has this information beforehand will be vastly superior to any other system that lacks it or has to deduce it; no matter what system we actually end up using (yours, mine, etc).
Which is why I want to postpone it and use it in 2.0.
0 x

User avatar
scrawl
OGRE Expert User
OGRE Expert User
Posts: 1119
Joined: Sat Jan 01, 2011 7:57 pm
Location: Germany
x 2

Re: [GSoC 2014] Announcement

Post by scrawl » Sat Feb 22, 2014 3:55 pm

So where exactly is the "duplicated effort"? I don't see it.

Can you please stop using the terms "my system" and "your system"? From what you've shown me so far, the goals are identical. Using information from the render pipeline (such as instancing state, skeletal animation state, etc) as you mentioned is perfectly possible in my proposal design. Those are arguments to the shader/material generator and nothing else. I just didn't mention it because this will obviously need Ogre core changes to pass those to the material system. I'll write another section for that as Future work. Once we do have that information it will be as simple as plugging it to the generator and it'll just work.
lacks enough information to handle it all in a scalable way
I don't get how you could come to that conclusion. What exactly is not scalable there in your opinion?

Adding the "RQ support", as you call it, to my generator code will be trivial. The generator is very modular - it has inputs and an output. This is simply adding an additional input, nothing more.
Which is why I want to postpone it and use it in 2.0.
Just because we can make the generators even better for 2.0 doesn't mean we should postpone them, especially not when these additions fit perfectly with the original design.
0 x

User avatar
affentanz
Kobold
Posts: 30
Joined: Tue Sep 03, 2013 10:34 pm

Re: [GSoC 2014] Announcement

Post by affentanz » Sun Feb 23, 2014 4:23 pm

Are the ideas on this wiki page up-to-date or are they outdated? http://www.ogre3d.org/tikiwiki/GSoC+Project+Ideas
0 x

User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 1
Contact:

Re: [GSoC 2014] Announcement

Post by Wolfmanfx » Sun Feb 23, 2014 5:39 pm

We have updated them before applying to GSOC2014
0 x

Post Reply