[GSoC 2012] Ideas from community

[nickG]

1)D3D11
2)D3D10
3)Apex
4)Scaleform Eval integration
5)WWISE Integration
6)Nvidia Optix integration

[Zonder]

1)D3D11
2)D3D10

These were merged as DX11 is available on the same platforms as DX10

3)Apex

Not sure what this one is :S

4)Scaleform Eval integration
5)WWISE Integration

These aren't relevant to ogre it self this type of integration woul dbe done with a plugin

6)Nvidia Optix integration

This one would be interesting.

[xiaoxiangquan]

Hi, dear all,
though it seems DX11 and Android is popular this year, I got an idea of making a Random Terrain Generator. With it we can create vast world automatically, or change the surroundings from time to time when players enter the game.


Firstly, implement the generator with several algorithms:
- Perlin Noise <GPU Gems 1, chap 5>
- Fault Formation <Game Programming Gems 1, chap 4.17>
- Diamond Square (Midpoint Displacement) <Game Programming Gems 1, chap 4.18>
- Particle Deposition <Game Programming Gems 1, chap 4.19>
- Terrain with Hollows <GPU Gems 3, chap 1>
And render them with some of the suggestions in <Game Programming Gems 6, chapter 5.5>.


Secondly, give some demos as usage examples, and show the power. There are two in my head currently:

Auto-Skybox:
Create beautiful distant mountains, maybe as well as a skydom ( using heightmaps to place clouds ), then render them to a skybox. It can be always fresh by changing from time to time. Of course you can make it fixed by using a fixed random seed.
In contrast with 2D backgrouds, I think it will be more attractive if we apply some real 3D techniques on the skybox, such as accurate ambient occlusion. I hope the final result could cheat the most discerning eyes.
The most awesome idea is that, just given a picture of the desired landscape, we can analyze it (using shapes to choose algorithm and parameters, using colors for texture). Finally, a similar world is produced.

Desert Fox:
Actually, it should be called Desert Worms. But I doubt there are no enough worms there. As you can guess, it's a simple 3D throwing game just like the Worms. A fox will throw something to boom the sand which has a certain degree of liquidity, and finally survive by traping or burying the enimies.
With a random terrain generator, different parameters will result in different deserts. And there are patterns in it. By controlling the terrain parameters as well as enimy settings, the game levels classificated. And, it is almost endless.

Combine the two above together, it becomes a game of chocolates, you never know what you're gonna get.


Finally, by doing all of these, there must be some opportunities to enhance some part of Ogre, especially the terrain manager.
===========================

I'm newbie for Ogre, but have some basic knowledge and experience on 3D programming. I'm learning Ogre hardly, and eager to do something for it.
Thanks for any advice!

[al2950]

My 5 cents!

Finish of DX11
RTSS:
----- Make RTSS more flexible (I have a few ideas for this )
----- Fix performance bottle necks
----- Add some more shaders
----- Add building blocks for creating a custom GBuffer
multi thread some of the core parts of Ogre
Nvidia Optix integration (This should probably go with DX11)
Add changes to allow deferred techniques to be intergrated easier into Ogre (eg, MRT Shadow casters)

[dark_sylinc]

* Create a heavy scene to showcase OGRE's performance (which we could use to optimize the culling - maybe a city of boxes)

I'm afraid you will be quite disappointed. Ogre's performance is below other AAAs engine standards (Anvil engine, CryEngine, Frostbite 2)
I'm struggling to get 1.000 of rendercalls @20 fps, while Anvil engine is doing three times those render calls at the same frame rate (in both cases, not being GPU bound)

Profiling reveals the compositor wastes a lot of time parsing the scene manager multiple times (when using something other than render_quad) and there are A LOT of cache misses.

The lack of threaded culling makes this even worse. Furthermore, with DirectX 11 threading model, it's possible to process a scene and batch render calls in multiple threads in a very concurrent way:

• One thread handles shadow rendering.
• One thread handles main scene
• One thread handles environment mapping (i.e. reflections)

Ogre's already struggling to get a high amount of entities in scenes doing main scene's & shadow's rendering in the same thread. When I add env. mapping (one pass, not 6) the amount of cache misses inside the scene manager is gigantic.

I'm afraid, as someone suggested, fixing this may require some strong redesign of the Ogre core. For instance, automatic reference counting of pointers goes against a concurrent system. Singletons don't help (as it's very easy for programmers to make a mistake and access a singleton when it isn't safe to do so)

* Refactor OGRE's Scenegraph to support CHC++ and other advanced techniques (tuan's scenemanager could be used as a base)

The industry is moving away from those fancy "advanced techniques" while going for a more raw-power approach taking advantage of the "buy more CPU cores" trend. And since most of those algorithms tend to increase the number of cache misses, that makes them an uglier option.
Using a software rasterizer for occlusion queries is quite a popular one these days.

[Wolfmanfx]

I am not disapointed at all because i know that OGRE will perform quite bad but i think to have a big scene will help to see the hotspots quite easier.
But every big change has to start small.

@CHC++
It would help to get something like up and running (The are test cases out there which show that CHC++ performs twice as fast on consoles in contrast to Hierarchical ViewFrustumCulling).

...software rasterizer for occlusion queries...

Yes true Frostbite/CryEngine have done this and also UMBRA is using this technique.

[Mako_energy]

Personally I try to use as little of ogre as I can for my project, using just as a renderer wherever possible. That said anything that enhances the core is where I'd like to see more progress.

@dark_sylinc
+1
I don't really know anything about the technical details of ogre and what all and why things slow it down, but in general if there are area's where rendering performance in a rendering engine can be increased then work should be done there. It does sound like a lot of work the way you described it, but I'm sure that whole thing can be broken down into smaller tasks and one or two of them can be made into really good GSoC projects.

Also in the spirit of using Ogre as "just a rendering engine", I recently posted a Feature Request for making the resource system more modular. In what I use Ogre with, I have a partially constructed resource system that I want to use for all my I/O, which is helpful in general plus gives me complete control for how it integrates with our non-standard threading strategy we have planned.

[Sqeaky]

As much as making tools sounds like a good idea, Ogre is a strong piece of software because it is focused. If tools are made as part of the Core of Ogre then I suspect there will be less attention to rendering performance and quality, something that dark_sylinc pointed out we definitely need more of. I do think the Ogre community should do something more active to foster an environment where people want to make more and better tools, the Apache foundation sure did.

As for all the calls for procedural generation, that really sounds cool, but I think it should be a plugin. I think Ogre Core needs more help at the moment.

I also like the idea of separating out or at least modularizing the resource system. It as a separate library would be really cool and allow it to advance faster without detracting from the high performance rendering that Ogre really should be doing. I do not know how feasible that is, but it would make it easier to create applications that share a larger amount of code. One could remove rendering on the server version of the application, or leave out unneeded loading tools when it is duplicated effort.

[nikki]

Hmm, how interested are you guys in the NVIDIA Optix integration?

[duststorm]

Procedural terrain generation techniques are interesting, but indeed might be better for a plug-in.
It would be nice if such a plugin could work automatically but also allow you to use it with brushes in an editor like Ogitor.
If you are looking for more concrete ideas concerning procedural terrain generation, have a look here: http://www.ogre3d.org/forums/viewtopic.php?f=11&t=68026
It has some really nice ideas.

But.. since this is not core rendering engine related this probably wouldn't qualify all that well for a GSoC project. (of course you could always try, with a well worked-out proposal )

[xiaoxiangquan]

Thanks!
Then I think I should draw my attention to the Terrain System, which is a core business.
For example, generating a extremely large world to test or to show the power of the new Terrain System:
- Paging Component works well ?
- Efficiency of generating global normal maps and light maps( in a background thread )
- LODs and things like this
Then do some enhancement, I think.

[duststorm]

If you want more concrete ideas for a proposal, track down the status of the Ogre::Terrain paging (last year's GSoC project).
I believe it still needs work before it is in a fully useable state (why it didn't go into Ogre 1.8 ).

[Domi]

I was thinking of real-time fluid simulation using SPH, pretty much similar to what happened here: http://www.ogre3d.org/forums/viewtopic.php?f=11&t=59439

It should come with working surface extraction (probably using the ideas from the NVidia demo), full integration into the Ogre Scenegraph and support for exporting fluid scenarios from editors, such as 3DMax etc.

Naturally, the simulation would have to be done on the GPU, and thus requires OpenCL support (I am thinking OpenCL is the best choice, since DirectCompute and CUDA both are not portable enough).
Of course that limits GPU computing power for the rendering itself, but since physics simulations are expensive, games with a lot of interactive fluids on contemporary hardware tend to be simpler anyway (I am thinking From Dust: http://www.youtube.com/watch?v=1Y8l8kEI354).

Edit: From what I understand, the Ogre core is not supposed to contain any physics simulation. So I am guessing that this or something like an Inverse Kinematics solver would not be too valuable for the project?

[jacmoe]

IK in Ogre would be appreciated by me!

[duststorm]

IK in Ogre would be appreciated by me!

Very good idea!
+1 on IK (Inverse Kinematics) by me

[Transporter]

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.

Agree A converter to convert SM3 to SM4 is interesting, because DX11 is not working with SM3. Tessellation and Displacement Mapping would be very nice features which increase the power of Ogre compared to other engines like Torque3d etc.

My second thought was Ogitor, too. But there are already enough comments to that topic.

[duststorm]

A converter to convert SM3 to SM4 is interesting

I think that would be a more general thing outside of the scope of Ogre.
Anyway it would probably better to support DX11 and skip 10, since all hardware that supports 10 also supports 11, so the duplicate effort wouldn't really pay off.

[Alexiss]

While we're on the water subject, I don't know if this would be elligible as a GSOC project but, I was thinking about porting this http://vertexasylum.com/2010/10/30/gpu- ... r-thingie/ to Ogre.

This is something I would be interested in applying for, granted it is elligible, and there is some interest from the community.

Video :
[youtube]-VjRq8YagdQ[/youtube]



The idea would be to tightly couple the water simulation port with Ogre::Terrain, so that anyone can easily add water to its terrain.

I believe it would be a logical extension to the terrain feature, and water is a subject that often comes up in the forums.
Although there already are several excellent solutions (OgreWater, Hydrax, probably others I am unaware of ...), none feature this level of control.


Geometry: I've already delved into the demo source code, and a quadtree is used to display both the terrain and water.
Therefore, it would make sense to use Ogre::Terrain::OgreTerrainQuadTreeNode to implement the water in Ogre.
Shaders: They are all written in HLSL. I would most likely port them to CG for maximum compatibility.
Pre-processing: The demo takes a heightmap as input, so it wouldn't be a problem to make use of Ogre::Terrain float data for water data computations.

Editing: (ie. adding spring sources, viewing the pre-processing simulation, ..) either :

• Extend the Ogre::Terrain sample to add water editing features
• Use IWE (Intuitive World Editor) which is a world editor for Ogre I've been working on for several months now.

In regard to IWE, It already features, among other tools, full Ogre::Terrain editing, and would provide a full Terrain editing environment with the addition of water.
I would of course make it FOSS (which is something I am already planning to do, regardless of this).

Let me know what you think !

[jacmoe]

Would be better if it was integrated with Ogitor - I am highly biased here! - which is open source and has been since it's first release years ago.
I like IWE, but I don't like duplicate efforts.
And I like the idea.
Why not submit a proposal?

[Xavyiy]

Hi all!

Well, it has been about two weeks since we knew we was accepted in the GSoC and honestly still there isn't any proposal which in my opinion fits the GSoC idea and the most important: current Ogre needs. (Core-related improvements)

Please, don't take my words as offense words, that's the last thing I want to do.

We've been talking about the fact that Ogre is getting old in this thread: http://ogre3d.org/forums/viewtopic.php? ... 50#p453778 since dark_sylinc re-started it a week ago, and there're some very good ideas/proposals for redesigning Ogre in general.

Obviously there are too much redesign ideas in this thread, too many for being able to make this huge redesign reality. So ,instead of making this whole redesign at the same time, I want to highlight the following fact: "Lots of cache misses: The way SceneNode creation is handled, is just very memory non-local." , and suggest a GSoC proposal for it.
There is a lot information about this topic in the same thread, specially in the last posts, which can be used as a strong initial point for the proposal, but it can be resumed in:

1. Modify the Ogre SM for pre-allocate big chunks(one per hierarchy level) of nodes, and also of its data: vectors(positions, scales, ...) and matrices, and use this data-oriented scheme for all node-related calculations (respecting almost -or all- the same current Node interface)
2. Add SSE/AVX/NEON optimizations for node transforms, being able to process 4(or 8 with AVX) transforms at the same time. That will need storing some data in SoA instead of AoS, more info here: http://ogre3d.org/forums/viewtopic.php? ... 75#p454096
2. Little demo app, in order to show the performance boost.

Also, it'll be very cool if dark_sylinc can be the mentor, I think he's the most indicated person.

So, if you are a student and you like the idea, just open a proposal on the forum!

------------

Also I would really like to see a DX11 proposal.

BTW, here is my opinion of current proposals:

Volume Rendering with LOD aimed at terrain ( http://ogre3d.org/forums/viewtopic.php? ... 49#p453641 )
I like the idea of a volume terrain component for Ogre, but ONLY if it gets COMPLETELY finished, well-documented and provides a great sample app.

CHC++ ( http://ogre3d.org/forums/viewtopic.php?f=13&t=69415 )
Promissing. Specially if tuan is the mentor (he has a huge experience/knowledge in this field).

Easily moddable Zombie Game Demo ( http://ogre3d.org/forums/viewtopic.php?f=13&t=69547 )
I don't think this requires a GSoC slot. The reason for that is that furthermore it's not an Ogre-core related project; it doesn't require a mentor and I also doubt a full modable game with decent art can be accomplished by just one person in the GSoC time-period.

Demo and Improve the Terrain System ( http://ogre3d.org/forums/viewtopic.php?f=13&t=69553 )
I like the idea of a random terrain generator component for Ogre, BUT: If, at the end, it's renderer-agnostic... why in Ogre and not as a separated lib?
This is why I would suggest finishing(fixing bugs and fully testing it) the last year GSoC terrain project and giving some less importance at the random terrain genereator part.
This way it could became a very important proposal for Ogre itself (integrate last year GSoC terrain project code + some improvements) and also you'll be able to showcase it with the random terrain generator.

Xavier

[xiaoxiangquan]

Demo and Improve the Terrain System ( http://ogre3d.org/forums/viewtopic.php?f=13&t=69553 )
I like the idea of a random terrain generator component for Ogre, BUT: If, at the end, it's renderer-agnostic... why in Ogre and not as a separated lib?
This is why I would suggest finishing(fixing bugs and fully testing it) the last year GSoC terrain project and giving some less importance at the random terrain genereator part.
This way it could became a very important proposal for Ogre itself (integrate last year GSoC terrain project code + some improvements) and also you'll be able to showcase it with the random terrain generator.
Xavier

Thanks very much!
I have decided to reduce the work of terrain generation, for example, just implement one simple algorithm to let it work.
Then draw more attention on the improvements, and maybe integrate last year GSoC terrain project code as your great suggestion.
Another idea is to integrate it into ogitor. If someone has tried Far Cry 2's Map Editor, he'll know that is really awesome!

The extension of the terrain generator will be done after the GSoC.

I'll adjust my proposal soon

[duststorm]

I also think, as I hinted to in the topic, that finishing last year's GSoC terrain project and expanding on it is the most interesting.
We first need good support for large terrain before it can be expanded upon.
Of course once it's there there are some really interesting things that could be done with it, for example:
- terrain generation (automatically or using brushes)
- water, rivers
- roads on top of terrain (I've shortly looked into doing an ogitor plugin for this but due to a lack of time I never got far, OgreProcedural could be useful in achieving this too)
...

Most of these things would fit better into an editor like Ogitor instead of Ogre itself. However maybe these functionalities could be offered by abstracted components that can be used by editors like Ogitor.

[xiaoxiangquan]

Proposal updated. Reduce the work of terrain generation, and instead complete last year's terrain project.

Have a look here: http://www.ogre3d.org/forums/viewtopic.php?f=13&t=69553

[Shadowrom]

First of all, Ogre is great! I really love it and I have lots of respect for the whole Ogre team! Keep on the great work

Things i'd like to see done:

Refurbish Ogitor and DotSceneLoader and integrate them into Ogre.
Finish off DirectX 11
NVidia OptiX

[kornerr]

Having read about different core enhancements, I vote for it. Plugins are much less frequently used, but core is the base of everything.