Incorrect cases in GetComponentCount about hazel

[LovelySanta]

Yes, that is the discrepancy I'm referring to. Small correction: it is GetComponentCount() that returns the size, not ShaderDataTypeToOpenGLBaseType.

Fixed my typo, thanks

I don't think we would ever even need to send a mat3 or mat4 as vertex buffer attribute.

It's about correctness... If we wouldn't support it, then we wouldn't add it in the first place...

[WhoseTheNerd]

I don't see anything wrong, can you clarify what's wrong about that piece of code?

[LovelySanta]

As I'm reading this, these lines will return a component count of 9 and 12 respectivly, which, i think is correct?

Hazel/Hazel/src/Hazel/Renderer/Buffer.h

Lines 54 to 55 in 3c14780

	case ShaderDataType::Mat3: return 3 * 3;
	case ShaderDataType::Mat4: return 4 * 4;

But as the OpenGL specification says for the second parameter:

size:
Specifies the number of components per generic vertex attribute. Must be 1, 2, 3, 4. Additionally, the symbolic constant GL_BGRA is accepted by glVertexAttribPointer. The initial value is 4.

Meaning the return value of the GetComponentCount function (as shown above) will result in an error as it returns a value that is higher than 4? Which in that case would result in an error:

GL_INVALID_VALUE:
Generated if size is not 1, 2, 3, 4 or (for glVertexAttribPointer), GL_BGRA.

As I am not sure, my intuition says it is correct, but the documentation clearly states it's not...

Yes, that is the discrepancy I'm referring to. Small correction: it is GetComponentCount() that returns the size, not ShaderDataTypeToOpenGLBaseType.

[philipkatis]

I don't think we would ever even need to send a mat3 or mat4 as vertex buffer attribute.

[rijenkii]

Also, bool can't be a vertex buffer attribute

[Puddlestomper]

I would like to point out this information from the OpenGL specification.

I would also like to point out that Buffer.h is part of our RendererAPI independent code and it might be standard in other APIs to provide the full size (I don't know other APIs so I can't say for sure). In that case this can stay as is and should be handled as a special case on the OpenGL side of the code.

Either way there should probably be specific code on the OpenGL side to handle the case for matrices properly.

[LovelySanta]

I would like to point out this information from the OpenGL specification.

I would also like to point out that Buffer.h is part of our RendererAPI independent code and it might be standard in other APIs to provide the full size (I don't know other APIs so I can't say for sure). In that case this can stay as is and should be handled as a special case on the OpenGL side of the code.

Either way there should probably be specific code on the OpenGL side to handle the case for matrices properly.

Yes, the function itself is correct, but it is still an error that OpenGL is using this. So it is still a valid issue, we just need an OpenGL solution for this