flexible projection matrix

[A027298]

Hi graphics people!!!

What I want to do is to calculate a projection matrix, where I can specify any orientation for the near plane. This means, I want to be able to rotate the near plane of my viewing volume.

I looked at Foley and tried to derivate it from his 6 steps, but it doesn' really work. Currently I am doing it like this:

1) I calculate the u,v,n -axis. I think this works. It gives me the following Matrix:

       ux uy uz 0
   R = vx vy vz 0
       nx ny nz 0
       0  0  0  1

(With the n-axis I specify the orientation with the near plane and calculate the u- and v-axis according to the n-axis)

2) after that I convert the frustum to the symmetric frustum by a shear transformation

   shx = (left + right) / (2 * near)
   shy = (bottom + top) / (2 * near)
 
       1  0 shx 0
   H = 0  1 shy 0
       0  0  1  0
       0  0  0  1

3) Here I scale the sides to: x = +/-z, z = -far, z = -near
The required scaling matrix is therefore:

   xscale = 2 * near / (left - right)
   yscale = 2 * near / (top - bottom)
   zscale = 1
 
       xscale 0      0      0
   S = 0      yscale 0      0 
       0      0      zscale 0
       0      0      0      1

4) In this step I transform the far plane to the plane z = +1 and the near plane to z = -1 using projection normalization.

   a = -(far + near) / (far - near)
   b = (-2 * far * near) / (far - near)
 
       1  0   0  0
   N = 0  1   0  0
       0  0   a  b
       0  0  -1  0

With multiplication of the matrices above I should get my projection matrix, with a flexible near plane:

P = N * S * H * R

But it doesn't work. I think that something is wrong with the rotation part. But I just did it like Foley. Without the last multiplication by R, it's just like the normal OpenGL projection matrix.

It would be so cool if somebody of yous could give me a suggestion to this, because it should be possible.

Thanks!!!

[This message has been edited by A027298 (edited 11-26-2002).]

[pkaler]

Originally posted by A027298:

4) In this step I transform the far plane to the plane z = +1 and the near plane to z = -1 using projection normalization.

Hmm, don't the coordinates range from -1..+1 after clipping and division by w, and range from 0..1 before then?

[A027298]

as far as I know the near plane should be after projection-normalization at z = -1 and the far plane at z = 1.

[Madoc]

I worked on this some time ago and came up with a solution which works with the far clipping plane at infinity, which is what I wanted. I was going to research it some more and perhpas post it to this site but I really haven't had the time (Cass Everitt and I thought about it somewhat but our early efforts didn't yeld much).
Anyway, clear or not, this works:

P[0][2] = a
P[1][2] = b
P[2][2] = c + 1
P[3][2] = -d

I worked out some scale factors to always make full use of the NDC range under this formulation but they're a bit messy and pointless really.

[A027298]

But do you agree, that the Foley version doesn't work very well on that?

PS What is a, b, c, d?

[This message has been edited by A027298 (edited 11-29-2002).]

[dorbie]

Almost everyone who asks for this is making fundamental mistake about matching projection to display. What is it you want to do? Generally you don't require a tilted near plane even for seemingly complex display setups. The view vector can always be maintained at right angles to the viewing plane in conjunction with modelview adjustments to match any planar display.

[Madoc]

a, b, c and d are simply the components of the plane equation.
I haven't seen Foley's work so I can't tell you much, I wasn't actually aware that someone had done this before. In fact, if the problem is covered in depth I might find it useful to clarify a few points and perhaps arrive at some more advanced applications I have in mind, what's the name of the pubblication?

Dorbie,
I imagine the poster is wanting to use the near pane as an arbitrary clipping pane, seeing as user clip panes on consumer hardware are problematic and slow. You can do this by changing the modelview matrix but it will screw up fog and lighting, possibly more.

[jwatte]

Madoc,

Foley, van Dam et al: Computer Graphics, practice and principle
(hope I got that right)

This has been the graphics "bible" for over ten years. It starts at "how to put a pixel on the screen" and ends at describing the state of the art in off-screen rendering in the very early nineties. It's still fairly relevant, and thorough on the needed basics. It covers things like the rendering pipeline transforms in a fair bit of detail.

Unfortunately, it seems to like scene graphs (SPHIGS, etc) better than raster APIs (GL). Oh, well, academics are often like that; you can't really fault them for it ;-)

[A027298]

Thanks Madoc. It works fine. I had something similar. But I think thats not the exact mathematical solution. The version I posted above is similar to Foley's.

@dorbie
I think I understood how projection matching to display. But since projective transformations are involved in that, the projection matrix is more appropriate.

Yes Foley's book is the 'bible' of computer graphics. But you know, in theory everything works fine. If you want to put something to application it sometimes doesn't work so easily like in theory. I think Foley never put one of his algorithms really in application or at least not all of his 'bible'-topics.

Thanks for your posts.