Change is coming

To quote the boss man : “What artgolf1000 writes is very true. Urho is mature in the sense that it has its way of doing things, and also quality / ease-of-use expectations are fairly high due to its history, which makes changing it in a large way challenging or undesirable. This is kind of unfortunate for its continued development.”

Boss man also indicated to me that I was free to tear up and rebuild anything that stood in my way.
I do hope the machine does not stand against progress.

The more I work with Urho, the more small corners I see that could use polish, I am yet to meet a single frost giant. But change is inevitable.


Only change I really care to see is a Vulkan rendering back end. Maybe see the EASTL fork go core, but that’s not really a huge deal. But if the rendering back ends can’t keep up with progress, Urho3D will die.

Edit: Also, the editor is a frequent pain point. The rbfx fork might be a good draw of inspiration here. Honestly, if rbfx hadn’t dropped Lua and AngelScript in favor of C# scripting, I would probably consider moving to that fork. But they did drop them, so… alas. Still, might be worth seeing if the editor work could be brought back here.


Vulkan support is coming - it has to.
I expect no end to this game of playing catch up with the latest rendering api.

I feel your pain regarding C# - can we get our grubby hands on an older version of rbfx and refork from there?

Urho is exceptionally well-written, in terms of code quality, compared to many engines I have worked with. Most of the codebase is well-reasoned and well tested, but there are many areas in the engine where improvements can be made. There is also a lot of resistance to change, which is natural for two reasons.

Firstly, we’re all hard-wired to fear and resist change when we are already in the comfort zone.
Secondly, change creates work… if I make a little change in the Urho source, it could mean making changes to a bunch of dependent samples, and it can break projects outside of that arena.

The fluttering of the wings of a butterfly can cause a tsunami on the other side of the world.

This is all true, but it’s still no excuse for complacency, when we know we can do better.

Yes, as in nature, if you are alive, you can be in one of three states - growing, stagnating, or decaying. Which state best represents Urho right now?

Despite the common anxiety about Urho going beyond undead I would like to note there still seems to be a steady stream of new people coming to the forums and an increasing amount of discussions on engine development happening lately. But that could just be spring. :slight_smile:

1 Like

You cant, because removing AS/lua was pretty much first thing i did :trolleybus:

1 Like

I’d better fork the engine as it is because it’ll get nasty from here on. Seems everyone wants to rip it apart and put a little bit of themselves in there.


Not if I can help it :wink: however, I don’t want to hold it back too. We can get dev branch for free in GitHub.

From what I read around the Net, Vulkan would not make all that much difference to performance in most cases unless the entire engine is multi-threaded which allows you to send render commands from multiple threads.

What I think would make a significant difference to the engine presentability is a more modern lighting solution with Global Illumination and a good SSAO shader.

1 Like

I know the feeling but I’m comforted by the knowledge that there seems to be a sense of direction. This is a prerequisite for things to go somewhere. When the directions fail to align this commonly results in mitosis (not cell death).

Multi-threading support is only one of the advantages of Vulkan, but not only. There’re also decreased driver overhead and the lack of the context-switch architecture (if you want to dig deep you can achieve the similar performance with advanced OpenGL techniques know as zero-driver-overhead). And you are right that non of this matters if engine itself couldn’t reach its own potential even without this modern graphics stuff.

tl;dr A careful selection of choices and directions must be made in order to avoid the common pitfalls for a game engine in this state .

I’m ok with change. And as long as there is one direction (not the band). However, I have a feeling there will be (is?) more than one direction going on, and it will end up a freak-show. Basically a Frankenstein engine with bits from all over the places that tries to cover just about everything under the sun to satisfy everyone but failing to do what it was actually meant to do.

But those are just my thoughts. I’m quite curious how it’ll actually end up.

I don’t think i have enough fingers for every engine where the author retired and everyone began to volunteer and start working on new features and exciting new stuff. However, by the end of it all that remained was an engine without purpose and features no one cared about or maintained or sometimes even completed. At which point you could label it yet another game engine that no one cares.

Like I said. I’m ok with change. But change(s?) without purpose or direction for the sake of not looking stagnant will not yield a favorable result.

My problem with game engines nowadays (at least most of them) is that they focus too much on the graphics side. I mean, is that all a game is about? Looking good?

When you actually begin to do the logic of said games you soon realize you entered a nightmare. A clusterf* of nonsense that can’t be evolved beyond a Hello World project. Basically, they lack the tools to build the logic of your game and aid you in getting a prototype without a ton of work.

How come no one here is offering to improve the GUI? Add better components. Everything boils down to graphics. Might as well just call it a rendering engine.

Which is why no successful game has ever use an open source engine. There are a few exceptions, I know. But they are too few for the plethora of games and free open source game engines out there.

I honestly have no right to complain about any of these. I don’t contribute much. I play with ideas from time to time as a hobby. And what I’ve mentioned are basically observations I’ve made in time (my opinions).


For me it comes down to this:

Urho3D is a free lightweight, cross-platform 2D and 3D game engine implemented in C++ and released under the MIT license.

When I read that line for the first time I knew I had found what I was looking for. That is what defines Urho3D, in my view. Meaning any decisions clearly diverging from that definition should be implemented as forks or extensions. The lightweight part can be somewhat hard to define. But to me it means anything too specialized should not be a part of the core repo. This should not stop the community from creating, indexing and co-developing awesome extras which would otherwise clutter core development.

@S.L.C Indeed, the industry tends to use industry standards or in-house/project-specific engines. Do id Tech engines count as open source game engines in your view? And I don’t think that many other engines out there match the exact definition mentioned earlier.

1 Like

Concerning forks I’d furthermore like to cite the Urho scriptures…


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

…and concerning commercial forks…

Evil shark
Eat my heart
So if I die I may respawn


:rofl: Nice and to the point.

In terms of fulfilling it’s scope of “lightweight all purpose engine”, I think Urho is quite complete and usable. The GUI is quite decent and usable, in what way should be improved? Also what better components could be added? You can always improve on things for sure (I’m thinking physics), but what we have is reasonably functional.

To me, the only area in which Urho is falling a bit behind the rest of the engine world is on the graphics side, so that should be the focus of improvements. I definitely agree that a good graphics does not equate a good game, however when you try to go commercial, you find that people do judge a book by its cover and a game by its graphics, so the game needs to look presentable, and having primitive lighting starts to get noticeable.

Not everything boils down to graphics.
There’s a lot of stuff missing from Urho - today I found that DecalSet has no AutoRemove implemented. Recently, I found that btPairCachingGhostShape is not supported. Also today, I found that the number of Collision Mask bits in the Editor is not sufficient for me (I have about 12 of the available 16 bits defined, while the editor provides eight checkboxes for eight bits). These are just a few small examples off the top of my head, but not a day goes by that I don’t notice something else.

Without suggesting that we should be adding new components at all, there is a lot of small things that can and should be addressed, and in most cases are unlikely to break existing code.


Those kinds of issues, though, won’t ‘kill’ the engine. A couple tiny pull requests will fix them, and users of Urho3D in the past have usually been pretty good about finding and fixing such things. However, eventually graphics backend stagnation will kill it. See Apple’s push to deprecate OpenGL. Eventually, the engine has to follow where the standards go, and right now Urho3D is already behind (no D3D12 support, no Metal support, no Vulkan support). It’s not critical yet, but there should be a plan in place to address it. From what I understand, this will be a pretty challenging task. I would take it on, but it is quite outside of my area of expertise.

I did implement Vulkan & Metal backends .
Most of it is working very well (you can try it ).
There are still some issues that need to be fixed , like shadow support and some memory issues .
I don’t have time now to continue working on it , I might continue working on it in a few months.
You are right , this is a challenging task and requires vast knowledge on SDL2, Urho3D , Angle , Vulkan , Metal.


Rendering tech is within my scope - I can certainly help with transition between rendering api, but right now I have no urgent need for widespread rendering support, so it’s not on my priority list.

1 Like

Please try to find some time to continue your work - Apple pulling OpenGL support sort of increases the pressure to add vulkan support.