, damn, that's awful. This thing reaches out and affects so many.
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.
Excellent! I'm glad to hear that, it makes me much less afraid of trying to port.
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.
I'm certainly not arguing Ogre shouldn't do those things, I just always wished that kind of functionality wasn't in the Ogre core but instead in customizable classes the user could easily hack at. So in the same way I might add a class to handle sound, or a class to handle monster AI, I can add a class made by Ogre experts that handles shadows. So I had a piece of production level code that I could also look inside and modify.
But if I can hack around all that stuff anyway, it doesn't really matter.
I know nothing of the Hlms. I'm guessing that means High Level Material System? I've had hardly any time last couple of years, and when I do have time I focus on my 1.8 project.
If you're going to get your hands dirty, don't complain the mud is not to your taste.
I'm fussy about what mud is to my tastes and what isn't. Like I said before, I have no time for the mud of resource management, DX or OGL obscure idiosyncrasies, shader compiling, and a tonne of other stuff I just want done and out of the way and to not have to think about.
On the other hand, I LOVE the mud of writing shaders, RTT and custom shadow methods.
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.
Cool. Last time I was here, it didn't even have Manual Objects. BTW, in the new manual objects, or whatever replaces them, please include all the possible vertex capabilities if you haven't already. 1.8 doesn't let you set binormal or specular, I had to hack that in myself. I use those parameters for other info, not actually binormal or specular.
(I'm assuming you still have, or intend to have, an easy way to construct meshes rather than the pain of having to fully construct meshes manually. Again, more of the kind of mud I don't want to have to deal with unless really necessary. Manual Objects are really handy for dynamically generated meshes.)
Anyhow, I'm liking the sound of 2.1 better now. Unlikely I'll use it for this project, too alien to 1.8, but after this project I'll definitely give it a go. But perhaps in the docs don't stress that doing low level stuff is somehow wrong, like the old docs did. Some of us like low level stuff, in some situations.
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.