Hi,
I’ve been having a look at the OpenGL pipeline and something strikes me as odd. As I understand it world data is projected to the unit cube by the projection matrix, clipped, and then put into viewing co-ordinates by the viewport matrix.
However, would it not be better if clipping were performed after the data is in viewing co-ordinates? Admitadly the clipping planes would have strange values such as 1024 instead of 1, but they will still be axis aligned so it shouldn't be any slower (from my limited knowledge of how the algorithms work).
If this were done would it not allow the projection and viewport matrices to be combined into one, thereby eliminating one matrix multiplication per vertex per frame?
Presumably there is a good reason why this is not done, perhaps there is another task performed between the two matrix multiplications which I don't know of? Or maybe it's just for flexibility?
Anyone have any ideas?
Regards,
David
Just because the pipeline is described in some specific language, doesn’t necessarily mean that those very operations are performed by the hardware.
Anyway, if you had to re-scale your projection matrix when you re-scaled your viewport, that’d mean you’d have to re-specify your clipping planes in a new coordinate frame. That seems inconvenient.
Just because the pipeline is described in some specific language, doesn’t necessarily mean that those very operations are performed by the hardware.
By which you presumably mean there is some freedom on the part of the implementers to change the order of operations, perhaps to use optimisations such as the one I mentioned?
I must admit I don’t know how tightly the OpenGL specification controls such aspects as these.
Anyway, if you had to re-scale your projection matrix when you re-scaled your viewport, that’d mean you’d have to re-specify your clipping planes in a new coordinate frame. That seems inconvenient.
I’m not sure that is true. I agree the product of the projection and viewport matrices would have to be re-calculated, but a copy of the projection matrix could just be stored. It doesn’t need to change just because the viewport does.
Besides, surely it would be worth it if it speeds up the pipeline. That said, I don’t know how significant one matrix multiplication per vertex is relative to the other operations that are performed on it. Maybe it’s simply not worth the effort.
As far as I understand its done in clipspace, because there you can still linearily interpolate texturecoordinates for clipped polygons, which is not true in perspective distorted viewspace. Please correct me on this if I´m wrong.
The OpenGL spec describes how OpenGL hardware should behave from a programmer’s point of view. And to some extent, from an implementor’s point of view. Implementors may make different decisions about how to organize the graphics pipeline, but the programmer’s view should remain consistent.
Speaking from an implementor’s perspective, there is a lot of design freedom in OpenGL. And there have been lots of fascinating, diverse hardware designs, each clever in different ways with unique pros and cons.
To your specific question of where-to-clip, it could easily be done in window coordinates instead of homogeneous clip coordinates. There are some advantages to doing it in homogeneous clip coordinates, though. You compare -wc <= {xc,yc,zc} <= wc. This makes computation of the clipped wc convenient which need for perspective correction. If you want to do clipping after the perspective divide (non-homogeneous clip space - AKA Normalized Device Coordinates or NDC, or non-homogeneous window space) you need to keep around 1/wc for the non-clipped vertexes and clip it just like you do for all the other interpolated attributes (again, for perspective correction). Working in this canonical “clip space” simplifies the clipping hardware somewhat too.
And, of course, there are still other ways to skin that cat.
