Discrepancy in water caustic rendering between VSCode shader-toy and shadertoy.com

[meisei4]

Description:
When running identical GLSL shader code on the VSCode shader-toy extension and the shadertoy website, this water caustic effect behaves differently. The original code (as used on Shadertoy.com) produces the intended look, while the VSCode preview renders the water layers incorrectly (resulting in blown‐out white areas).

Expected Behavior:
The shader should produce an identical water caustic effect on both the VSCode shader-toy extension and theshadertoy.com website since they are using the same GLSL code.

Actual Behavior:

• Shadertoy.com:
  The original code renders water layers and highlights correctly.
• VSCode Extension:
  The original code results in a white or blown-out image, where adjusting the thresholds/inequalities (as shown below) is necessary to match the intended visual output.

Steps to Reproduce:

1. Original shader (Shadertoy.com):

   • Link: https://www.shadertoy.com/view/wdG3Rz
   • Running this on Shadertoy.com produces the expected water ripple and highlight effects.

2. Original shader in VSCode Extension Preview:

   • The identical code produces a blown‐out white output, with water highlights not rendering as expected.
   • code to run on vscode preview: https://github.com/meisei4/shadertoy/blob/main/shaders/ref_for_galaxy.glsl (apologies for the local file paths)

Original shader in VSCode preview:

3. Refactored Version in VSCode:
   In order to correct for the blown-out output and achieve a similar visual effect in the VSCode GLSL preview, I adjusted lines 44~50 to invert the inequalities and the threshold values as follows:

Original:

if(avg(water1 + water2) > 0.3) {
    alpha = 0.0;
}
if(avg(water1 + water2 + highlights1 + highlights2) > 0.75) {
    alpha = 5.0 * opacity;
}

Refactored version:

if(avg(water1 + water2) < 1.7) {
    alpha = 0.0;
}
if(avg(water1 + water2 + highlights1 + highlights2) < 1.25) {
    alpha = 0.5 * opacity;
}

Refactored Version in VSCode preview:

• full refactored code: https://github.com/meisei4/shadertoy/blob/main/shaders/ref_for_galaxy_vscode.glsl
• And while this is not a perfect correction to replication, it at least seems to demonstrate what might be leading to the discrepancy in the behavior? I don't understand why this is happening though.

4. Refactored shader in shadertoy website view:

• For comprehensiveness, conversely when i run the refactored version on the shadertoy website it eliminates much of the caustic highlights from the original

Refactored Version in shadertoy website preview:

Textures used:
source: https://shadertoyunofficial.wordpress.com/2019/07/23/shadertoy-media-files/

Abstract 1 texture 1024x1024

Gray Noise Small texture 64x64

Pebbles texture 512x512

Environment:

• Shader Toy Extension Version: 0.11.2 (Last Updated 2025-02-01, 12:40:24)
• VSCode Version: 1.97.2 (Commit: e54c774e0add60467559eb0d1e229c6452cf8447)
• VSCode Architecture: x64
• OS: macOS 12.7.6 (Build: 21H1320)
• Kernel: Darwin 21.6.0

[meisei4]

Update for this. I have found out a different work around that is unrelated to editting the thresholds and inequalities. instead it gets closer to the texture sampling as a potential cause for the issue.

here is an observation i made with the sampling behavior in vscode vs shadertoy.

apologies for the ugly formatting, but i got them in screenshots for better comparison:

The gray noise texture gets sampled resulting in different colors despite the same function and texture

leading me to test a dimming constant on the noise texture in order to achieve a similar brightness level

and so in going back into the original shader code that gets blown-out in the vscode extension, i was able to experiment with some dimming constants that further show that something is happening in the texture sampling that differs between the two contexts:

I am not sure how or why these numbers are meaningful (2.0, 3.0, and 10.0, but im wondering if its related to some kind of scaling vscode is doing to the sampling? that results in much brighter results for the noise and pebbles texture.

because the rock background texture alone seems to be sampled identically:

[meisei4]

I believe I have found the source of the discrepancy:

ShaderToy samples the gray noise small texture using R8 (1 channel uint8)!
So:
sample1 = vec4(R, 0, 0, A);

Whereas VS Code samples the texture as RGB (3 channel uint8). This is actually how ShaderToy samples the Abstract 1 texture (1024x1024) too. You can see these configurations in the texture details when choosing them in the channels in the shadertoy web interface. But VS Code will sample everything by R8/1 channel, including grayscale images.
So:
sample1 = vec4(R, G, B, A);

Ultimately, what's happening in the avg function:

float avg(vec4 c) { return (c.r + c.g + c.b) / 3.0; }

When this is being called on a single-channel sampling of the gray noise:

avg(vec4(0.5, 0.0, 0.0, 1.0)) == (0.5 + 0.0 + 0.0) / 3.0 == 0.1667

This makes it much darker than the original RGB image:

avg(vec4(0.5, 0.5, 0.5, 1.0)) == (0.5 + 0.5 + 0.5) / 3.0 == 0.5

So, the original person's ShaderToy is working with a much dimmer average of the noise texture. That’s why they are using much larger opacity constants and lower constants for adjusting the highlights (1.5).

Final workaround (not sure if this can even be considered a bug, as im not sure how the textures are marked as single channel vs 3 channel in shadertoy.com, and or even if thats possible to do in the vscode extension)

• create a second avg function (this is obviously not a true average, since it's just the red channel R / 3) to be used only for single-channel grayscale textures (the gray noise small and pebbles).

The original avg function must still be kept, but only used once the R values have been copied over the G and B values

So here is the final code needed to reproduce IDENTICALLY the Original shader from within the VSCode extension