NeoSpark314
commented
5 years ago I tried the attached reproducer and the problem is clearly visible on the quest while it does not occur on desktop:
I used renderdoc to inspect the created shader and it seems to be a floating point precision problem: In the final fragment shader there is at the top a
#if defined(USE_HIGHP_PRECISION)
precision highp float;
precision highp int;
#else
precision mediump float;
precision mediump int;
#endifbut USE_HIGHP_PRECISION is not defined. So the default precision for computations is mediump.
The computation from the shader graph later looks like this.
{
vec3 m_n_out7p0;
m_n_out7p0 = vec3(uv_interp, 0.0);
float m_n_out2p0;
m_n_out2p0 = time;
float m_n_in5p1 = 0.3;
float m_n_out5p0;
m_n_out5p0 = (m_n_out2p0 * m_n_in5p1);
float m_n_in4p2 = 0.0;
vec3 m_n_out4p0;
m_n_out4p0 = vec3(m_n_out5p0, m_n_out5p0, m_n_in4p2);
vec3 m_n_out6p0;
m_n_out6p0 = (m_n_out7p0 + m_n_out4p0);
vec3 m_n_out3p0;
float m_n_out3p1;
vec4 m_tex_frg_3_read = texture2D(m_tex_frg_3, m_n_out6p0.xy);
m_n_out3p0 = m_tex_frg_3_read.rgb;
m_n_out3p1 = m_tex_frg_3_read.a;
albedo = m_n_out3p0;
}even though the time variable is defined as uniform highp float time; the actual computation is done in mediump!
Querying the precision on the oculus quest using glGetShaderPrecisionFormat gives
V GodotOVRMobile: Fragment Shader Precision: LOW [15, 15] 10
V GodotOVRMobile: Fragment Shader Precision: MED [15, 15] 10
V GodotOVRMobile: Fragment Shader Precision: HIGH [127, 127] 23so all computations are done with 10bit mantissa.
Looking into the godot code the only place where USE_HIGHP_PRECISION is defined for the shader seems to be in the JavaScript case:
https://github.com/godotengine/godot/blob/ac38f0782fbf781265ec34a43196e3ea157f3696/drivers/gles2/shader_gles2.cpp#L180
Forcing this define to be always present by disabling the #ifdef JAVASCRIPT_ENABLED fixed the issue.
I don't know what the proper solution to this problem is. Two ideas from my side are
- Add an optional
highpmode for shader graph computations - Have a global flag in the mobile settings to push the high precision mode for all shaders
m4gr3d
akien-mga
fakedeltatime
Firepal
When using the Time input in a Visual Shader, then the quality of the change in the Time input as well as the quality of textures altered with it deteriorates, making the changes stutter and lowering the resolution of the textures. The project I've provided shows three cubes, two with the same noise texture the right of which has an animated shader using the Time input, and one with a cycling opacity. The quality of the latter two should deteriorate in under 60 seconds.
time_deterioration.zip