3
\$\begingroup\$

I'm debugging a lighting problem where the camera position is effecting the diffused lighting component on my 3d model. In researching my problem I went back and am reading over all the how to documents. I found that one of my old sources (where I learned open gl 2.0) said this (summarized):

When creating the modelViewProjection matrix you can't change the order or you'll get unexpected results. First take the View Matrix and post-multiply it by the projection matrix to create a viewProjection matrix. Then post-multiply the model matrix to get the modelViewProjection matrix.

Looking at my code, all this time I haven't been doing this:

matrixMultiply(mView, thisItem->objModel, mModelView);
matrixMultiply(mProjection, mModelView, mModelViewProjection);

As a test I tried changing it to this:

matrixMultiply(mView, thisItem->objModel, mModelView);
matrixMultiply(mProjection, mView, mViewProjection);
matrixMultiply(mViewProjection, thisItem->objModel, mModelViewProjection);

...but the result appears the same.

EDIT: To answer a question about what the matrices contain. A snapshot of the matrix values:

Model Matrix

View Matrix

Projection Matrix

EDIT2: As a test I did the math both ways to compare the results and even with moving the camera and model around and rotating the model I'm getting the same results for the final ModelViewProjection.

\$\endgroup\$
  • \$\begingroup\$ Is one of the matrices a noop (identity matrix)? Then order wouldn't matter... \$\endgroup\$ – david van brink Dec 16 '14 at 2:15
  • \$\begingroup\$ I added a snapshot of the data. The View is almost identity but there's a -160.0 for the camera z. \$\endgroup\$ – badweasel Dec 16 '14 at 2:40
  • \$\begingroup\$ camera position is effecting the diffused lighting component -> perhaps the problem is not in matrix math but in your lighting calculations? In wat coordinate system are you passing in light position and in what coordinate system is the calculations done? \$\endgroup\$ – user55564 Dec 16 '14 at 2:49
  • \$\begingroup\$ This was a rabbit hole in trying to solve that. I mentioned it just in case it was connected. Because I do pass modelView to the shader as a normalMatrix. I'm working up that question as a separate post and will link to it here in a few minutes. Thanks. \$\endgroup\$ – badweasel Dec 16 '14 at 2:52
  • \$\begingroup\$ The correct MVPmatrix is = projection * view * model which means do model * view then mv * projection. The order of operation matters and maybe you should try switching the order of arguments in your matrixMultiply calls. matrixMultiply(mView, thisItem->objModel, mModelView); to matrixMultiply(mView, mModelView, thisItem->objModel); Also see opengl-tutorial.org/beginners-tutorials/tutorial-3-matrices \$\endgroup\$ – user55564 Dec 16 '14 at 3:08
3
\$\begingroup\$

It depends on the implementation of the multiply operation. The internals will suppose an ordering within your matrices, row major or column major. If the ordering of your matrices is arranged the way the function expects them, then it is up to the second dpendancy: namely the respect of the correct mathematical commutativity. (which they should)

When you have these 2 conditions, then your multiplication order is the reverse of the pipeline. Therefore you do totalmat = proj * view * model.

If ever your matrices were to be transposed, you need to reverse this application order. Whenever one component of what I mentioned before is opposed, it commutes the multiplication.

| improve this answer | |
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.