Page 1 of 1

[GSoC 2014] Ideas

Posted: Wed Feb 05, 2014 6:52 pm
by Transporter
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

Re: [GSoC 2014] Announcement

Posted: Wed Feb 05, 2014 10:06 pm
by Wolfmanfx
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.

Re: [GSoC 2014] Announcement

Posted: Wed Feb 05, 2014 11:45 pm
by hydexon
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.

Re: [GSoC 2014] Announcement

Posted: Thu Feb 06, 2014 3:25 am
by scrawl
I posted my proposal :)

Re: [GSoC 2014] Announcement

Posted: Thu Feb 06, 2014 6:58 pm
by Transporter
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.

Re: [GSoC 2014] Announcement

Posted: Thu Feb 13, 2014 2:58 am
by holocronweaver
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.)

Re: [GSoC 2014] Announcement

Posted: Thu Feb 13, 2014 9:00 am
by TheSHEEEP
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.

Re: [GSoC 2014] Announcement

Posted: Thu Feb 13, 2014 12:55 pm
by Zonder
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.

Re: [GSoC 2014] Announcement

Posted: Thu Feb 13, 2014 5:02 pm
by c6burns
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.

Re: [GSoC 2014] Announcement

Posted: Mon Feb 17, 2014 1:18 pm
by scrawl
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.

Re: [GSoC 2014] Announcement

Posted: Tue Feb 18, 2014 1:14 am
by hydexon
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:

Re: [GSoC 2014] Announcement

Posted: Thu Feb 20, 2014 5:24 pm
by affentanz
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".

Re: [GSoC 2014] Announcement

Posted: Thu Feb 20, 2014 6:07 pm
by hydexon
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?

Re: [GSoC 2014] Announcement

Posted: Thu Feb 20, 2014 7:33 pm
by affentanz
hydexon wrote:
Like COLLADA but for scenes?
I didn't know Collada, but it seems to be something like that.

Re: [GSoC 2014] Announcement

Posted: Thu Feb 20, 2014 8:00 pm
by Transporter
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.

Re: [GSoC 2014] Announcement

Posted: Thu Feb 20, 2014 8:23 pm
by affentanz
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.

Re: [GSoC 2014] Announcement

Posted: Sat Feb 22, 2014 4:36 am
by dark_sylinc
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.

Re: [GSoC 2014] Announcement

Posted: Sat Feb 22, 2014 11:34 am
by scrawl
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.

Re: [GSoC 2014] Announcement

Posted: Sat Feb 22, 2014 11:51 am
by scrawl
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).

Re: [GSoC 2014] Announcement

Posted: Sat Feb 22, 2014 3:10 pm
by dark_sylinc
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.

Re: [GSoC 2014] Announcement

Posted: Sat Feb 22, 2014 3:28 pm
by dark_sylinc
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.

Re: [GSoC 2014] Announcement

Posted: Sat Feb 22, 2014 3:55 pm
by scrawl
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.

Re: [GSoC 2014] Announcement

Posted: Sun Feb 23, 2014 4:23 pm
by affentanz
Are the ideas on this wiki page up-to-date or are they outdated? http://www.ogre3d.org/tikiwiki/GSoC+Project+Ideas

Re: [GSoC 2014] Announcement

Posted: Sun Feb 23, 2014 5:39 pm
by Wolfmanfx
We have updated them before applying to GSOC2014