Problem accessing multiple texcoords in shader [SOLVED]

[Locien]

Hello. I was wondering if anyone knows how to access multiple texture coords in a GLSL shader using meshes build with S3DVertex2TCoords vertices. I've patched texture array support made by hendu into Irrlicht and I need some way to select different textures with my shader. My first texture coordinates just serve as normal UV coordinates while the second ones are meant to be used to select the right texture from the array. However I can't seem to access the second texture coords whatsoever, I've tried everything basically.

This is the code which draws two triangles/a square using SMeshBuffer:

Code: Select all

    Buffer->Vertices.push_back(S3DVertex2TCoords(140.0f, 90.0f + Size, 140.0f + Size, 0.0, 1.0, 0.0, SColor(255, 255, 255, 255), 0.0, 1.0, 1.0 , 0.0));
    Buffer->Vertices.push_back(S3DVertex2TCoords(140.0f + Size, 90.0f + Size, 140.0f + Size, 0.0, 1.0, 0.0, SColor(255, 255, 255, 255), 1.0, 1.0, 1.0, 0.0));
    Buffer->Vertices.push_back(S3DVertex2TCoords(140.0f + Size, 90.0f + Size, 140.0f, 0.0, 1.0, 0.0, SColor(255, 255, 255, 255), 1.0, 0.0, 1.0, 0.0));
    Buffer->Vertices.push_back(S3DVertex2TCoords(140.0f, 90.0f + Size, 140.0f, 0.0, 1.0, 0.0, SColor(255, 255, 255, 255), 0.0, 0.0, 1.0, 0.0));

The shader material:

Code: Select all

ShaderMaterial = IrrDriver->getGPUProgrammingServices()->addHighLevelShaderMaterialFromFiles(vsFile, "main", EVST_VS_4_1, psFile, "main", EPST_PS_4_1, ShaderCallback, EMT_SOLID, 0, EGSL_DEFAULT);

OnSetConstants:

Code: Select all

    virtual void OnSetConstants(video::IMaterialRendererServices* Services, s32 UserData)
    {
        IVideoDriver* IrrDriver = Services->getVideoDriver();
 
        matrix4 ModelMatrix = IrrDriver->getTransform(video::ETS_WORLD);
        ModelMatrix.getTransposed();
        Services->setVertexShaderConstant("M", ModelMatrix.pointer(), 16);
 
        matrix4 ViewMatrix = IrrDriver->getTransform(video::ETS_VIEW);
        Services->setVertexShaderConstant("V", ViewMatrix.pointer(), 16);
 
        matrix4 ProjectionMatrix = IrrDriver->getTransform(video::ETS_PROJECTION);
        Services->setVertexShaderConstant("P", ProjectionMatrix.pointer(), 16);
 
        f32 Texture = 0;
        Services->setPixelShaderConstant("TextureArray", &Texture, 1);
 
    }

Vertex shader:

Code: Select all

 
#version 410 compatibility
 
uniform mat4 M;
uniform mat4 V;
uniform mat4 P;
 
out vec4 texCoord;
out vec4 texCoord1;
 
void main()
{
    
    texCoord = gl_MultiTexCoord0;
    texCoord1 = gl_MultiTexCoord1;
    
    mat4 MV = V * M;
    mat4 MVP = P * MV;
    gl_Position = MVP * gl_Vertex;
    
}

Pixel shader:

Code: Select all

#version 410
#extension GL_EXT_texture_array: enable
uniform sampler2DArray TextureArray;
 
in vec4 texCoord;
in vec4 texCoord1;
 
out vec4 colorOut;
 
void main()
{
    //This doesn't work
    colorOut = texture2DArray(TextureArray, vec3(texCoord.xy, texCoord1.x));
 
    //This doesn't work either
    //colorOut = texture2DArray(TextureArray, vec3(texCoord.xy, texCoord.z)
}

Can someone please tell me what I'm doing wrong? Do I need to send the texture coordinates myself in the shader OnSetConstants? I appreciate any help, thanks

[Locien]

I did some more testing this time with a color output from the pixel shader. I also tried to load a normal texture instead of an array and the same problem persists so I don't think it has anything to do with the code changes from Hendu's patch. Anyways I discovered something peculiar.

Both of these pixel shaders create the exact same result.

Code: Select all

void main()
{
    colorOut = vec4(1.0*texCoord.x, 1.0*texCoord.y, 1.0*texCoord.z, 1.0*texCoord.w);
}

Code: Select all

void main()
{
    colorOut = vec4(1.0*texCoord1.x, 1.0*texCoord1.y, 1.0*texCoord1.z, 1.0*texCoord1.w);
}

And to make sure I wasn't crazy I changed the code a little bit and tried again.

Code: Select all

    Buffer->Vertices.push_back(S3DVertex2TCoords(140.0f, 90.0f + Size, 140.0f + Size, 0.0, 1.0, 0.0, SColor(255, 255, 255, 255), 0.3, 1.0, 0.0 , 0.0));
    Buffer->Vertices.push_back(S3DVertex2TCoords(140.0f + Size, 90.0f + Size, 140.0f + Size, 0.0, 1.0, 0.0, SColor(255, 255, 255, 255), 0.7, 1.0, 0.0, 0.0));
    Buffer->Vertices.push_back(S3DVertex2TCoords(140.0f + Size, 90.0f + Size, 140.0f, 0.0, 1.0, 0.0, SColor(255, 255, 255, 255), 0.0, 0.4, 0.0, 0.0));
    Buffer->Vertices.push_back(S3DVertex2TCoords(140.0f, 90.0f + Size, 140.0f, 0.0, 1.0, 0.0, SColor(255, 255, 255, 255), 0.2, 0.2, 0.0, 0.0));

Again I tested it on both gl_MultiTexCoord0 and gl_MultiTexCoord1 and both times they yielded the exact same result.



So I went deeper and tried gl_MultiTexCoord2 and this was the result:



So it seems like the shader recognizes two texture coordinates(and not 3 or more) as it's supposed to, but it's always the same one no matter how I change the texture coordinates in S3DVertex2TCoords.

That brings me to the question. Am I doing something wrong still or is S3DVertex2TCoords bugged? Because gl_MultiTexCoord0 and gl_MultiTexCoord1 are always identical no matter how I shuffle the values in my code and I'm frankly at a loss. Oh and, for your information I'm using Irrlicht 1.8.1 with Hendu's texture array patch but otherwise nothing is changed.

[Foaly]

I'd pass the texture coordinates this way in the Vertex Shader.

Code: Select all

gl_TexCoord[0] = gl_MultiTexCoord0
gl_TexCoord[1] = gl_MultiTexCoord1

Then you can use gl_TexCoord[0] and gl_TexCoord[1] in your Fragment Shader.

Btw. you said you are using an SMeshBuffer? It does not support multiple texture coordinates.
You'll have to use either SMeshBufferLightmap. (Or CDynamicMeshBuffer.)

[Locien]

Btw. you said you are using an SMeshBuffer? It does not support multiple texture coordinates.
You'll have to use either SMeshBufferLightmap. (Or CDynamicMeshBuffer.)

Thank you so much! This was the problem, I just changed the mesh type to SMeshBufferLightMap and now it's working

[hendu]

A side note, you don't want to use GLSL 4 compatibility, because it limits you to Windows basically. That is not available on OS X nor on Linux open source drivers.

I'd advice either 130, 140 or 150 for a baseline, or the forward 300.