OSX Problem with shaders Alpha

[IcemarkUK]

Included here is a shader I use for most of the graphics on screen. @rh101 kindly converted my old shader when I moved to axmol last year.

I clone the shader and add it to the sprites (AddTerrainTimeShader). I originally used SimpleShader to wrap the shaders. But I think most of the code has now been removed/ported.

I then set the graphics colours and alpha using UpdateTerrainTimeShader

What I am noticing is that the alpha is getting applied to pretty much all the sprites that use the shader. As a test I set the alpha to all sprites apart from mountains to 1.0f and mountains were set to 0.25f.

The included video is the result of looking around. You can see how the alpha is randomly being applied and on sprites that should be 1.0f

Edit: On further inspection it seems all variables are being affected (ie: colours) so I suspect I have something wrong with my shader variable handling.

alpha.issue.mov

As usual, any help would be much appreciated.

Node* shadermanager::AddTerrainTimeShader(Node* node)
{
    return AttachShader(node, terrainTimeShader);
}

Node* shadermanager::AttachShader(Node* node, SimpleShader* shader)
{
    auto ref = shader->programState->clone();
    node->setProgramState(ref);
    ref->release();
    return node;
}

void shadermanager::UpdateTerrainTimeShader(Node* node, f32 alpha, Color4F& outline, Color4F& body)
{
    auto state = node->getProgramState();
    setUniform(state,"p_alpha", alpha);                                             // alpha
    setUniform(state,"p_left", Vec4(outline.r,outline.g,outline.b,outline.a));      // outline
    setUniform(state,"p_right", Vec4(body.r,body.g,body.b,body.a));                 // body
}

template<typename T>
void setUniform(ax::backend::ProgramState* state, std::string uniform, T value)
{
    auto uniformLocation = state->getUniformLocation(uniform);
    state->setUniform(uniformLocation, &value, sizeof(value));
}

Shader creation:

void shadermanager::CreateTerrainTimeShader()
{
    terrainTimeShader = SimpleShader::createWithFragmentShader("custom/terrainTimeShader_fs");
    terrainTimeShader->setUniform("p_left", Vec4(0,0,(165.0f/255.0f),alpha_normal));   // Outline
    terrainTimeShader->setUniform("p_right", Vec4(1,1,1,alpha_normal));                // Body
    terrainTimeShader->setUniform("p_alpha", alpha_normal);                            // Alpha
}

custom/terrainTimeShader_fs

#version 310 es
precision highp float;
precision highp int;

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 {
    vec4 p_left;
    vec4 p_right;
    float p_alpha;
};


#ifndef saturate
#define saturate(v) clamp(v, 0.0, 1.0)
#endif

void main()
{
    vec4 c = texture(u_tex0, v_texCoord).rgba;
    vec4 n;
    vec4 m = vec4( 0.0, 0.0, 0.0, 0.0 ) ;

    vec3 fragRGB = c.rgb; // current color

    // convert to non-PMA
    fragRGB = saturate(fragRGB / c.a);

    //if(c.a!=0.0)
    {
        m.g = 1.0 - fragRGB.g ;
        m.a = c.a;

        n = vec4(
            (p_right.r*fragRGB.g)+(p_left.r*m.g),
            (p_right.g*fragRGB.g)+(p_left.g*m.g),
            (p_right.b*fragRGB.g)+(p_left.b*m.g), c.a * p_alpha) ;
    }

    fragRGB = n.rgb * n.a; // Premultiply alpha

    FragColor = vec4(fragRGB.rgb, n.a);
}

SimpleShader* SimpleShader::createWithFragmentShader(const std::string& fragShaderPath)
{
    return createWithVertexAndFragmentShader("custom/standard_vs", fragShaderPath);
}

SimpleShader* SimpleShader::createWithVertexAndFragmentShader(const std::string& vertShaderPath, const std::string& fragShaderPath)
{
    //custom vertex shader
    auto vertSource = ax::FileUtils::getInstance()->getStringFromFile(vertShaderPath);

    //custom fragment shader
    auto fragSourceRaw = ax::FileUtils::getInstance()->getStringFromFile(fragShaderPath);

    return new SimpleShader(vertSource, fragSourceRaw);
}

[rh101]

If the shaders will have different uniform values, then they should have separate batch identifiers, otherwise all sprites using that shader will end up with the same uniform values, which, if I recall correctly, would be the values from the last calls made to the setUniform method for each uniform.

ProgramState::updateBatchId() would need to be called after setting the uniform values, to ensure the batch ID is updated based on those values. For example, see if the following fixes the issue:

void shadermanager::CreateTerrainTimeShader()
{
    terrainTimeShader = SimpleShader::createWithFragmentShader("custom/terrainTimeShader_fs");
    terrainTimeShader->setUniform("p_left", Vec4(0,0,(165.0f/255.0f),alpha_normal));   // Outline
    terrainTimeShader->setUniform("p_right", Vec4(1,1,1,alpha_normal));                // Body
    terrainTimeShader->setUniform("p_alpha", alpha_normal);                            // Alpha

    terrainTimeShader->updateBatchId();
}

and

void shadermanager::UpdateTerrainTimeShader(Node* node, f32 alpha, Color4F& outline, Color4F& body)
{
    auto state = node->getProgramState();
    setUniform(state,"p_alpha", alpha);                                             // alpha
    setUniform(state,"p_left", Vec4(outline.r,outline.g,outline.b,outline.a));      // outline
    setUniform(state,"p_right", Vec4(body.r,body.g,body.b,body.a));                 // body

    state->updateBatchId();
}

Also, you can simplify the following code a bit:

Node* shadermanager::AttachShader(Node* node, SimpleShader* shader)
{
    auto ref = shader->programState->clone();
    node->setProgramState(ref);
    ref->release();
    return node;
}

to

Node* shadermanager::AttachShader(Node* node, SimpleShader* shader)
{
    auto ref = shader->programState->clone();
    node->setProgramState(ref, true); // pass ownership of the PS to the node, so no need to free/release the created PS after this call
    return node;
}

[rh101]

That would have been Cocos2d-x v3, but the renderer backend was re-written for Cocos2d-x v4. The reason this is happening is because of the renderer re-write in Cocos2d-x v4, which broke batching when using custom shaders with the same uniform values, resulting in a separate draw call for each Sprite. That batching issue for custom shaders was fixed in Axmol, but that resulted in the issue you're seeing.

There is no simple way for the engine to know if shaders should or should not be batched without setting some kind of identifier. Initially the identifier was a value set by the developer, which would mean managing the identifiers manually, but that was changed at some point to generate an identifier based off the uniform data (a hash of some kind). Calculating the hash is an expensive process, so the engine leaves that up to the developer (by calling ProgramState::updateBatchId()), since the developer would know if and when different uniform values would be used for the same shader. It seems like a reasonable compromise.

[IcemarkUK]

I was running under Cocos2d-x v4 - but hey, no issue.
Out of interest what kind of hit am I taking for batching on each sprite? Should I be trying to keep all sprites that are using the same shader with same variables into the same batch. I guess I'm pretty low nodes on screen at any one time...

[rh101]

I was running under Cocos2d-x v4 - but hey, no issue.

Sorry, you're correct, the rendering works fine in Cocos2d-x v4 as well, but you would have noticed more draw calls than v3. The only issue with Cocos2d-x v4 is that each Sprite using the custom shader, with the same uniform values, is not batched (refer to the comment left by the Cocos devs, and the attempt to fix it in the PR here).

Out of interest what kind of hit am I taking for batching on each sprite? Should I be trying to keep all sprites that are using the same shader with same variables into the same batch. I guess I'm pretty low nodes on screen at any one time...

It shouldn't be an issue, especially if there isn't a lot of uniform data to process. The hash calculation is done by this:

void ProgramState::updateBatchId()
{
    _batchId = XXH64(_uniformBuffers.data(), _uniformBuffers.size(), _program->getProgramId());
    _isBatchable = true;
}

If the uniform data and the program ID are the same, then the resulting hash value should be the same, so the Sprites using that ProgramState will automatically be batched. The usual things that break batching and cause extra draw calls will still affect this, but that has nothing to do with the custom shader or using updateBatchId(). If you want an example of this, check cpp-tests -> Renderer -> RendererUniformBatch test, and you'll see what I mean.

I'll re-word my previous post to avoid any confusion for anyone else coming across this thread.

[IcemarkUK]

In this instance all the images should have the same colours but distance objects and closer than the viewer objects have alpha.. So I could batch on those 3 elements (I presume z order breaks batching). But I think it's a small optimisation for future me... ;)

[rh101]

Global Z will break batching, but local Z won't necessarily do so unless something like a texture switch happens. For example, having a TTF label on a sprite will break batching, because the TTF font is rendered onto its own texture. A graphics debugging tool helps to see exactly what is happening, layer by layer; something like nVidia Nsight or RednerDoc, although I'm not sure if there are OSX versions.

All of this isn't really an issue unless you are running into many hundreds of draw calls, and even then, for desktop releases, you may not notice any performance issues.