Hi, community.

I wrote a new article about Perspective Projection Matrix Generation (Part 2 of this article)

The post is the following

https://nbertoa.wordpress.com/2017/01/13/how-can-i-find-the-pixel-space-coordinates-of-a-3d-point-part-2-perspective-projection-matrix-generation/

I tried to explain in detail about its generation and answer several question I had in the process.

If you have any suggestions (things to add, modify, things that are wrong, corrections, etc) please let me know, because the intention of this post (in addition to helping people with the same doubts than me) is to learn if my knowledge is correct or not.

Hope you find it useful!

I only skimmed it, but one thing you may want to add: D3D uses the convention that the NDC z axis ranges from 0.0 to 1.0, but OpenGL uses the convention that the NDC z axis ranges from -1.0 to 1.0... So OpenGL users must construct their projection matrices differently.

Also, it's standard practice these days to map the far-plane to 0.0 and the near-plane to 1.0, as this gives better numerical precision due to quirks of floating point encoding -- the perspective division biases precision towards the near plane, and floating point numbers bias precision towards 0. With the typical mapping of near=0, this gives waaaaay too much precision at the near plane, and absolutely terrible precision at the far plane. With the alternative mapping of near=1, these two biases mostly cancel each other out and you end up with a mostly linear distribution of precision from near to far.

I only skimmed it, but one thing you may want to add: D3D uses the convention that the NDC z axis ranges from 0.0 to 1.0, but OpenGL uses the convention that the NDC z axis ranges from -1.0 to 1.0... So OpenGL users must construct their projection matrices differently.

I explained that in Part 1, but it will be useful to repeat that in Part 2 too. Thanks!

Also, it's standard practice these days to map the far-plane to 0.0 and the near-plane to 1.0, as this gives better numerical precision due to quirks of floating point encoding -- the perspective division biases precision towards the near plane, and floating point numbers bias precision towards 0. With the typical mapping of near=0, this gives waaaaay too much precision at the near plane, and absolutely terrible precision at the far plane. With the alternative mapping of near=1, these two biases mostly cancel each other out and you end up with a mostly linear distribution of precision from near to far.

Thanks for that suggestion. I planned to talk about it in the next post about depth buffer, but I will mention this stuff in the part I want to map [nZ, fZ] ---> [0.0, 1.0]