Ogre Forums

I've often read in the last time, that some of the OGRE users are using: BGFX https://github.com/bkaradzic/bgfx
I wounder if this could be used by OGRE itself as render back end, because it seems to be only a wrapper around OpenGL/DirectX?
Maybe with this lib some of the development work can be shifted. But maybe there are also some good reasons to not use it.

What do you think?

Nope.

BGFX is in the middle between OGRE and using an API directly. It is much more of a competitor, really.

BGFX selects APIs at compile time, while Ogre does this at run time. That difference alone would mean a significant change in Ogre's source code (I prefer compile time selection though).

Also this endeavour (adopting bgfx as backend) could potentially break our traditional materials.
Furthermore bgfx renders via a Command Buffer; which can conflict with Ogre 2.1 which implements its own Command Buffer as well.

Another problem is that bgfx is preserving compatibility with DX9 and GL 2.x; which we've dropped in Ogre 2.1 in order to get a lot of freedom for certain techniques and achieve the level of performance we are currently getting in the latest version in the repository.

I recommend you try the latest 2.1 version from our repo and drop by over the +2.0 forum (link to nice post) to see where the engine is heading.

Same here.

I wanted to my engine support both BGFX and Ogre 2.1 but seems they can get complicated when is about materials and other things. Also BGFX has his flaws too, from his github page, they can't support Fullscreen and some other crucial features, but the engine calls me the attention by the Compute Shader demo and the Weighted, Blended Order-Independent Transparency demo, but who needs it when you have an engine which your PBS materials looks almost exactly the Marmoset Toolbag 2 renders?.

(Another feature-overkill will be OGRE has an modern Global Illumination technique like Voxel Cone Tracing, or similar, i'm pretty tired of open-source engine still using baked lightmaps of Quake 3/2, The Godot Engine, has an WIP GI. )

dark_sylinc wrote: BGFX selects APIs at compile time, while Ogre does this at run time. That difference alone would mean a significant change in Ogre's source code (I prefer compile time selection though).

It's interesting that you bring this up though. A bit off-topic, but who really needs run-time API choice ? I have a strong guess that the answer is no one.
Can we imagine a future where Ogre would slowly transition towards your preference ? I think we can argue that it's more than a preference, in the end it just makes more sense.
Is it possible that Ogre would lose some weight in the process ?

you are right, not even Fullscreen:

BGFX_RESET_FULLSCREEN` - Not supported yet.

Strange, that is an out of discussion must have feature...

N0vember wrote:It's interesting that you bring this up though. A bit off-topic, but who really needs run-time API choice ? I have a strong guess that the answer is no one.

Choosing between APIs is useful because often one RS provides better performance in one driver/vendor/card while another RS provides better performance for someone else.
However it is completely acceptable to provide two different builds (i.e. MyGameD3D11.exe and MyGameGL.exe) and select between them by a launcher that reads the saved config.

N0vember wrote:Can we imagine a future where Ogre would slowly transition towards your preference ? I think we can argue that it's more than a preference, in the end it just makes more sense.

This is already happening. But it's slowly getting there. The RS in particular is hard to change without breaking everything for everybody.

N0vember wrote:Is it possible that Ogre would lose some weight in the process ?

Yes. I'm aiming at making Ogre more light weight. Additionally making RS a compile-time decision can make interesting performance optimizations I can't do if it is runtime based; besides just dropping the virtual table pointers.

Choosing between APIs at runtime is useful historically mainly on Windows where DirectX could give a huge boost depending on the game, graphic card/driver etc. and typically all games provided a way to chose between the two.
That being said today disc memory is cheap so building both versions in two separate binaries could be a better solution.

I stopped bothering with this when I started focusing on OGL because cross platform and I don't want to manage two sets of shader code (whatever the way, with a shiny-like system or not).
So compile-time choice would be ok in my case too. I think there might be ways to do this with minimal change to the Ogre code (by adding a template constructor to Root to setup the specified type of renderer, and making the renderer library static), but exploiting compile-time choice of renderer type optimally is definitely non-trivial.

I've done my homework, and bgfx is the most promising piece of software I've found: very lightweight, low-level abstraction (including shader languages abstraction) and simply powerful.

I believe it should be considered as a serious option for Ogre, rather than a competitor.