Matrix order in bgfx, bgfx' shaderc and inside the shaders

[PowerOfNames]

I want able to find a clear answer to this, so this is just to reassure my assumption:

Bx' simd implementation seems to do matrix multiplication using column multiplication, indicating that bgfx uses the column major convention.

Now how is this in the shaderc implementation? I try to figure out if the matrices get transposed somewhere, because I end up with row major order matrices there.

Thats said, I use glm for my math (default is column major as well) and put them into bgfx using

 bgfx::setViewTransform(m_Specification.BgfxIdx, glm::value_ptr(m_Camera->GetView()), glm::value_ptr(m_Camera->GetProjection()));

I just need a short answer, if you'd be so kind, to rule out some unknown pieces! :)

Thanks!

PS: On that behalve: How does bgfx handle different handedness for the rendering backends? I know that ogl is right,y and vulkan is supposed to be a lefty. Does bgfx change anything here or is it up to the user to write their shaders and math correctly for different APIs, if multiple are in use that have different conventions in use?

[bkaradzic]

You should look at provided examples.

[PowerOfNames]

Where can I find these helpers? Looking through bgfx_shader.sh I dont see them. There are functions to create matrices though

[bkaradzic]

bgfx/src/bgfx_shader.sh

Lines 741 to 813 in a73c12d

	vec3 mtxGetRow(mat3 _mtx, int _row)
	{
	#if BGFX_SHADER_MATRIX_COLUMN_MAJOR
	return vec3(_mtx[0][_row], _mtx[1][_row], _mtx[2][_row]);
	#else
	return vec3(_mtx[_row]);
	#endif // BGFX_SHADER_LANGUAGE_GLSL
	}
	vec3 mtxGetColumn(mat3 _mtx, int _column)
	{
	#if BGFX_SHADER_MATRIX_COLUMN_MAJOR
	return vec3(_mtx[_column]);
	#else
	return vec3(_mtx[0][_column], _mtx[1][_column], _mtx[2][_column]);
	#endif // BGFX_SHADER_LANGUAGE_GLSL
	}
	#if !BGFX_SHADER_LANGUAGE_ESSL
	vec4 mtxGetRow(mat4x3 _mtx, int _row)
	{
	#if BGFX_SHADER_MATRIX_COLUMN_MAJOR
	return vec4(_mtx[0][_row], _mtx[1][_row], _mtx[2][_row], _mtx[3][_row]);
	#else
	return vec4(_mtx[_row]);
	#endif // BGFX_SHADER_LANGUAGE_GLSL
	}
	vec3 mtxGetColumn(mat4x3 _mtx, int _column)
	{
	#if BGFX_SHADER_MATRIX_COLUMN_MAJOR
	return vec3(_mtx[_column]);
	#else
	return vec3(_mtx[0][_column], _mtx[1][_column], _mtx[2][_column]);
	#endif // BGFX_SHADER_LANGUAGE_GLSL
	}
	#endif // !BGFX_SHADER_LANGUAGE_ESSL
	vec4 mtxGetRow(mat4 _mtx, int _row)
	{
	#if BGFX_SHADER_MATRIX_COLUMN_MAJOR
	return vec4(_mtx[0][_row], _mtx[1][_row], _mtx[2][_row], _mtx[3][_row]);
	#else
	return vec4(_mtx[_row]);
	#endif // BGFX_SHADER_LANGUAGE_GLSL
	}
	vec4 mtxGetColumn(mat4 _mtx, int _column)
	{
	#if BGFX_SHADER_MATRIX_COLUMN_MAJOR
	return vec4(_mtx[_column]);
	#else
	return vec4(_mtx[0][_column], _mtx[1][_column], _mtx[2][_column], _mtx[3][_column]);
	#endif // BGFX_SHADER_LANGUAGE_GLSL
	}
	float mtxGetElement(mat3 _mtx, int _column, int _row)
	{
	#if BGFX_SHADER_MATRIX_COLUMN_MAJOR
	return _mtx[_column][_row];
	#else
	return _mtx[_row][_column];
	#endif // BGFX_SHADER_LANGUAGE_GLSL
	}
	float mtxGetElement(mat4 _mtx, int _column, int _row)
	{
	#if BGFX_SHADER_MATRIX_COLUMN_MAJOR
	return _mtx[_column][_row];
	#else
	return _mtx[_row][_column];
	#endif // BGFX_SHADER_LANGUAGE_GLSL
	}

[PowerOfNames]

Ah nice, okay I updated the repo again.

Anyways, looking through the bgfx_shader.sh file, There is this definition-block:

#define BGFX_SHADER_MATRIX_COLUMN_MAJOR (0 \
	|| BGFX_SHADER_LANGUAGE_GLSL           \
	|| BGFX_SHADER_LANGUAGE_WGSL           \
	)

so I suppose all other shader languages are interpreted as row-major than, including spirv.

The spirv-documentation states, that matrices need to be marked with majorCol or majorRow, which means both are valid.

So, using the vulkan backend, I need to use the spirv (I suppose) interpretation. But you said, as long as I'm consistent, everything works fine. I work with col-major matrices, and with the getMtxCol/getMtxRow helper I can do what I want, which is fine, but its confusing in Renderdoc, because one would expect matrices to be in the order you put them in (in the backend)

So, is this just a "flaw" of bgfx you need to learn or is there still something I miss?

Ah, and I suppose one should always also use the mul helper function instead of direct multiplication to work around "unknown" column then order then (just saw that in the docu).

Its just that I still cant quite wrap my head around the multiplication order, because that is to my knowledge dependent on the majority of the matrix, which is a problem if you start programming shaders and expect the matrices to be in the layout you put them in, but they end up in a forced layout (at least for the spirv-case, as for the other languages, the order is set in stone (I think)...

[bkaradzic]

The spirv-documentation states

You're not using SPIR-V directly in bgfx.

Ah, and I suppose one should always also use the mul helper function instead of direct multiplication to work around "unknown" column then order then (just saw that in the docu).

Yep.

Its just that I still cant quite wrap my head around the multiplication order,

I noticed people who are too much into math notation can't understand this. I even had coworker who would argue in lengths about use of mul in memory row order layout because it was better for SIMDification, so I renamed method to be concat matrices, because flipped mul was so much confusing. People who don't even know math, and doing copy and paste from examples trivially go around these issues you're talking about. 😄

Basically you just need to let it be... Put whatever data on CPU, in shader do mul(a, b); and if it doesn't work do mul(b, a); and if it works, just be consistent, and you won't have problems. 😄

[PowerOfNames]

Haha thats funny, but yeah, I feel it ^^

Got it to work in the end. I missed also missed the shaderc documentation (dont know how, sometimes I seem blind).

Thanks for the help!