Simple questions as I wrestle with the perspective projection matrix.
First, I am assuming that the "width" of the frustum in the equation is a subset of whatever coordinate "units" I choose to use. To clarify, let's say my world is 1000 to 1000 in the x axis, and that I've decided that my camera should see 100 of these units at the near plane, at z=0. Thus, my understanding is that 100 would be the 'w' in "x(2n/w)" .
Ok, so I haven't really investigated yet how camera space is implemented in a working engine , but my understanding is that mathematically, the camera stays still, and the world is moved around it. This brings me finally to my question.
Why wouldn't one just use units such that 1, to 1 are already the camera's visible coordinates? In my example with a 1000 to 1000 wide world, with a 100 wide viewport at z=0, I would instead have a 10 to 10 wide world, with a 1 to 1 viewport in camera space.
I feel I wrote this clumsily, but the gist is that the math to convert to NDC seems like it could be circumvented if you just used that kind of units to begin with. The only thing I see that wouldn't work is that your FOV couldn't easily be changed.
Am I missing something fundamental?
Projection matrix and NDC
 cyboryxmen
 Posts: 180
 Joined: November 14th, 2014, 2:03 am
Re: Projection matrix and NDC
The perspective projection matrix is more complicated than that. It shrinks and warps objects based on the angle you're looking at them and how far away they are from you. Resizing your world according to Normalised Device Coordinates isn't enough to avoid doing perspective computation.
Zekilk

 Posts: 3978
 Joined: February 28th, 2013, 3:23 am
 Location: Oklahoma, United States
Re: Projection matrix and NDC
Check out chili's 3D Fundamentals tutorials, he covers this stuff actually.
If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves.  gameprogrammingpatterns.com
Re: Projection matrix and NDC
Ok, I should clarify. I'm not talking about the Z divide. Just the conversion to NDC, which is preperspective divide. In an orthographic projection, you do the same thing.

 Posts: 3978
 Joined: February 28th, 2013, 3:23 am
 Location: Oklahoma, United States
Re: Projection matrix and NDC
If I'm understanding you correctly, the NDC coordinates being between 1, 1 for width and height would cause issues for FOV in that monitors aren't square, so yeah. You'd still need to keep the dimensions around to know how many pixels in X and Y directions you are interpolating.
Besides all that, the projection matrix doesn't provide a Z divide, but more of a ratio if I understand it correctly, but stored in the W slot in a 4D vector when the vertex position is transformed. For orthographic projections, W is always equal to 1 whereas in a perspective projection W is like 1/ ( farZ  nearZ or something like that ( based on the view frustum anyway ). This matrix concatenated with the View and World provides a single matrix to do all the transformations in one shot instead of for each vertex. Once the transformations are done, the vertices will be in NDCs. I don't see how you'd be able to bypass the projection because there is still an Object space coordinate system, a World space coordinate system and a View space coordinate system...which would you consider using NDC coordinates with?
Model > World > View > projection ( NDC ) > perspective divide > Screen
You are wanting to cut out an earlier step, and use normalized device coordinates ahead of time, but the View is the inverse camera transform and doesn't have much to do with the dimensions or aspect ratio of the physical screen. The frustum is more tied to the projection matrix than the view matrix...as a matter of fact if you check out the DirectXCollision library , you can create a view frustum from your projection matrix. The BoundingFrustum is used to check if another Bounding type ( BoundingBox, BoundingSphere, etc... ) is in view so you can draw what's in view and skip those that aren't.
Besides all that, the projection matrix doesn't provide a Z divide, but more of a ratio if I understand it correctly, but stored in the W slot in a 4D vector when the vertex position is transformed. For orthographic projections, W is always equal to 1 whereas in a perspective projection W is like 1/ ( farZ  nearZ or something like that ( based on the view frustum anyway ). This matrix concatenated with the View and World provides a single matrix to do all the transformations in one shot instead of for each vertex. Once the transformations are done, the vertices will be in NDCs. I don't see how you'd be able to bypass the projection because there is still an Object space coordinate system, a World space coordinate system and a View space coordinate system...which would you consider using NDC coordinates with?
Model > World > View > projection ( NDC ) > perspective divide > Screen
You are wanting to cut out an earlier step, and use normalized device coordinates ahead of time, but the View is the inverse camera transform and doesn't have much to do with the dimensions or aspect ratio of the physical screen. The frustum is more tied to the projection matrix than the view matrix...as a matter of fact if you check out the DirectXCollision library , you can create a view frustum from your projection matrix. The BoundingFrustum is used to check if another Bounding type ( BoundingBox, BoundingSphere, etc... ) is in view so you can draw what's in view and skip those that aren't.
If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves.  gameprogrammingpatterns.com