Frankly, if it were by me I would've packaged the repo as is and call it a day. But fortunately the other devs don't agree and persuaded me of polishing it a bit more.
We kept polishing and we narrowed the broken stuff list to quite a small bunch.
TagPoints isn't going to be fixed soon. First we need to integrate the new skeleton system into Entities (which is already in InstancedEntity).
SSAO & Deferred Shading we'll wait until the next update, because porting them then will be a lot easier (and in the case of Deferred Shading, a lot more user friendly).
That leaves shadows and volume component. As for the Volume component, I have no idea what's the status. I'm not quite involved in that component.
Finally... shadows. This is where I can actually make the change. Shadow support has vastly improved in 2.0; but the sample needs to be fully rewritten. And that's where the headaches begin.
The old shaders have a lot of useful functionality (PSM, Regular bias, Slope Bias, linear depth) that my simpler shaders don't have, but at the same these shaders are so heavily modified across the repo history that they're heavily broken (even in 1.x branches); thus it's just better to start from scratch. But it's just a nightmare, because there are many RS to support (HLSL, GLSL, ES, Cg).
So basically to release Ogre 2.0; we'd just need to get Shadow samples working again. But this raises another concern we've been discussing: The next release will be quite disruptive too.
The next release will make Render Queue changes, as well as massive changes in how we handle materials.
The current way of handling materials will be labelled "low level materials". It will still exist and continued to be supported (it is still very useful for i.e. postprocessing effects).
However, the preferred method for using materials for rendering common entities and stuff (probably including UI elements) will be this new "high level" system. This will help us a lot in maintaining shader codebases from all RenderSystems, while making Ogre much user friendlier and easier to make it look good, from newbies to experts. Most Samples will switch to these high level materials.
So, all things considered releasing Ogre 2.0 now "as is" means:
- Mobile devs will love it. Advanced features (like TagPoints) aren't usually required, and Ogre's 2.0 huge performance benefits will be welcomed in these platforms.
- Any developer involving too much time in this release will be mad when he finds out the next release strongly suggests to move their material databases to the new system. Their old materials will still work; so if were written 2 years ago, it's ok. But if they're newcomers who decided to give 2.0 a shot and already started writing around their own materials and shaders, they'll be pissed and think their time was wasted.
- Advanced users will poke a bit with it, but probably won't find it more than a curiosity. No TagPoints could scare them away. And TagPoints will only be supported in the new Animation system, which is quite different from the legacy one. Advanced users won't like to code with a Skeleton interface that's going to change in the next version. They can use the new version with InstancedEntities, but with regular entities, they're stuck. Furthermore, enthusiasts are probably already trying 2.0 from the latest repo.
- Newcomers may feel these limitations as a sign that Ogre 2.0 is a mess, when this isn't true, but damages our image and reputation.
"Alpha" & "Beta" usually means "this can crash!! and it has memory leaks!!!", which isn't our case. Crashes & bugs in 2.0 are rare(*) and we don't leak. But at the same time, it isn't final and I wouldn't recommend it to be used in AAA production (Torchlight, I'm thinking of you)
A CPT gives us the opportunity to test a stable release (we need feedback), the mobile devs will be happy, advanced users will know what they get, and newcomers know this comes with a label attached "this may change in the future; it's a (stable) work in progress"; that is we avoid damaging our image.
(*)Bugs are rare, but 2.0 doesn't have the extreme flexibility of 1.x and is much less forgiving to user mistakes. For example, altering the camera or creating a light in a RenderTarget listener is forbidden and will trigger an assert. Read the porting manual (also contained in the Docs folder in the repo).
What is so hot that will change in the next release?
The reason of this post is to ask the community about the idea of releasing Ogre 2.0 Community Technology Preview, while we work on the final Ogre 2.0 (or just skip to 2.1 entirely; my team mates disagree in skipping 2.0); the big changes are:
- New High level material system (HLMS). Easier to use, to extend, to setup, to maintain; and will look much better (basically "make me pretty" magic button).
- Auto instancing, only possible with the HLMS. This will bring HUGE performance improvements.
- All samples will use the HLMS except when inappropriate.
- New Animation system: The same system that is now in InstancedEntity will also be in Entity. If your codebase contains Skeleton/Animation/NodeAnimationTrack pointers, you'll probably have to make a lot of changes there. Legacy skeleton system can still be used (by compiling w/ OGRE_LEGACY_ANIMATIONS in CMake) but they won't have TagPoint support.
- RenderQueue changes: A brand new RQ. If you have calls to setRenderQueueGroup & Co. you may have to revise them, and RQ listeners will probably no longer work.
The HLMS benefits cannot be taken lightly!
Btw, the CPT release would be released with a less interactive version of Shadows sample so that we can show how to setup Shadows in 2.0; without much hassle for us (while we prepare a more advanced version in 2.0 Final using the HLMS)
In summary Ogre 2.0 Final can become quite different from 2.0 CTP; which is the whole point of this post.
So guys, what do you think?
Edit: I'm leaving this sticky for 60 days.