Shader help needed porting from axmol 1.X to 3.X

[TedGriggs]

Hi!

I had a shader for Axmol 1.X that took a 3D .c3t model with Blinn-Phong shading without a texture and rendered it. I generate a material with the shading information for each mesh within the model. This information is properly passed into the frag shader. However, when a set the Material on the model. I get two errors:
VertexInputBinding: attribute: 'a_normal' not present in shader
VertexInputBinding: attribute: 'a_texCoord' not present in shader

The vertex shader is below. I do declare a_normal. However, I am not being passed the normal and just a vector of NANs.

Also, I don't use a_texCoord, and so I am not sure why it is even trying to send me one.

The model has the all the necessary data, as it used to work in Axmol 1.X.

By the way, this is just a slightly modified version of SkinnedOutline.vert for the cpptests.

How do I get it to pass the normal?

Thanks!

---

#version 310 es

#include "base.glsl"

layout(location = POSITION) in vec3 a_position;
layout(location = NORMAL) in vec3 a_normal;
layout(location = BLENDWEIGHT) in vec4 a_blendWeight;
layout(location = BLENDINDICES) in vec4 a_blendIndex;

const int SKINNING_JOINT_COUNT = 60;
// Uniforms
layout(std140, set = 0, binding = 0) uniform vs_ub {
    vec4 u_matrixPalette[SKINNING_JOINT_COUNT * 3];
    mat4 u_MVPMatrix;
};

// Varyings
layout(location = NORMAL) out vec3 v_normalInterp;
layout(location = POSITION) out vec3 v_vertPos;

vec4 SkinnedVec3(vec4 vec)
{
    float blendWeight = a_blendWeight[0];

    int matrixIndex = int (a_blendIndex[0]) * 3;
    vec4 matrixPalette1 = u_matrixPalette[matrixIndex] * blendWeight;
    vec4 matrixPalette2 = u_matrixPalette[matrixIndex + 1] * blendWeight;
    vec4 matrixPalette3 = u_matrixPalette[matrixIndex + 2] * blendWeight;
    
    
    blendWeight = a_blendWeight[1];
    if (blendWeight > 0.0)
    {
        matrixIndex = int(a_blendIndex[1]) * 3;
        matrixPalette1 += u_matrixPalette[matrixIndex] * blendWeight;
        matrixPalette2 += u_matrixPalette[matrixIndex + 1] * blendWeight;
        matrixPalette3 += u_matrixPalette[matrixIndex + 2] * blendWeight;
    }
    
    
    blendWeight = a_blendWeight[2];
    if (blendWeight > 0.0)
    {
        matrixIndex = int(a_blendIndex[2]) * 3;
        matrixPalette1 += u_matrixPalette[matrixIndex] * blendWeight;
        matrixPalette2 += u_matrixPalette[matrixIndex + 1] * blendWeight;
        matrixPalette3 += u_matrixPalette[matrixIndex + 2] * blendWeight;
    }
    
    
    blendWeight = a_blendWeight[3];
    if (blendWeight > 0.0)
    {
        matrixIndex = int(a_blendIndex[3]) * 3;
        matrixPalette1 += u_matrixPalette[matrixIndex] * blendWeight;
        matrixPalette2 += u_matrixPalette[matrixIndex + 1] * blendWeight;
        matrixPalette3 += u_matrixPalette[matrixIndex + 2] * blendWeight;
    }
    

    vec4 _skinnedPosition;
    vec4 postion = vec;
    _skinnedPosition.x = dot(postion, matrixPalette1);
    _skinnedPosition.y = dot(postion, matrixPalette2);
    _skinnedPosition.z = dot(postion, matrixPalette3);
    _skinnedPosition.w = postion.w;
    
    return _skinnedPosition;
}

void main()
{
    vec4 pos = u_MVPMatrix * SkinnedVec3(vec4(a_position,1.0));
    v_vertPos = vec3(pos) / pos.w;
    
    vec4 normalproj = u_MVPMatrix * vec4(SkinnedVec3(vec4(a_normal,0.0)).xyz, 0);
    v_normalInterp = vec3(normalproj);

    gl_Position = pos;
}

[rh101]

Have you tried the MeshRender tests in cpp-tests that use the SkinnedOutline.vert shader in v3 of Axmol? If not, build and run cpp-tests, and see if that test actually works, or if it shows the same errors. The material using that shader seems to be MeshRendererTest/outline.material.

[TedGriggs]

Yes, test #45 (MeshRender) prints the error: VertexInputBinding: attribute: 'a_normal' not present in shader

[rh101]

Yes, that worked for removing the error. I'll mess around with the shader a bit now and see if I can get it working with version 3.

Is there any specific reason that you are using v3 of Axmol? It has not yet been released, and features may still be incomplete or unstable.

[TedGriggs]

Well, I used Axmol 1 awhile back, and decided to give it a try again for a new project. Pulled the main branch from GitHub and it gave me version 3. I actually did go back to version 2, but there were errors and it would not compile. The fix was made and I was told to go back to version 3. It seems like if you want people to use version 2, it should be the thing that GitHub clones, not version 3.

[rh101]

Well, I used Axmol 1 awhile back, and decided to give it a try again for a new project. Pulled the main branch from GitHub and it gave me version 3. I actually did go back to version 2, but there were errors and it would not compile.

Debian support has been added to v2, as you can see in this commit: c8e8114

The fix was made and I was told to go back to version 3.

That may be because you stated that you were using v3, so Debian support was added to it first, but that is the development version, and not the one to be used for production.

It seems like if you want people to use version 2, it should be the thing that GitHub clones, not version 3.

Cloning has nothing to do with branches. When you clone a repository, git creates a local copy of the entire repository, so your local copy has all the branches. The default branch is, generally, the one in active development, and should not be considered stable. Specific branches and tags are created for stable and release version, and those are the ones that should be used. In this case, the branch you should be using is release/2.x, or check out the latest tag of v2, the list of which you can see here: https://github.com/axmolengine/axmol/tags

[TedGriggs]

Again, nice to know, but this seems unusual from other repos. Usually you pull it and compile to get the one that is official release. The dev version is the one that's locked. Anyway, not really important.

Since I'm just starting my project, I think using the latest is fine. The issue I found was in both 2.X and 3.X, so it doesn't seem like having the older version was the problem.

However, I do have a question about 3D support. I have a game idea that has a decent amount of 3D, bt's not an action game. Is Axmol suited for this?

[aismann]

However, I do have a question about 3D support. I have a game idea that has a decent amount of 3D, bt's not an action game. Is >Axmol suited for this?

Have a look at cpp-tests: 40. Physics3D