Jump to content
  • Advertisement
Sign in to follow this  
Nick of ZA

OpenGL Transform matrix application order

This topic is 2200 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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:

  1. Please offer your advice on whether or not the above structure is sensible.
  2. 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?
  3. 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

Share this post


Link to post
Share on other sites
Advertisement
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'.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Ah, many thanks. Updated again with the multiplication order. This should allow me to proceed. I hope you have a good weekend too smile.png

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!