Help with shader error at u_time

[rudiHammad]

Hello,
here my first attempt of doing a shader.

#version 300 es
precision mediump float;

in vec2 v_texCoord; // Texture coordinates passed from vertex shader
uniform sampler2D u_tex0; // Texture sampler
uniform float u_time; // Time uniform for animation

out vec4 fragColor;

void main() {
    // Normalize the texture coordinates to [-1, 1]
    vec2 uv = v_texCoord * 2.0 - 1.0;

    // Distortion parameters
    float frequency = 10.0; // Number of waves
    float amplitude = 0.05; // Intensity of the distortion

    // Apply sine wave distortion to the vertical coordinate
    float distortion = sin(uv.x * frequency + u_time) * amplitude;
    uv.y += distortion;

    // Convert back to [0, 1] range for texture sampling
    uv = (uv + 1.0) / 2.0;

    // Sample the texture with the distorted coordinates
    vec4 color = texture(u_tex0, uv);

    fragColor = color;
}

I get this error: Assertion failed!

Program: ...AMES\production\core\build\bin\core\Debug\core.exe
File: C:\axmol\core\renderer\backend\opengl\ProgramGL.cpp
Line: 392

Expression: uniform.type == GL_SAMPLER_2D || uniform.type == GL_SAMPLER_CUBE

Being new to glsl, this is cryptic to me at this point. So I tried to debug the code above, and I pinned down that there is something
wrong with my u_time, because if I replace the line
float distortion = sin(uv.x * frequency + u_time) * amplitude;
with
float distortion = sin(uv.x * frequency + 0.1) * amplitude;

I do get a distorted image by a sin wave

But of course it is static because the u_time is not evaluating.

The code in axmol to load the shader is:

    auto program = ProgramManager::getInstance()->loadProgram(positionTextureColor_vert,  "custom/ch_learning_fs", VertexLayoutType::Sprite);
    auto programState = new backend::ProgramState(program);
    sprite->setProgramState(programState);

I don't thing it has to do anything with it, but just in case.
So my guess is that u_time has the wrong type of data? but i don't know why.
I'd appreciate any help with it.

thanks.

[rh101]

@rudiHammad In the wiki, it shows an example of the structure of the shader. Also, the included shaders in the Axmol source can be use as an example of how to correctly write a shader. You should be able to easily see the differences between those and your implementation.

[rudiHammad]

Yes, I have been looking a them as reference but don't understand why in mine u_time is not updating.
I'll try to figure it out.
Cheers

[rh101]

Yes, I have been looking a them as reference but don't understand why in mine u_time is not updating.

Are you using v1 or v2 of Axmol? If you are using v2+, then the differences in the shader implementations from yours should be very obvious. For example, you're missing the block where you define your uniform:

uniform float u_time; // Time uniform for animation

should be:

layout(std140) uniform fs_ub {
    float u_time; // Time uniform for animation
};

out vec4 fragColor;
should be
layout(location = SV_Target0) out vec4 FragColor;

etc. etc.

Review the existing fragment shaders carefully.

[rudiHammad]

I am using axmol 2.1.3
I think I will start again copying the noise_fs in my file and start modifying and studing what everything is doing.
I read yesterday about what are uniforms, in, out and location, and I guess I kind of understand it.
But there are to many things I don't understand yet. For instance, why u_time should be inside uniform block, or what on earth SV_target0 means, etc... I have a lot of googling to do.

[rh101]

See if the info here helps:

https://github.com/septag/glslcc?tab=readme-ov-file#hlsl-semantics
https://registry.khronos.org/OpenGL/specs/es/3.2/GLSL_ES_Specification_3.20.pdf

[rudiHammad]

okey, I give up.
It's not clicking in my head. I've read the docs many times now. My understanding is that .frag and .vert extensions are shader written in GLSL 400, where HLSL shader semantics are used, correct? So I tried to study the shaders in https://github.com/axmolengine/axmol/tree/dev/core/renderer/shaders. But then I had a look at the shader in runtime/axslc which are those same shaders but converted to OpenGl Es 300 using the command ./glslcc.exe --vert=path/to/shader.vert --frag=path/to/shader.frag --output=path/to/shader.hlsl --lang=hlsl --reflect.
The example I posted I wrote in OpenGl Es 300, and you mentioned that out vec4 fragColor; should be layout(location = SV_Target0) out vec4 FragColor;, but that is for GLSL400...
Anyway, I am going to take a break from this because clearly, despite the explanations you provide me, I have finding all this very confusing.
I might try again some other time.

[rh101]

But then I had a look at the shader in runtime/axslc which are those same shaders but converted to OpenGl Es 300 using the command ./glslcc.exe --vert=path/to/shader.vert --frag=path/to/shader.frag --output=path/to/shader.hlsl --lang=hlsl --reflect.
The example I posted I wrote in OpenGl Es 300, and you mentioned that out vec4 fragColor; should be layout(location = SV_Target0) out vec4 FragColor;, but that is for GLSL400...

It seems like you're just adding confusion by looking at the generated shaders, but there is no reason to be looking at them; they are exactly what is required for the platform you are targeting.

Have you tested out the shader on ShaderToy or similar site to make sure it actually works before using it in your app? If not, then it is perhaps best that you do so, in case the problem is with the shader logic rather than the Axmol implementation. Also, I just ran your shader, and it did show something, but it wasn't changing the output based on the u_time value.

I think that this may be the correct shader code:

#version 310 es
precision mediump float;

layout(location = COLOR0) in vec4 v_color;
layout(location = TEXCOORD0) in vec2 v_texCoord;
layout(location = SV_Target0) out vec4 FragColor;

layout(binding = 0) uniform sampler2D u_tex0;

layout(std140) uniform fs_ub {
    mediump float u_time;  
};

void main()
{
    // Normalize the texture coordinates to [-1, 1]
    vec2 uv = v_texCoord * 2.0 - 1.0;

    // Distortion parameters
    float frequency = 10.0; // Number of waves
    float amplitude = 0.05; // Intensity of the distortion

    // Apply sine wave distortion to the vertical coordinate
    float distortion = sin(uv.x * frequency + u_time) * amplitude;
    uv.y += distortion;

    // Convert back to [0, 1] range for texture sampling
    uv = (uv + 1.0) / 2.0;

    // Sample the texture with the distorted coordinates
    vec4 color = texture(u_tex0, uv);

    FragColor = color;
}

Using it as follows:

auto program = ProgramManager::getInstance()->loadProgram(ax::positionTextureColor_vert, "custom/TestShader_fs", VertexLayoutType::Sprite);
auto programState = new ProgramState(program);
_timeLocation = programState->getUniformLocation("u_time");
_sprite->setProgramState(programState, true);

Then in update() I added the following, although I don't know how you're using it, so it was just a guess:

void MainScene::update(float delta)
{
    _sprite->getProgramState()->setUniform(_timeLocation, &delta, sizeof(delta));
...
}

This is the output that doesn't change:

[rh101]

@rudiHammad Turns out my guess wasn't correct. You actually need the current time, not the time delta, so this works:

auto t = std::chrono::duration_cast<std::chrono::duration<float, std::milli>>(std::chrono::high_resolution_clock::now().time_since_epoch()).count() / 1000;
_sprite->getProgramState()->setUniform(_timeLocation, &t, sizeof(t));

With that change, you can see a ripple effect, assuming that is the correct output of the shader.

[rh101]

Just FYI, the logic is a bit odd. The frequency value should affect the period of the wave, but in the existing implementation all it does is make it look like it has more waves but the speed remains the same. If you want to affect how fast the wave is, then try something like this:

// Distortion parameters
float numRipples = 4.0; // Number of waves (not sure if that is what this value represents)
float frequency = 5.0;
float amplitude = 0.05; // Intensity of the distortion

// Apply sine wave distortion to the vertical coordinate
float distortion = sin((uv.x * numRipples + u_time) * frequency) * amplitude;

This would be the output of the above settings:

[rudiHammad]

@rh101 Thanks for taking the time to show me how to fix it.
I followed you code and made it work, but I had to remove all from the code all layout (location = SEMANTIC) and change #version 310 es to #version 300 es. I will have a look again to the guide. Right now I updated from axmol 2.1.3 to the last one and I have some stuff breaking that I have to fix.

quick question : using glslcc.exe , when I set the language flag to essl, it says there is no such thing. It does work for the rest.

[halx99]

I think should refer to this guide: https://github.com/axmolengine/axmol/wiki/Shaders-in-Axmol

[rudiHammad]

I took the time to explain with an image the workflow that I am doing after reading the guides. I think that way you can detect faster what I am doing wrong, and hopefully help others that are getting started with shading.
In a nutshell, as a learning exercise I am copying to my project shader folder an existing shader from axmol's source code, and try to recompile as working version. In the image you can see how I use the command and how the output file in the axslc/custom/ is missing
many thing that are required (precision, the "es" after 300), no location, etc...
I hope this helps clarify what I am doing wrong.

thanks again

[rh101]

Sorry, I feel like I've missed something completely, because I don't quite understand why you're building the shader manually, or why the shader code I provided above doesn't work for you as-is. The shader code I posted above was tested in a Windows build (win32/x64).

Please provide the following info:

What platform are you building for?
Why are you compiling the shader manually?
Can you please show where exactly you're placing the shader in your project? Or, better yet, create a new project via axmol new ... etc., and put a shader into it like you would in your own project, and then post it up somewhere (zip file or repo etc). No need to build it, just curious how it's being set up in your project structure.

[rudiHammad]

Sure,
I am building for windows x64.
Here is an image of my project. It is called core. I build it with axmol new etccc..., and then I build the windows solution (so the build folder)
That would be the starting point of the default project. And then I added what you see in the image.

In side the Source, I create a folder called shaders, and in there I write my own shaders. That's what I was doing and then I read about using the glslcc.exe and I followed the guide because that what I though I had to do....

[rh101]

In side the Source, I create a folder called shaders, and in there I write my own shaders. That's what I was doing and then I read about using the glslcc.exe and I followed the guide because that what I though I had to do....

That is not correct. Is there something in the wiki shader guide that caused you confusion? If there is something in there that is not clear, then we should address it, so please do point out any areas in the documentation that are lacking.

Now, regarding your project structure, you just need to do this:

1- Create a folder named shaders in the Source folder
2- Add the shader files to that folder (in the correct format, like the version in my post above)
3- Run the same axmol build ... command that you initially used to regenerate your project (such as for Visual Studio etc.) in order to update the project with the new shaders you added
4- Open the project in your IDE (VS etc.)
5- Build
6- The shaders will automatically be processed, and compiled into the correct format for the target platform. You simply reference these shaders by prefixing the name with custom, such as custom/shadername_fs and custom/shadername_vs.

That is all. You should not be copying glslcc to your project, or using it to process your shaders. Also, do not modify anything in the build/runtime/axslc folder, and in fact, nothing in the build folder should ever be manually modified by you, since that is a generated folder, which you can delete and re-generate at any time.

[rudiHammad]

[rh101]

The project in the zip file doesn't have anything in it besides the default project, so there was no need to attach it. It also contains the generated build folder, which you should avoid adding to the archive, since it is a folder that can be generated at any time, and just adds to the size of the file. Perhaps it would be best to edit your post and just delete the attachment, since it serves no purpose.

[rudiHammad]

done

[rudiHammad]

Got it, now everything is working exactly as you said in that quick point by point guide from your last answer.
I copied the shader as you wrote it, went point by point and everything worked.

It could be just me, but ultimately the thing that confused me was the fact that you have to run every time the build command (in my case : cmake -S . -B build -G "Visual Studio 17 2022" -A x64)), because though this is just done once at the beginning of the project.
I'm used to coding directly in the file I'm working on, saving it, and testing the changes immediately. Having to regenerate the project every time just to add a new shader felt odd. So I though the answer was in the cross-compiler guide and well... you know the rest.

Just those 6 points you wrote made things really clear, at least for me.
Thanks.

ps: at point 1 you meant a folder named shaders instead of shader, right?

[rh101]

It could be just me, but ultimately the thing that confused me was the fact that you have to run every time the build command (in my case : cmake -S . -B build -G "Visual Studio 17 2022" -A x64)), because though this is just done once at the beginning of the project.

Everything revolves around CMake. Using it reduces the effort involved in targeting different platforms, so in the long run it saves a lot of time and effort. The reason you need to re-generate the project files with CMake is because you should not be editing the generated project files directly. Everything needs to be done via CMake (basically in CMakeLists.txt).

Using cmake -S . -B build -G "Visual Studio 17 2022" -A x64 is fine, but be careful in doing this, because the axmol build command may actually pass more settings to the cmake .... command when you run it. It's also easier to remember axmol build -p win32 -c -f, or better yet, axmol -p win32 -c -f, since the 'build' is the default option. So, I recommend that you use that instead of the raw cmake command.

Also, when you do use the axmol build command, it will print out the cmake command that it runs in the output, so you can see exactly what it is using. For example, in a project with folder named "test1", running axmol -p win32 -c -f shows this in the output:
1kiss: CMake config command: cmake -A x64 -D_1KFETCH_UPGRADE=FALSE -B C:\dev\projects\test1\build -DCMAKE_INSTALL_PREFIX=C:\dev\projects\test1\install

ps: at point 1 you meant a folder named shaders instead of shader, right?

Yes, it should be "shaders".

[rudiHammad]

I Just adapted it to Shader toy with this:

void mainImage( out vec4 FragColor, in vec2 fragCoord )
{
    vec2 uv = fragCoord/iResolution.xy;
    
    // Distortion parameters
    float numRipples = 4.0; // Number of waves (not sure if that is what this value represents)
    float frequency = 10.0; // Number of waves
    float amplitude = 0.05; // Intensity of the distortion
    
    // Apply sine wave distortion to the vertical coordinate
    float distortion = sin((uv.x * numRipples + iTime) * frequency) * amplitude;
    uv.y += distortion;
    
    // Convert back to [0, 1] range for texture sampling
    uv = (uv + 1.0) / 2.0;
    
    // Sample the texture with the distorted coordinates
    vec4 color = texture(iChannel0, uv);

    // Output to screen
    FragColor = color;
}

Once we get use to move between shader toy and axmol by adapting the in and out parameters, testing things in real time get easier.

[rh101]

That's exactly how I tested your original shader to see what output it should be producing before modifying it in Axmol. Shadertoy is great for prototyping, and if you ever need to see the value of variables in the shader, you can use something like this: https://www.shadertoy.com/view/dsGXDt