Use high precision in generated ESSL

[kwokcb]

Change

• Specify highp to use 32-bit precision with ESSL

Fixes: #2655, #2654.

Details

High Precision Change

The minimum ESSL version required is 3.0 , where highp precision is mandatory in fragment shaders, so the switch is safe.
Instead of IEEE 754 half‑precision (16‑bit) we now use single‑precision (32‑bit). This avoids cases of underflow/overflow and reduces accumulated math errors (for Std surface, OpenPBR and glTF).

Results

I have pushed locally to: https://kwokcb.github.io/MaterialX/

Viewer on Samsung	Viewer on Desktop

Specific testing for specular roughness shows that this is now working:

Viewer on Samsung	Test
	Metalness up and specular roughness to 0
	Same test glTF
	Same test OpenPBR
	Same test USDPreview

[jstone-lucasfilm]

@kwokcb I think you're right on the mark with your change from mediump to highp in ESSL, which aligns with modern expectation in ESSL 3.0, and I'd have no objections to merging that part of your proposal.

I'm less convinced by the universal raising of M_FLOAT_EPS from 1e-8 to 1e-4, which would affect all of our Fresnel and energy compensation computations at grazing angles, in addition to the roughness clamping that originally motivated this adjustment.

What are your thoughts on the earlier suggestion to provide a shader generator option for MIN_SAFE_ALPHA? That still seems like a safer approach to me, if it addresses the roughness errors that you're seeing on Android platforms.

[kwokcb]

The issue with the approach is that there is no way to detect when your generating the code where it's going to be deployed to, and I'm not sure if these are the only places that can be affected.

So I propose to either:

1. Just remove this second change or

2. Add in this:

#ifdef GL_ES
   #ifdef GL_FRAGMENT_PRECISION_HIGH
       #define MX_FLOAT_EPS 1e-8
   #else
      #define MX_FLOAT_EPS 1e-4
  #endif
#else
   #define M_FLOAT_EPS 1e-8
#endif

This would not affect any device which guarantees highp (like iOS), but also
provides a safe-guard for Android variants.

I can remove the second change and see how it goes. If it's still not good, I can put up a separate PR for a better tolerance approach, or add 2. into this PR if your okay with it. How does that sound ?

[kwokcb]

The latest deployment seems good with just the highp fix. Added new snapshot which explicitly tests specular roughness value issue.

[jstone-lucasfilm]

Thanks for this improvement, @kwokcb!