Why OGRE is Dying
-
- Gnoblar
- Posts: 1
- Joined: Sun May 19, 2019 8:07 pm
- x 1
Why OGRE is Dying
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...
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...
- dark_sylinc
- OGRE Team Member
- Posts: 5296
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1278
- Contact:
Re: Why ORGE is Dying
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.
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.
I hope you have at least seen the online manual?
Ogre is a graphics engine, whereas Unity, Unreal and Godot are game engines, making them higher level.cliftmaples wrote: ↑Thu Sep 12, 2019 1:52 am 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...
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.
Unfortunately that is true.cliftmaples wrote: ↑Thu Sep 12, 2019 1:52 am it is quite steep and the documentation is quite sparse comparatively.
I hope you have at least seen the online manual?
I hope the quick start build scripts help you with that!cliftmaples wrote: ↑Thu Sep 12, 2019 1:52 am But, the OGRE killer in my opinion is the ridiculous effort it takes to even build the engine.
-
- OGRE Expert User
- Posts: 1148
- Joined: Sat Jul 06, 2013 10:59 pm
- Location: Chile
- x 168
Re: Why ORGE is Dying
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 =(
Agree that everything can be improved but there's limited resources =(
-
- OGRE Team Member
- Posts: 1994
- Joined: Sun Mar 30, 2014 2:51 pm
- x 1074
- Contact:
Re: Why ORGE is Dying
Anything that you would Like to See improved particularly?cliftmaples wrote: ↑Thu Sep 12, 2019 1:52 am 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.
We have prebuild sdk packages Form windows, including different language bindings. So i cannot agree Here.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.
-
- Halfling
- Posts: 73
- Joined: Tue Jun 14, 2016 12:26 pm
- x 19
Re: Why ORGE is Dying
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.
P.S. Also, it's OGRE, not ORGE.
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.cliftmaples wrote: ↑Thu Sep 12, 2019 1:52 am Most people, myself included, who want to explore a game engine and who work full time have very limited time
P.S. Also, it's OGRE, not ORGE.
-
- Gnoblar
- Posts: 16
- Joined: Mon Jun 03, 2019 2:45 pm
- x 19
Re: Why ORGE is Dying
man, i just love this topic....couldn't resist replying....
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...
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
frankly saying- your'e not OGRE's target audience, to be honest ogre will fail you in all aspects the aspects you've mentionedcliftmaples wrote: ↑Thu Sep 12, 2019 1:52 am 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.
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...
well my friend, no pain no gain...cliftmaples wrote: ↑Thu Sep 12, 2019 1:52 am 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...
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
-
- Hobgoblin
- Posts: 583
- Joined: Mon Aug 06, 2007 12:53 pm
- Location: Saarland, Germany
- x 50
Re: Why ORGE is Dying
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!
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!
http://www.lukas-kalinowski.com/Homepage/?page_id=1631
Please support Second Earth Technic Base built of Lego bricks for Lego ideas: https://ideas.lego.com/projects/81b9bd1 ... b97b79be62
- mkultra333
- Gold Sponsor
- Posts: 1894
- Joined: Sun Mar 08, 2009 5:25 am
- x 114
Re: Why ORGE is Dying
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.
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.
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.
-
- OGRE Team Member
- Posts: 1994
- Joined: Sun Mar 30, 2014 2:51 pm
- x 1074
- Contact:
Re: Why ORGE is Dying
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 wrote: ↑Fri Sep 13, 2019 7:22 am 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.
- mkultra333
- Gold Sponsor
- Posts: 1894
- Joined: Sun Mar 08, 2009 5:25 am
- x 114
Re: Why ORGE is Dying
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.
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.
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.
- mkultra333
- Gold Sponsor
- Posts: 1894
- Joined: Sun Mar 08, 2009 5:25 am
- x 114
Re: Why ORGE is Dying
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
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
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.
-
- OGRE Team Member
- Posts: 1994
- Joined: Sun Mar 30, 2014 2:51 pm
- x 1074
- Contact:
Re: Why ORGE is Dying
I mainly have this sample in mind:mkultra333 wrote: ↑Sat Sep 14, 2019 3:37 am 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.
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.
Custom visualization solutions e.g. this is ogremkultra333 wrote: ↑Sat Sep 14, 2019 3:37 am 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?
https://plantium.com/productos/displays/1/sbox11
or this:
https://apps.apple.com/app/id1294681561
- mkultra333
- Gold Sponsor
- Posts: 1894
- Joined: Sun Mar 08, 2009 5:25 am
- x 114
Re: Why ORGE is Dying
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.
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.
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.
-
- OGRE Team Member
- Posts: 1994
- Joined: Sun Mar 30, 2014 2:51 pm
- x 1074
- Contact:
Re: Why ORGE is Dying
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.mkultra333 wrote: ↑Sun Sep 15, 2019 4:02 am 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.
But I would argue that even farm machinery apps look better with real time shadows and advanced global illumination
if the goal is to render something reliably instead of writing a renderer, they should be using Ogre though.mkultra333 wrote: ↑Sun Sep 15, 2019 4:02 am 9 out of 10 people who need something like that may as well just use OpenGl or the like directly, and probably do.
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.
-
- Halfling
- Posts: 73
- Joined: Tue Jun 14, 2016 12:26 pm
- x 19
Re: Why ORGE is Dying
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.
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
- Gold Sponsor
- Posts: 1894
- Joined: Sun Mar 08, 2009 5:25 am
- x 114
Re: Why OGRE is Dying
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.
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.
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.
- dark_sylinc
- OGRE Team Member
- Posts: 5296
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1278
- Contact:
Re: Why OGRE is Dying
I'll go off topic a bit.
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.
5ms is too little. Sounds fishy.mkultra333 wrote: ↑Mon Sep 16, 2019 3:46 am 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!)
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
- Gold Sponsor
- Posts: 1894
- Joined: Sun Mar 08, 2009 5:25 am
- x 114
Re: Why OGRE is Dying
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.
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.
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.
- luis
- Greenskin
- Posts: 122
- Joined: Tue Mar 02, 2004 3:33 pm
- Location: Spain / Argentina
- x 7
- Contact:
Re: Why OGRE is Dying
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.
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.
-
- OGRE Team Member
- Posts: 1994
- Joined: Sun Mar 30, 2014 2:51 pm
- x 1074
- Contact:
Re: Why OGRE is Dying
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
- Greenskin
- Posts: 122
- Joined: Tue Mar 02, 2004 3:33 pm
- Location: Spain / Argentina
- x 7
- Contact:
Re: Why OGRE is Dying
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.
Shrinking user-base is the real problem with open source projects.paroj wrote: ↑Wed Sep 18, 2019 11:04 pm 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.
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
-
- OGRE Team Member
- Posts: 1994
- Joined: Sun Mar 30, 2014 2:51 pm
- x 1074
- Contact:
Re: Why OGRE is Dying
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
-
- OGRE Team Member
- Posts: 1994
- Joined: Sun Mar 30, 2014 2:51 pm
- x 1074
- Contact:
Re: Why OGRE is Dying
I could track down some of the shadow issues to using the legacy tex2D intrinsic functions. Including this "porting" header:luis wrote: ↑Thu Sep 19, 2019 11:54 am 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
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
- Greenskin
- Posts: 122
- Joined: Tue Mar 02, 2004 3:33 pm
- Location: Spain / Argentina
- x 7
- Contact:
Re: Why OGRE is Dying
Thank you! I'll take a look at new v1.12.2paroj wrote: ↑Mon Sep 23, 2019 11:49 pm 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
-
- OGRE Team Member
- Posts: 1994
- Joined: Sun Mar 30, 2014 2:51 pm
- x 1074
- Contact:
Re: Why OGRE is Dying
Rather Go with master. I pushed some d3d11 Terrain fixes thereluis wrote: ↑Tue Sep 24, 2019 8:41 pmThank you! I'll take a look at new v1.12.2paroj wrote: ↑Mon Sep 23, 2019 11:49 pm 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