What a heated up discussion. I'll chime in.
mkultra333 wrote:2.1 which is bleeding edge, incomplete, and no where near ready for prime time?
Actually quite the opposite. Despite whatever impression you may have, some users are already using it in production, and we (as in the team I'm working with) are using it heavily in production.
It works, it's fast, it's reliable.
@mkultra333 in particular (but maybe useful for others too):
As al2950 said, you're certainly not the average user. The compositor lets you do almost any effect you could imagine.
If you want the kind of low level you want; the compositor lets you do this via the Workspace listener and/or custom compositor passes. Additionally, you can treat workspaces like you used to treat RTTs (i.e. you now associate an RTT to a workspace, then call workspace->_update(); whereas in 1.x you would create a viewport from an RTT, then call rtt->_update() )
Custom compositor passes let you control the rendering with C++ in a level much lower than 1.x ever did.
I always felt those things were what Ogre should really concentrate on. Leave stuff like deferred or forward shading, shadows and post processing for the user to figure out, or provide a couple of example classes for these things that the user can then customize and build off.
The average user certainly feels otherwise. Programming your own shaders and BRDFs is too overwhelming for most people. They actually want to focus on making an actual game/simulation/medical software.
The new Hlms material system aims at solving exactly that.
But the Hlms also lets you plug in your own implementation if you want to. You can do like xrgo did and heavily customize the implementations we provide to suite his needs. Or you can do like white_waluigi, who is writing his own deferred renderer using its own Hlms implementation.
Kinslore also has researched into the custom Hlms realm, and has provided lots of introductions to it in the 2.0+ subforum.
In my own project I have two extra Hlms implementations, one that renders atmospheric scattering effects, another that renders volumetric ones (no, sadly I cannot share this with the community). Such is the power of the Hlms.
Using the Hlms "as is" provides the average user a magic black box that deals with their materials applied to meshes and scenes automatically, living in that nice world/illusion we protect our users from (like Unity and UE4 do with their own material systems).
Users who want to go deeper, can get their hands dirty and write their own Hlms implementations. Some users have complained writing Hlms is hard. It can be overwhelming at first, at least until "it ticks" inside your head. It gives you incredible power that comes with great responsibility.
The Hlms is a system designed for modern GPUs in mind. It works so great and so fast because of this fact. But it can be difficult to grasp at first; and it is extremely different to how "Materials" worked in 1.x. There are no "constant parameters" in the DX9 sense.
If you're going to get your hands dirty, don't complain the mud is not to your taste.
@not to anyone in particular:
The website thing is indeed a problem. It's an old Wordpress template with lots of old information accumulated. Unfortunately I barely know the site's structure on the server side of things.
TBH it would be easier for me to come up with a minimalist (also more eye candy) website that points up to the most recent information, a small news/blogpost section, and a link to the old website as an "archive".
As for the SDK download:
This is one of the things I haven't put my hands to work on. I despise the old "SDK" model where a CMake scripts copies the libs and headers to a separate folder just for the sake of altering the project structure unnecessarily. Users who want to switch from the SDK to their own built-from-source often find trouble, and devs who want to alter the Ogre source code (included myself) need to run the "install" CMake command after compiling so that the SDK structure gets updated.
I find much more useful
a CMake script like the one in OgreMeshy where OGRE_SOURCE points to Ogre's source code, and OGRE_BINARIES points to where CMake created the binaries.
However I don't know if this approach works in OS X/iOS/Android. It certainly does on Linux and Windows.
This way both the SDK and regular source code project structures would match 100%; making things smoother for everyone.
