History: Ogre 2.1 FAQ

Is Ogre 2.1 stable?

I am biased because I am one of the developers, but here's my answer:
Yes, it is stable. It rarely crashes, rarely leaks (no more, no less than other stable software).
However being still in development there is the occasional build-breaking change that usually takes 10-20 minutes of your dev time to adapt your code. There aren't huge/major changes anymore.

We've found the most common problem about working with Ogre 2.1 is the lack of up to date Wiki examples and plugins (e.g. CEGUI, etc) instead of stability. Some community users have ported existing plugins to 2.1; but I don't know their quality (does not mean they're bad!).

If you're not convinced, here's three projects:

• Racecraft (Official Site)
• xrgo's user is working on a commercial non-gaming VR project (sorry, there no public pictures).
• Unnamed Wild West shooter.

Is there a manual?

Yes!
It's located under Docs/2.0/Ogre 2.0 Porting Manual DRAFT.odt. We recommend viewing it in OpenOffice or LibreOffice, then exporting to PDF if you want to see it in your favourite PDF reader.
MS Word has a tendency to screw up the formatting.

Are there sample code / examples?

Yes!
You need to enable OGRE_BUILD_SAMPLES2 in CMake (note the 2 at the end, not OGRE_BUILD_SAMPLES which is broken at the moment and will probably be removed).
If the samples aren't building, you may be missing SDL2 dependency. Some samples use Rapidjson. If you've cloned ogredeps you should have them both (note: you must clone, don't download the zip, as it won't download SDL2 which is linked like as a subrepo module).

The samples are under %OgreRoot%/Samples/2.0 (yes we know, confusing name... labeling it 2.0).

Is Ogre 2.1 too different from 1.x? What changes should I expect?

Most of these changes have been covered in the manual. However here's a quick summary:

1. Old stuff has been put under the v1 namespace. If you get compiler errors, you may just need to append the v1. i.e. Entity *myEntity ---> v1::Entity *myEntity;
2. Items replace Entity, which are faster and easier to setup. However Items don't support everything yet (e.g. Entity has pose animations useful for facial animations, Items do not... yet). Entity is still useful for porting.
3. There is a new material system: the Hlms (High Level Material System).
4. Old materials are not recommended unless it's for rendering a few Entities at most (since they're slow and clunky to support), or unless it's for postprocessing (the place where they are most useful)
5. Textures remain largely unmodified at the time being.
6. The HlmsTextureManager handles textures for our new Hlms (High Level Material System), but don't let it fool you: Behind the curtains it's just cleverly managing the TextureManager for faster rendering performance. You could bypass it if you need to.
7. Rendering is now done through Compositors. It's not an optional component for postprocessing, but rather an integral part that tells Ogre how you want to render the scene.
8. The default ParticleFX still works.
9. Math (Vector3, Matrix4, Quaternion) has largely stayed the same.

Is there Android Support?

See What about GLES support?

What about GLES support?

The plan is to eventually fix the now-broken GLES2 renderer, supporting both GLES2 and 3. However the idea for GLES2 is to support it for compatibility since it's a very retarded API but sadly present in millions of Android devices and isn't suited for high performance. So the focus will be more about compatibility and stability rather than performance (it should be faster than it was in Ogre 1.x anyway). There may be other limitations I can't predict yet.
With GLES3, it should be much easier to run performance oriented mobile applications.

What about WebGL support?

Once GLES2 is ready, WebGL should be a piece of cake because it's 99% similar to GLES2.

What about D3D9 support?

There is no plan to support D3D9. It might be possible for someone to revive it by reusing whatever workarounds we'll write for GLES2 to run with Ogre 2.1.
But most of the team isn't thrilled about D3D9 anymore, only Assaf still cares.
Though until GLES2 isn't ready, I'd hold D3D9 support.

What about D3D11 level 9.x support?

It's not a priority. Again, it may get easier to support it using the same paths we'll write for GLES2. But D3D11 level 9.x is a special snowflake very hard to deal with (it imposes stupid restrictions HW didn't have, it doesn't map well to GLES2 nor D3D9. Things would've been much easier if level 9.2 Shader Model 2.x; level 9.3 Shader Model 3.0; but no... they mixed things and got the worst of all worlds).
The hopes really is that by the time we reach to this point, level 9.x hardware support would become irrelevant.

What about iOS support?

For older iOS devices, support is tied to GLES' rendersystem.
For newer iOS devices, we're currently working on a Metal RenderSystem.

What about OS X support?

Once the Metal RenderSystem is ready, OS X should in theory be supported as well. For older Macs that do not support Metal, Ogre supporting GLES3 is their last hope. We do not know how well that will work until that's done.

What about Vulkan/D3D12 support?

These APIs are in our plans. In fact we are moving to a PSO (Pipeline State Object) approach and our Compositor already knows about tracking Texture/RenderTarget/UAV dependencies and their resource transitions, which should ease greatly porting to these APIs.

However, they're not in the short term goal. Except for Async Shaders, most of these new APIs benefits reduce CPU overhead, not GPU. Ogre 2.1 is vastly GPU-bound.
Vulkan has greater priority than D3D12 because there is little D3D12 can do that D3D11 can't, and because Vulkan is the only way to target high performance graphics in Android (a void no version of GLES is filling). But still not a huge deal because Vulkan capable Android devices are very rare. Even in 2016 there are still devices being manufactured and sold that can only do GLES2 and KitKat.
Short term, we're aiming at focusing in our D3D11 and OpenGL paths and extending towards mobile support (GLES & Metal). Our design decisions leverage Vulkan and D3D12 for easy adaption when that happens. But it will be some time until that happens.

I've created 2 (or more) RenderWindows and I'm having severe graphical glitches or I get many GL_INVALID_OPERATION errors

If you're using OpenGL, you need to reuse the OpenGL context for all of the RenderWindow you create. Otherwise bad things happen. See this post: http://www.ogre3d.org/forums/viewtopic.php?f=2&t=84711&p=522308#p522313