LibGDX support GLSL shaders. GLSL is an standard language… ShaderToy scripts, while based in GLSL are not standard.
It looks like you can use ShaderToy scripts directly with other frameworks so am wondering what the difference is.
What do you mean directly? I have seen plugins for a couple engine that will allow you to paste ShaderToy scripts and use them as materials. Not what I would call “directly”, but it works most of the time. People also convert ShaderToy scripts to GLSL by hand.
It is worth noting that ShaderToy scripts closely resemble fragment shaders, and – unless the ShaderToy script uses some other features, such as input or sound – it takes little work to adapt them by hand to GLSL fragment shaders. If the script uses such features… well, though luck, because shaders are programs uploaded to the GPU, and thus are unable to take user input or play sound. Which means that a complete implementation of a ShaderToy script runtime in another engine is not a trivial task.
What work does it take to adapt it? As per the fragment shader, first ShaderToy has some built-in variables that you would have to pass as uniforms. And second you need to write a
main function that calls the
mainImage function from ShaderToy (or just paste the code from
main). If you want an output equal to the one you get in ShaderToy you will also have to setup an scene with a single quad that covers the view, and has the appropriate UV coordinates.
I want to make empahsis on that ShaderToy scripts are not standard. The function
mainImage is not standard. On the other hand,
main is part of the GLSL standard.
These are the input uniforms according to the ShaderToy documentation:
uniform vec3 iResolution;
uniform float iTime;
uniform float iTimeDelta;
uniform float iFrame;
uniform float iChannelTime(4);
uniform vec4 iMouse;
uniform vec4 iDate;
uniform float iSampleRate;
uniform vec3 iChannelResolution(4);
uniform samplerXX iChanneli;
You can see you will have to pass stuff like the current time and the position of the mouse. That means you also need a script that is updating these uniforms before doing the render call. For LibGDX in particular, you would do that inside
render. You can imagine, from there, how to go about making a ShaderToy clone in LibGDX. If you are trying to do this as a shorthand to implement your game, you probably should simply implement your game instead.
However, chances are, you want to use the ShaderToy scripts as a material. That is, you would be rendering a scene, as you would normally do, and the ShaderToy scripts defines how to shade a surface. That means that you would create your GLSL fragment shader based on your ShaderToy script, then when rendering the mesh that uses it, you would set the uniforms and call render on the mesh. And at that point, it makes much more sense to implement only what you need instead of cloning all ShaderToy functionality, and it would be much more efficient.
To reiterate, ShaderToy is based on GLSL. Thus, if you can use ShaderToy, you got a head start in GLSL. However do not let ShaderToy prevent you from learning GLSL.