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.
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:
(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.