Calling @Matias Goldberg

Hi!

I'm an Ogre3D dev.

There are many things that can be said.

As you said, Ogre3D is a rendering engine rather than a game engine. Although it's fair to say that compared to other rendering frameworks (e.g. bgfx, The Forge / ConfettiFX, D3D12 Mini Engine) we do a lot more, putting us closer to game engine, but not quite there.
We don't do physics, sounds or networking.

It's great if you want to glue different components together (or write your own), but not so much if you just want to start making a game out of the box ASAP. That's where Unity, UE4, Godot, Wicked, and Skyline shine as game engines.

Ogre stays strong in non-games applications, such as simulation and architecture SW.

As to development: Ogre has two main branches: +2.1 and 1.x
I maintain +2.1 while Pavel maintains the 1.x one.

Ogre 2.1 isn't WIP. In fact there are games released using it such as Racecraft and Sunset Rangers. Skyline Game Engine is built on top of Ogre 2.1

The main reason you haven't seen an official release is because our CMake scripts that generate the SDKs are ancient and the SDK they generate do not match the folder structure from an out-of-source build. This problem isn't new, it affects Ogre 1.x too; but it is too bothersome and there's a lot of CMake ancient legacy to sort out.
Previously another reason was that we were waiting for GLES3 support (to get Android support for 2.1), but it became less of a priority given Android's extremely poor driver quality.
But that doesn't mean Ogre is WIP.

The main highlights from Ogre 2.1:

1. Serious boost in performance. Ogre 1.9 used to be the slowest alternative. Pavel has been doing a lot of good work to improve that in 1.11; but in Ogre 2.1 we made architecture changes to address the problem from the root. It's common to hear 4x improvements when migrating to 2.1. When it comes to performance nowadays we do very well against the competition in this front. We seem to be popular for VR simulations thanks to that (but still take in mind VR requires rendering at 90fps in two eyes, and that is hard whatever engine you pick!).
2. PBR material & pipeline
3. Hlms materials are friendlier as we handle all shader work for you (unless you specifically don't want to), unlike 1.9 where you had to either write your own shaders or setup the RTSS component.

There are many more differences but I don't want to clutter this forum thread and turn it into a Changelog

With OpenGL you can target Linux (NVIDIA & Mesa-based drivers), with GL & D3D11 you can target Windows (minimum GPU: D3D10 hardware), with Metal you can target iOS, and with Metal you can target new Macs while you can use GL to target older Macs (our GL for Mac is Beta, not to mention Apple itself is deprecating it).

We want to target Android and community member did an excellent job, but the poor driver quality continues to be an issue. We get deadlocks inside the driver while compiling shaders, incorrect results when using shadow mapping, crashes while generating mipmaps. We may address via workarounds for Ogre 2.2; or maybe through Vulkan. But at the current time, if you plan on targeting Android, you'll have to use Ogre 1.11 or something else.

Of course it's not as easy as Unity where targetting another platform is just one click away. The rest of your application code has to be able to run on those platforms as well and deal with the differences.

Ultimately it depends on what you want to deal with. Personally and most of the people I work with like to write custom stuff, specific for our needs. That gives us flexibility, better framerates and distinct look. Or it's because we like to own our tech ("owning" as in if something is broken we can fix it ourselves because we've got source code access, or we can write our own alternative, or we can swap another solution). UE4 gives you source level access (though it's a huge codebase) but it's not technically free. The standard Unity licenses doesn't give you source level access. It may be fine for you, but then if a feature you need is broken, you have to patiently wait for the next release for a fix (if it gets fixed, and pray the upgrade doesn't break your game), but I admit is the one with most user friendly interface. Godot is lighter and open source, so that engine would be my decision if I'd go for a game engine.

Ogre3D gives you more control and power, and generally better performance which is something to take in mind if your game wants to have a lot of dynamic objects on screen (i.e. RTS games fit that description). But the downside is that you have to do a lot of tech work yourself. It's not "free" in that sense.

Right now our development efforts are focused on Ogre 2.2 (which IS wip), and as our Progress Report from December 2017 says, it centers on a overhaul of texture code to heavily improve memory consumption and allow for background streaming (among other improvements).

But we still add incremental features to 2.1; for example we've recently added approximate fake area lights (including textured area lights; the "fake" stands as in that the math is not PBR).

Cheers

If we travel back in time to 2010, there wasn't much to chose. Unity was paid and starting to get known, an Unreal Engine license costed tens of thousands of dollars. I don't remember if CryEngine was open to licensing.

So the question would have been unequivocally "use Ogre3D or roll your own engine" for games.

We did lose a lot in terms of community since lots of users started to migrate to all these new options. But the small community we still have usually responds quickly at least when it comes to 2.1, and I usually respond quickly as well. You still get support if that's what you're asking. But it's a far cry from our very active community 8 years ago, and a big community meant your obscure questions were likely to be answered (like "I can't get Ogre to run in a custom Arduino") which most of us cannot or have little experience.

As for being an Ogre old timer: If you were familiar with Ogre 1.4/1.6/1.7/1.8/1.9 then we have a porting manual for you (online manual, more up to date; but the porting part hasn't changed).

The recommended flow for old timers porting is Ogre 1.x -> 2.0 -> 2.1

Ogre 2.0 implemented some architectural changes to core (make SceneNode traversal cache friendly, SIMD and threadable) plus a new Compositor architecture (whose scripts are similar in syntax, thus relatively easy to port). In fact the samples from 2.0 are the same as 1.9; Thus Ogre 2.0 still feels very 1.4-1.9. Note that 2.0 is not actively maintained, and as the link explain, is a good "middle step" to move to 2.1

Ogre 2.1 added architectural changes to the renderer and material system. If you've used Unity or UE4, you'll feel the material system very familiar because "it just works" by defining PBR properties such as roughness, diffuse, fresnel etc. Which is very different from 1.x's materials (now called "low level materials" in 2.1; which are still there but mostly used for compositor effects, and are not recommended for scene objects) which required you to manually specify a vertex & pixel shader.

So by trying them in sequence 1.x -> 2.0 -> 2.1; you can see the changes progressively. Going from 1.x -> 2.1 is possible but feels more shocking.

Many concepts are still there: The ResourceGroupManager hasn't changed, the new "Item" that replaces "Entity" (now v1::Entity) work similarly (they still need to be attached a node, most functions have the same name, etc).

Perhaps what's most confusing is that we call "HlmsDatablock" or simply "datablock" what you would normally call a "Material", because the name was taken by the old materials.

Does that answer your question?