Support GLES3 in engine

I m add support for GLES3 rendering API and it features:

  • Instancing
  • Uniform buffer object
  • Multiple render targets
  • Texture2DArray
  • Texture3D
  • Support for textures: ETC2, sRGB, floating point, depth, 1 & 2 channel (R & R/G).
    Worked render pathes - Deferred, DeferredHWDepth, Prepass, PrepassHWDepth.

Sources -

For build set option URHO3D_GLES3=1
For CMake need -DURHO3D_GLES3=1, for Gradle /PURHO3D_GLES3=1.

Builded for Android (arm64, armv7a) -
Please test on some devices.

In the builded version, there are no Lua and Lua scripts, and in the example added 70 point lights and deferred render path used. Here is a screenshot from the phone - CPU MTK Helio P60, GPU - Mali G72 MP3.

After test I will PR it at main repo.


this is great! and I really like your launcher. the ui is a bit small, but still functional. (I had to use back softkey to exit console, touch wouldn’t register at the close button.)

are you planning to add an option for user data, like scripts/resources in /sdcard/urho3d/?

Launcher is not my work, it is stock Urho3D launcher. Later I will publish my own laucher, which I use for develop script games for Android.

There seems to be a problem with shadows.

I test on VinSmart Active 1+ ( CPU: Snapdragon 660, GPU: Adreno 512)

Yes, a strange picture.
On my device, it’s like that.

Now, for optimization on mobile devices, shadows from distant objects are not drawn.
And for some reason you have a character far from the camera, not like mine.
Can you take a screenshot with the HUD turned on?

1 Like


Confirm. On other my phone with Adreno same picture. I will investigate it.


I am not a very big specialist in OpenGL, so it took a couple of days to find the cause. As a result, it turned out that it was just necessary to set the GL_TEXTURE_COMPARE_MODE parameter to GL_COMPARE_REF_TO_TEXTURE for the shadowmap texture.

Now I corrected it, plus a few more edits - I activated the use of constant buffers in uniforms.glsl for tests, and corrected a few more minor errors. I’ll make a commit soon, but for now, using the same link, you can download a new build for testing.

Here I checked the shadows on Adreno:

… In Mali:

Even on the old weak Adreno 330, deferred rendering works (although not so fast, but for its power the scene is complicated)

In general, according to - OpenGL ES3.0-3.2 occupies about 80% of devices, it is strange that there is so little interest in adapting the engine for ES3. Using only ES2 now you will not achieve much on Android - there is no intansing, no ETC2 - the biggest problems.
I hope, with my improvements for ES3 and to improve interaction with Android (, the engine will be an excellent choice in the niche of creating Android games.


Yeah, this is great ^^

By the way, I noticed that in terms of instancing on GLES3 Urho3D works better than Unity. In particular, Unity disables the use of instancing when working in GLES3 on the weak models of Adreno (330 and others, with the GL ES 3.0 driver), while on Urho3D, the instancing on these GPUs works. This is due to the fact that Unity uses the uniforms array for instancing and fetching from it through gl_instanceID, which does not work correctly on these drivers. Urho3D uses vertex buffers with instanced attributes and glVertexAttribDivisor. They work correctly on these GPUs, and in addition, they allow transferring a much larger number of instances per draw call than when using uniforms arrays.


Since the majority of the mobile devices support GLES3, should we enable the GLES3 build option by default?

1 Like

Please read below ,

21.1% of the Android devices still support only GLES2
On some there is 3.x support but with some issues/bugs .
I think GLES2 should be the default configuration with the ability to enable GLES 3.x by using CC

1 Like

Just to clarify. I am not planning to remove that build option. The “URHO3D_GLES3” build option stays. What I have in mind is to set its default to true for Android and iOS/tvOS, but user can still opt to explicitly disable it to get GLES 2 instead. Something like this in CMake build script.

cmake_dependent_option (URHO3D_GLES3 "Use GLES 3 instead of GLES 2 (Android/RPI/ARM/iOS/tvOS platforms only); default to true for Android and iOS/tvOS" "ANDROID OR IOS OR TVOS" ARM FALSE)

The GLES days for iOS/tvOS should be numbered. So if we exclude these two platforms, we left with Android. If you guys think that for Android it should not be defaulted to true too then we could simplify the above script.

cmake_dependent_option (URHO3D_GLES3 "Use GLES 3 instead of GLES 2" FALSE ARM FALSE)
1 Like

My 2 cents ,
Currently the iOS/tvOS angle-metal-backend implementation is not part of Urho3D , hopefully that will change in the near future.
So for now the configuration should remain common to both Android , iOS/tvOS

What scholastic disputes do you have? Can you immediately name the game in the playmarket on the Urho3D engine? What about two? This is what should really serve as a sad subject for discussion, and not what option to default. Game developers will be able to solve this issue for themselves. But where are they? No matter how beautiful the engine is, but without the games made on it, the meaning disappears in it.
If there are no games, then it makes no difference whether the developers DO NOT make games on GLES2 or GLES3.

1 Like

I really don’t have any disputes with anyone .
I really would like this amazing game engine to prosper and still be relevant in the future .

I agree with you , there are not so much developers that are making games with this amazing engine .
Chicken and the egg problem :
Developers will not invest time in making games with a game engine that is rarely maintained.
Developers will not maintain an game engine that is rarely being used to develop games.

I think you made a great job with GLES3 .
With my limited resources I am trying to bring Metal to iOS/macOS .
Hopefully more developers will join in the future …

I don’t want to answer your other question here, but as for why I care for which options be made default matter for me because I am a CLI user. The default should be set to what makes the most sense. Whether the engine takes off or not, I do not really care much. If we do, we would probably stop long time ago.


The engine is being used a bit more than would be apparent looking at these forums or the contribution activity lately. I know personally of three potential commercial projects in the works (not mine), plus I know of a high school teacher who is using it to teach students. Please, you guys, don’t be discouraged by the seeming lack of interest. Urho3D is a project that has a great deal of merit and potential, and a larger audience than it seems, and it has really always been that way. Rest assured that everyone here is appreciated for their efforts by people, such as myself, who don’t necessarily have the time to contribute to the codebase or the forums that much anymore.


I worked on big commercial game that was built on urho3d fork. Game was GLES3 initially, but they insisted on implementing GLES2 support in order to expand possible audience. GLES may be a minority, but it is not insignificant minority yet. With that said - it probably does not matter which is default. GLES3 can be default if only to get more performant and prettier samples…

Edit: I should note that by saying big i meant size of the project, not necessarily it’s popularity.

Hi, I was started my GLES3-work based on your fork :slight_smile:
For me personally, the most important thing from GLES3 is the guaranteed instancing and ETC2 textures. In my game was up to 608 simultaneous objects of the same type in the frame, and in new version it there can be up to 860, and without instancing I had to go to different tricks in order to realize this. Although I also have to do this and with instancing :slight_smile:

1 Like