Porting bgfx to Urho3D

Hi ,
I am thinking of porting bgfx to Urho3D as an extension or replacement of the existing rendering engine.
Is there currently any easy way of adapting third party rendering library in Urho3D, like passing geometry, lights, cameras ?
They have a long feature list that can even surpass Unreal Engine in some areas .

It as it has been used in a few mobile commercials games and they look quite good .




Look at how the existing Render subsystem is implemented. OGL, DX9, and DX11 all define their own Renderer subsystem that gets switched between at compile time. You could implement your bgfx renderer similarly.

Alternatively define your own bgfx subsystem, initialize the engine with no Renderer subsystem, and then wire everything appropriately.

Alternatively keep everything the same, but implement you bgfx subsystem that renders to a render texture. Then draw it similarly to the UI subsystem, on top of the existing Renderer, etc…

I can’t believe I haven’t heard of this before. :confused: It is very cool! I would like to see this be ported to the engine. If it is possible, I do wonder how it would perform in comparison to the subsystems already finished.

I debated whether or not to do this awhile ago. After the renderer refactor I don’t think it is really worth doing. For one, the bgfx-specific submission-based renderer where it sorts everything for you using hash keys would be doubling up the work Urho3D already does when arranging and sorting batches so you’d disable it like you would when drawing GUIs with bgfx. Unless you replace all of Urho3D::Graphics and how it submits calls to how bgfx expects and not just make a bgfx toggle next to DX9/11/GL. You’d also need to make yet another set of shaders for it, albeit ones which would work in both GL and DX.

Bgfx has the option to render in another thread so that’s something interesting to see if it would speed things up with Urho3D, but it might behave oddly with Urho3D’s threaded culling, but I’m just speculating. Also the planned DX12/Vulkan backends that Urho could support ‘for free’ once bgfx gets patched.

Urho would probably benefit more from just adding a compute shader abstraction like bgfx has to make it on-par with bgfx imo.

Funny story, the Dogbyte game was once using Horde3D that used some of my GL ES 2.0 porting efforts to render it, before they changed to bgfx… :smiley:

I’m not sure if bgfx handles well the large amount of shader permutations that Urho generates. If I understand right, you pass an “ubershader” similar to Urho’s shaders to its shader compiler, then it spits out the permutations as separate files. In Urho there may easily be thousands of permutations of a single shader, though most of them never get used, so it would rather need to be able to invoke the compiler at runtime on demand, or have the compiler built-in to the renderer. Also, it has a fixed drawcall limit per frame due to the drawcall sorting scheme. It was something quite high (32768?) but nevertheless it’s something I’d personally feel uneasy about.

Other than that, it’s your usual API agnostic low-level graphics solution, outside of the drawcall submission queue and the compute shader support the low-level operations are very similar to Urho’s existing graphics subsystem.

I have feeling that it might get slower than the native Urho3D rendering subsystem which kind of kills it for me. Also I think feature-wise Urho3d is not that far away. For something in the future if they support more Rendering APIs it might make more sense. I wonder how the guys from Dogbyte balanced the graphics so well on mobile.

Hi guys, I noticed traffic to my GItHub project is coming from here and joined forum to clarify a few things.

Default bgfx limit is 64K, but it’s configurable if you need more or less (if you want to save memory). Limits do exist on GPU, CPU, memory, etc. It’s not like renderer without explicit limit are just unbound and can do whatever, more likely limit is there you just don’t know what is it.

There is performance comparison with different renderers and platforms, see 17-drawstress table:

This test specifically stresses bgfx submission loop. There is num^3 cubes, updating their model matrix while trying to maintain 60Hz. You can try recreating similar example with Urho3D and comparing it with bgfx. Benefit of switching Urho3D to bgfx is that you have to stop worrying about renderer and focus on other things like user usability, editors, effects, etc.

Hi Branimir welcome to the forums! I’m that annoying guy who added the ‘Add Vulkan Support’ to bgfx’s issue tracker… :slight_smile:

We do have an object count stress test but it’s more or less mirroring the Ogre3D one:
github.com/urho3d/Urho3D/tree/m … bjectCount

Maybe one that copies bgfx could be made to see the differences like you said.



The object stress test in Urho tests also culling, light interactions, scene render queue management and automatic instancing, which the bgfx drawstress-test doesn’t. To perform a more equal test one needs to use the Urho Graphics class directly for the low-level interface, something like this (not exactly same, but it performs a number of drawcalls in different positions using the same state. The setting of the material color and viewproj matrix are actually redundant, when the shaders are kept same.)

    Model* mod = GetSubsystem<ResourceCache>()->GetResource<Model>("Models/Box.mdl");
    if (mod)
        ShaderVariation* noTextureVS = graphics_->GetShader(VS, "Basic");
        ShaderVariation* noTexturePS = graphics_->GetShader(PS, "Basic");

        int num = 200;

        for (int x = -num; x < num; ++x)
            for (int y = -num; y < num; ++y)
                Matrix3x4 pos(Vector3(x*0.007f, y*0.007f, 0.5f), Quaternion::IDENTITY, 0.005f);
                graphics_->SetShaders(noTextureVS, noTexturePS);
                graphics_->SetShaderParameter(VSP_VIEWPROJ, Matrix4::IDENTITY);
                graphics_->SetShaderParameter(PSP_MATDIFFCOLOR, Color::RED);
                graphics_->SetShaderParameter(VSP_MODEL, pos);

                mod->GetGeometry(0, 0)->Draw(graphics_);

I tested both drawstress & this code snippet, both using D3D9, and the performance figures were nearly equal. Which is as I suspected, as in the end both bgfx & Urho Graphics class will be talking to the graphics API using a minimal amount of API calls. This leads me to believe that migrating to bgfx would not offer either significantly worse or significantly better performance.

With @cadaver resigning maybe this matter is worth revisiting? Even if bgfx does not offer immediate performance gains it still provides free support for new rendering APIs, some of which we will definitely not see ever implemented in Urho3D as it is now. bgfx port (or even full migration) could relieve some maintenance stress.

Maybe. I heard about some problems with bgfx, but I’ve never tried it.

Could you elaborate? @bkaradzic is very helpful and they might just get addressed. Besides i would like to point out that i am willing to help too. As far as i am capable anyway.

My suggestion now is that you should have some kind of game plan how you’re going to benefit from it, and how you’re going to change the high-level rendering to accomodate. E.g. doing clustered forward lighting, using compute shaders? Otherwise it’s just a lot of work, and it’ll be hard to keep the existing featureset 100%.

Preferably you shouldn’t be compiling new shaders during runtime at all (ie. know all used permutations beforehand), but that’s kind of hard with the level of configurability the renderpath and materials / techniques offer.

However, I think you should be bold in taking Urho rendering to new directions, as if you ask enough users you will no doubt end up with an impossible featureset (e.g. function on low-end mobiles, keep all existing features…) At some point it may be better to just break compatibility majorly, if the benefits are clear enough.


There is already Urho3D to bgfx port going on here:

Need more info… :slight_smile:

Benefits of porting to bgfx are not just about high-level features. There is benefit of having identical feature set while using common shader language so that adding new, and maintaining existing features is not difficult. Also by just switching to bgfx, Urho3D will get new rendering backends, and that part of maintenance will be offloaded elsewhere.

I actually recommend first straight port to achieve 1:1 feature set, as if bgfx is just another rendering backend (next to existing ones) in Urho3D. Once that’s complete old rendering backends can be dropped, and all state tracking, sorting, and then in 2nd step other stuff that bgfx internally supports can be removed from higher level scene code in Urho3D. Once bgfx is fully integrated people should investigate about adding more advanced stuff.

The reason why I think it’s not good idea to start port + add bunch of new features is that engine might end up in rump state, where port is not fully functional, but new features are not completely added either. So in that state might not be appealing to anyone.

Anyhow if anyone is interested to help with this port just let join effort in that repo above.

Don’t do that porting inside the main Urho3D repo. If ported, Urho3D is no longer Urho3D. If this port is desirable, please do so in other repo, any other repo.

1 Like

That port is not in main repo, it’s done by someone from AtomicEngine community for their purpose (their focus is more shipping games than building an engine). As for Urho3D, it’s whatever Urho3D community wants. bgfx is intentionally designed as renderer-only in hope that not having other parts of engine will be more appealing for engine creators to use it. Idea was like people are using 3rdParty libs for physics, sound, navigation/AI, networking, windowing/input, etc. but there is nothing like that for rendering. From my point of view, Urho3D using bgfx or not, there is no change…

This is absurd and suggesting that is suggesting engine to stagnate because noone is going to write backend for dx12, noone is going to write backend for metal, noone is going to write backend for vulkan. Not to mention bgfx solving write-once shader problem…

IMHO, being done elsewhere first does not exclude us to pull the good bits in later, if the license permits it and if it turns out to be really that good where we may be decide to trade it off with Urho backward API compatibility. For one time we could be just the “recipient” of other people hard work and experiment. I have my doubt it will happen anytime soon though as it looks like the porting work has just began a few days ago.

This is not absurd and this is not suggesting engine to stagnate. keep Urho3D what makes it is Urh3D, then add to it, not try to make it another one. If dx12 is to be supported, do so in Urho3D’s style, If vulkan is to be supported, do so in Urho3D’s style. Do not drag it to another structure with other design desicions. This kind of backend should be carried out in other repo. What in Urho3D’s main repo, should be adapted to Urho3D first. Urho3D can bring over the good bits of course. But keep Urho3D what makes it Urho3D is essential.

BTW, If you are so eager to help Urho3D, why not begin to port useful rendering features from Atomic Engine to urho3D engine, instead of arguing about porting to a completely different rendering backend?