To rbfx and not to rbfx

Hi everyone.

In this topic I want to discuss fork of Urho3D known as rbfx and possible feature merge from rbfx back into original Urho3D. This topic is not a proposal or announcement but the opening of discussion.
I really don’t believe rbfx and vanilla can be merged completely, but I’d like to bring them as close as possible.

In case you have no idea what I’m talking about, here is the link to rbfx:

Initially rbfx was quite close to original Urho3D (I will call it vanilla from now on) in terms of codebase and feature set.

However, the divergence grows as time goes on.

And this divergence becomes really annoying for users of both projects.

I cannot make wide-scope changes in rbfx because it will make things even worse than they are now. I cannot merge my changes into vanilla because it would require tedious rework of codebase. Users of both projects cannot simply switch back and forth because API is already incompatible to a certain degree: it’s nearly impossible to write code working both on vanilla and rbfx.

Oh, I hate forks soo much. And I don’t want to repeat the story of Atomic.

What does rbfx offer and why bother?

There are several major and multiple minor features, including native Editor (WIP), automatic C# bindings, built-in lightmapper that you all have probably seen, universal user-friendly serialization from/to binary/XML/JSON instead of this terrible (and sometimes broken) x6 copy-paste in vanilla Urho, profiler, type-safe logging and string formatting using fmt, subdirectory support by build system and so on and so on.

I’m planning to do some major renderer changes too, but I won’t make any promises here.

What’s the problem with “just merging” everything back into vanilla Urho?

Short story: there are breaking changes. A lot. And a lot of dependencies between features too.

So it’s actually impossible to merge rbfx into vanilla “by bits”: it’s a package deal, and the package is huge.

  1. The broadest (in terms or API affected) breaking change is using EASTL standard library instead of custom Urho containers. Yeah, Urho containers may have some nice features, but they are sorely lacking compared to EASTL or STL libraries. I personally switched to rbfx just because it’s so much easier to write code with standard containers. Maybe in the future it would even be possible to take the next step and switch to STL completely.

    This change is mandatory to merge anything else from rbfx into vanilla Urho. It will also require certain rework in script bindings. Lua would probably be easy to fix because it has compile-time type checks. AS would be more painful. Speaking of which…

  2. The biggest (in terms of functionality) breaking change in rbfx: AngelScript is gone. Forever.

    You see, AS is assembly library. Just think about it. Urho is using raw assembly right now in 2020. Not just for optimization, but as scripting core. AS has zero compile-time type safety, so if you make a mistake or forget to update some manually written binding code, you will get real-time crash, or UB, or data corruption, or anything. Manual and fragile bindings to AS greatly decrease code maintainability.

    Consequently, vanilla Urho Editor is gone. Yeah, writing Editor basing on AS scripting sample was a mistake. It’s sad because vanilla Editor is quite nice and has a lot of features. But it is really hard to extend due to poor architecture and using AS bindings instead of propper C++.

    Theoretically, it’s possible to merge stuff from rbfx and keep AS and vanilla Editor. However, I’m not going to do anything for it – neither to fix conflicts on merge nor support manual bindings, ever. Feel free to volunteer for this task.

So, what do you think?
Is it worth a shot, or I want too much?
Is it better to try to bring rbfx and Urho closer or let them diverge forever, essentially becoming separate projects?
It’s not too late yet, but every major update in rbfx will make things more complicated than they are now.

Here are some polls.

About possible merge

  • [against] I’m fine with current state of Urho (stagnation) and I don’t care about any changes;
  • [against] I want changes in Urho but I don’t want to merge anything from rbfx;
  • [tentative] I want to get breaking changes from rbfx as long as Urho doesn’t suffer any feature cut;
  • [supportive] I want to get breaking changes from rbfx and I’m ready for a reasonable feature cut (e.g. removing AS);
  • [supportive] I’m already using rbfx and I want to get code merged back into Urho;
  • [skip] I don’t care
  • [impossible] I want to get changes from rbfx as long as it doesn’t break any API

0 voters

And about AngelScript specifically (assuming that you will get native Editor as replacement):

  • I don’t care about AS;
  • I’d like to have AS but I can deal with its removal;
  • I need AS support and I’m ready to maintain it;
  • I need AS support and I don’t want to do anything to maintain it;

0 voters

Damn, I’ve spent hours writing this chunk of text. Please don’t ignore it. Thanks.
I’m summoning here all ppl I can think of.

@rku, @weitjong, @Modanung, @Miegamicis, @JTippetts, @JTippetts1 (I have no idea who is real you), @boberfly, @Dave82, @Lumak… And I hit the limit of mentions, sorry if you aren’t listed here. I’d summon @cadaver too, but I don’t think he have strong opinion on the subject.


As long as that C# filth stays far away…


Here are my 2 cents of this proposal.

It was actually one of my plans to get some parts of the rbfx back to the Urho. It has a lot of nice features that Urho lacks. It’s sad seeing AS go, but I guess it’s the right thing to do.

I know there are a lot of guys out there who don’t want to see the C# support in it, but I guess it’s fine as long as it’s a optional dependency and by default the engine is built without it. (note: I’m not too excited about it either)

1 Like

I have so far been completely unbothered by the presence of the C# stuff. Was skeptical at first, but it really is separate.

I believe this would be a foot in the door of a slippery slope to soullessness.



1 Like

@rku Or people could be pointed to rbfx for that. I believe this is exactly the dispute that inspired you to fork Urho in the first place, correct?
Most other effort stuck into rbfx could have been applied to Urho3D.

Fish Executioner

Flash of the knife, on top of a pizza box
Divide the fish into two
Eyes and mouth slowly open and close
Even after the mutilation

Unceremoniously into trash
But the spirit remains to haunt
Fear for the day when it returns from the dead
And traps you into a net

Two fish halves on top of a pizza box
Motion not yet ending
Electric impulses or proof of afterlife?
Never know for sure

Fish Executioner!
Death to be done on this blasphemous day
Fish Executioner!
Face of the dead fish will never go away

1 Like

It’s actually a technical question, we can’t make our decision based on our emotions or religious beliefs. Nothing is decided yet, we as a comunity have to agree what’s best for the engine.


In regards to removing AngelScript, is C# a usable replacement if the only use was in a handful of scripted components and plugin type things called from within C++ code, or does the C# code have to be the main application?
Is there a way to do something like CallCSharpFunction("doStuff(int)", 42) and get the result?

1 Like

Hello, this is my first time using the forum although I have been using Urho3D for about 2 or 3 years now.

I would like to say that I think that this proposal is a very radical change.

Although I have seen rbfx mentioned before on the forum, I never took a close look at it until now.
And seeing C# and that WYSIWYG editor that looks like Unity sent shivers down my spine.

I fear that bringing C# to Urho3D will turn this into a nightmare, and, in time, will root itself permanently into the core of the engine.
Given how traumatic apparently merging the changes from rbfx to Urho3d will be, I am afraid that that will almost certainly be the case.

To be quite honest, I would like to see even AngelScript and Lua completely removed from the engine.
C/C++ is not that hard and it tends to force the developer to know what he is doing and to program properly and efficiently.

In my opinion, bringing C# and WYSIWYG to Urho3D is steering the ship on the very opposite direction of what Urho3D is now.

I only ask that if this goes forward, please, announce it early so those that don’t like this direction can have time to fork Urho3D or move to some other engine or library.


I don’t like AS because it has no IDE or real useful debugger which supports urho. I don’t see scripting is useful in a serious project without IDE support. I don’t like C# because it is heavy and pain to maintain? Though its IDE and stuff would be much better.

Urho’s container is good IMO, light weight as Urho itself. Not as powful, but easy to read and use. Just like Urho. Why we like Urho, because it is simple and nice. Otherwise I would just use UE4, Unity or Godot.

The worst thing about Urho is Editor and workflow. IMHO, rbfx is better in some aspects is because the brave author has been really working hard on it.

If Urho also has a IMGUI based editor, people would be much optimistic.

1 Like

C# bit uses sort of a “hack” where main exe is .NET. This is so we can support multiple runtimes without writing code to host managed runtime. This is just a detail though. You can write most of your code in a .dll. Editor is a good example of large native application that gets loaded as a DLL. You do not even notice that it isnt a native exe.

CallCSharpFunction bit is possible (terms and conditions apply!), but someone needs to write it.

You do not have to use it as it is optional.

@adhoc99 Hear hear and welcome to the forums! :confetti_ball: :slightly_smiling_face:

1 Like

Why is merging rbfx stuff back into Urho necessary? They’re essentially different engines, with different goals. If people like rbfx, why not continue using it and supporting it?


It is not necessary. It is just merely an offer to progress the project.

“There are several major and multiple minor features, including native Editor (WIP), automatic C# bindings, built-in lightmapper that you all have probably seen, universal user-friendly serialization from/to binary/XML/JSON instead of this terrible (and sometimes broken) x6 copy-paste in vanilla Urho, profiler, type-safe logging and string formatting using fmt , subdirectory support by build system and so on and so on.”

I’m using my phone to type. To me, many of the features seems can be implemented without breaking the vinila and some are still optional.

This is quite funny to read about “bringing WYSIWYG to Urho3D” because vanilla Urho Editor is the stereotypical example of WYSIWYG editor.

How on Earth can it happen if is impossible to even build C# in some supported configurations?

Unusual point of view. I wouldn’t say Urho containers are easy to use. They have maybe 5% of EASTL functionality and I had to write several times more code with Urho containers.
And this is after all the time we (me including) spent on improving these containers.

When two engines share 95% of codebase, I cannot really call them “different”.

Because it is a waste of manpower to split efforts on two projects when same effort can be spent on one.

It is possible to merge these features without breaking vanilla, true.
If someone is ready to do tedious manual merge every time either rbfx or Urho3D are updated.
Who is going to do that?

So, you’re basically saying that you want Urho3D to be rbfx.


I basically said the opposite in the very first paragraph of this topic.

1 Like

I won’t miss rbfx since we have urho. Is it because of the underlying container change which makes feature merge difficult? Brave move for rbfx at the first place. I respect the author but dislike the change of stl introduction based on the destroy.

1 Like