From the OPENGL PROGRAMMING GUIDE VERSION 4.5 WITH SPIR-V kindle edition. I have a Table H.2 std430 layout rules that states for:
"Three-component vectors (e.g., vec3) and Four-component vectors (e.g, vec4)
“Both the size and alignment are four times the size of the underlying scalar type. How ever, this is true only when the member is not a part of an array or nested structure.”
So far I am programming OpenGL with glfw and Python 3.8. So far I understand that an SSBO buffer will need to be created in the typical similar sense that a VBO or EBO type of buffer is created. I have a drawing system where I would like to put vec4’s into the SSBO from a GLM api array (I guess of GLM type float32’s). I have to admit that after reading the language from the std430 table describing how this should be done that I don’t reall understand it what the table means. What does that description actually mean in terms of loading a GLM array of vec4’s into the buffer (is there some type of packing to reconsider from just buffering a glm float32 array like I nornally do for a VBO with Python)?
An array of vec4 has the same layout as float[][4] in C: packed 32-bit floats with no padding. An array of vec3 has essentially the same layout (every fourth entry is unused). This is true for both std140 and std430. They differ in that std140 also pads float and vec2 to match a vec4 while std430 doesn’t.
In structures, vec3 and vec4 are aligned to 4-word (16-byte) boundaries, but std430 lets you pack a vec3 followed by a float or a pair of vec2s into a 16-byte block.
Essentially, std140 was designed for hardware where a vec4 was the smallest addressable unit; anything else was just a vec4 with unused fields. std430 relaxes those restrictions, allowing objects to be aligned to 1-word, 2-word or 4-word boundaries (but this still means that vec3s can’t be packed; the fourth word must be padding or a single float field).