## Re: [Algorithms] More on frustum plane extraction

 Re: [Algorithms] More on frustum plane extraction From: Nicolas Serres - 2001-03-31 00:22:05 ```> Well, it comes down to the question "what are the z clip space inequalties > for D3D?" > [...] > But then I thought they changed them to: > -w But I really don't know. You said near was working, but far was not. If > that is the case then both of these are the same for zfar. What numbers > are you getting? It works like a charm if you use a "standard'" projection matrix.. I suspect Mark's matrix is not a standard one; that it includes a transformation from a right-handed world into d3d left handed coordinate system. If so, flipping z should be enough to get the (not yet normalized) far plane equation.. Basically, it means that instead of C=C4-C3 for C.V, you have C.x=C4.x-C3.x C.y=C4.y-C3.y C.z=C3.z-C4.z <-- here C.w=C4.w-C3.w Nicolas ```

 [Algorithms] More on frustum plane extraction From: Mark Wayland - 2001-03-30 00:20:24 ```Actually the title should read "moron using frustum plane extraction" :) As you can assume by the previous sentence, I was wondering if any of you kind folk out there may be able to help with the frustum plane extraction problem I'm having (Gil?) I have some code which successfully extracts the left, right, top and bottom planes but for some reason has a problem with the near and far. Actually, I think the near is working too, but it's a little hard to test at the moment. The far plane seems to be the problem. Firstly, I'm using D3D not OpenGL. That places the restriction on the homogenous z' being 0 < z' < 1. I believe in OpenGL this is expressed as -w' < z' < w' which is where my difficulty comes in. I thought I understood the math behind it, thanks to Gil's explanation, so I derived my own equations to be sure - the left, right, top, bottom and near seem to work... Anyway, here's my derivation for the (near and) far clip plane. Can someone show me where I went wrong? I've even tried using the eqn 0 < z' < w'. At this point, i'm thoroughly confused so any advice would be very welcome :) in = [x y z 1] Cn = nth column in view-projection matrix. These basically represent a 4x4 matrix transformation: x' = in dot C1 y' = in dot C2 z' = in dot C3 w' = in dot C4 For NEAR and FAR planes, must satisfy following constraint to be in frustum (in D3D terms): 0 < z' < 1 For NEAR, 0 < z' => z' >= 0 Substituting z' = in dot C3, we get: in dot C3 >= 0 So the plane equation is simply C3... For FAR, z' < 1 => z' - 1 < 0 => 1 - z' >= 0 Substituting z' = in dot C3, we get: 1 - (in dot C3) >= 0 Now we need the equation in the form of in dot P, so we rearrange to give: in dot ( [0 0 0 1] - C3 ) >= 0 So the plane equation is [0 0 0 1] - C3 if the equation should be 0 < z' < w', then w' - z' >= 0 (in dot C4) - (in dot C3) >= 0 in dot (C4 - C3) >= 0 Plane equation in this case is C4 - C3 I've tried both and only the near plane equation seems correct. Any suggestions? Thanks a heap, Mark ```
 Re: [Algorithms] More on frustum plane extraction From: Gil Gribb - 2001-03-30 13:54:16 ```Well, it comes down to the question "what are the z clip space inequalties for D3D?" I thought they used to be: 0 To: Sent: Thursday, March 29, 2001 6:21 PM Subject: [Algorithms] More on frustum plane extraction > Actually the title should read "moron using frustum plane extraction" :) > > As you can assume by the previous sentence, I was wondering if any of you > kind folk out there may be able to help with the frustum plane extraction > problem I'm having (Gil?) > > I have some code which successfully extracts the left, right, top and > bottom planes but for some reason has a problem with the near and far. > Actually, I think the near is working too, but it's a little hard to test at > the moment. The far plane seems to be the problem. > > Firstly, I'm using D3D not OpenGL. That places the restriction on the > homogenous z' being 0 < z' < 1. I believe in OpenGL this is > expressed as -w' < z' < w' which is where my difficulty comes in. > > I thought I understood the math behind it, thanks to Gil's explanation, > so I derived my own equations to be sure - the left, right, top, bottom > and near seem to work... > > Anyway, here's my derivation for the (near and) far clip plane. > Can someone show me where I went wrong? > I've even tried using the eqn 0 < z' < w'. At this point, i'm > thoroughly confused so any advice would be very welcome :) > > in = [x y z 1] > Cn = nth column in view-projection matrix. > > These basically represent a 4x4 matrix transformation: > > x' = in dot C1 > y' = in dot C2 > z' = in dot C3 > w' = in dot C4 > > For NEAR and FAR planes, must satisfy following constraint to be in frustum > (in D3D terms): > > 0 < z' < 1 > > For NEAR, 0 < z' => z' >= 0 > Substituting z' = in dot C3, we get: > > in dot C3 >= 0 > > So the plane equation is simply C3... > > For FAR, z' < 1 => z' - 1 < 0 => 1 - z' >= 0 > Substituting z' = in dot C3, we get: > > 1 - (in dot C3) >= 0 > > Now we need the equation in the form of in dot P, so we rearrange > to give: > > in dot ( [0 0 0 1] - C3 ) >= 0 > > So the plane equation is [0 0 0 1] - C3 > > if the equation should be 0 < z' < w', then > > w' - z' >= 0 > (in dot C4) - (in dot C3) >= 0 > in dot (C4 - C3) >= 0 > > Plane equation in this case is C4 - C3 > > I've tried both and only the near plane equation seems correct. > Any suggestions? > > Thanks a heap, > > Mark > > _______________________________________________ > GDAlgorithms-list mailing list > GDAlgorithms-list@... > http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list ```
 Re: [Algorithms] More on frustum plane extraction From: Nicolas Serres - 2001-03-31 00:22:05 ```> Well, it comes down to the question "what are the z clip space inequalties > for D3D?" > [...] > But then I thought they changed them to: > -w But I really don't know. You said near was working, but far was not. If > that is the case then both of these are the same for zfar. What numbers > are you getting? It works like a charm if you use a "standard'" projection matrix.. I suspect Mark's matrix is not a standard one; that it includes a transformation from a right-handed world into d3d left handed coordinate system. If so, flipping z should be enough to get the (not yet normalized) far plane equation.. Basically, it means that instead of C=C4-C3 for C.V, you have C.x=C4.x-C3.x C.y=C4.y-C3.y C.z=C3.z-C4.z <-- here C.w=C4.w-C3.w Nicolas ```
 Re: [Algorithms] More on frustum plane extraction From: Gil Gribb - 2001-03-31 00:38:54 ```> I suspect Mark's matrix is not a standard one. It should not matter. The derivation only relies on the clip space inequaties. There is no assumtions on the matrices at all. I'd like to see some numbers to diagnose the problem. -Gil > > Well, it comes down to the question "what are the z clip space inequalties > > for D3D?" > > [...] > > But then I thought they changed them to: > > -w > It is definitely 0 Just take the matrix from "what is the projection transformation" help page, > if you want to be sure, and transform [0,0,Zn,1] > > On the other hand, open gl, and "some hardware with a nice clipping > instruction" use the -w another was a real pain for my brain :-) > > > But I really don't know. You said near was working, but far was not. If > > that is the case then both of these are the same for zfar. What numbers > > are you getting? > > It works like a charm if you use a "standard'" projection matrix.. > > I suspect Mark's matrix is not a standard one; that it includes a > transformation from a right-handed world into d3d left handed > coordinate system. If so, flipping z should be enough to get the > (not yet normalized) far plane equation.. > > Basically, it means that instead of C=C4-C3 for C.V, you have > C.x=C4.x-C3.x > C.y=C4.y-C3.y > C.z=C3.z-C4.z <-- here > C.w=C4.w-C3.w > > Nicolas > > > _______________________________________________ > GDAlgorithms-list mailing list > GDAlgorithms-list@... > http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list ```