Advertisement

Normalising Ranges to -1 to 1

Started by March 21, 2019 03:16 PM
7 comments, last by calioranged 5 years, 5 months ago

glm::mat4 proj = glm::ortho(0.0F,960.0F,0.0F,540.0F,-1.0F,1.0F);
glm::vec4 vp(100.0F, 100.0F, 0.0F, 1.0F);
glm::vec4 result = proj * vp;

How exactly are these calculations performed? What is the actual equation.

The actual call is in glm/gtc/matrix_transform.inl.


template <typename T>
	GLM_FUNC_QUALIFIER tmat4x4<T, defaultp> ortho
	(
		T left,
		T right,
		T bottom,
		T top,
		T zNear,
		T zFar
	)
	{
		tmat4x4<T, defaultp> Result(1);
		Result[0][0] = static_cast<T>(2) / (right - left);
		Result[1][1] = static_cast<T>(2) / (top - bottom);
		Result[2][2] = - static_cast<T>(2) / (zFar - zNear);
		Result[3][0] = - (right + left) / (right - left);
		Result[3][1] = - (top + bottom) / (top - bottom);
		Result[3][2] = - (zFar + zNear) / (zFar - zNear);
		return Result;
	}

 

I've always liked http://www.opengl-tutorial.org/beginners-tutorials/tutorial-3-matrices/ for a refresher.

Advertisement

This stuff is so hard to get a grasp of as a beginner. I haven't yet managed to understand any of the tutorials I have been following, including that one.

What do the two array operators represent ?


[i][i]

 

And why is there no [3][3]

Don't feel bad. Been playing this game for a while and still have trouble with the divide by w concept.

Give this [ guy ] a listen. Maybe not do his software rendering tutorial series but at least watch. Well worth the time.

Thanks a lot.

Advertisement
1 hour ago, calioranged said:

And why is there no [3][3] 

Because it's not being changed from the value set in the constructor. The same with the other missing values.

1 hour ago, calioranged said:

And why is there no [3][3]

The starting matrix is the identity matrix, a 4x4 matrix that has zeros except for the [0][0] to [3][3] diagonal which is all ones. Not all elements need to be computed.

The ortho (or persp) matrix takes vertices (naively one at a time) from the scene and smashes them onto a plane based on the camera location ( this is only somewhat true, the w is passed to the shader as a divisor to calculate the final location ). The equations (in the form of a matrix) are derived from the camera settings.

If your camera is centered and symmetrical, the equations are fairly easy for an ortho camera.

r l t b f n are right left top bottom far near

from http://www.songho.ca/opengl/gl_projectionmatrix.html

gl_projectionmatrix_eq25.png

🙂🙂🙂🙂🙂<←The tone posse, ready for action.


glm::mat4 proj = glm::ortho(0.0F,960.0F,0.0F,540.0F,-1.0F,1.0F);
glm::vec4 vp(100.0F, 100.0F, 0.0F, 1.0F);
glm::vec4 result = proj * vp;

bROb5qAlkFK2chOCC3n0kn8F76UIrXlhUWY8agmoqLcaKgJtg8paKma2cHIuxtxWYQUocbzdqrf1zdSwlZGn688qU6TLMpnpxa35oNok0skDOdSacl3OApzctIR_95G19BpPeuoZd6M

After multiplying the above matrix by the vector of x,y,z,w coordinates, I can now see how the normalisation works:

X: ((2/960-0)*100)+(0*100) + (0*0) + ((-960+0/960-0)*1) = −0.7916666667

Y: (0*100)+((2/540-0)*100) + (0*0) + ((-540+0/540-0)*1) = −0.6296296296

Z: (0*100)+(0*100) + ((-2/1--1)*0) + ((- 1+-1/1--1)*1) = 0.0

W: (0*100)+(0*100)+(0*0) + (1*1) = 1.0

But how are the matrix elements decided in the first place? For example why is (2/right-left) in the top left corner, why is           (- right+left/right-left) in the top right corner. Is there a computation before hand that determines where these matrix elements are placed?

This topic is closed to new replies.

Advertisement