Shared Parameters in Shaders are Always Zero Topic is solved

[Adrian Samoticha]

Ogre Version: 14-3-4
Operating System: Kubuntu 24.10 (running on X11)
Render System: OpenGL Rendering Subsystem

Hello guys!

This is my first post on this forum.

I have applied a fragment shader to an entity using GPU Program Scripts. This works fine and the shader appears on the entity’s mesh and is displayed correctly. However, I would now like to use Shared Parameters to send Shader Storage Buffer Objects containing voxel data from the CPU to the GPU.

Let’s keep things simple. Rather than create a buffer, I’ll try to simply define a simple integer as a shared parameter, similarly to how this example project does it:

MyMaterial.material:

Code: Select all

shared_params YourSharedParamsName
{
    shared_param_named mySharedParam1 uint 1
}

fragment_program MyFragmentShader glsl
{
    source MyShader.glsl
    default_params
    {
        param_named alpha_value float 0.4
        param_named_auto time time_0_x 100
        shared_params_ref YourSharedParamsName
    }
}

material MyMaterial
{
    technique
    {
        pass
        {
            lighting off

            fragment_program_ref MyFragmentShader
            {
            }
        }
    }
}

MyShader.glsl:

Code: Select all

#version 400

uniform float alpha_value;
uniform float time;

buffer YourSharedParamsName
{
    uint mySharedParam1;
};

out vec4 fragColor;

void main()
{
    uint counter = atomicAdd(mySharedParam1, 1);
    uint myValue = counter;

    vec4 color;
    color.x = 1.0; // Red
    color.y = myValue == 0 ? 0.0 : 1.0; // Green
    color.z = 0.0; // Blue

    fragColor = color;
}

I initialize mySharedParam1 to 1 in the material script and atomically increment it by 1 in the shader itself, and yet the result looks like this:

I would have expected the cube to appear yellow (since the green channel should be 1.0), but it’s red, instead.

Changing the value of the mySharedParam1 variable in the C++ code like this also has no effect:

Code: Select all

  auto material = Ogre::MaterialManager::getSingleton().getByName("MyMaterial");
  Ogre::GpuProgramManager::getSingleton()
      .getSharedParameters("YourSharedParamsName")
      ->setNamedConstant("mySharedParam1", 10);

  auto* ogreEntity = sceneMan->createEntity("cube.mesh");

  auto* ogreNode = sceneMan->getRootSceneNode()->createChildSceneNode();

  ogreNode->attachObject(ogreEntity);

  ogreEntity->setMaterial(material);

I’ve had the same exact experience with all other data types I’ve tried (integers, floats, vectors, arrays). I’ve also tried defining the shared parameters programmatically using Ogre::GpuProgramManager::getSingleton().createSharedParameters(), but to no avail. The uniform values (alpha_value and time) have the correct, value, though, and I do not see any shader-related errors in the console output.

What am I missing?

[paroj]

does the referenced example project work for you? If so, you can use https://renderdoc.org/ to compare what gets sent to the GPU with your code vs the example.

[rpgplayerrobin]

What happens if you do not use a buffer in the shader at all for it?

In my game, I simply just have the shared parameters like any other parameter (but I still use shared parameters).

So the only change to test it would be to alter the shader, to something like this:

Code: Select all

#version 400

uniform float alpha_value;
uniform float time;

uniform uint mySharedParam1;
//buffer YourSharedParamsName
//{
//    uint mySharedParam1;
//};

out vec4 fragColor;

void main()
{
    uint counter = mySharedParam1;//atomicAdd(mySharedParam1, 1);
    uint myValue = counter;

vec4 color;
color.x = 1.0; // Red
color.y = myValue == 0 ? 0.0 : 1.0; // Green
color.z = 0.0; // Blue

fragColor = color;
}

I realize that the atomicAdd will most likely not work with that code (since it does not work for uniforms I think), but it might be a good test to see if the value is even being sent over correctly to the shader itself.

[rpgplayerrobin]

Also, it seems you are using version 400, but it says online that atomicAdd requires 430.
So you might just have to upgrade the shader version to make this work instead.

If that does not work, you can also try this in the shader (which also requires 430):

Code: Select all

layout(std430, binding = 0) buffer YourSharedParamsName
{
    uint mySharedParam1;
};

[Adrian Samoticha]

does the referenced example project work for you? If so, you can use https://renderdoc.org/ to compare what gets sent to the GPU with your code vs the example.

I must admit, I haven’t actually tried running it. That said, RenderDoc doesn’t actually work with OGRE3D, because of OpenGL version incompatibilities. I wasn’t able to get Vulkan working reliably, so I’m a little out of luck on that front. I might still try to get the example to work just to check if it’s an issue with my OGRE installation somehow, I guess.

[Adrian Samoticha]

Also, it seems you are using version 400, but it says online that atomicAdd requires 430.
So you might just have to upgrade the shader version to make this work instead.

If that does not work, you can also try this in the shader (which also requires 430):

Code: Select all

layout(std430, binding = 0) buffer YourSharedParamsName
{
    uint mySharedParam1;
};

I’m aware that atomicAdd requires 430 or above, but I downgraded to 400 because the example project used version 400 (for some reason, despite it being incompatible). The result is the same in both versions. I also tried

Code: Select all

layout(std430, binding = 0) buffer YourSharedParamsName

as well as

Code: Select all

layout(std140, binding = 0) uniform YourSharedParamsName

(to prevent potential alignment issues, even though I’d probably need an actual SSBO because the voxel data can be quite large), but neither works.

Unfortunately,

Code: Select all

uniform uint mySharedParam1;

doesn’t work either. Did you register your shared parameters differently than I did in your material script?

[paroj]

does the referenced example project work for you? If so, you can use https://renderdoc.org/ to compare what gets sent to the GPU with your code vs the example.

I must admit, I haven’t actually tried running it. That said, RenderDoc doesn’t actually work with OGRE3D, because of OpenGL version incompatibilities. I wasn’t able to get Vulkan working reliably, so I’m a little out of luck on that front. I might still try to get the example to work just to check if it’s an issue with my OGRE installation somehow, I guess.

ah.. you are on GL instead of GL3+. Both RenderDoc and SSBOs require GL3+.

[Adrian Samoticha]

does the referenced example project work for you? If so, you can use https://renderdoc.org/ to compare what gets sent to the GPU with your code vs the example.

I must admit, I haven’t actually tried running it. That said, RenderDoc doesn’t actually work with OGRE3D, because of OpenGL version incompatibilities. I wasn’t able to get Vulkan working reliably, so I’m a little out of luck on that front. I might still try to get the example to work just to check if it’s an issue with my OGRE installation somehow, I guess.

ah.. you are on GL instead of GL3+. Both RenderDoc and SSBOs require GL3+.

You’re right. After switching to GL3+ (and adding a vertex shader, since apparently, GL3+ requires both), my cube appears nice and yellow. Thank you very much!