GI was just an example. But sure, you might get some submissions for all of that stuff. From where I sit, the 5 greatest pinch points for Urho3D are:
Backend stuff, like renderers for new architectures like Vulkan and Metal. Apple got the ball rolling on deprecating OpenGL, Microsoft is always progressing their own architecture, things are always rolling forward and without someone to write backends for the new architectures, Urho3D is inevitably going to fall behind. Additionally, without someone to prune the cruft, the engine is going to be hampered by having to support ancient architectures. For example, the D3D9 backend is quickly approaching its expiration date, and already leads to branching in HLSL shader versioning. Which leads me to…
Shaders. Urho3D really needs a unified shader system. I’ve seen plenty of tech demos that are D3D11 only, or GL only, etc… writing ‘bulletproof’ shaders workable on all platforms for a given tech is a hard and (most importantly) boring problem. It’s boilerplate, it’s tedious, it’s prone to errors. Shaders written in HLSL require conditional includes depending on if they are for D3D9 or D3D11. GL shaders require differentiating between GL and GL ES. If shaders could be unified into a single common syntax and structure, to be compiled invisibly (to the user) to whatever the backend requires, that would solve a lot of the roadblocks to introducing new tech.
Scripting. I love Lua, but I still feel like it was a bit of a mistake to introduce Lua, at least without implementing some sort of language-neutral script binding system. Introducing tech to the engine requires the same kind of redundant boilerplate as shader code: having to implement the tech in C++ as well as provide bindings for both AngelScript and Lua. Anything less than full support for all 3 codepaths risks having the tech rejected in pull requests, yet having to support all 3 codepaths is unnecessarily burdensome to the implementer. Allowing tech into the base without full script support risks rendering the script systems useless and broken.
The Editor. I only typically use it for UI stuff, but in the age of Unity, having an editor is probably a necessity. Unless Urho’s editor gets some badly-needed TLC, it is quickly going to become a liability rather than an asset. Ideally, of course (as has been discussed before) the editor should probably be rewritten in C++ so that it is usable in builds without enabled script support. (FWIW, I tend to prefer editors that are more closely tailored to specific games, rather than general-purpose editors. For example, I’ve repurposed my terrain editor to create hex-tile levels for my game, Goblinson Crusoe, something that would be quite difficult to do with the Urho3D editor.)
Build system. What we have works, and works pretty well considering the relative complexity of supporting so many environments. But it definitely has its drawbacks, and I think that new project launching and minimal application scaffolding could use some love as well.
A case could be made for including UI as a 6th point, but I personally don’t find the UI system to be too onerous, all things considered.
Unless these 5 issues are seen to, I don’t know that Urho3D has a very rosy future. And unless we can attract talented developers to contribute to these 4, then they’ll continue to be sticking points.
I think what Urho3D needs most is evangelization. It’s a solid library. I’ve introduced many people to it over the years, and most of them have loved it. It has always baffled me as to why it isn’t more popular and well-known than it is, given its strengths. @cadaver, @weitjong, and everyone else have given us a pretty cool engine, now we just need to sell the shit out of it so that we can keep it alive and help it to grow.