Noob here, looking to contribute

I recently start fiddling with Urho3D looking in into its code. I would like to contribute something useful in Urho3D specially in Graphics. What I believe, Urho3D does not have Vulkan/Metal support and I think it would be good opportunity for me to learn and contribute here. Although I had found on forum that there is support available for angle–>vulkan–>moltenvk, which I guess would be performance killer.
What is your thought on this, or what are other items you can suggest?


These are complex topics that require lots of experience. Such first task would definitely be overwhelming and demotivating. Start small. Walk before you fly.


The issues on GitHub might provide some inspiration for things to work on:

Or maybe you could run by some existing pull requests?

What experience do you have with graphics pipelines?

1 Like

thanks to @kakashidinho and @elix22 the port works fine. Surprising, it is quite fast.
Hence, the only possible improvement would be a direct, unencumbered Metal port.
But that would require a mastership in shading, beyond in-deep Urho3d knowledge…

Just to gain, then, some relative feature beyond opengles2… it’s a lot of work for a couple of systems, ios and mac, whose games comes, for the former, mainly in 2d format, and, for the latter, mainly in poor shape, being mac os the worst video game platform you can find.

And, of course, you need to have a Mac…

1 Like

You are right its complex and I am also new to Urho3D. So I am learning it by going through available samples first later will focus on Vulkan port.

Ok. So it seems metal port won’t be that useful. So I guess Vulkan port would be more useful as its available on Windows, Android and Linux platforms.


If you want to add vulkan/metal renderer I think the whole rendering subsystem code needs to be refactored to incorporate “manually batching commands in a command buffer” style of vulkan/metal. The current subsystem of urho3d uses immediate style of dx11 and opengl.
Implementing vulkan in such a way that it adapts to existing immediate style will defeat the performance advantages of vulkan. It might be even slower than dx/gl renderer.
I might be wrong thought. That’s being said, I am also planning to add metal renderer to urho3d.


Great to hear that you are planning to add metal renderer. You may be right about performance but my first aim is to have a working vulkan sample with Urho3d, later will look at performance and refactoring, meanwhile if you have a plan idea or design I would like to have a look at that so we can align these two efforts.

1 Like

Actually, I don’t have any concrete idea yet. Currently I’m just looking at the existing renderers & shaders code to see what is the most feasible & elegant way to add metal. You are right that initially the performance might not be a concern yet, so direct vulkan implementation of Graphics subsystem could be the first step.
anw, the metal renderer addition might not be a trivial task after all. The existing HLSL & GLSL shader code are huge and there are many ifdef macros lurking around.
Nevertheless, adding metal/vulkan and refactoring could make the graphics subsystem more modern and open doors for more modern rendering technique to urho3d.

1 Like

Just my 2 cents
Your current Angle-Metal implementation works great ,
All samples work perfectly well on all the devices I tested (except the 42_PBRMaterials, which is understandable )
It even outperformed vanilla GLES2 on some devices ,

I am not trying to discourage you :slight_smile:
As you said writing a pure Vulkan & Metal solution for Urho3D would be a huge effort, I am sure you have the knowledge to tackle it however it will require an additional substantial amount of people with vast knowledge on this topic which I am afraid are currently not part of this community .

I’m just saying a possibility. It might not happen or not very soon. I concur that the addition of metal could be huge and tedious change. Not to mention it could just be a close replicate of what Angle-metal has done initially.
Actually, I’m thinking of adding Forward+ rendering mode to Urho3d (well it might not be important for some, but could be a fun thing to do). But it requires compute shader. Angle-metal will not support compute at current stage. Nevertheless, I think i will start with dx11 and opengl compute shader addition to urho3d first. Though opengl on mac doesn’t have compute shader capability.
The alternative way to add compute shader to mac is using angle-metal and and adding compute shader to it in a non-OpenGL-specification conformant way. I’m not sure it is an ugly design or not.

1 Like

I strongly recommend against poking at adding a Vulkan backend unless you’ve implemented several before.

Vulkan makes a lot of restrictions on what you can do while a render-pass is in-flight which won’t go well for the way Urho3D handles the RenderPaths.

I use a similar system in my own renderer and it required an additional stage abstraction in order to force restraints regarding rather basic things like clearing buffers and there’s tons of vkCommandBuffer queuing going on before they finally get submitted.

All despite using V-EZ. With raw Vulkan it would’ve been so much much worse.

The GLSL shaders in Urho3D aren’t written with Vulkan in mind either. You’ll have to rewrite them. If your shaders run in GL3.3 then they definitely don’t run in Vulkan. Glorious set-space hell.

A reasonable (but still bonkers) contribution would be setting up the build scripts (or even an external project) to build the tools necessary to cross-compile HLSL -> GLSL / ESSL / Metal (maybe ShaderConductor, maybe something else). That’s very viable and although still a lot of work you could start seeing the results fairly quickly (in days possibly) even though the task as a whole is very long (weeks to months).

If you aren’t focused on Graphics then there’s tons of things you could look at. Even alternative backends could be worthwhile like an FMODStudio backend choice for Audio. AMD’s new FemFX could be interesting too.

1 Like

I understand your concern, but isn’t it a chicken and egg problem? Before having worked on several one has to begin first.
I had seen other implementation where CommanBuffer like abstraction are in use for GL and DX backends as well, but before making any such decision I want to have one sample working with vulkan first. Possibly it may need a re-write to fit everything to gather but lets consider it later.

So, I guess there is an elegant solution already exist and I am familiar with. Angle shader translator works fairly well to translate shader source from one version to another and one language to another.

I had several years of experience in graphics but noob to Urho3d and want to utilize that, so I will focus on graphics only for now.

1 Like

@shiv a better way for me to put is that I suspect that “if you had to ask then you can’t”. Most that could wouldn’t bother asking, if you’re not one of them then go ahead.

So, I guess there is an elegant solution already exist and I am familiar with. Angle shader translator works fairly well to translate shader source from one version to another and one language to another.

No, Angle is not good. It’s ESSL -> others. Can you even build it on Windows without Cygwin? Google loves Cygwin and it’s not an acceptable dependency. Ignoring that ESSL is a joke language targeting platforms few can actually afford to target beyond toy projects.

MS ShaderConductor is a much better base. I know for a fact that it works as I use it to compile HLSL -> ESSL for GLES3, GLSL for GL3.3, GLSL for 4.3, and SPIR-V for Vulkan.

1 Like

Yes, but you should do several isolated Vulkan renderer’s first. The code I github-gist’ed was my 5th Vulkan renderer and it is still freaking terrible despite using V-EZ.

There’s no good in having new blood nuke itself.

I don’t agree but it’s ok to assume that.

I was talking about “ANGLE’s Shader translator” only (which is one module in ANGLE), which is very powerful tool to translate shaders across multiple languages and versions. It is being used as shader validator/translator in chrome/firefox and other popularly used software. Also, ANGLE is no more a toy, its being used by QT, chrome, Firefox (Webgl on most of Windows is powered by it) and list may go on. And yes of course you can build ANGLE without cygwin. MS ShaderConductor might be good option too btw it’s new kid in town.

1 Like

7 posts were split to a new topic: Social hygienics

angle can be built on windows without cygwin. I contributed to angle project before. I mostly worked on metal backend implementation and used to test the vulkan backend on windows as reference but not much, so the windows situations might be changed from time to time that I’m not aware of.

Regarding the offline cross-compiler solution. The problem with urho3d shaders is that they contain too many #ifdef. So one glsl/hlsl shader code would be translated into multiple variations in spirv depending on preprocessor definitions (doesn’t matter what cross-compiler used). I think the tedious part is knowing all needed variations beforehand in order to generate them.
If the vulkan renderer was to be implemented, a runtime hlsl-spirv translator could be an easier and less tedious choice. Since all needed variations will be known at runtime.

Anw, these are just my thoughts. You may have a better idea. Metal renderer (if it would ever be implemented) could benefit from an offline shader converter also, to reduce runtime shader loading/converting.

1 Like

Right , Angle compiles fine on Windows without cygwin .
One can always try my Urho3D-Angle-Vulkan implementation on Windows
git clone -b angle-vulkan
cmake_vs2017_vulkan.bat - will create an Visual Studio project using Angle on top of a Vulkan backend

1 Like

Do you do Windows? If so, you could do DX12 instead. Vulkan will never matter to Windows, there’s no argument for it. Whether you wished to work on DX12, Vulkan, or Metal, any of them will be “big heavy change” to Urho3D’s method of operation. Any solution would ultimately be common to all 3. Windows cares about DX12. Apple cares about Metal. Only Linux cares about Vulkan, there’s no other motive. Well honestly I don’t know what Android cares about.

Anyways, platform war. You didn’t specify one. You don’t have to solve all of them or engage in perceived portability. Nobody cares about Vulkan except platforms where it will actually be used. So if you happen to like Windows more than I would guess from your 1st post, thought I’d sanity check this.

What you can accomplish, is up to your skill. Big project to do any of these. Do 1. Let someone else do others, if you even get so far as to do 1.