View more

View more

View more

### Image of the Day Submit

IOTD | Top Screenshots

### The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.

# Transform matrix application order

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

5 replies to this topic

### #1NickWiggill  Members

Posted 06 July 2012 - 12:19 PM

I'm building my first OpenGL demo to incorporate into the game I'm writing. I wonder if you gentlefolk might help clarify the transformation process for me. I have a basic vertex and fragment shaders up and running already.

Here's what I see as the method for getting 3D objects perspective-transformed to screen:

(pseudocode)


On update:

Create the camera matrix: c = camRotation * camTranslation
Create the view matrix by inverting the camera matrix: v = c^-1
Create the projection matrix using the standard perspective projection matrix terms
Create view-projection matrix: vp = p * v

For each entity
Create a model matrix using entity world position, rotation, and scale values
Multiply this specific entity's world transform matrix (the model matrix): mvp = vp * m
Set mvp as a uniform for vertex shader
glDrawElements(...);


Queries:
• What options do I have to reduce the number of draw calls? Merging static geometry into a single vertex list using a common texture atlas seems to be the only option?
• Re the MVP matrix above, why do some sources present the final matrix value as -1, and others as 1? What should I use?
Any other tips, suggestions on this structure welcome.

Primary references:

OpenGL wiki page on viewing and transformations
Joe Groff's tutorial on transformation and projection

Edited by NickWiggill, 06 July 2012 - 01:50 PM.

### #2larspensjo  Members

Posted 06 July 2012 - 12:43 PM

The order of the projection-view matrix is wrong. It shall be Proj*view. So the MVP matrix would be P*V*M. Some of this is done in the shader, some is not. It depends on the complexity of your design. The shader is much faster to compute this, but if a result stays the same for every pixel, then you might as well do it in the main application before sending it to the shader. You don't need a "window matrix", it is included in the projection matrix.

The vertex shader now need to compute PVM*v, for each vertex 'v'.
Current project: Ephenation.
Sharing OpenGL experiences: http://ephenationopengl.blogspot.com/

### #3NickWiggill  Members

Posted 06 July 2012 - 01:03 PM

Hi larspensjo,

Thanks for clarifying, I've updated the question by removing the reference to the "window" matrix.

Also could you confirm the order then, for matrix multiplication:
[source lang="java"]modelViewMatrix = viewMatrix * modelMatrix; //??modelViewProjectionMatrix = projectionMatrix * modelViewMatrix; //??[/source]

...Assuming matrix mul() ordering is thisMatrix * otherMatrix?

Edited by NickWiggill, 06 July 2012 - 01:03 PM.

### #4larspensjo  Members

Posted 06 July 2012 - 01:41 PM

Hi larspensjo,

Thanks for clarifying, I've updated the question by removing the reference to the "window" matrix.

Also could you confirm the order then, for matrix multiplication:
[source lang="java"]modelViewMatrix = viewMatrix * modelMatrix; //??modelViewProjectionMatrix = projectionMatrix * modelViewMatrix; //??[/source]

...Assuming matrix mul() ordering is thisMatrix * otherMatrix?

Confirmed. If you are using C++, I recommend the package glm. It is a matrix manipulation package, with a syntax close to the shader language.
Current project: Ephenation.
Sharing OpenGL experiences: http://ephenationopengl.blogspot.com/

### #5NickWiggill  Members

Posted 06 July 2012 - 01:52 PM

Ah, many thanks. Updated again with the multiplication order. This should allow me to proceed. I hope you have a good weekend too

### #6scniton  Members

Posted 06 July 2012 - 09:01 PM

Personally, I find this reference helpful: www.songho.ca/opengl/gl_transform.html

You could split up the modelview matrix into two parts, and so you would transform your vertices using your model matrix first, and then by your view matrix.

I like thinking in terms which order the transformations are applied, then afterwards rearrange things to match the multiplication order I am working with (i.e. "pre" or "post" multiplication.)

Edited by scniton, 06 July 2012 - 09:15 PM.