1

I have uniform defined in my shader like below

// FragmentShader.glsl
#define MAX_NUM_LIGHTS 5
struct DirectionalLight
{
    vec3 direction;
    vec3 color;
    vec3 ambient;
    float strength;
};

layout (std140) uniform StaticDirectionalLights
{
    int SL_numDirectionalLight;
    DirectionalLight[MAX_NUM_LIGHTS] SL_DirectionalLights;
};

and i have corresponding C++ structs as

#define MAX_NUM_LIGHTS 5
struct R3D_DirectionalLight
{
    Vec3 direction;
    float padding1;
    Vec3 color;
    float padding2;
    Vec3 ambient;
    float padding3;
    float strength;
    Vec3 padding4;
};

struct R3D_DirectionalLights
{
    int numDirectionalLights;
    char padding1[sizeof(Vec4) - sizeof(int)] = {0};
    R3D_DirectionalLight directionalLights[MAX_NUM_LIGHTS];
};

when i copy my C++ struct to glsl uniform using glBufferSubData, SL_numDirectionalLight doesn't reflect correct value. is there any problem in my C++ struct memory layout which is not complying to std140 rule?

bhawesh
  • 1,310
  • 2
  • 19
  • 57
  • 2
    Please read [Should I ever use a `vec3` inside of a uniform buffer or shader storage buffer object?](https://stackoverflow.com/questions/38172696/should-i-ever-use-a-vec3-inside-of-a-uniform-buffer-or-shader-storage-buffer-o) – Rabbid76 Sep 13 '19 at 19:03
  • What data type is `hwfloat`? – Rabbid76 Sep 13 '19 at 19:05
  • When the first member of a block doesn't work, then it's not a padding issues since the first member will in all cases start at offset 0. You should add the relevant c++ code for uploading/binding your data. Besides, your current layout uses 16 floats although the relevant data is only 10 floats. I highly recommend packing the data in a maximum of 3 times vec4. (or even better, 5 vec2). – BDL Sep 13 '19 at 19:10
  • @Rabbid76 its plain C++ float – bhawesh Sep 13 '19 at 19:10
  • @NicolBolas: That's not a good duplicate here since the problem is most likely not caused by the vec3 and/or padding. I would encourage the user to read that post, but it doesn't solve the problem. – BDL Sep 13 '19 at 19:13
  • 1
    @BDL: "*the problem is most likely not caused by the vec3 and/or padding*" And yet it is. `padding3` should not exist (neither should `padding4`), as clearly explained in the answer in the duplicate question. It's why you can't just align C++ `vec3` types to 16-bytes. – Nicol Bolas Sep 13 '19 at 19:15
  • @NicolBolas Thanks for sharing link. i understood wrong structure alignment in C++ side. Changing to Vec4 fixed it. Thanks – bhawesh Sep 13 '19 at 20:36

0 Answers0