[Solved] shader error on Android(Oculus Quest) build

[Snail921]

Hi,

I started getting errors on compiling the project for Oculus Quest.
Here is the errors:

1. Shader error in 'Obi/Particles': invalid subscript '_ShadowCoord' at line 92 (on gles3)
   
   Compiling Vertex program with DIRECTIONAL SHADOWS_SHADOWMASK LIGHTPROBE_SH
   Platform defines: UNITY_NO_DXT5nm UNITY_NO_RGBM UNITY_ENABLE_REFLECTION_BUFFERS UNITY_FRAMEBUFFER_FETCH_AVAILABLE UNITY_NO_CUBEMAP_ARRAY UNITY_NO_SCREENSPACE_SHADOWS UNITY_PBS_USE_BRDF2 SHADER_API_MOBILE UNITY_HARDWARE_TIER2 UNITY_LIGHTMAP_DLDR_ENCODING
   
   
   
2. Error building Player: Shader error in 'Obi/Particles': invalid subscript '_ShadowCoord' at line 92 (on gles3)
   
   Compiling Vertex program with DIRECTIONAL SHADOWS_SHADOWMASK LIGHTPROBE_SH
   Platform defines: UNITY_NO_DXT5nm UNITY_NO_RGBM UNITY_ENABLE_REFLECTION_BUFFERS UNITY_FRAMEBUFFER_FETCH_AVAILABLE UNITY_NO_CUBEMAP_ARRAY UNITY_NO_SCREENSPACE_SHADOWS UNITY_PBS_USE_BRDF2 SHADER_API_MOBILE UNITY_HARDWARE_TIER2 UNITY_LIGHTMAP_DLDR_ENCODING
   

I did not get any errors before and have no idea why the project starts throwing errors.
Could you please give me a solution for this?

Unity 2019.3.2f1
Obi Cloth 5.2

[josemendez]

Hi,

This looks like a regression of a very old issue:
(http://obi.virtualmethodstudio.com/forum...=Kumaresan)

The gist of the issue is that when using certain lightning modes that make use of light maps, the particle shader should not be compiled (as particles cannot be lightmapped).
Line 21 of ParticleShader.shader should read:
#pragma multi_compile_fwdbase nolightmap

Can you check it just in case you updated from an old version?

Edit: also try adding noshadowmask to the pragma directive, just in case. It *should* be included by nolightmap if Unity's docs are correct, but adding it can't hurt.

[Snail921]

Thank you for the advice.
Indeed, the package was new from 5.2 and not updated from any older version.

The line #21 was correct and by adding noshadowmask removed particle shader compile error while causing other compile error from another shader not from your package.
I have no knowledge about shader programming but these behavior of Unity looks very strange.
By checking GL ES3.1, the all issues are gone. I did this without any clear idea but anyway ES3.1 and noshadowmask pragima did work well indeed.

Do you have any idea what is going on about this?

[josemendez]

Thank you for the advice.
Indeed, the package was new from 5.2 and not updated from any older version.

The line #21 was correct and by adding noshadowmask removed particle shader compile error while causing other compile error from another shader not from your package.
I have no knowledge about shader programming but these behavior of Unity looks very strange.
By checking GL ES3.1, the all issues are gone. I did this without any clear idea but anyway ES3.1 and noshadowmask pragima did work well indeed.

Do you have any idea what is going on about this?

Unity's shader macros are a huge mess that conditionally compile out certain chunks depending on many factors (platform used, pipeline used, lightning settings, graphics API used, and a few others). Given that they must support many different capabilities in many different platforms/environments, this is not surprising (I'm not blaming them).

Our debug particle shader uses their lightning macros to get light attenuation values. It very well might be that these macros are compiled out if certain specific features are not available in  a given API, so the _ShadowCoord variable (which is used for sampling the shadow map to get light attenuation) might just disappear when using certain settings.

I was under the idea that light maps were the only thing that determined the availability of light attenuation macros, but this might have changed in recent versions   . I will check it out.

[Snail921]

Unity's shader macros are a huge mess that conditionally compile out certain chunks depending on many factors (platform used, pipeline used, lightning settings, graphics API used, and a few others). Given that they must support many different capabilities in many different platforms/environments, this is not surprising (I'm not blaming them).

Our debug particle shader uses their lightning macros to get light attenuation values. It very well might be that these macros are compiled out if certain specific features are not available in  a given API, so the _ShadowCoord variable (which is used for sampling the shadow map to get light attenuation) might just disappear when using certain settings.

I was under the idea that light maps were the only thing that determined the availability of light attenuation macros, but this might have changed in recent versions   . I will check it out.

I really appreciate your detailed explanation. I think I am able to understand the situation.
Thank you.