Reviewing the Ogre OpenGL RenderSystem in Tundra.

[Jukka Jylänki]

Hi,

today got a short break from the usual work items, and had time to do
some reviewing of a rather old issue of why Ogre rendering performance is
not exactly what we'd expect. Instead of writing a wall of text here, I
put up the report on the github issue tracker:
https://github.com/realXtend/naali/issues/440

For tl;dr:

Ogre looks like this:
http://dl.dropbox.com/u/40949268/Ogre/OpenGLRenderSystem.png
It should look like this:
http://dl.dropbox.com/u/40949268/Asteroids/GLStateChanges.png

Big problems:
- legacy OpenGL 2, not modern OpenGL 3 or newer.
- naive, and does a lot of redundant work.
- dumb, and does not do tricks to optimize rendering objects which share
state.

Possible future strategies:
- rewrite Ogre OpenGL rendersystem.
- new Ogre GLES 2 rendersystem is the hope?
- scrap Ogre.

jj

[Lord]

Ogre 1.8.0 finally came out May 26th, 2012

[Jukka Jylänki]

Tundra (ogre-safe-nocrashes, https://bitbucket.org/clb/ogre-safe-nocrashes
) was migrated to use Ogre 1.8.0 last Friday. Currently we are testing to
detect if there are any regressions.

jj

[Lord]

How is the testing working out ? Did OGRE 1.8.0 work better ?

 

[Peter C.]

The new roadmap for Ogre 1.9 and 2.0 was just proposed:
http://www.ogre3d.org/forums/viewtopic.php?f=4&t=70522

At least a few of these changes could have some pretty big impacts on improving performance.

[Jonne Nauha]

Thanks for the link Peter. It's actually amazingly fitting roadmap for us. Seems that Ogre is focusing on all the right things, the same things we have issues with it!

• OpenGL 3 and DX 10/11 render systems. Modern rendering plugins that we have been missing a bit.
• Mobile platforms: this is good in general, as we want to focus on some sort of mobile support in our roadmap too... (and good for my Android thingie https://github.com/Adminotech/tundra-android :).
• State cache for rendering. I think this was one big problem when Jukka analyzed the current rendersystems. They made large amounts of unneeded state changes, which makes Ogre slow.
• SceneManager redesign. This might impact us most if they do big changes to SceneNodes there. But in principal it sounds great to make SceneNodes lighter in mem and faster to use. I cant recall us having direct issue with this but hey, optimize away ogre devs :)
• Rework multithreading support: Oh yes please. My biggest issue with Ogre personally is (prolly as i wrote the thin layer in tundra to support threaded loading) threaded loading blocking our main loop. There are several things that do this, as Jukka noticed once he got to profiling the situation. Jukka also removed some of the mutexes in the threaded loading path inside our Ogre fork to ease the loading a bit. But it still has some lag in textures at least, depends on the resolution etc. Anyways, reading the forums for this subject is seems other people have issues with this also. Now they are addressing it, hopefully they do a good job so our avatar can fly full speed, load ogre assets around it asynchronously and our fps not dropping ;)

I'm amped! Of we have to remember they have ~6-12 months release cycle. Like we saw with 1.8 it was delayed quite heavily. That's ok, we delay releases too and stuff, that happens in open source. I'm sure most (or all) of the Ogre devs don't get paid anything. So we will just be thankful and wait. One thing we could also do is help, Ludo has talented guys for this 3D engine stuff, and we already have a fork to do work to upstream. Maybe if we (not admino, the project in general) get some rex money at some point we can allocate some to helping Ogre get forward, just an idea.

Best regards,
Jonne Nauha
Adminotech developer

--
http://groups.google.com/group/realxtend-dev
http://wiki.realxtend.org
http://dev.realxtend.org

[Jonne Nauha]

Lord: Jukka has merged 1.8 final to our ogre. I dont think there was anything special we really gained from it. At least concerning the rendering performance. The 1.8 ogre will be in the next rex release and has been in couple of the latest Admino releases already.

[Jacob Moen]

Since I found this from a Google search, I just want to add that - in preparation for the 1.9 release - the Ogre developers are concentrating on OpenGL3, and that should be what you want from Ogre.

I think it will be out in a couple of weeks.

Of course, I have an interest in seeing ogre-safe-no-crashes being brought up to date with current Ogre (which is going to be 1.9 soon) because it could be useful for Ogitor (Ogre scene editor). :)

[Peter C.]

I agree with the sentiment that ogre 1.9 should be used in the next big version. 1.9 has a lot of nice new stuff besides just gl3 support. I should also note that in the next version or two, it would be prudent to consider enabling double precision in both bullet and ogre. That's for another ticket however.

--
Sent from Kaiten Mail. Please excuse my brevity.

[Lasse Öörni]

On Friday, April 5, 2013 11:51:56 AM UTC+3, Jacob Moen wrote:

Since I found this from a Google search, I just want to add that - in preparation for the 1.9 release - the Ogre developers are concentrating on OpenGL3, and that should be what you want from Ogre.

I think it will be out in a couple of weeks.

Of course, I have an interest in seeing ogre-safe-no-crashes being brought up to date with current Ogre (which is going to be 1.9 soon) because it could be useful for Ogitor (Ogre scene editor). :)

Once 1.9 is officially out, it is worthwhile to bring ogre-safe-nocrashes up to speed with it, time permitting.

Due to compatibility reasons it might not be feasible to require GL3 in Tundra.

In any case, the performance problems in Ogre are spread-out and a lot of it has to do with how the scene manager interacts with the rendersystem, plus how it does the actual scene update and culling process, and I doubt any dramatic improvements will happen.

- Lasse

[Peter C.]

The 2.0 redesign is supposed to fix a lot of the performance problems, but that will likely be a year or two away before it's back to feature parity with 1.9. Gl3 shouldn't be required in my opinion, but should be optional. It's also worth noting that 1.9 has at least some of gl4 support.