BGFX Makes It Easy Targeting Multiple Rendering APIs

[phoronix]

Phoronix: BGFX Makes It Easy Targeting Multiple Rendering APIs

BGFX is a cross-platform rendering library that makes it easy targeting multiple versions of OpenGL and Direct3D on platforms ranging from Apple iOS to Windows to Google Native Client...

http://www.phoronix.com/vr.php?view=MTU0NTQ

[scionicspectre]

Sweet- wouldn't this be similar to the same kind of technology as SDL? Or perhaps even more simple, since it focuses mainly on graphics? I'd like to see what kinds of engines could plug into this, since it could be useful for game developers if it's so flexible.

[newwen]

This is a little bit lower level than SDL, SFML and other toolkits. It's a very thin layer over Direct3D and OpenGL with minimal overhead so there is no need for graphics engines to deal with them directly. Ogre3D and similar graphics engines which are dealing with multiple D3D and OGL backends might benefit from this.

Doesn't Valve also use a thin layer like this in their Source Engine?

[mdias]

..It's a very thin layer over Direct3D and OpenGL with minimal overhead so there is no need for graphics engines to deal with them directly. Ogre3D and similar graphics engines which are dealing with multiple D3D and OGL backends might benefit from this.

It's not that thin of a layer, considering they their own shading language, sort drawing calls, do font rendering and have their own geometry file format.
Ogre already have their own abstraction layer of the rendering API adapter to their specific needs, and since bgfx is not that thin, I doubt it will be useful to them.

I never read much into Valve's approach, but it sounds like a custom implementation of the Direct3D device interface class. I could be wrong though...

[zester]

It's not that thin of a layer, considering they their own shading language, sort drawing calls, do font rendering and have their own geometry file format.
Ogre already have their own abstraction layer of the rendering API adapter to their specific needs, and since bgfx is not that thin, I doubt it will be useful to them.

I never read much into Valve's approach, but it sounds like a custom implementation of the Direct3D device interface class. I could be wrong though...

Looks like a great library except that it's using stb_image, and to quote the Musl Wiki http://wiki.musl-libc.org/wiki/Alternative_libraries

beware of stb* from nothings.org since author is ignorant about invoking UB

[bkaradzic]

Hi thanks for posting about bgfx here.

So just to clarify things, bgfx is higher level than GL/DX renderers (it's not thin wrapper around API, it doesn't try to mimic GL nor DX behavior at all), and it's lower level than common 3D engines like Ogre3D. bgfx doesn't deal with scene at all, whatever is submitted to bgfx it will be rendered. But unlike GL/DX bgfx before submittion will sort draw order and optimize to minimize state changes. Sorting allows also submission to be more optimal, since order of submission is not preserved, it's possible to submit object for multiple passes at the same time. For example if you pass over scene with GL/DX you would need to submit in order of rendering, which means you have to pass over scene multiple times in order to submit in the right order, which is usually expensive. With bgfx higher level code can traverse scene once, and submit for all passes at once, then internally bgfx sorts these draw calls and they get properly rendered.

stb_* stuff is optional, and it's there for mostly tools and examples. It's not used in runtime. bgfx natively can process only DDS, PVR or KTX texture. Runtime code is located inside include/ and src/ (+ glext headers from 3rdparty).

bgfx is similar to SDL, since it tries to simplifies cross-platform development. But it's focused to graphics part only and it can work with SDL, GLFW, and similar windowing APIs. I provide some basic windowing harness for examples (to minimize external dependencies), but that can be replaced with SDL, GLFW, etc.

[zester]

Hi thanks for posting about bgfx here.

So just to clarify things, bgfx is higher level than GL/DX renderers (it's not thin wrapper around API, it doesn't try to mimic GL nor DX behavior at all), and it's lower level than common 3D engines like Ogre3D. bgfx doesn't deal with scene at all, whatever is submitted to bgfx it will be rendered. But unlike GL/DX bgfx before submittion will sort draw order and optimize to minimize state changes. Sorting allows also submission to be more optimal, since order of submission is not preserved, it's possible to submit object for multiple passes at the same time. For example if you pass over scene with GL/DX you would need to submit in order of rendering, which means you have to pass over scene multiple times in order to submit in the right order, which is usually expensive. With bgfx higher level code can traverse scene once, and submit for all passes at once, then internally bgfx sorts these draw calls and they get properly rendered.

stb_* stuff is optional, and it's there for mostly tools and examples. It's not used in runtime. bgfx natively can process only DDS, PVR or KTX texture. Runtime code is located inside include/ and src/ (+ glext headers from 3rdparty).

bgfx is similar to SDL, since it tries to simplifies cross-platform development. But it's focused to graphics part only and it can work with SDL, GLFW, and similar windowing APIs. I provide some basic windowing harness for examples (to minimize external dependencies), but that can be replaced with SDL, GLFW, etc.

Is Mesa's OpenVG and Nvidia Path Rendering something you would be willing to consider including at some point?

Also I see ...

OpenGL 3.1
OpenGL ES 3

Isn't OpenGL ES 3 something you get for free via OpenGL 4.3, just wondering why there is OpenGL ES 3 support and not OpenGL 4.3+ support.

[bkaradzic]

Is Mesa's OpenVG and Nvidia Path Rendering something you would be willing to consider including at some point?

I haven't consider that at all. But I might port something like nanovg (https://github.com/memononen/nanovg) to bgfx API.

Isn't OpenGL ES 3 something you get for free via OpenGL 4.3, just wondering why there is OpenGL ES 3 support and not OpenGL 4.3+ support.

I'm using feature set I support for API versioning. There are no GL4 features in bgfx yet, and GL4 is not much different API to be listed there separately (like DX11). Once there is feature that can't be listed under lower version GL (for example compute shaders) I'll update supported GL version.

[zester]

I haven't consider that at all. But I might port something like nanovg (https://github.com/memononen/nanovg) to bgfx API.

Cool thanks for sharing the link I wasn't aware of that library.

I'm using feature set I support for API versioning. There are no GL4 features in bgfx yet, and GL4 is not much different API to be listed there separately (like DX11). Once there is feature that can't be listed under lower version GL (for example compute shaders) I'll update supported GL version.

Ok I was just wonder, It seamed strange that there was OpenGL ES 3 support but not OpenGL 4.3 as OpenGL 4.3 provides full compatibility with OpenGL ES 3.0