Is OGRE still relevant today?

[cliftmaples]

Most people, myself included, who want to explore a game engine and who work full time have very limited time to enjoy learning a new platform. If you compare the learning curve of OGRE to that of say unity/unreal/godot etc... it is quite steep and the documentation is quite sparse comparatively.

But, the OGRE killer in my opinion is the ridiculous effort it takes to even build the engine. It's almost impossible and most give up before even having the opportunity to learn/enjoy this incredibly capable game engine. With the disadvantage awarded to the Windows Community which owns the lion's share of computing today.

Something to think about...

edit: changed the title as this became the first result on Google

[dark_sylinc]

When it comes to building the engine, we recently added quick start build scripts for 2.1 & 2.2 to handle that step in a few clicks.

Most people, myself included, who want to explore a game engine and who work full time have very limited time to enjoy learning a new platform. If you compare the learning curve of OGRE to that of say unity/unreal/godot etc...

Ogre is a graphics engine, whereas Unity, Unreal and Godot are game engines, making them higher level.
Having a graphics engine means you still have to take care of physics, input, networking and sound by yourself.

It gives you greater flexibility to do things Unity/Unreal/Godot aren't well fit to do due to their canned nature (usually games), but it also means it's harder and takes a lot more work.
It also means sometimes we want to do things that would lighten our user's load, but we can't because it enters game engine territory and we would have to also provide a lot more (i.e. the full game engine) and would also restrict or alienate our small but loyal user base.

it is quite steep and the documentation is quite sparse comparatively.

Unfortunately that is true.
I hope you have at least seen the online manual?

But, the OGRE killer in my opinion is the ridiculous effort it takes to even build the engine.

I hope the quick start build scripts help you with that!

[xrgo]

A few years ago there were no good free game engines, that were the golden years for Ogre. Most people just want to focus on making games and there are many free great options now. But there's people who want to make an engine that fits their needs and workflow like me! and for that Ogre is a solid option. There's a reason why many companies all have their own in house engine, and many others still create their own even now that there are many options. In my company (vr simulation) we use Unity and Unreal too, but for complex applications our engine beat them in speed and easytouse (once you know how to use it), we can now make a new full vr simulation software in less than a month.

Agree that everything can be improved but there's limited resources =(

[paroj]

Most people, myself included, who want to explore a game engine and who work full time have very limited time to enjoy learning a new platform. If you compare the learning curve of OGRE to that of say unity/unreal/godot etc... it is quite steep and the documentation is quite sparse comparatively.

Anything that you would Like to See improved particularly?

But, the OGRE killer in my opinion is the ridiculous effort it takes to even build the engine. It's almost impossible and most give up before even having the opportunity to learn/enjoy this incredibly capable game engine. With the disadvantage awarded to the Windows Community which owns the lion's share of computing today.

We have prebuild sdk packages Form windows, including different language bindings. So i cannot agree Here.

[Hrenli]

As mentioned already, Ogre is not a game engine. Which makes it very niche. This niche is quite small, but it definitely exists and IMO Ogre is quite good in that niche. And being a niche product it of course suffers quite a lot, especially in such areas as documentation, tutorials and examples.

Most people, myself included, who want to explore a game engine and who work full time have very limited time

For people in such situation (and I am counting myself between those too) I think there is a very important question to answer, which is: why Ogre and not Unity (or Unreal or whatever else)? Without knowing the answer to this you'd better look in Unity direction. But if you know the answer, then putting some effort into learning Ogre architecture and infrastructure goes a long way and is worth it IMO.

P.S. Also, it's OGRE, not ORGE.

[frostbyte2]

man, i just love this topic....couldn't resist replying....

Most people, myself included, who want to explore a game engine and who work full time have very limited time to enjoy learning a new platform. If you compare the learning curve of OGRE to that of say unity/unreal/godot etc... it is quite steep and the documentation is quite sparse comparatively.

frankly saying- your'e not OGRE's target audience, to be honest ogre will fail you in all aspects the aspects you've mentioned
lets start for starter with that c++ nature is not really meant for being a joyful experience
paroj is making an effort to bring ogre to other langage but that's a new fresh addition to ogre's core so its not mature or battle tested
i my self am working with java-ogre and i can tell you it's a nightmare, so many pitfalls- hard crashes, memory-leaks, bad performance and gc stalls all over... but when you get over those( promise to publish a wiki explaining how to avoid those when i get some mojo ) its pure magic...

ogre is stable as a rock, its a fast and flexible renderer with a great animation system and so many other options, allowing me to explore what ever crazy algo i can come up with

with ogre2.x you also get most of the modern rendering features offered by the big-guys , so i would say thaat the phrase 'ogre is dying' is not a good phrase to describe the decline in ogre's adaptation rate, especially since there is no real commercial or other interest to increase its adaptation rate among hobbyist

"it is quite steep"- wrong...its very steep, ogre is really a massive piece of software developed for a decade, and by 'massive' i mean that 7 years in , and i still don't know all features it contains, i am constantly amazed by the magnitude of this project
i would also like to point that ogres steep learning curve comes from the fact that you actually need to understand how the cg works in general and how OGRE works in specific, so by the time you build your game engine you actually become somewhat of a pro on those subjects( errors and bugs are a great teacher )
i guess that a 'no learning curve' type of engine also means 'no learing' and in that since i would say the using OGRE is a great even if somewhat slow and painful learning experience, this learning experience brought me lot's of knowledge and ideas which led directly to the software i'm working on...
so, thank you 'steep learning curve'...

"documentation is quite sparse" can't agree with you on this, beside the books the wiki the well documented api,the samples and hundreds of github projects, their is also ogres sacred forum, a temple of knowledge which contains answers to almost any problem you can come up with(regarding ogre)

honestly i've read both unity's and unreal's manuals, couldn't understand a thing- i faintly remember it was all about dragging this and pressing that kind of tutorials...no meat...no learning...no coding..., ogre is strictly for coders and i think that its much better documented than the big names in that aspect

also beside the fact that unreal is realy targeting AAA studios, unreal's c++ look horiffic...not to mention 20GB download, and it works only high-end graphic cards, while ogre runs even on my 2012 intel-4000HD laptop( my nvidia-660m burned to crisps... )
about godot...3d is a new thing for godot not sure how well its documented, also looking at godot issue's list on github, i rather stick with ogre...
now, about unity... i guess its a solid option for you, if i was you today i would probably go with that...

But, the OGRE killer in my opinion is the ridiculous effort it takes to even build the engine. It's almost impossible and most give up before even having the opportunity to learn/enjoy this incredibly capable game engine. With the disadvantage awarded to the Windows Community which owns the lion's share of computing today.
g
Something to think about...

well my friend, no pain no gain...
i kind of enjoy the idea of placing a barrier to ogre adaptation ,feels like prepackaged has made developers either spoiled or incompetent, as said before if you can't handle building ogre then your'e probably not equipped to handle the engine and should not waste your time
but anyway ogre's team is working in various new directions to allow for smooth installation , this efforts are quite new ,so you are welcomed to check out progress on this subject in a few month while they mature

thanks for bringing this exciting topic of 'is/why ogre dying' again.
hope to see you on the forum in 10 years with the same question

[Lax]

Yeah, OGRE is for people, that love programming, especially C++
Yes it takes a long time to get warm with OGRE, but that makes it attractive, if you program some code and get nice graphics rendered as a result!

[mkultra333]

I've made one game using Ogre now, and I'm finishing a second built on the same code. I'll probably try and make two or three more based roughly on the same code base, since it's already done.

Writing the engine took way, way longer than setting up Ogre. I started a decade ago when the engines available were either rubbish or expensive.

Now engines are often free, or not that expensive, and quite powerful. So I think there's very little reason to use Ogre unless you have a team and a budget and some significant reason not to use an off the shelf engine. If I were starting again tomorrow, I doubt I'd use Ogre. Why reinvent the wheel when there are production level engines already easily accessible?

I think it's a pity no one ever made a basic, generic game engine for Ogre. Just a basic shooter that shows how to load levels, setup menus, integrate physics, that kind of thing. I know there have been several false starts from people in that area, but I don't think any really survived for long. A serious generic engine (something very simple) maintained by the Ogre core group would be great. Ogre as strictly only a rendering engine obviously has it's uses, but becomes more and more irrelevant to most people as time goes by.

[paroj]

I think it's a pity no one ever made a basic, generic game engine for Ogre. Just a basic shooter that shows how to load levels, setup menus, integrate physics, that kind of thing.

IMO the SampleBrowser is pretty close to that. As of 1.12.2 the DotSceneLoader lives in the ogre repo, so we even provide a file format for levels now.

[mkultra333]

I'm on a modified version of 1.10, at the time I don't think I could get the sample browser to compile. So I haven't had a look at it in a while.

But if a new user can't look at it and say "Cool, a simple first person shooter template!" and see the integrated physics, sound, etc, then it's not really doing what I'm thinking of. They need to see a jumping off point for their own game.

I know there's a lot of resistance to such a thing, and that Ogre is supposed to be strictly rendering. I just wonder, if you're adding all these awesome rendering techniques, instancing, model animation and so on, who do you think the market for that is? 90% of the time, it's going to be people thinking of making a game.

Sure, you'll get the odd person who just wants to render some scientific data they've researched, or whatever, but those people would probably be happy with basic OpenGL rendering and will see Ogre as overkill for their needs.

So given that the rendering power Ogre is offering is obviously best suited for people making games, it seems a serious marketing mistake to not include one or two basic but complete game templates as well.

[mkultra333]

One idea to make this possible is to take some other open source game and add Ogre rendering to it. This was my plan long, long ago. I took the Quake 3 code and added an Ogre renderer. This gave me a mostly functional game but with Ogre's power to render real time shadow maps. This was around the time of Ogre 1.6. I moved on from this idea because I decided the GPL Quake 3 code wouldn't work well with Steam integration.

But if you could find a similar type of engine that had a better license, this could make an easy starting point. Another I looked at was the Cube 2 engine, https://en.wikipedia.org/wiki/Cube_2:_Sauerbraten

[paroj]

I'm on a modified version of 1.10, at the time I don't think I could get the sample browser to compile. So I haven't had a look at it in a while.

But if a new user can't look at it and say "Cool, a simple first person shooter template!" and see the integrated physics, sound, etc, then it's not really doing what I'm thinking of. They need to see a jumping off point for their own game.

I mainly have this sample in mind:
https://ogrecave.github.io/ogre/emscripten/

It shows a HUD, WASD controls and simple "collision detection". Of course physics and sound are separate plugins and thus not included.
However, I am working on making the integration easier by consolidating the different repositories. Basically you should be able to select what you need in CMake.

I know there's a lot of resistance to such a thing, and that Ogre is supposed to be strictly rendering. I just wonder, if you're adding all these awesome rendering techniques, instancing, model animation and so on, who do you think the market for that is?

Custom visualization solutions e.g. this is ogre
https://plantium.com/productos/displays/1/sbox11

or this:
https://apps.apple.com/app/id1294681561

[mkultra333]

This is what all the hard work on the 1+ and 2+ branches is about?



9 out of 10 people who need something like that may as well just use OpenGl or the like directly, and probably do.

I'd speculate that the people most likely to want Ogre's capability for things like instancing, shadow mapping, compositors, or whatever latest graphical technique ogre has added (cone step mapping, etc) are going to be people looking at making games. But since Ogre lacks any kind of example game template, most game makers are going to look elsewhere.

So by default, your users end up being people making bike trail maps and farm machinery apps. Wasn't always like that, people used to use Ogre to make things like Torchlight. But that was when choices for engines were limited, and Ogre could get away with having no example game template.

[paroj]

So by default, your users end up being people making bike trail maps and farm machinery apps. Wasn't always like that, people used to use Ogre to make things like Torchlight. But that was when choices for engines were limited, and Ogre could get away with having no example game template.

yes, basically this is the niche we are in right now. Even if ogre did provide a game template, we would be talking about a game editor right now. At this point we would be competing with Godot. However if Godot is what you actually are looking for, it is easier to contribute than to compete.

But I would argue that even farm machinery apps look better with real time shadows and advanced global illumination

9 out of 10 people who need something like that may as well just use OpenGl or the like directly, and probably do.

if the goal is to render something reliably instead of writing a renderer, they should be using Ogre though.
There are years of experience with platform specific quircks in the codebase and you get a file format that your artists can export to from e.g. blender.

However, even in our niche there is a tough competition by bgfx, which basically just the RenderSystem layer of Ogre. I guess only time can tell whether our feature level between godot and bgfx is a good one. But this is why I try to keep "old" addons like ogre-procedural or particleuniverse alive. They are very handy tools at the abstraction level of Ogre and you dont write these things on a afternoon yourself.

[Hrenli]

It's just my opinion, but I think it's less about elaborate example and more about whole ecosystem around the engine. People who are looking to make "a" game are better off with Unity these days because they get a whole pipeline, WYSIWYG editors, a whole workshop of plugins and even some platform which helps you to publish the result as far as I understand.

I don't think it's realistic for OGRE to compete with that. And considering the fact that there are several free(-ish) game engines out there already it's probably wise not to even try to compete with them, keep it niche and build on the strengths instead.

Doesn't mean OGRE wouldn't benefit from more examples and tutorials. But it might be also a question of how relevant an elaborate example would be for a user considering that one of the main strengths of being just a rendering engine is that user is free to do whatever he/she wants with the rest of the program. How to approach the balance between that freedom and guides/tutorials/documents etc - I am not sure. And that's even before we consider the limited resources.

[mkultra333]

Paroj, I don't want to seem like I'm disrespecting those uses of Ogre. I just get a little depressed at how totally under-utilized the full power of Ogre is.

Hrenli, I agree, sorting out your pipeline and overall setup with Ogre can be tricky.

We've covered the cons of using Ogre, but I want to point out the one big pro. Unlike a generic engine, you can really customize the rendering methods and optimize them to suit *exactly* your game's requirements.

I don't think I do almost any of my game's rendering in standard ogre fashion. I disabled all the Ogre culling systems and instead use my own zone-portal method. All my lighting and shadowing is custom written. I don't use compositors at all, I write all my own HLSL shaders, and control all rendering at the level of switching nodes in and out and rendering surface by surface.

I use my own version of instancing, which allows me to do things like remove and attach bones as required. My game has huge numbers of enemies whose limbs can be shot off, but they're all just one big mesh, while the entire environment is just a second mesh. And the enemy body parts are permanent, gore and wreckage stays in the environment for good.

[Edit: You might say "If you're doing everything in a custom way, why use Ogre instead of just directly using DX11 or OpenGL?" The reason is as Paroj says for the other uses: Ogre deals with all the platform and API specific quirks, gotchas and corner cases, and I don't have to worry about all the tedious work of managing resources. Plus it'll make things easier if I decide to make versions of the game for other platforms, like OpenGL+Linux instead of Windows+DX11.]

This has allowed me to maintain a good frame rate even in VR, where you only get about 5ms to render the entire scene. (While VR updates at 90Hz, I discovered the hard way that you don't get 11ms. Man, I dream of having 11ms!)

In a nutshell, I don't think I'd be able to have that many enemies (with detachable body parts), plus virtual reality, if I used an off-the-shelf game engine. It requires too many optimizations for a very specific requirement.

Here's a quick 1 minute vid showing the game I'll be releasing soon. Unfortunately YouTube recompression seems to really mangle the video quality, but hopefully it conveys the idea.



So I think Ogre is more than up to the task of being an excellent game renderer. I guess the idea of including a basic game template will never happen, but I think that is a massive missed opportunity.

[dark_sylinc]

I'll go off topic a bit.

This has allowed me to maintain a good frame rate even in VR, where you only get about 5ms to render the entire scene. (While VR updates at 90Hz, I discovered the hard way that you don't get 11ms. Man, I dream of having 11ms!)

5ms is too little. Sounds fishy.
I've been adding OpenVR to Ogre 2.2
You lose 1-3ms of GPU time in SDK stuff (reprojection, etc). So you have 8-10ms for your frame.

However the main cause I see for slowdowns is incorrect use of Submit & WaitGetPoses. Submit must be done before present.
WaitGetPoses will stall and return 3ms before VSync. Valve calls this "running start"

Hence whatever you do after calling WaitGetPoses, it can't take longer than 3ms or else you'll be moved to the next frame.
And you don't want to have nothing to do after returning from WaitGetPoses either, else you're wasting precious CPU time.

A common mistake is to submit, then immediately afterwards call WaitGetPoses. This will force your CPU (not GPU) to take no less than 3ms per frame or else you could be subjected to slowdowns.

You may want to see our new OpenVR sample in latest Ogre 2.2; as it provides multiple places for where to place WaitGetPoses (there is no "one true place", because the location depends on your scene's workloads).

Even if you have no intention of using Ogre 2.x; playing around with it should give you a better understanding of how best to take advantage of WaitGetPoses.

[mkultra333]

Interesting. I'll check that out. When I was first adding VR I experimented a lot, for a month or so, trying to time things to the hmd, but in the end the only thing that worked was to focus on getting the best frame rate possible and rendering in the 5-6 ms range.

Also, that 5ms is just for the rendering, there's a bit of game code that runs just before the rendering which chews up 2-4 milliseconds per frame as well. Organizing the actions of a hundred monsters and their missiles and attacks isn't free.
So the total frame time for VR is in the 7-8ms range, of which about 5ms is taken to render.

Maybe I should have said that in *my situation* I only have about 5ms to render a VR frame.

I do call WaitGetPoses right after Present, but at that stage most the CPU work (physics, pathfinding, metaballs) is being done by other threads. The main CPU hog is the physics thread, and that gets launched for the next frame just before the rendering for the current frame is started, and so runs in parallel to the rendering. So there's time to spare on the CPU where WaitGetPoses is called, and a little lost time there shouldn't really have much, if any, effect.

At least that's the theory. Maybe I'm messing up something. At any rate, VR is running pretty well.

[luis]

I've been using Ogre for personal projects for more than 13-14 years (since version 0.12.4 I think) and I've been in the video game industry for >10 years.

In my opinion Ogre is dying not because of Ogre itself but because high level game engines (i.e. Unity & Unreal) have more permissive and cheap licenses for indies and for dev studios, and of course those engines have been increasing functionality, stability and the work-flow now works well for teams (it wasn't the case in the first versions).

Also the Ogre team had many important losses (Simbad, Monster, and many others) and the addons developed by the community had important losses too. The impact of that is quite evident now and it translates to: less users + less developers = less support in the forums & less bugfigxing/porting of addons.

The best things about Ogre are the flexibility, portability and it is made in C++ making it really easy to integrate external APIs, it makes Ogre relevant even now even in the "Unity3d era".

BUT, things that in my opinion should be improved is the QA, I'm surprised that the 1.12.1 version was released with a " blocker bug" and I'm talking about shadows in the terrain (using D3D11), it is quite obvious in the official demos that it isn't working. So, 1.12.1 shouldn't be in production.
Also there was quite a mess in the wiki because some times you don't know if the article is about Ogre 2.x or Ogre 1.x.

Thanks to all developers here.

[paroj]

BUT, things that in my opinion should be improved is the QA, I'm surprised that the 1.12.1 version was released with a " blocker bug" and I'm talking about shadows in the terrain (using D3D11), it is quite obvious in the official demos that it isn't working.

actually QA did improve significantly in the 1.x series. We now have unit tests that run after each commit and the visual tests are executed. (however they currently have to be verified manually)
I also work on growing test coverage (e.g. depth based shadow tests were added in 1.12).

As of your particular issue; the bug was known prior to the release. However, it affects just one component on 1/4 supported render-systems and is not a regression.

Finally users of open source software are not customers. You rather collaborate with others by means of it. This means you still have to invest time/ code.
You are free to blame the shrinking user-base for this particular bug not yet having been fixed by others though.

[luis]

As of your particular issue; the bug was known prior to the release. However, it affects just one component on 1/4 supported render-systems and is not a regression.

I'm glad to know the QA is improved and taken seriously. I can understand DX11 is 1 of 4 render-systems but I'm making a game with 2 render systems so in my case it is 1 of 2

Maybe I missed the "known-bugs" part in the release notes ? I read the release notes and since I didn't find the bug listed, I went with the porting from 1.9 to 1.12
If there is another doc, please let me know.

Finally users of open source software are not customers. You rather collaborate with others by means of it. This means you still have to invest time/ code.
You are free to blame the shrinking user-base for this particular bug not yet having been fixed by others though.

Shrinking user-base is the real problem with open source projects.

Long time ago I used to collaborate with the NxOgre, OgreOde and MyGUI addons but in the last 5 years I was 100% working in my project and using old Ogre versions, now I am an "outsider" here, I'm really far far away from understanding the Ogre code so I feel a bit of frustration for not being able to help

[paroj]

Maybe I missed the "known-bugs" part in the release notes ? I read the release notes and since I didn't find the bug listed, I went with the porting from 1.9 to 1.12
If there is another doc, please let me know.

you are right, there was nothing like that. I created such a list from the issues just now:
https://github.com/OGRECave/ogre/labels/Known%20Issues

[paroj]

Long time ago I used to collaborate with the NxOgre, OgreOde and MyGUI addons but in the last 5 years I was 100% working in my project and using old Ogre versions, now I am an "outsider" here, I'm really far far away from understanding the Ogre code so I feel a bit of frustration for not being able to help

I could track down some of the shadow issues to using the legacy tex2D intrinsic functions. Including this "porting" header:
https://github.com/OGRECave/ogre/blob/m ... pport.hlsl

mostly fixed the PSSM3 RTSS stage. However I had no luck with the Terrain shader so far. If you like, you can take a look at it here:
https://github.com/OGRECave/ogre/blob/v ... g.cpp#L279

[luis]

I could track down some of the shadow issues to using the legacy tex2D intrinsic functions. Including this "porting" header:
https://github.com/OGRECave/ogre/blob/m ... pport.hlsl

mostly fixed the PSSM3 RTSS stage. However I had no luck with the Terrain shader so far. If you like, you can take a look at it here:
https://github.com/OGRECave/ogre/blob/v ... g.cpp#L279

Thank you! I'll take a look at new v1.12.2

[paroj]

I could track down some of the shadow issues to using the legacy tex2D intrinsic functions. Including this "porting" header:
https://github.com/OGRECave/ogre/blob/m ... pport.hlsl

mostly fixed the PSSM3 RTSS stage. However I had no luck with the Terrain shader so far. If you like, you can take a look at it here:
https://github.com/OGRECave/ogre/blob/v ... g.cpp#L279

Thank you! I'll take a look at new v1.12.2

Rather Go with master. I pushed some d3d11 Terrain fixes there