Do not deprecate "Programmable Shaders" component - michaliskambi/x3d-tests GitHub Wiki

I was thinking about the notion to deprecate X3D "Programmable Shaders" component, that was made at one Web3d teleconference.

In short, I believe we should not deprecate this component. It's not a perfect component (due to shader code not being easily compatible with all X3D browsers), but it is incredibly useful, so it should stay.

1. We are using it in Castle Game Engine, and in various games using CGE:

   • Some people use X3D standard nodes: https://castle-engine.io/x3d_implementation_shaders.php

   • I recommend people to use CGE "compositing shaders" extensions (Effect node etc.), which are based on X3D standard nodes: https://castle-engine.io/compositing_shaders.php

   • For screen effects, we also allow to assign shaders, this allows to place ComposedShader within ScreenEffect node: https://castle-engine.io/x3d_extensions_screen_effects.php

   So, not only people use X3D "Programmable Shaders" component, it is also the basis for other useful work.

2. I looked at glTF, and it has, as an extension, a way to use shaders too:

   https://github.com/KhronosGroup/glTF/tree/master/extensions/2.0/Khronos/KHR_techniques_webgl

   This confirms that there are usecases for it.

   Note: glTF solved the problem with uniforms by requiring a declaration that specifies "semantics" of uniforms, this way you can say that "this matrix uniform should contain modelview matrix". This approach is transferable to X3D... but would require some work. (And input from browser implementors.-- the glTF extension specifically targets only GLSL in WebGL, while X3D is more portable, targeting GLSL, HLSL, Cg, and our GLSL is not necessarily WebGL -- it also fits OpenGL and OpenGL ES. While the differences are small, they do matter for the people that want to write direct shader code.)

3. I would say: leave in the specification, with a clear note in spec that

""" Warning: Perfect compatibility of the shader code between all X3D browsers is not possible. Although everything defined in the X3D specification of this component should be implemented the same way by all browsers (that support appropriate component). But there are some details that we intentionally leave undefined in this specification, as defining them would constrain the possible implementations too much.

In particular,

• Various browsers may pass information to shaders through different means. E.g. uniform variable names may have different names, or different types, or different precision between browsers. The way material, textures and light parameters are passed may differ. (E.g. they may be passes as structures, or as a number of separate uniform variables.) Moreover, some browsers may perform (some subset of) animation using shaders. When you write custom shaders, you need to account for these details yourself, otherwise various 3D features (like transformation, lighting, texturing, fog, clipping planes....) may not work as expected.

• Various browsers may require a specific version of the shading language. E.g. OpenGL Shading Language has a couple of versions, and various X3D browsers may impose various limits on the GLSL version used. (These limits come from the implementation details -- which version of OpenGL, OpenGLES or WebGL is used for rendering. These details in turn depend on the platforms supported by the browser.)

Refer to the documentation of your X3D browser for details about these issues. """