Bge + ogre

Can the BGE incorporate the OGRE render? What i mean is would it be faster with the Ogre?

Many years ago, there was a project that was started that would’ve replaced the BGE’s rasterizer with a new one based on the OGRE engine (was called project Echo), but it ultimately failed for various reasons.

Right now, it might seem more sensible to just extend the BGE’s existing GLSL capabilities because one of the original reasons for starting the integration project soon after the 2.40 release was because the BGE did not have pixel shading or shadows (which it now has). Kupoman has been in the midst of doing a complete rewrite of the BGE rendering core, but he doesn’t always have the time to develop on a consistent basis.

Ok, got it, but what if someone wants to change the rasterizer with Ogre, how much work will that be? I like the integration with ogre since it support android platform, dx11 and ogl3.
Just wondering will the bge be faster if it got separated from the blender? Isn’t the tight integration makes the bge slow?
I prefer c# over Lua.

would it be faster with the Ogre?

Are you having speed problems?
Are you sure it is the renderer?
Are you sure you aren’t being ridiculous? (eg having 75 lamps with shadows)

Don’t try to solve problems you aren’t having.

But would it be faster? Who knows? Quite honestly, I’ve never had issues with renderspeed on my laptop. (specs: 2.6hgz quad core, 8gb ram, Radeon 7670M. Pretty high spec, but nothing compared to gaming machines.)
Even on an old 1.6ghz single core laptop without a graphics card I got DEEP Space to run at 60fps (though not record video at that speed).

I’ve played around with replacing parts of the BGE with Ogre. However, before starting to attempt Ogre integration, we need to clean up various interfaces, which I’ve been slowly doing. I’m not looking at Ogre so much for speed/features/etc, but to have a larger chunk of the BGE being maintained by more developers. We have very few devs right now so the more we can delegate to other libraries, the better off we’ll be. Even if this means a slower engine (e.g., using some Blender code). We can always contribute “upstream” to speed things up if need be.

That being said, don’t expect any Ogre integration soon, or possibly ever (at least from me). My time is limited and this is just something I’ve been slowly poking at.

I’m not looking at Ogre so much for speed/features/etc, but to have a larger chunk of the BGE being maintained by more developers

Hmm, that’s an interesting idea. Use bullet for physics, ogre for graphics, and then all the BGE devs have to worry about is the interface between them and the logic/control of objects in game.
But aren’t there already some planned changes with the game engine planned for 2.7 and 2.8 versions? I’ve yet to find a clear roadmap for this. If anyone knows, please point me at it.

Thats nice to know. Im interested to know if the filters will be faster with ogre, last time i check, i get frame drop.

Pretty sure game engines work like this:

  1. Add an object: the framerate drops
  2. Add a texture: the framerate drops
  3. Add a shader: the framerate drops

Yeah, but still most engines give you good frame rate with filters -> bloom, hdr etc…

Ogre is a render engine, not a game engine. So, we’d only be replacing the drawing code. Every thing else such as the physics and logic would stay the same. Furthermore, the Ogre code would be sitting behind already existing interfaces, which means people would be interacting with Ogre the same way the are now (more or less).

As for other renderers, BI and Cycles are not designed for real-time use, they are offline renderers. The BGE and the viewport share shader code, but that’s about it. In general, the viewport code is much slower than the BGE.

Replacing the BGE’s renderer with Ogre = GameKit? (without logic bricks and Python->LUA)

Not quite. It’s still using the same gameloop and API, so most of the code remains the same.

Sent from my Nexus 5 using Tapatalk