GLES2 support for shadow mapping shaders

[AbduSharif]

Minetest version:

5.5.0 dev - db17c22 (Shadows PR artifact signed)

OS / Hardware:

Operating system: Android 10 arm64, but I'm using armv7 apk
CPU: MediaTek Helio G80
GPU model: Mali-G52 MC2
OpenGL version: OpenGL ES 3.2

Summary:

Shadows don't work on android, if I switch to ogles2 then enable shaders and shadows, then open a world; the game will be black.
If I close the game and then re-open it, it will crash.

Steps to reproduce:

• Go to All Settings, then Graphics.
• Go to In-Game, choose Advanced, then change the Video driver to ogles2.
• Get back to enable Shaders, then Shadows.
• Open a world, and among other errors there's this:

ERROR[Main]: Error compiling shadow mapping shader.

[AbduSharif]

Why was the crash report mention removed? (Is it because it's not useful?)

[AbduSharif]

Also I'm not sure how this is a feature request? Isn't the shadows option obviously buggy on GLES2? So maybe disable it on GLES2 to prevent users from breaking their game? (At least until it's supported or something).

[sfan5]

(Is it because it's not useful?)

Yep.

Also I'm not sure how this is a feature request?

Saying "shadows do not function on GLES2" is no different from a request to make them work.
The menu option is a different story and we will be doing that either way depending on the state they're in just before 5.5.0 is released.

[AbduSharif]

Saying "shadows do not function on GLES2" is no different from a request to make them work.

That actually depends on who says it and their intentions, I never thought you guys might be able to support shadows for GLES2 in the first place (with all that amount of errors I've seen in-game), so the summary and the steps to reproduce pointed out to issues.

Eitherway good luck getting the shadows on GLES2 working if you guys are willing to, if I see some PRs for that I'll try to help in testing them.

How do you get Minetest reports to show where it crashed at rather than just symbols? were the artifacts not set to debuggable or something? I think making a custom build (with all the debugging help) might help in getting what that crash report was about, I'll try my hand at that.

[x2048]

Due to limitations in OpenGL ES 2.0, implementing shadow mapping for this platform will require significant effort, beyond fixing shader compilation errors. It looks like there is little interest in this functionality overall, so I suggest documenting that dynamic shadows do not work on OpenGL ES 2.0 hardware and optionally disabling configuration in the UI.

[AbduSharif]

"It looks like there is little interest in this functionality overall"

I wonder where this is coming from? Not even release versions have this feature, and it's pretty closed off.

(It not working on GLES2 doesn't help in measuring either).

[x2048]

I wonder where this is coming from?

This feature request has no reactions (compare to 11547 and 11366), and Discord community has not shown interest to far.

[AbduSharif]

Those aren't good basis for an assumption.

As I said:
"Not even release versions have this feature, and it's pretty closed off.

(It not working on GLES2 doesn't help in measuring either)."

Are you guys even sure you have that many Android debug build testers? I know the majority use release builds which don't have the feature yet.
(I myself used a build artifact which I had to sign with an app to test the feature, as I don't have a PC where I live right now).

If you want to measure interest in something you need a proper working version of it in the first place.

[x2048]

It looks like there is little interest in this functionality overall

Those aren't good basis for an assumption

I might not have expressed myself correctly or clear enough. Porting shadow mapping to GLES2 is difficult, and in order to even start doing that I need some indication of interest in the community. Quick comparison to other feature requests did not play in favor of this feature and a ping in Discord has resulted in only your response. Even if, supposedly, we have a large Android user base, not many of them are active participants of Minetest community, otherwise I would expect a different reaction.

If you still think that dynamic shadows on GLES systems are an absolute must in the nearest future, I'd suggest reaching out to community to find more voices in support of the feature.

That said, I have already spent some time poking around, and some work is captured in shadows_gles2 branch in my repository. It did not work for me on a Raspberry Pi, but it may work for you on an Android.

[AbduSharif]

Here this shows how large the base is for Android players (if you had any doubts):
https://play.google.com/store/apps/details?id=net.minetest.minetest

I'm not sure why you're suggesting to me to find more voices in support of the feature, since you already think not many of the Android player base are active participants in the community.

How much voices do you need until it's actually reconsidered for you though?

In any case here I made a forum post if you want to follow it:
https://forum.minetest.net/viewtopic.php?p=410799#p410799

About the test branch:
It isn't successful because there are more errors:
https://github.com/x2048/minetest/tree/shadows_gles2

I'm only getting this for now:

ERROR[Main]: Irrlicht: 0:175: L0001: Expected identifier, found '['
ERROR[Main]: generate_shader(): failed to generate "nodes_shader", addHighLevelShaderMaterial failed.

Also this comment here by sfan5 on the first dynamic shadows PR is maybe of help here:

#11244 (comment)

[Extex101]

I'm not able to get to a computer a lot of the time, so my main platform for Minetest is on Android. So if you need voices to advocate for Android I and a few of my friends all use Android.

[x2048]

@AbduSharif Can you try to disable Poisson filter?

I'll check whether I pushed all the changes to the branch later.

[AbduSharif]

Okay, will try it.

[AbduSharif]

So I no longer see an error with that option disabled, but I don't see any shadows either.

Probably what sfan5 mentioned in his comment here what could be remaining (although I'm no developer of course):
#11244 (comment)

[x2048]

I've already made the changes mentioned by sfan5, syntax is not the problem now, it's the (lack of) support for texture formats with the right precisions. Redoing SM for textures supported on GLES2 is essentially starting almost from scratch, and it took a year to do SM in the first place.

My hope right now is that we can find some GLES2 hardware that has the right extensions to support what's needed without drastic changes.

Can you also try with 16bit shadow textures on a very low preset?

[AbduSharif]

I did try that but no shadows.

Can you specify what the texture format extension you're talking about is?
This website will show how many GPUs/devices have a certain extension:
https://opengles.gpuinfo.org/listextensions.php

[x2048]

@AbduSharif The extension is OES_texture_float, but judging from what Godot implemented and what you and I observe, it does not work with render buffers, and GLES2 does not allow reading from the depth buffer. As a result shadow must be decomposed into 4 byte components in a GLES2-compatible texture format.

This change of texture format will require compatibility changes to the shaders and is not compatible with the incremental shadow rendering, so that will need to be redone for GLES2.

[oong819]

what about ogles 3? i think its will be easier

[x2048]

We don't have a dedicated driver for it, so it will have to run through the prism of gles2 plus extensions.

[numberZero]

Doing it for GLES2 doesn’t worth the effort IMO. Any device powerful enough for dynamic shadows should support GLES3. Using that is not a short way either, adding GLES3 support to the unified driver should be easy but it can only run on SDL currently, and Android/SDL is only planned (minetest/irrlicht#175; although I had a working PoC somewhere, it’s not that hard actually) — but it is the right way.