I worked extensively with Ogre for a few years doing professional projects, ending about 5 years ago. At that time focus was mainly on desktop but iOS was of interest and there was support.

Back then, Ogre3D was a great option although slightly cumbersome for cross-platform work - we did look at alternatives when we started c2010 like Unity3D. Now as I consider getting back in the game I wonder if the world has moved on? It seems Ogre 2.0 is still WIP and even 5 years ago, 1.x was starting to feel a little dated to me. Since then major engines like Unreal have become way more accessible, and Unity3D has grown hugely (I think). Ogre is middleware not an engine so I know it's apples and oranges and this is not meant to be a criticism of Ogre - just an objective question whether many/most use cases 5-10 years ago are now better suited by Unity3D et al, especially for multi-platform?

I'm historically a C++ developer but have done a lot of C# too (I can do JS but prefer not to) and on pure language preference, C# is nicer IMO. I hate with a passion CMake and all that guff

What do other experienced people think of Ogre in 2018? Has it remained relevant? For someone wanting to make games not engines, would something else get me running faster while having the flexibility I want? What about toolsets/chains - this used to be a pain in Ogre too but perhaps has moved on?

I am thinking of posting similar on the Ogre forum but don't want to come across like I'm dissing Ogre - I loved working with it but 5 years is a long time and I'm out of date!

I am still working with ogre and have been since early 2k. At the moment most everyone has left for actual game engines, and the support in terms of member provided content and wiki is pretty bad or at least it is compared to the glory days. As far as, should you use it? I can't say as that would be more specific to your project requirements. You say you want to jump into making games, not engines, well, I think statement does a lot to point you where you should go.

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

Many thanks for the detailed reply @Matias Goldberg. If I can ask a follow-up question, how would you say things have changed in respect to my question or your arguments, in the last 5-8 years? i.e. if I'd asked this question in 2010 would you have given the same general advice or these days would you reckon more use cases have shifted to make more sense moving away (or towards) Ogre?

Other than architectural changes, if I got back into Ogre these days would anything have changed in a big way in the 'feel' of the project and community, and the way things work? Or would it all feel very familiar?

The poster above you suggested things have gone downhill in terms of community and so on - would you agree with this? 

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?

I think so - or as close as it is answerable objectively! I would still love to canvas others' views if Ogre users are around here

Many thanks for your thorough replies.

I have been using Orge3D for over 10 years and still have an active Windows desktop application that uses it.  I have been super happy with the Ogre3D product and the community.  However, I moved to Unity3D for the mobile development.  The following narrative is the reasoning for the change.

To start, let's move back to 2007.  The team inherited an application (originally VS6, C++, XP, MFC, D3D7) that needed to be modernized and have a better/more-flexible/higher-level graphics system implemented so that the project could be moved forward and expanded.  Also, we did not need/want to be "on the hardware" for the graphics system, so a higher level of abstraction (above DX and OpenGL) was desirable.  After research, we chose Ogre3D because it had the features, flexibility and abstraction that were needed for the redesign of the graphics/object system.  Additionally, the library architecture fit well with my personal past experience of using IRIS Performer and OpenInventor.  We implemented Ogre3D and were delighted with the results.  However, we still relied on MFC for all of our UI needs.

Now, let's move move forward to 2015.  The client wanted to add mobile to the project for both iOS and Android.  We looked at many libraries and ways we could approach cross-platform development (neither Java nor Objective-C are in our wheelhouse).  We also took stock of the areas of code that could be extracted from the desktop application. Unfortunately, only the graphics/object system put in place during the implementation of Ogre3D could be reused.  There was no UI (it was MFC) or file management (it was also MFC) that could be leveraged.  So, much of the application needed to be created from scratch.  We created a few of proof-of-concept projects with the various offerings (one being in Unity3D) to test the development time and workflow.

In the end it was decided that Unity3D meshed best with our needs and provided us a great environment for design, development and workflow.  Also, it bridged a concerning gap by providing us with the tools to create the UI needed for the mobile apps (the new UI system is great).  Finally, we were able to deliver the mobile apps faster than expected.

I have been very happy with the choice of Unity3D for the mobile applications and I really enjoy working in the Unity editor.  The progress that I have seen being made in Unity over the last 2+ years has been impressive and has helped us delivery great mobile apps.  With that said, there are no plans to move from Ogre3D in the desktop application.

Thanks for reading!

Interesting, thanks.

I was quite pleased to get my Ogre project running on iOS without (too many) major problems. It was a lot of steps into the unknown and I still have no idea how OBJ-C works, but despite it being experimental there was quite good community support including one of the main Ogre contributors.

A project I'm on these days is WebGL/3JS which I suppose is another option though it's foreign to me. I only recently realised Unity had dropped their plugin and apparently the native Unity->JS setup is very lacking in comparison to native JS middleware.

6 hours ago, d000hg said:

A project I'm on these days is WebGL/3JS which I suppose is another option though it's foreign to me. I only recently realised Unity had dropped their plugin and apparently the native Unity->JS setup is very lacking in comparison to native JS middleware.

Unity3D dropped support of their WebPlayer a number of versions ago (many browsers starting blocking it, starting with Chrome).  However, WebGL remains one of their target build platforms.  

Additionally, Unity3D has end-of-life'd their UnityScript support (the JavaScript-like language).  They are going the C# route.  With that said, they still support Java, C++ plugins.