# directx matrices

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

## Recommended Posts

in my app i need to set the projection matrix myself (meaning i CAN'T use D3DXMatrixPerspectiveFovLH) i went to the documentation that comes with directx and read about D3DXMatrixPerspectiveFovLH and this is what they say:
 xScale     0          0               0
0        yScale       0               0
0          0       zf/(zf-zn)         1
0          0       -zn*zf/(zf-zn)     0
where:
yScale = cot(fovY/2)

xScale = aspect ratio / yScale


when i use it it seems to be completely wrong! i can only make it work this way: Change #1: i do xScale = yScale / aspect ratio (and not the other way as they say) Change #2: i negate xScale. that's the only way i get visual output, but i get it ofcourse mirrored on the x axis ... can anyone here please help me on this ?

##### Share on other sites
cot(x) = 1 / tan(x). Do you do it that way ?
I ask because the first time I read this I thought cot(x) was a typo and that it was cos(x).

I also found this one :
h = cos(fov/2) / sin(fov/2);w = h / aspect;2*zn/w  0       0              00       2*zn/h  0              00       0       zf/(zf-zn)     10       0       zn*zf/(zn-zf)  0

##### Share on other sites
like you, for cot i used cos/sin.

i'll try the projection matrix you offered, i hope it will work ;)

thanks :)

##### Share on other sites
The matrix you got from D3DXMatrixPerspectiveFovLH looks correct. Make sure you are doing the multiplying correctly. It seems that for some reason your code works when you multiply by the inverse (or something like that) of the projection matrix.

BTW, why can't you use D3DXMatrixPerspectiveFovLH?

##### Share on other sites
The reason i need to use the directx matrix is that my engine supports both directx and opengl, being that way the engine is an abstraction above both of those graphcis apis, so i want both outputs to be perfectly identical so i want to completely control what happens inside all the projection/modelview etc...

##### Share on other sites
Are you aware that GL and D3D utilize different matrix representations, and if so are you correctly compensating?

##### Share on other sites
The projection matrices for OpenGL and DirectX are different because the locations of the clip space planes are different.

##### Share on other sites
Quote:
 Original post by RavyneAre you aware that GL and D3D utilize different matrix representations, and if so are you correctly compensating?

i'm aware that it's left handed verses right handed, and i negate the z value of coordniates, but nothing more.

am i missing something ?

##### Share on other sites
Yes, AFAIK OpenGL matrices are in column-major form, where the translation components tx, ty, tz occupy elements 13, 14 and 15 of the matrix (with respect to a 16 element, single-dimentional array containing the matrix).

DirectX, on the other hand, uses row-major form, where the translation components tx, ty, tz occupy elements 4, 8 and 12 of the matrix. D3D matrices are the transpose of equivilant GL matrices.

| 01 02 03 04 |
| 05 06 07 08 |
| 09 10 11 12 |
| 13 14 15 16 |

##### Share on other sites
Also note that the screen-space z-axis bounds are different between OpenGL and DirectX (as indicated by JohnBolton)

In DirectX the near-plane is z = 0 and the far-plane is z = 1
In OpenGL the near-plane is z = -1 and the far-plane is z = 1

I can't remember the exact changes you have to make to the projection matrix to account for this but they're fairly simple (a sign change and a multiplication if I remember correctly).

##### Share on other sites
Quote:
 Original post by RavyneDirectX, on the other hand, uses row-major form, where the translation components tx, ty, tz occupy elements 4, 8 and 12 of the matrix. D3D matrices are the transpose of equivilant GL matrices.| 01 02 03 04 || 05 06 07 08 || 09 10 11 12 || 13 14 15 16 |
Not quite. D3D uses row vectors, so the translation components are in 13, 14, and 15 (just like OpenGL).

[Edited by - JohnBolton on December 1, 2005 12:21:19 PM]

##### Share on other sites
John, if this is correct (and not to question your knowledge... My confusion stems from the fact that GL and D3D docs explicitely state the use of column-major and row-major respectively.) could you explain more or provide some links? Can anyone confirm/explain?

Perhaps this stems from how vector/matrix multiply is defined in these APIs? IIRC:

GL:
[Matrix]x<col-vec>

D3D:
<row-vec>x[Matrix]

[Edited by - Ravyne on December 1, 2005 4:50:18 PM]

##### Share on other sites
Quote:
 Original post by RavyneMy confusion stems from the fact that GL and D3D docs explicitely state the use of column-major and row-major respectively.) could you explain more or provide some links?

"column-major" and "row-major" refer to the order that matrix elements are stored in memory.

OpenGL is "column-major" so elements are stored in memory in this order:
    0  4  8 12    1  5  9 13    2  6 10 14    3  7 11 15
OpenGL also uses column vector (v' = Mv) notation, so the translation elements of a matrix are 12, 13, and 14.

D3D is "row-major" so elements are stored in memory in this order:
    0  1  2  3    4  5  6  7    8  9 10 11   12 13 14 15
D3D also uses row vector (v' = vM) notation, so the translation elements of a matrix are 12, 13, and 14.

These conventions cause lots of confusion and that's too bad because, in reality, it means that OpenGL matrices and D3D matrices and math libraries are interchangeable as long as you keep the notation straight (i.e. you could use D3DX matrices in an OpenGL app).

##### Share on other sites
Yeah, this has been one of those things that's caused endless confusion. I thought I had it figured out, but appearantly not :) I was going off what I've heard about D3D, but I checked the D3D docs to be sure which *seemed,* at first glance, to support my understanding, of course the use of row vectors was overlooked. Thanks for clearing that up.

And here I thought that whoever made that decision for DirectX must've been braindead for not using columns, thus makeing SIMD optimizations more difficult. I had always attributed that to D3D being a more hardware-oriented API where it could be compensated for. Live and learn :D