Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


#Actualhaegarr

Posted 01 January 2013 - 04:42 AM

There are several minor and major issues with your code as well as some lack of information to verify the code. In the order they came to my attention:
 
1. The 2nd argument of createView is named "dir". That connotes a direction. But it is set and interpreted as a position. The usual name for that parameter is "lookAt" or something similar.
 
2. Initializing mat and invView to be the identity matrix is needless.
 
3. How does "sub(dir, pos)" work? It should be "dir minus pos".
 
4. How does "crossProd(up, &rowZ)" work, and do you use a LHS or RHS? In other words, is the order of up and rowZ correct? Edit: I would expect it to be "rowZ cross up"...
 
5. Normalizing rowY after setting it to a constant is needless, not to say that it must not work at all because rowY has the length of zero at that moment!
 
6. Setting "up" as-is as rowY of the matrix is wrong. Instead, rowY needs to be computed by a cross product using the computed rowX and rowZ. Otherwise you don't respect pitching and the rotation matrix will be corrupted.
 
7. Do you use column or row vectors? Calling "setRowv" hints at row vectors. Correct?
 
8. Naming the result "invView" is misleading. In fact, you store the camera's local-to-global frame matrix in "mat", so that computing its inverse yields in what is usually called the view matrix: In other words: The camera matrix is the inverse view matrix, and the inverse camera matrix is the (standard) view matrix.

#1haegarr

Posted 01 January 2013 - 04:24 AM

There are several minor and major issues with your code as well as some lack of information to verify the code. In the order they came to my attention:

 
1. The 2nd argument of createView is named "dir". That connotes a direction. But it is set and interpreted as a position. The usual name for that parameter is "lookAt" or something similar.
 
2. Initializing mat and invView to be the identity matrix is needless.
 
3. How does "sub(dir, pos)" work? It should be "dir minus pos".
 
4. How does "crossProd(up, &rowZ)" work, and do you use a LHS or RHS? In other words, is the order of up and rowZ correct?
 
5. Normalizing rowY after setting it to a constant is needless, not to say that it must not work at all because rowY has the length of zero at that moment!
 
6. Setting "up" as-is as rowY of the matrix is wrong. Instead, rowY needs to be computed by a cross product using the computed rowX and rowZ. Otherwise you don't respect pitching and the rotation matrix will be corrupted.
 
7. Do you use column or row vectors? Calling "setRowv" hints at row vectors. Correct?
 
8. Naming the result "invView" is misleading. In fact, you store the camera's local-to-global frame matrix in "mat", so that computing its inverse yields in what is usually called the view matrix: In other words: The camera matrix is the inverse view matrix, and the inverse camera matrix is the (standard) view matrix.
 

PARTNERS